Build reassessment into AI procurement

A buyer evaluates an AI product against one model version, one data flow and one set of controls. Six months after award, the provider changes the model, adds a tool and revises the conditions under which it stores prompts. The contract still names the product. The evidence supporting the original buying decision no longer describes the whole service.

The procurement decision needs a reassessment path. The buyer should agree which changes require notice and evidence, who can approve continued use and what happens while a material change is under review. A one-time supplier questionnaire cannot carry a system whose design keeps moving.

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 process on a plausible change during procurement. Ask the shortlisted supplier to walk through a new model release: what notice arrives, which metrics are supplied, what can be deferred and how the customer pauses the feature. A polished change policy is less useful than a credible example of the rights and mechanisms it gives the buyer.

Make the example uncomfortable enough to expose the clause. Suppose the supplier replaces the underlying model on a Friday and the new version can call a customer-record tool. The buyer needs to know when notice arrives, whether the tool is enabled by default, what evaluation shows about the firm’s cases and whether the old configuration can remain in service during review. A general promise to announce “major updates” leaves the supplier free to decide whether this counts as major.

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.

The agreement should also cover silence. If the supplier cannot supply a version identifier, relevant test results or a workable delay, the buyer needs a safe operating choice. That may mean keeping the previous version, disabling an affected feature or using the manual route. The right choice depends on the service, but the decision should be available before the change arrives.

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.

The procurement lead and system owner should leave award with a recorded answer to one question: when the product changes, what evidence lets us keep using it? If no one can answer, the evaluation has an expiry date the contract does not acknowledge.