How to Prevent AI Vendor Lock-In: Clauses and Exit Plan

Reading time: ~8 min · Cluster: Vendor evaluation · Level: CISO / CIO

Spotting vendor lock-in is only half the job. I broke that half down separately into three layers and two contractual traps. This post is about the other half: what to actually do so the lock-in never closes. And that can only be done at two moments: when you sign the contract and when you design the architecture. Never on the day you want to leave, because by then it is too late.

Prevention stands on two legs. The first is the contract: concrete clauses that move the right to exit from the vendor's goodwill onto paper. The second is the exit plan: the operational ability to actually migrate, prepared in advance and tested, rather than improvised under pressure. Both are below, ready to use.

Table of contents

• Why the right to exit has to be on paper
• Contract clauses worth having before the MSA
• Exit plan: what to prepare from day one
• Exit drill: why a plan without a rehearsal is fiction
• Where on-prem changes the math, and where it does not
• What this post does not cover
• Disclosure and biases

Why the right to exit has to be on paper

For an essential entity under NIS2, the ability to end a vendor relationship without losing operational capability is not a convenience, it is a supply-chain security element assessed under Article 21(1)(d). If you cannot describe how you would leave your AI vendor, you hold an undocumented compliance risk, not just a potential cost headache.

The key difference from ordinary SaaS: in AI, what you want back is not only input data. It is also the derived artifacts the vendor may own by default if the contract is silent: embeddings of the whole corpus, vector indexes, fine-tunes, prompts and logs. A silent contract is not neutral. A silent contract works in the vendor's favor.

Contract clauses worth having before the MSA

The table below is not a ready legal template, it is a checklist of intents for a lawyer to translate into contract language. Each row is one safeguard and one red flag when it is missing.

Clause	What it must guarantee	Red flag when missing
Data and artifact portability	Right to export source data, embeddings, indexes and logs in an open, documented format, during the contract and at exit	"Export on request" with no format or deadline is not a real right
Ownership of derived artifacts	Explicit assignment to you of fine-tunes, embeddings, prompts and logs	A silent contract means default control sits with the vendor
No punitive egress fees	Zero exit-data fees, or a cap agreed up front	Per-GB egress charged only on departure is a penalty for leaving
Notice and objection: sub-processor and jurisdiction	Prior notice and the right to object to a change of sub-processor or processing location	A unilateral terms change hands your risk profile to the vendor
Model change and deprecation notice	Advance warning and a window to re-validate on a base-model change	A silent model update is your unplanned re-validation cost under the AI Act
Transition assistance	A commitment to support migration for a set period after termination, priced or in-scope up front	"Good-faith cooperation" without an SLA is an empty promise
Data return and deletion	An SLA for return plus confirmed deletion after expiry, relevant under GDPR too	No clause means data stays with the former vendor
Configuration escrow	Escrow of model weights, configuration and prompts with a third party in case the vendor fails	Missing it on a critical workload is a business single point of failure
Price-increase cap and termination window	A cap on price escalation plus a real termination window without auto-renewal	Auto-renewal with no cap is a price lock-in independent of the technical one

A practical negotiation order: portability and artifact ownership first, because without them the rest is theoretical. Then notices on sub-processor and model changes, because those govern your risk profile over time. Keep transition assistance and escrow as clauses you can concede in exchange for harder portability wording if the negotiation demands it.

Exit plan: what to prepare from day one

The best portability clause is useless if, on exit day, you have nowhere and no way to receive the data. So the second leg of prevention is operational. An exit plan is not a document for later, it is a set of things you keep current from the start of the deployment.

Exit-plan step	What to prepare	Owner	When
Dependency register	A map of which data, artifacts, integrations and trained people tie you to the vendor	Architect / CISO	From day 1, updated quarterly
Business logic outside the vendor	Prompts, rules and mappings kept in a repository on your side, not inside the vendor's orchestrator	AI team	Continuously
Regular artifact export	A cyclical dump of embeddings, index and logs in an open format	Ops	Monthly or quarterly
Identified fallback model	An alternative model and inference stack you can move to	Architect	Reviewed every six months
Migration runbook	Step by step: recompute embeddings, switch connectors, validate outputs, cut over traffic	AI team + Ops	Ready before signing the MSA
Exit drill	A rehearsed migration on a test environment, measured in time	AI team	Once a year

The heart of this plan is one rule: the more of your logic and your artifacts live in a format you control, the shallower every layer of lock-in becomes. I covered the data and model layers in more depth in the three-layers post; here the point is to have a prepared way out for each of them before you need it.

Exit drill: why a plan without a rehearsal is fiction

An exit plan never executed is worth the same as a backup never restored: nothing, until it turns out not to work, at the worst possible moment. An exit drill is a controlled migration rehearsal once a year, on a test environment, with a limited corpus.

What you actually measure in such a rehearsal: whether the artifact export can really be loaded by another stack, how long recomputing embeddings on the fallback model takes, whether the ERP and MES connectors switch over without a rewrite, and how much quality you lose on the fallback model against production. The result of the drill is not just confirmation that exit is possible. It is a number: the real cost and time of migration, which you can use in negotiations and in your NIS2 risk documentation.

If the first drill shows migration is infeasible in a reasonable time, that is the cheapest moment to learn it. Far cheaper than the day the vendor raises the price or swaps the base model without asking.

Where on-prem changes the math, and where it does not

On-prem mitigates lock-in most strongly in the model layer, because you decide when and whether to update the model, and physically in the data layer, because the corpus sits with you. But it does not zero out lock-in automatically. Data can physically live in your server room and still be trapped in a closed index format. Physical control is not the same as portability, and people trained on one interface plus a proprietary orchestrator tie you regardless of where the hardware stands.

That is why the clauses and exit plan in this post apply to on-prem deployments too. Their weight shifts, not their necessity: with on-prem you worry less about egress and jurisdiction, and more about artifact ownership, open formats and how much of your logic lives outside the vendor's stack. Whoever evaluates on-prem bids in procurement will find complementary criteria in the sovereignty test.

What this post does not cover

I deliberately do not go into the full vendor-scoring framework, which I keep separately in the 24-question RFP skeleton and the 12-question vendor security review before the MSA. I also do not cover the data processing agreement in detail, which I break down in the 8 DPA clauses post, nor conformity assessment under the AI Act, nor price-negotiation tactics. This is a note on preventing lock-in in the contract and the architecture, not a complete guide to vendor evaluation.

// disclosure & biasesDisclosure and biases

I write from the view of a team that builds on-prem AI systems, so I naturally tilt toward solutions that give control over the model and data layers. I tried to balance that: above I state plainly that on-prem does not zero out lock-in and that your own artifacts can be trapped in a closed format despite physical control of the hardware. This text is not legal advice. Treat the clause list as intents for a lawyer to translate into the language of a specific contract and jurisdiction.

Related notes

• Recognition: Vendor lock-in in AI: three layers, two contractual traps — how to spot lock-in before you start preventing it.
• Vendor scoring: RFP for an AI compliance vendor: a 24-question skeleton — a fuller framework for scoring a bid.
• Security: Vendor security review AI: 12 questions before signing the MSA — what to check on the security side before you sign.
• Agreement: DPA for an AI vendor: 8 clauses whose absence breaks your audit — related wording in the data processing agreement.
• Procurement: The sovereignty test in procurement: how to assess an on-prem bid — complementary criteria for on-prem deployments.