Rehearse Your AI Supplier Exit Before You Sign

The Sovereign Cloud

20 October 2026 | By Ashley Marshall

The best time to discover that your AI data cannot be moved is before the contract starts. A working exit rehearsal is a stronger buying signal than another polished demo.

The exit question belongs in the buying decision

Most AI purchasing conversations start with what a tool can do in a demonstration. A more revealing question is what happens on the day you stop paying for it. Can you retrieve the source documents, prompts, conversation records, evaluations and decisions in a usable format? Can another provider reproduce the essential workflow without rebuilding it from screenshots? If the honest answer is unknown, the apparent speed of adoption may simply be deferred migration work.

This is not an argument against buying a managed AI service. For many UK firms, a hosted assistant is the quickest sensible route to value. It is an argument for treating exit as a normal acceptance test. The GDS Responsible AI Advisory Panel summary from September 2026 explicitly discussed responsible AI procurement as a way to strengthen transparency, accountability and assurance without placing unnecessary barriers in front of suppliers. That balance matters. A buyer does not need a 90-page questionnaire. It needs a short, practical demonstration that the organisation can keep serving customers if a contract, model or integration changes.

Ask the supplier to export a representative project during the trial, not after a dispute. Inspect the result with a person who did not set up the tool. Are timestamps, authors, source references and approval decisions preserved? If an assistant has drafted customer replies, is the final approved text separable from intermediate generations? If a system has classified cases, can you explain how the categories map to your own records? A file marked export.zip is not evidence of portability. A colleague successfully opening, understanding and reusing it is evidence.

What this means in practice: put one exit rehearsal in the pilot success criteria. Time the exercise, document missing fields and assign an owner to resolve them before annual renewal. The commercial conversation then moves from vague reassurance to an observed result.

Separate the data from the workflow

An AI deployment usually contains more than one thing to move. There is the underlying business data, the instructions and prompts, the integrations that call other systems, the model configuration, and the operating decisions that humans make around the output. A supplier may export one layer while leaving the rest embedded in its platform. That is why a generic promise of data portability can be technically true and operationally useless.

Start with a simple inventory. For each workflow, record the input system, output destination, account owner, access credential, model or service used, retention setting and human review point. For a support assistant, this could mean CRM tickets in, a proposed answer out, a named reviewer before send, and an audit record of what was actually sent. The useful question is not merely whether tickets can be downloaded. It is whether the organisation can reconstruct the route from ticket to approved response when it moves provider.

The NCSC interim advice on agentic AI from August 2026 distinguishes lower-autonomy assistance from agents that can take actions in production systems. It recommends proportionate controls and says model-level safeguards alone should not be treated as complete protection. An exit plan needs the same distinction. Turning off a read-only summariser is relatively straightforward. Removing an agent that holds live credentials, has scheduled tasks and can update records requires a deliberate cutover. List every permission that must be revoked and every task that must be paused.

What this means in practice: retain your canonical records outside the AI product, wherever feasible. Keep prompt and workflow definitions in a version-controlled document your team owns. Use service accounts that can be disabled without disrupting unrelated applications. Test a small export and a small restore every quarter. These are ordinary operational disciplines, not a demand to build your own model.

Test a replacement against real work, not a sales demo

The simplest exit drill is a controlled replacement exercise. Choose ten to twenty representative tasks, including awkward ones. Include incomplete records, ambiguous customer requests, documents with conflicting dates and cases where the right answer is to escalate. Capture the current system's inputs, outputs, review decisions, time taken and failure types. Then run those same cases through a replacement route. The replacement might be another hosted provider, a manual process for a short period, or a smaller in-house workflow. It does not need to outperform the incumbent. It needs to prove the business can continue safely.

Agree the acceptance criteria before testing. For example, every customer-facing message may require a named human approval; every extracted invoice field may need a link to its source; no agent may have permission to issue a refund. These are business requirements rather than model benchmarks. A result that looks fluent but loses its audit trail is a failed migration for a regulated or dispute-prone process. Equally, a slower fallback can be acceptable if it preserves essential service for two weeks.

The GDS panel's September meeting summary also raised the importance of reassessing AI products as they change, in its discussion of tutoring tools. That principle extends beyond education. A supplier switch is not the only trigger for an exit drill. A model update, integration redesign or revised retention policy can change the controls on which your original approval depended. Record the version and assumptions behind the baseline test, then rerun the high-risk cases when the service changes materially.

