Build reassessment into AI procurement

Procurement assesses a particular configuration of a service. A later model replacement, additional tool or retention change can alter the evidence on which the buying decision rested, even when the product name and supplier remain the same.

Include a reassessment path in the procurement decision. Agree the changes that require notice, the evidence the supplier must provide and the owner who can approve continued use. Define the operating choice while a material change is under review.

A procurement discussion, not a new rule

The GDS Responsible AI Advisory Panel’s September 2026 summary reports discussion of how procurement can strengthen transparency, accountability and assurance without creating unnecessary barriers. It also records discussion of assessing AI tutoring tools, including conditions of use and reassessing products as they change. This is a published account of a panel discussion. It is not a new procurement rule or an endorsement of a particular contract clause.

Existing UK government AI procurement guidelines already ask buyers to assess data, benefits, risks and accountability before purchase. The operational extension is to decide when those assessments need to be reopened. A supplier can remain the same legal entity while a model change alters data handling, output quality or the work staff must review.

The earlier article Your model retires before your system does looks at system design across model retirement. This procurement question is about the buyer’s evidence and rights: what must the supplier disclose, and what decision can the buyer take before the changed service reaches users?

Make the change classes concrete

Start with changes that affect the original assessment. A new model family, fine-tuning process, retrieval source, external tool, data retention practice, human handoff or hosting location may each cross a different boundary. A routine security patch need not trigger the same process as a new decision function. Record categories of change and the evidence needed for each, rather than treating every release as identical or leaving all classification to the supplier.

For a material change, ask for a version identifier, description of what changed, affected uses, evaluation against the buyer’s relevant cases and any new limits. The buyer should be able to reproduce the comparison against its incumbent configuration where that is feasible. If the supplier cannot preserve the old version, the contract and operating plan need a different rollback or suspension route.

Assign review authority. Procurement can secure notice and information rights, but a system owner must decide whether the change is acceptable in the workflow. A privacy lead may review new processing, an architect may review tool permissions and a service owner may judge customer impact. The agreement should make enough time and access available for those decisions before an irreversible rollout.

Test the proposed process with a plausible model release during supplier selection. Inspect the notice, comparison metrics, deferral rights and pause mechanism. Require enough detail to establish what the buyer can do, rather than accepting a change policy whose practical effect is unspecified.

For a hypothetical model release that adds a customer-record tool, ask whether the tool is enabled automatically, which permissions it uses and which evidence supports its behaviour on the buyer’s cases. Determine whether the existing configuration can continue during review. Define materiality in terms of those effects, rather than leaving the term entirely to the supplier.

Write a decision for each material-change class. A change in tool permissions could require an access review before activation. A changed retention practice could require privacy review and a new data-flow record. A model upgrade that changes answer quality could require replay against a versioned case set. The evidence and reviewer may differ, but each path should end in accept, accept with conditions, defer or suspend. Record who communicates that decision to the supplier and who verifies the deployed version.

Agree an operating response when required evidence is unavailable. Depending on the service, that may mean retaining the previous configuration, disabling a feature or using the manual route. The system owner should be able to exercise that response before the change reaches users.

What this does not tell you

The panel summary does not prescribe a universal set of contractual rights. The appropriate triggers depend on the use, risk, market and bargaining position. Contract drafting and statutory duties require specialist review. Nor should a change process freeze an AI product indefinitely. It should make material changes observable and subject to a proportionate decision.

Before award, procurement and the system owner should identify the evidence required for continued use after each material-change class. Record who reviews it and who verifies the deployed version. The agreement then supports an ongoing decision, rather than preserving only the assessment made at purchase.