AI vendor lock-in — when the model is not the only dependency

Lock-in is not just the logo on the model

In classic SaaS, lock-in is often visible in the data, the API and the contract. In AI it is trickier: the model is the visible part, but the dependency also grows through prompt templates, tools, eval sets, security exceptions, internal approvals and billing practices. A company is not only changing a vendor. It is changing the work process that grew around the model.

That is why asking only “which model is best” is weak. The better question is: what breaks if we replace this model, cloud or agent platform in six months?

Where the dependency sticks to the system

The first layer is contractual: cloud commitment, enterprise agreement, regional availability, data processing terms. The second layer is technical: API shapes, tool use formats, embeddings, fine-tuning artifacts, sandboxing, logging and integration with internal systems. The third layer is operational: who approves changes, who pays for tokens, how quality is measured and how fast the team can stop an incident.

Technical dependency is not unique to generative AI. Hidden Technical Debt in Machine Learning Systems describes how connections between data, models and surrounding code increase system maintenance costs. A vendor migration can expose those connections.

Dependencies disguised as convenience are difficult to estimate. One button, one provider, one account, one integration. Beautiful during a pilot. Expensive when pricing, compliance requirements or model quality changes.

Portability is not free

A multi-model architecture sounds attractive, but it is not a magic insurance policy. Every model has different limits, behaviour, pricing and failure modes. If an application only switches endpoints but has no quality tests, tool interface, test data and defined failure handling, it is more a chaos switch than a strategy. A fallback model must not silently receive data that the applicable rules prohibit sending to it.

Good portability means exportable domain data, your own quality tests, tool interfaces separated from one SDK, and logs that support before-and-after comparisons. For example, MCP standardises how applications connect to tools and context. That does not imply that different models will perform a task equally well. Portability needs to be demonstrated in a trial.

What procurement, engineering and legal should watch

Procurement watches price, commitments and termination options. Engineering watches latency, quality, APIs, observability and real error handling. Legal and security teams watch data, audit, jurisdiction, liability and export or sector limits. In AI, these three views cannot be handled separately, because a pricing change can change the architecture, and an architecture change can change the risk.

A practical test is simple: can we name the five most expensive places where our current AI vendor holds us? If not, lock-in may already exist; it just has not been named.

Build with an exit path

Start with a short list of rules. Critical workflows need an eval set and an audit log. Sensitive data should not unnecessarily end up in a provider-specific format. Prompts, tool schemas and retrieval pipelines should be versioned like code. A model decision should have a next review date, not religious status.

An exit path does not mean every system must run on five models. It means you know what leaving would cost, what would need to be rewritten and which tasks are important enough to deserve a second option. Lock-in is not always bad. Bad lock-in is the kind the team discovers only when it needs to leave.

Example: a trial migration of a support assistant

Choose approved test questions without personal data and run them against the original and alternative systems. Compare answer accuracy, citations, incorrect tool calls, cost and latency. Include the effort needed to export documents and rebuild retrieval. If new embeddings are needed, budget for rebuilding the index. The result should identify concrete dependencies and costs, rather than merely show a successful API response.

Sources

• Hidden Technical Debt in Machine Learning Systems — system dependencies and ML maintenance costs.
• MCP: Architecture overview — the scope of tool and context integration standards.