AI vendor independence: how to prove you are not locked in

Lock-in is an exit cost, not a feeling

Every AI deployment has an exit cost. The question is whether anyone has measured it. A vendor that cannot tell you the cost is not necessarily trapping you deliberately; more often nobody has ever tried to leave, so the path has never been walked. That is exactly the problem. An untested exit is an assumption, and assumptions fail under pressure: an acquisition, a price rise, a supervisor asking about a third country transfer, a model deprecation notice with 90 days on it.

Write the exit cost as three figures and independence stops being abstract: elapsed weeks to run production elsewhere, euros of one-off migration effort, and the percentage of your current capability you would lose on day one. If any of the three is unknown, you are locked in by ignorance even where the contract is clean.

The seven layers where lock-in lives

Lock-in is rarely one big thing. It accumulates across layers, each individually reasonable, and only the stack of them makes leaving expensive. Treat them separately, because the remedies differ.

Layer six is the one buyers consistently miss. Weights and data are visible assets and people negotiate them. The evaluation suite is invisible: the prompts, the graded outputs, the thresholds that define good enough for your use case. If that lives in the vendor's console, then even with perfect data portability you cannot prove a replacement is equivalent, and the migration stalls in an argument nobody can settle.

What EU law now expects

Exit readiness used to be a procurement nicety. Three instruments made it a compliance matter.

• The Data Act, Regulation (EU) 2023/2854, gives customers of data processing services the right to switch providers, requires contractual switching terms and a maximum transition period, and phases out switching charges. It applies to cloud and edge services, which includes hosted AI platforms.
• NIS2, Directive (EU) 2022/2555, makes supplier relationships part of mandatory risk management under Article 21(2)(d), and business continuity including backup and crisis management under Article 21(2)(c). A single non-substitutable AI supplier inside an essential function is a documented risk your customer must answer for.
• DORA, Regulation (EU) 2022/2554, is the strictest: financial entities need documented exit strategies and transition plans for ICT services supporting critical functions, and their registers of information name you. If you cannot describe your own exit path, you become the reason their register entry is incomplete.

The practical effect is that a buyer asking about independence is often not negotiating price. They are collecting an artefact they owe to a supervisor. Answering with a portability statement and a tested exit plan closes the request; answering with reassurance restarts it.

The five artefacts that prove it

1. Exit plan with numbers. Named steps, an owner per step, elapsed time, and the cost of running both systems in parallel during cutover.
2. Export specification. What comes out, in which formats, how long it takes, and what is explicitly not exportable, said plainly rather than omitted.
3. Portable evaluation suite. A golden dataset and scoring harness you can run against any candidate model, so equivalence is measured rather than argued.
4. Second-source test result. A dated record of the same workload running on an alternative model or deployment, with the quality and cost delta stated.
5. Termination assistance clause. A defined window after termination, a fixed or capped price, and continued access to data and support during it.

Artefact four is the only one that cannot be faked. Everything else is a document; a second-source test is an event. Run it once a year against a realistic slice of production traffic, keep the result dated, and independence becomes a claim you can evidence in a single page.

Independence is not the same as self-hosting

On-premise deployment reduces some lock-in and creates other kinds. An appliance you cannot patch without the vendor, a licence keyed to hardware, or a model you may run but not inspect leaves you dependent while feeling sovereign. Conversely a hosted API behind a thin abstraction, with exported data, a portable eval suite and a proven fallback, can be more replaceable than an appliance in your own rack. Judge deployment on residency, latency and cost, and judge independence on substitutability. They are different questions and conflating them produces expensive architecture that solves neither.

You are not independent because your data is in your building. You are independent because you have run the same workload somewhere else and know exactly what it cost.

The answers that fail

• Our API is OpenAI-compatible. Useful, and it covers one layer of seven. It says nothing about fine-tunes, embeddings or your evaluation suite.
• You can export your data at any time. In which format, over how long, and does it include embeddings, adapters and logs? Unqualified export rights usually mean nobody has tried.
• We are built on open source. Open components under a proprietary orchestration layer still ports badly. Ask which part you could actually run yourself.
• No customer has ever left. Presented as loyalty, read as an untested exit path.
• We will support a migration if it comes to that. Without a window and a price, that is goodwill, not a commitment.

How to run the assessment in a week

Pick one production workload. Write down what it would take to run it on a second model this quarter, and stop guessing where you are uncertain: ask the vendor the specific question and record the answer with a date. Then run the workload on an alternative for one day against your evaluation set. You will finish the week with an exit cost expressed in weeks, euros and quality delta, which is the only form of the answer that survives contact with a supervisor, a board, or a renewal negotiation.