AI procurement needs a tested exit, not just a successful pilot

Buy the outcome, retain the ability to leave

An AI procurement decision should include a practical question before the service becomes business-critical: can the organisation keep the work moving if it stops using this supplier? A successful demonstration answers whether a tool can perform a task. It does not establish whether the buyer can recover its records, preserve approvals and move unfinished work elsewhere. Oakhampton’s operational assessment is that a small, observed exit exercise belongs beside the usual performance trial.

That assessment is consistent with three established official resources, not a claim of a new private-sector legal obligation. Australian Government Architecture guidance treats cloud dependency as a trade-off to manage, rather than something to eliminate at any cost. The UK’s AI procurement guidance addresses supplier lock-in and end-of-life responsibilities. NIST’s AI Risk Management Framework 1.0 includes safe decommissioning and contingencies for high-risk third-party systems. These resources serve different audiences; their shared operational lesson is to plan beyond initial deployment. [1][2][3]

Separate useful specialisation from hidden dependency

The Australian guidance advises agencies to identify material dependencies, weigh provider-specific value against switching costs, and consider reusable data exports. It also warns that diversification brings additional complexity and capability demands. Maximum portability is therefore not automatically the best design. Its cloud guidance is relevant context for cloud-hosted AI, not an AI-specific certification scheme. [1]

For a commercial buyer, Oakhampton proposes a dependency map organised around the work rather than the product catalogue. A document-assessment service might depend on storage, identity permissions, extraction rules, a model endpoint and a queue of exceptions. Ask which elements the business controls, which can be reconstructed and which require supplier assistance. An export of uploaded documents is not necessarily an export of the workflow: approvals, unresolved queries and links between records may be equally important.

This distinction changes the buying discussion. A specialist feature may justify some switching friction where its benefit is measurable and the exposure is understood. The concern is an unpriced dependency that only becomes visible when a renewal, outage or service change forces a decision. Record the accepted limitation and the person responsible for reviewing it, rather than describing every integration as portable.

Test a handover, not just a download

The UK guidance, published in 2020 for public-sector AI procurement, recommends considering lifecycle support, knowledge transfer and end-of-life arrangements. It also calls for ongoing evaluation rather than treating procurement as a one-time judgement. Those are enduring design considerations; they should not be presented as newly introduced requirements for all businesses. [2]

A proportionate commercial test could use a small set of non-sensitive cases, including one completed item, one awaiting approval and one requiring correction. Export the available records, then give a different operator the task of reconstructing the case status in a simple alternative workspace. Check whether the operator can identify the source material, distinguish an AI suggestion from a human decision and see what still needs doing. This is an illustrative test design, not a reported customer result.

Record what was recovered, what was missing and the time required. Do not use a clean export as evidence that every historical case can be migrated. A passing sample demonstrates a bounded capability under stated conditions. If the supplier must provide assistance, test that handover too and document the dependency. The useful output is an executable transition procedure, not simply a file archive.

Keep continuity distinct from replacement

NIST’s AI RMF 1.0 includes processes for phasing out systems safely, clear responsibilities and contingencies for failures in high-risk third-party data or AI systems. The framework’s core describes continuous risk management, rather than a fixed sequence of compliance checks. [3]

Oakhampton’s practical distinction is between continuing essential work and replacing the technology. A fallback need not reproduce every AI feature. It may temporarily route new items to a person, preserve the approval queue and postpone lower-priority processing. That can be a credible continuity option even where a full migration takes longer. Define what staff can actually sustain, rather than assuming manual handling has unlimited capacity.

Before broader adoption, nominate who can pause automated processing, who owns the outstanding work and who checks that no item has been silently lost or processed twice. Keep that decision separate from a later choice of replacement supplier. A service interruption is a poor moment to discover that operational authority and technical access sit with different people.

Make the exit case part of the investment case

A buyer’s final assessment should compare the productive value of the service with the full effort required to operate, supervise and, if necessary, leave it. Oakhampton suggests documenting a named transition owner, the tested recovery boundary, unresolved dependencies and the conditions that would trigger another exercise. A substantial workflow change should prompt a review of whether the earlier test still represents the service being used.

This approach does not require a second platform on standby for every small experiment. Start with the business consequence of losing the capability and scale the evidence accordingly. A low-impact drafting aid and a tool embedded in a time-sensitive approval process need different continuity arrangements. The commercial objective is not frictionless switching at any price. It is a deliberate buying decision supported by evidence that the business can retain control of its work.