Handover passes when the replacement team runs the system
Another team can operate what your AI vendor built only after that team has rebuilt, evaluated, deployed, observed, rolled back, and operated the system.
Documentation, credentials, a transfer call, and a support period are inputs to that test. They are not evidence that handover succeeded. The contract should define handover as a witnessed acceptance exercise performed by a qualified replacement team in an environment the buyer controls.
This distinction matters before signing. Scottish public procurement guidance directs buyers to require supplier access to everything their organisation will need to maintain the service itself. It also calls for the transfer of operational records, including data, procedures, access logs, and error logs, rather than a final document assembled at exit. 1
A buyer who asks only for “complete documentation” cannot reject a handover because the build instructions fail, an alert has no owner, or rollback depends on an account the vendor still controls. Picture the on-call engineer at the replacement team, three weeks after cutover, paging out for an alert that has never had a named owner and finding the runbook points to a login only the vendor can use. Those conditions were never made part of acceptance.
The evidence must come from a clean run by the replacement team
The supplier produces the materials needed to run the test. The replacement team produces the evidence that those materials work.
Start with an agreed release of the system. Record its source, configuration, approved evaluation thresholds, deployed behaviour, monitoring state, and recovery point. That becomes the reference release. The replacement team then starts from the delivered materials and buyer-authorised access, without copying a prepared vendor environment.
This follows the useful meaning of reproducibility: independent recreation from the same data and code used by the original team. 2 Reading the instructions is not the test. Executing them is.
The required evidence set is:
| Capability | What the supplier must deliver | Evidence that passes | What absence tells the buyer |
|---|---|---|---|
| Rebuild | Complete source, dependency definitions, configuration inventory, build automation, model and data provenance, required licences, and instructions for obtaining restricted inputs | The replacement team creates deployable artifacts from a clean starting point. The record identifies the inputs, commands, outputs, and artifact identifiers. | The delivered source is incomplete, an input cannot be obtained, or part of the build remains vendor-controlled. |
| Evaluate | The executable evaluation suite, approved test inputs, scoring rules, acceptance thresholds, known exclusions, and reference results for the agreed release | The replacement team runs the suite and reproduces an acceptable result. Failed cases remain visible rather than being removed from the report. | Performance claims cannot be checked independently, or the evaluation depends on undisclosed data or judgement. |
| Deploy | Deployment automation, environment requirements, access map, secret-provisioning procedure, release checklist, and health checks | The replacement team deploys the rebuilt artifact into a buyer-controlled target and passes the agreed health checks. | The system can be built but cannot be released without vendor knowledge, permissions, or manual intervention. |
| Observe | Dashboard definitions, log and event definitions, alert conditions, routing rules, operating objectives, and investigation runbooks | The buyer introduces agreed test conditions. The replacement team detects them, receives the alerts, finds the relevant records, and follows the escalation path. | Monitoring is decorative, operational records are missing, or alerts still terminate with the vendor. |
| Roll back | A recoverable prior release, rollback automation, data compatibility instructions, decision authority, and post-rollback checks | The replacement team deploys the agreed release, initiates rollback, restores the prior state, and reruns the required checks. | Recovery depends on memory, unavailable artifacts, irreversible data changes, or permissions retained by the supplier. |
| Operate | Routine task schedules, ownership map, incident procedures, access administration, backup and restoration instructions, dependency renewal dates, and support contacts | The replacement team completes the agreed operating scenarios and leaves an auditable record of decisions, actions, and outcomes. | Day-to-day operation still contains undocumented supplier labour or unassigned responsibilities. |
These outputs are difficult to fabricate because the buyer controls the environment, witnesses the run, and retains the generated records. Screenshots of an earlier vendor-run demonstration do not meet that standard.
For a high-risk AI system within the scope of the EU AI Act, the provider’s instructions must address relevant training, validation, and testing data. The required technical documentation also covers how software components feed into one another and integrate into the overall processing. 3 A vendor in that position should already possess this material. Asking for it only during exit creates avoidable delay.
Document delivery, escrow, and retained support buy different protections
A document-only handover has the lowest coordination burden. Its cost appears later, when the replacement team discovers that an instruction assumes hidden access, an unavailable input, or knowledge held by one person. Review can improve the prose, but it cannot prove execution.
A vendor-led demonstration proves that the incumbent team can operate the system. It says little about transfer because the demonstrator can compensate for missing instructions from memory: the vendor engineer who built the rollback script does not need the runbook, since she remembers the one manual step it leaves out. Use demonstrations to inspect the workflow, then require the replacement team to repeat it.
Source escrow protects access under defined release conditions. It does not establish usability. One escrow provider states that access alone is insufficient and describes verification through independently rebuilding the deposited application in a real environment. 4 Escrow can complement the handover test when release risk warrants it, but it cannot replace it.
Retaining the vendor for transition support reduces immediate continuity risk, but it can conceal an incomplete transfer. UK government guidance separates commercial lock-in created by inflexible contracts from technical lock-in caused by scarce skills and knowledge. 5 A termination right addresses the commercial constraint, but only a successful replacement-team run addresses the knowledge constraint.
These options are therefore cumulative protections, not interchangeable handover standards.
Put the acceptance mechanism in the contract before work begins
Attach a handover schedule to the statement of work. Define the reference release, required materials, buyer-controlled test environment, qualified replacement-team role, acceptance scenarios, evidence format, defect process, and consequences of failure.
The operative clause can follow this form:
Handover is accepted only when a replacement team designated by the buyer uses the delivered materials and authorised access to rebuild, evaluate, deploy, observe, roll back, and operate the reference release against the acceptance criteria in the handover schedule. The supplier may explain the materials and cure defects, but the replacement team performs the acceptance actions. All generated artifacts, logs, results, decisions, and unresolved exceptions become buyer records.
Tie acceptance to something the buyer can enforce, such as a payment holdback, exit completion, or continuing transition assistance. Counsel should adapt the remedy to the governing contract. The technical schedule should still state that a failed step remains failed until the replacement team reruns it successfully.
Require the evidence set at agreed release points, not only at termination. Otherwise the buyer tests old instructions against a system that has continued to change. Material changes to data preparation, evaluation, deployment, monitoring, recovery, or access should trigger an updated evidence run.
Vendor selection should use the same standard. How should you test an AI vendor before hiring? explains how to examine capability before award, while Make AI vendors prove they can run production systems covers the operating evidence that should exist before a supplier is trusted with production responsibility.
A passed handover test does not remove every dependency
The test can produce a false failure if the replacement team lacks the skills specified for the role, the way a rebuild fails not because the pipeline is undocumented but because nobody on the new team has run that particular orchestration tool before. Define the required competence before testing and let the buyer select the team. Do not let the incumbent reject every candidate while claiming the materials are complete.
A passed test also does not transfer rights that the buyer never purchased. Data licences, model access, third-party services, certificates, and support agreements need separate assignment or replacement terms. The rebuild evidence should expose these dependencies, but the test cannot rewrite their contracts.
The exercise proves operability for the reference release under the tested conditions. It does not prove security, legal compliance, future model quality, or suitability after the operating context changes. Those require their own acceptance and review processes.
Finally, rebuilding in a controlled environment is different from moving a live service without interruption. The migration plan still needs cutover authority, data reconciliation, user communication, recovery criteria, and a tested fallback. A successful handover run cannot substitute for those controls.