When OpenAI retired several GPT-3 models in 2023, customers received roughly six months’ notice to rebuild their integrations. For businesses that had never thought about what leaving would involve, that window felt very short. Prompts had to be ported, API endpoints replaced, and outputs re-tested against the new model’s behaviour. Some firms managed it cleanly. Others scrambled.
You will leave your AI vendor at some point. The tool will be superseded, the pricing will change, a better fit will emerge, or the company behind it will be acquired. The question is whether you leave in a controlled way or in a scramble. That difference is almost entirely determined by what you put in place before you need it.
What does a clean AI vendor exit actually involve?
A clean exit means leaving an AI vendor without losing access to your data, compromising your security, or triggering a service gap your clients feel. In practice, it involves five things: mapping every touchpoint the vendor has in your business, reviewing your contract rights, planning your target state, executing a phased migration, and confirming data deletion. Each step has a sequencing logic; skip one and it tends to surface as a problem later.
The mapping step is regularly underestimated. Firms often discover mid-exit that the vendor has API connections into their CRM, their document management system, and their client-facing tools simultaneously. Identifying which systems call the vendor’s API, what categories of data are being sent, and whether outputs feed into decisions about individuals gives you an honest picture of what the exit involves before you start.
The contract review is where most of the control sits. Check your termination rights and notice periods, whether the vendor can use your data for model training, what formats they will supply data in on exit, and whether they commit to a deletion certificate at the end. Enterprise AI and cloud contracts frequently specify notice periods of 30 to 90 days for non-critical services and six to twelve months for embedded platforms. If your contract is thin here, assume you will need to negotiate arrangements rather than rely on stated rights.
Why does your business need to take this seriously?
UK businesses using AI to process personal data sit under ICO obligations that actively shape what a vendor exit must include. Under UK GDPR Article 20, you have the right to receive personal data in a structured, machine-readable format and transmit it to another provider where technically feasible. But that right is only actionable if your contract obliges the vendor to supply logs, configurations and training data in usable formats.
Security is a second pressure point. The NCSC’s supply chain security guidance recommends a formal off-boarding process for every supplier: revoking API keys, removing vendor access from your identity providers, rotating shared credentials, and confirming data deletion. Poor off-boarding has contributed to multiple UK data exposure incidents. An AI vendor with API access to your systems is a supplier in exactly this sense, and the same disciplines apply.
If you operate in financial services, the FCA’s outsourcing rules (PS21/3 and FG16/5) require firms to ensure exit plans are workable before entering material outsourcing arrangements, covering access to data and continuity of critical services. The FCA has confirmed that AI use sits within existing operational resilience frameworks. Even if you are not regulated, these standards are a useful benchmark for what a careful exit looks like.
Where does a vendor exit go wrong in practice?
The most common failure is discovering what you don’t have access to after you’ve already decided to leave. Prompt libraries built inside the vendor’s interface, fine-tuned configurations, training data you labelled over months, and interaction logs that form your audit trail can all be stranded if your contract doesn’t specify export rights in usable formats. By the time you realise, negotiating from a position of notice is harder.
Four specific failure modes appear consistently in AI and cloud vendor exits. First, credentials left live after the commercial relationship ends: the NCSC flags this as a source of ongoing security exposure. Second, migration timelines that are shorter than the reality: moving integrations, porting prompts, and re-validating outputs frequently takes months rather than weeks, particularly in regulated settings. Third, the audit trail lost: the ICO and FCA both expect you to be able to evidence how past decisions were made, and failing to export interaction logs before exit creates regulatory exposure. Fourth, a different model producing different outputs: a replacement AI system will not behave identically on edge cases, and ICO guidance on AI and data protection emphasises the need to test for accuracy and fairness after significant changes, which includes a vendor swap.
When should you start planning your exit?
The right moment to plan your AI vendor exit is at contract signing, not when you decide to leave. The UK Government’s AI Playbook advises public bodies to include data portability and replacement planning at procurement, and the same logic applies to private firms. A vendor relationship that starts with a clear exit clause, defined data formats, and a stated termination notice period is categorically easier to leave than one started without those terms.
KPMG’s analysis of AI outsourcing contracts recommends including AI-specific governance from day one: data usage rights, training consent, performance standards, IP ownership, and termination provisions. Retrofitting these into an existing contract is harder, but a renewal or renegotiation is the practical moment to introduce them.
The proportionate version of this planning depends on how embedded the vendor actually is. If you use an AI tool only for non-personal data in low-impact internal tasks with no custom integrations, many of the heavier steps are less pressing. A tool handling client data, feeding decisions, or embedded across your tech stack warrants the fuller treatment. Vendor-side changes are a real enough scenario to plan for: the CMA’s AI Foundation Models review flags the risk of concentrated dependency on a small number of providers, and the history of model deprecations shows that access can change quickly when a vendor changes direction.
What else should be on your radar?
Three areas sit adjacent to vendor exit and are worth knowing before you reach for a contract. Data retention obligations mean your exit plan cannot simply hand back data and close the account: UK finance firms typically hold records for five to seven years, and prompt logs or decision outputs that form part of client records must be exported and retained in your own systems for the full retention period.
Second, if you serve clients in the EU, the EU AI Act introduces logging and documentation obligations for high-risk AI use cases that facilitate decommissioning or modification. UK firms with EU-facing services may need to demonstrate they can switch or modify AI components while maintaining required records.
Third, if you are building toward a sale, how you handle AI vendor relationships affects what buyers see. AlixPartners, advising private equity on AI value creation, notes that reliance on opaque third-party AI without clear data portability or documentation can undermine the exit story at due diligence. The documentation you keep during a vendor exit, including contracts, deletion certificates, test records, and data export manifests, becomes part of the evidence base a buyer will want.
The Monday action is straightforward enough. Pull one AI vendor contract, find the termination and data export clauses, and check whether they would let you leave cleanly. If the answer is unclear, that is the gap to close.