There is a counterargument: small businesses have little time for elaborate procurement. Fair. This is why a narrow rehearsal beats a large paperwork exercise. Pick one revenue-critical or customer-facing workflow and spend half a day proving the fallback. If the process cannot survive that simple test, a longer checklist would not have made it safer.

Make privacy and security part of the handover

Leaving an AI supplier is not complete when the final invoice is paid. Personal data may remain in stored conversations, uploaded files, logs, backups or connected services. The organisation needs to understand what is retained, on what basis, for how long, and which deletion or return commitments can be evidenced. The ICO response on generative AI and data protection explains that UK GDPR and the Data Protection Act 2018 apply to specific aspects of generative AI development and use. It is not a blanket certificate for a particular vendor. Your own deployment and contract still need scrutiny.

Write the handover checklist before the supplier relationship becomes strained. Identify who can request an export, who verifies its completeness, who checks the lawful handling of personal data and who confirms deletion obligations. Preserve records needed to explain business decisions, but do not casually copy everything into a new assistant. The destination system should have a defined purpose, access boundary and retention policy. A rushed migration can multiply exposure if teams move historic chats containing sensitive information without reviewing them.

Security deserves its own cutover sequence. The NCSC's agentic AI advice calls for observability, attribution, oversight and an emergency shutdown capability. Translate that into concrete steps: suspend scheduled agent jobs, revoke API keys and OAuth grants, disable webhooks, confirm that old service accounts cannot still write to the CRM, and watch logs for unexpected calls. Keep a rollback option until the new process has passed its acceptance cases. An integration that was forgotten can keep operating after staff believe the old tool is gone.

What this means in practice: ask for a sample deletion confirmation and export format during procurement. Record the promised response times in the agreement. At exit, verify the technical disconnection as well as the commercial closure. Neither a supplier email nor a disabled user login proves that all automated access has ended.

Price the option to leave

An exit rehearsal also improves the financial decision. Compare the supplier's annual price with the whole cost of dependence: staff retraining, integration changes, data cleaning, contract notice, parallel running and the interruption to a customer-facing service. These are not reasons to reject a useful product. They are costs that belong in the same decision as the licence fee. A slightly dearer provider with clean exports and documented interfaces can be cheaper over three years than a lower-cost tool that requires a full rebuild to replace.

Use three scenarios. First, a planned switch at contract end. Second, a sudden loss of an API or model feature. Third, a privacy or security event that requires an immediate pause. For each scenario, estimate who makes the decision, how long the fallback takes and which customer commitments remain at risk. State assumptions openly. Do not manufacture a precise return on investment from guesses. A range with a tested recovery time is more useful than an impressive spreadsheet built on an untested export claim.

A practical contract conversation follows. Ask for documented export formats, reasonable notice of material changes, clear retention and deletion terms, and a way to obtain assistance during transition. Avoid demanding unlimited custom development from a small supplier. The GDS panel's emphasis on assurance without needless barriers is a useful discipline here: ask for evidence proportionate to the risk and value of the workflow. A small internal drafting aid needs a lighter test than an agent that can alter customer records.

My recommendation is to make exit readiness a recurring operational metric. Once a quarter, have someone outside the implementation team perform a limited restore, then record the elapsed time, missing context and residual permissions. If the result worsens, fix it before adding more work to the platform. The aim is not to leave every vendor. It is to preserve the freedom to choose, negotiate and recover when the business needs to.

Frequently Asked Questions

Is an export button enough to prove portability?

No. Have someone outside the implementation team open and reuse a sample export, checking context, timestamps and decision records.

What should a small business test first?

Choose its most consequential AI workflow and rehearse ten representative cases through a manual or alternative route.

Do we need a second AI supplier on contract?

Not necessarily. A documented manual fallback can be sufficient for a short outage if it protects essential service.

How often should an exit test be repeated?

A limited quarterly restore is a sensible operational cadence; also retest after material model, integration or retention changes.

What happens to personal data when we leave?

Verify contractual return and deletion terms, preserve required business records, and obtain evidence that access and retention commitments have been met.

Should prompts and workflow instructions be included?

Yes. Keep business-owned copies of prompts, rules and approval logic so an export of raw records is not your only asset.

How do we price supplier lock-in?

Estimate planned and emergency switching costs, including retraining, parallel running, integration work and service interruption.

Does this mean avoiding managed AI products?

No. It means buying useful managed services with a tested fallback and proportionate evidence of portability.