Vendor Lock-in
Vendor lock-in is the condition in which a customer cannot move to a different supplier without prohibitive cost, effort, or risk, so that the incumbent vendor gains pricing power and the customer loses bargaining leverage. It predates AI: enterprises experienced it with proprietary databases, operating systems, and cloud platforms. In AI it takes familiar forms and some new ones tied to how models work, because prompts, embeddings, fine-tuned weights, and evaluation data can all be quietly coupled to one provider's model in ways that are not obvious until a switch is attempted.
Proprietary APIs and features are the most visible source of lock-in, since each provider exposes its own request formats, tool-calling conventions, safety filters, and special capabilities. Code written against one vendor's SDK, structured-output schema, or assistant and agent framework must be rewritten to move. The OpenAI chat-completions format has become a de facto interface that many other providers and open-source servers imitate, which eases portability for basic calls, but advanced features such as built-in tools, long-context caching, and batch or realtime endpoints are often not interchangeable. More subtle is behavioral lock-in: prompts are tuned to one model's quirks, so another model given the same prompt can produce different formats, refusals, or quality, and the application's tests may have been written implicitly around that behavior.
Embeddings are a particularly sticky form of lock-in because vectors from different models are not comparable. An embedding model maps text to a point in its own learned space, with its own dimensionality and geometry, so vectors from two models cannot be mixed in one index and similarity scores are meaningless across them. Changing the embedding provider therefore means re-embedding the entire corpus, which costs compute, time, and index rebuilds, and the vector database layout, if built around one dimension, may also need changes. Teams sometimes realize this only after indexing millions of documents. Storing the original text and metadata separately from the vectors, and recording which model and version produced each vector, keeps the re-embedding path open.
Data formats, egress charges, and fine-tuned artifacts compound the problem. Moving large datasets out of a cloud provider can incur data-egress fees, and proprietary storage or logging formats can make exports lossy. Fine-tuning a model on a vendor's hosted platform usually produces weights that remain on the vendor's infrastructure and cannot be downloaded, so the investment in curated training data is portable but the trained artifact is not, and the process must be repeated on a new base model. The European Union Data Act (Regulation 2023/2854), which applies from September 2025, includes provisions intended to make switching between cloud data-processing services easier and to phase out switching charges, an example of regulation treating lock-in as a competition and consumer concern.
Mitigation is mostly architectural and contractual, and it is cheapest when done early. An abstraction layer, a single internal interface that routes calls to interchangeable provider adapters, localizes vendor-specific code; open-source libraries such as LiteLLM or frameworks like LangChain offer this role, though each adds its own dependency, so a thin in-house wrapper is sometimes safer. Maintaining a model-agnostic evaluation suite lets a team measure a candidate replacement within days. Open-weight models, such as Meta's Llama and Mistral's releases, offer an exit path because the weights can run on any compatible infrastructure, and standard formats such as ONNX or GGUF reduce runtime coupling. Contracts can add data-portability, deprecation-notice, and price-protection terms, since vendors retire model versions on their own schedule and can force unplanned migrations.
Lock-in is a trade-off, not an evil, and a common mistake is to over-engineer against it. Deep use of a vendor's integrated platform can deliver speed, support, and reliability that a portable lowest-common-denominator design cannot, and an abstraction layer that hides useful features may cost more than the risk it removes. Open-weight models also carry operational lock-in of their own, to the hardware and serving stack. The sensible approach is to identify what would be expensive to rebuild, keep that portable, and accept coupling elsewhere with eyes open. This is part of the wider build versus buy and total-cost-of-ownership analysis.
Read vendor lock-in as the accumulated switching cost of prompts, vectors, weights, and data, which stays small only if the exit is designed before it is needed.