--- title: "AI vendor lock-in: exit strategy and independence from suppliers" url: https://zerofive.ai/en/blog/strategy/ai-vendor-lock-in canonical: https://zerofive.ai/en/blog/strategy/ai-vendor-lock-in language: en published: 2026-05-14 updated: 2026-09-18 author: "ZeroFive.AI" tags: AI vendor lock-in, technology lock-in, supplier exit strategy, AI vendor independence, AI data portability abstract: "The four forms of lock-in in AI projects, what they really cost and how to design the exit strategy at the entrance: abstraction, clauses, portable data." --- # AI vendor lock-in: exit strategy and independence from suppliers There is a precise moment when lock-in gets decided, and it is not when you realise you are captive: it is at signature, when the supplier is courting, discounts rain down and the exit clause looks like a pessimistic detail to postpone. In AI this old enterprise software mechanism has become faster and subtler, because dependencies form in weeks instead of years, and some never pass through the contract at all. From a vendor-agnostic position, the topic matters to us for a professional reason: the client's independence is the condition under which our recommendations are worth anything. ## The four forms of captivity The first form is behavioural lock-in, the newest and the most underestimated. Prompts, workflows and evaluations get tuned to the behaviour of a specific model, and after months of refinement the system works because that model answers that way: changing provider means redoing the tuning, and the cost appears on no invoice, it sits in the months of accumulated work. The second form is lock-in on data and derived artefacts: embeddings computed in a proprietary format, fine-tunes living only on the provider's infrastructure, histories of conversations and feedback that come out, when they come out, in unusable formats. The third form is platform lock-in, the classic one: the more a use case integrates with an ecosystem's accessory services (orchestration, vector stores, evaluation tools, connectors), the more the exit stops being a model migration and becomes an architecture relocation. The fourth is contractual, and it lives in the clauses nobody negotiated: prices revisable unilaterally, short deprecation notices, ambiguous rights over the customisations built on top of the product. The cost of captivity, in all four forms, presents itself the same way: at renewal, when the supplier knows leaving would cost you more than the increase, and the negotiation happens with only one side holding alternatives. ## The insurance is bought at the entrance The effective exit strategy has the uncomfortable property of needing to be designed when nobody feels the need, and its components are known. On the technical side, the abstraction layer we wrote about regarding infrastructure: applications talk to an internal interface and never directly to the single provider, so that substitution is a configuration change. Alongside it, the evaluation golden set kept in-house, which turns the question "would the alternative model work?" from a debate into an afternoon of tests, and the discipline of keeping data, feedback and artefacts in portable formats, with the export actually tested at least once, because a portability clause never exercised is a written hope. On the contractual side, the clauses that matter get negotiated when the supplier wants you: guaranteed export formats and timelines, minimum notice on deprecations and price changes, clear ownership of customisations, and for critical workloads the option of a second qualified supplier, even just kept warm on a fraction of the traffic, which is the most concrete form of negotiating power in existence. ## What independence is worth, in numbers The insurance has a premium, and it is fair to say so: the abstraction layer costs engineering, the second supplier costs management, portable formats cost discipline. The correct question is not whether the premium is zero, it is how it compares with the expected damage, and the comparison is made through an exercise we recommend putting on the agenda once a year: for every critical dependency, estimate the time and cost of a forced exit within ninety days, as one does with continuity plans. The figures that come out usually close the discussion about the premium. Finally there is a balance to declare, because independence taken to the extreme becomes a cost itself: building every component in-house so as to depend on nobody is the most expensive form of lock-in, the one towards your own past. The sensible goal is not depending on nobody, it is that every dependency be chosen, measured and reversible at a known cost. It is the criterion with which, in our AI Strategy work, we design architectures and contracts together with clients, with the exit strategy as a design requirement and never as a remedy: calendly.com/fabiolalli/zerofive, or hello@zerofive.ai. The test to run this week costs one question to your team: if the main supplier doubled its prices at the next renewal, what would saying no actually cost us?