The Write-Back Warrant: A Sandbox Trial for AI Actions in UK SaaS

The procurement question has moved on

For the past two years, most UK buyers have assessed generative features in SaaS tools by asking whether the output looked right. That was reasonable when the feature read a record and produced a summary. It is no longer sufficient when the same feature can create a case, update a CRM field, merge duplicate supplier records or draft a purchase order and submit it for approval.

The risk is not primarily that the model writes something inaccurate. It is that the platform now writes something persistent. A wrong summary can be ignored. A wrong merge, a silent field update or an unauthorised status change becomes part of the system of record. It may propagate to downstream reports, trigger payments, alter customer entitlements or distort a regulatory return.

For data and procurement teams, the question is therefore not “how accurate is the assistant?” but “what changed, who approved it, and can the vendor prove it?” That is a data governance question, and it can be tested before production.

Read-only features leave no trace; write-back features leave evidence

A read-only assistant can be evaluated with a set of prompts and a review of outputs. A write-back assistant must be evaluated as an action system. It needs an inventory of actions, a record of each action, an approval path and a recovery route. Without those, the buyer is relying on the vendor’s assurances rather than on evidence.

The first request to any SaaS supplier should be an action inventory. Which objects can the feature create, update, delete, merge or archive? Which actions are automatic, which require a human confirmation, and which are merely proposed? What permissions does the agent use — a named service account, a delegated user identity or a shared integration account? The answer matters because it determines whether the change can be attributed to a person, a role or an opaque process.

Build a sandbox that can be audited

A sandbox trial should use a non-production copy of realistic data. For a UK mid-market firm, that might mean 100 to 200 records drawn from a live export, with identifiers replaced and unusual cases preserved. Include duplicate supplier names, incomplete addresses, dormant accounts, records with conflicting ownership and at least one record that should never be changed.

The trial should be run in a vendor environment that matches the production version. If the vendor cannot provide a sandbox with logging enabled, that is itself a finding. Ask for the change log to be exported at the end of each test day, not merely viewed in a console. A log that cannot leave the platform is difficult to reconcile with internal controls and almost impossible to use in an audit.

Define a small set of test cases in advance. For example: create a new contact from an unstructured note; update a renewal date from an email; merge two duplicate organisation records; change an account status; and propose a purchase order without submitting it. For each case, record the expected outcome, the approval required and the evidence the vendor will provide.

The change log is the deliverable

The change log should be treated as the main output of the trial, not an administrative by-product. At a minimum, it should show the timestamp in UTC, the actor, the action type, the affected record identifier, the before and after values, the approval reference, the feature or model version and a correlation identifier that links related actions.

A useful log also distinguishes between a proposal and a committed change. If the assistant suggested a merge and a human approved it, the log should show both events. If the assistant wrote directly under a service account, the log should make that clear rather than presenting the change as if it came from the user who happened to be logged in.

Reconciliation is the practical test. Export the log and compare it with the actual state of the sandbox records. Count the changes. Check the before and after values. Confirm that every high-risk action has an approver. Look for fields that changed without appearing in the log. A single unexplained field change is a more serious finding than a hundred well-documented proposals.

Acceptance criteria that reflect authority, not fluency

A sandbox trial should end with a pass, fail or conditional pass against written criteria. The following are a reasonable starting point for UK buyers.

• Every write action is recorded in an exportable log with actor, timestamp, before and after values, and approval reference.
• High-risk actions — merges, deletions, status changes and financial commitments — require a named human approver and cannot be completed by the assistant alone.
• The buyer can suspend write-back permissions without disabling the whole platform.
• The vendor can demonstrate a recovery route for each action type, including merge reversal or restoration from a retained snapshot.
• The log is retained for a period that matches the buyer’s records management policy and can be provided in a machine-readable format.
• Changes to the feature’s action set or logging behaviour are notified in advance as a material change.

These criteria are deliberately about control rather than capability. A feature that writes fluently but cannot show its work is not ready for a system of record.

Approval paths are part of the design

Write-back features often fail in production because the approval path was never designed. A trial should show who approves what. Low-risk internal notes might be accepted automatically within a defined scope. A supplier bank detail change should not be. The same tool can support both, but only if the workflow distinguishes them.

For UK organisations, this connects directly to accountability obligations under UK GDPR and to existing internal controls. The buyer needs to know whether the assistant is acting as a tool under human direction or as an autonomous agent with its own permissions. That distinction should appear in the contract, the data protection assessment and the access review.

Put the warranty in the contract

A sandbox trial provides evidence, but the contract should preserve the right to keep receiving it. Ask for audit rights over write-back logs, a commitment to retain them for an agreed period, notice of material changes to action scope, and clarity on liability for unauthorised changes. If the vendor cannot export the log today, a contractual promise to do so later is weak comfort.

The practical conclusion is straightforward. Write-back AI is an authority feature, not a content feature. UK buyers should test it in a sandbox with sample records, a reconciliation exercise and an exported change log before enabling it anywhere near production. The question to settle is not whether the copilot can write back. It is whether the organisation can prove what it wrote, who allowed it and how it can be undone.