An owner of a fourteen-person professional services firm is trying to leave an AI tool she signed for eighteen months ago. The product works, more or less, but a competitor has launched something materially better for half the price and she wants to switch this quarter. Then the wheels start coming off. Her data exports in a format nothing else accepts. The integration she paid five thousand pounds to have built into her CRM does not transfer. The customer success team that returned her emails inside an hour for the first year has gone quiet since she gave notice. Her notice window turns out to be sixty days, not thirty, and the contract is silent on whether she can run the two tools in parallel while she migrates.
She had read the contract before signing. She had asked the obvious questions. None of them were these. The engagement was the bit she had planned for. The exit was the bit she had not.
That is the pattern this post is about. The single most expensive part of an AI vendor relationship that goes wrong is usually the exit, not the engagement itself. The lock-in accumulates gradually, the switching happens decisively, and by the time the owner is ready to leave, the asymmetry has shifted heavily towards the vendor. A ninety-minute conversation at the contract stage, anchored on three specific questions, prevents the bulk of it.
What are exit clauses and switching costs in an AI contract?
Exit clauses are the contract provisions that govern what happens when the engagement ends, covering data export format, the disposition of customer-developed configuration, parallel-running with a successor, deletion certifications, and the price of any extraction work. Switching costs are the operational and commercial weight of moving to a replacement tool, which include data conversion, integration rebuilds, retraining of any fine-tuned components, and the parallel period when you are paying both vendors at once.
AI vendor contracts commonly cover this ground in vague terms. Standard SaaS language about returning data “in a commonly used format” within thirty days, plus generic transition assistance “at the vendor’s then-prevailing rates”, does little useful work when the time comes to leave. The questions in this post turn that vagueness into something specific enough to act on, before the balance of power shifts.
Why does the exit matter more than owners expect?
The exit matters because lock-in compounds quietly across the engagement while switching has to happen on a fixed timeline, and the balance of power flips at the moment of notice. During the engagement, the buyer holds the budget and the vendor courts attention. At notice, the vendor holds the data, the configuration, and the operational dependency, and the buyer has to be somewhere by a fixed date.
The UK regulatory picture has shifted in the buyer’s favour over the last two years. The Information Commissioner’s Office guidance on Article 20 of UK GDPR mandates portability for personal data in a structured, commonly used, machine-readable format. The EU Data Act, Regulation (EU) 2023/2854, goes further on cloud and AI specifically, requiring providers to enable switching by exporting data in standard formats without undue delays or fees, and banning unfair switching terms in Article 22. Practitioner guidance from Morgan Lewis on exit rights in AI deals and Bird and Bird on UK vendor lock-in clauses translates those statutory floors into specific contract language buyers can require. The standing is there. It only works if the contract makes it operable on the specific data, logs, prompts, and trained state your engagement actually generates.
Where do owners actually meet exit clauses in practice?
Owners meet them in three contract-stage questions, each answerable in plain English without legal training. First, what format does our data come out in at the end, and does the export cover the full picture. Second, what happens to the integrations, prompt libraries, and trained state we have built, and can we extract them. Third, what does the parallel-running window look like, and what cooperation can we expect with a successor.
The data export question is the one owners commonly ask first and answer least well. The contract usually says “structured commonly used format” and means CSV. The right specification names the formats you want, JSON, CSV, or Parquet, names the records the export must cover, raw inputs and outputs, audit logs, prompt libraries, fine-tuned weights or retrieval indices, agent memory if any, sets a timing window, and prices any extraction work at a fixed rate written into the contract rather than the vendor’s then-prevailing rates at the point of notice.
The integration and configuration question is the one that catches owners after signing. Customer-developed artefacts need to be defined explicitly in the contract, with extraction obligations on the vendor and a prohibition on vendor reuse of any fine-tuned state derived from your data. Morgan Lewis’s guidance on building exit rights into AI deals covers this in detail. The parallel-running question closes the loop. A contractual right to ninety days of parallel access at a capped rate, with vendor cooperation on data pipelines and successor integration, is what makes the export and configuration work usable in practice rather than theoretical.
When to push hard on exit clauses, and when to skip the conversation
Push hard on the three questions for any AI vendor contract above roughly five thousand pounds a year, on any contract that touches customer personal data, and on any contract with a term longer than twelve months. Push hardest where the tool sits in an operationally critical workflow, or where it holds proprietary data, prompt libraries, or fine-tuned configuration that took months to develop.
For a small tool on rolling monthly cancellation, a quick scan of export format and notice is proportionate, and the conversation can be lighter. The framing that works in negotiation is not adversarial. A vendor whose commercial lead bristles at “let us make sure both sides are clear on off-boarding if we ever get there” is telling you something about how the relationship will run once the balance of power shifts. Reasonable vendors expect this conversation on any AI engagement of meaningful size and have draft language ready. If they do not, that is itself useful information.
Once signed, the discipline is a one-page exit-readiness note in your own files, refreshed annually, that captures four things. Where the data lives and the export format the contract obliges. The integrations you have built and how they would be unwound. A rough thirty-day plan for parallel running with a hypothetical successor. The current renewal date and notice window. The aim of the note is to keep the option of leaving real, so the relationship stays balanced when renewal comes around.
Related concepts
This post sits in the contracts section of the buying AI cluster for owner-operated businesses. The Plain-English explainer what is vendor lock-in covers the underlying concept. The sibling reviewing an AI vendor contract covers the wider seven-provision pattern of which exit is one. The sibling data and IP clauses in AI contracts goes deeper on training rights and output ownership, which intersect with what your data export covers.
Upstream sit the four questions before buying AI that frame the buying job, and buying AI for owner-operated businesses which sets the wider cycle. Downstream sits switching AI vendors without burning everything down, which picks up the operational migration after notice has been given, and when an AI engagement goes wrong, which covers the broader patterns of mid-engagement repair before leaving becomes the answer. None of this is legal advice. Exit clauses in any material AI vendor contract should be reviewed by a qualified commercial solicitor before signature, and the narrow scope of that review is what the discipline in this post earns.
If you are looking at an AI vendor contract this week and you want a second pair of eyes on the exit provisions before you sign, book a conversation.
