AI Applications
What Is Vendor Lock-In in AI? The Costs Nobody Puts in the Proposal
Vendor lock-in in AI happens when your product, data or workflows become so dependent on one provider's models and tools that leaving costs more than staying. This article explains where the lock-in actually sits (prompts, embeddings, fine-tunes, agent frameworks), how to spot it early, and what a sensible exit plan looks like for Indian startups and teams building on OpenAI, Anthropic, Google or a managed platform.
CSEWhy ·
Vendor lock-in in AI happens when your product, data or workflows become so dependent on one provider's models and tools that leaving costs more than staying. This article explains where the lock-in actually sits (prompts, embeddings, fine-tunes, agent frameworks), how to spot it early, and what a sensible exit plan looks like for Indian startups and teams building on OpenAI, Anthropic, Google or a managed platform.
The short answer
Vendor lock-in in AI is when your system becomes so tightly bound to one provider's models, APIs, tooling or data formats that moving to another provider costs more time and money than it is worth. So you stay. And the vendor knows you will stay, which is exactly why lock-in matters commercially and not just technically.
It is the same idea as cloud lock-in, with one difference that catches teams out. Cloud lock-in is mostly about infrastructure you can, in principle, replicate elsewhere. AI lock-in is about behaviour. When you swap GPT-4o for Claude or Gemini, the code change takes an afternoon. The output changes, and your users notice. Your prompts were tuned to one model's quirks, your evaluation set was built around its failure modes, your guardrails were written for its refusal style. That is the real switching cost, and it does not appear on any invoice.
Where the lock-in actually hides
Most teams think lock-in means the API. It rarely does. The OpenAI chat completions format has become a near-standard, and half the ecosystem mimics it. The stickiness sits deeper, in places nobody audits until the migration meeting.
Embeddings are the worst offender. If you have indexed two million support tickets using one provider's embedding model, those vectors are meaningless to any other model. There is no converter. Switching means re-embedding everything, which costs compute, engineering time and a fresh round of retrieval testing. Teams discover this at the point where their vector database has grown past the size where a weekend re-index is possible.
Fine-tunes are the second. A fine-tuned model on a hosted platform is usually not yours to take. You can export nothing useful. Your training data is yours, the resulting weights are not, and rebuilding the same behaviour on a different base model means starting the whole evaluation cycle again.
Then there is the quieter layer: agent frameworks, proprietary tool-calling schemas, managed RAG pipelines, a vendor's own function-calling dialect. Every one of these is a decision you will have to unmake.
| Layer | How locked in you are | What switching actually costs |
|---|---|---|
| Chat/completion API calls | Low | Hours. Most SDKs are near-interchangeable. |
| Prompts and system instructions | Medium | Weeks of re-tuning and re-testing per major feature. |
| Embeddings and vector index | High | Full re-embed plus retrieval quality regression testing. |
| Hosted fine-tunes | Very high | Weights are non-portable. Rebuild from scratch. |
| Proprietary agent/orchestration framework | High | Rewrite of orchestration logic and tool definitions. |
| Data residency and compliance setup | Medium to high | New DPA, new audits, new legal review. |
Why this got worse in the last two years
In 2023, most companies used one model for one thing. Summarise this, classify that. Lock-in was shallow because the integration was shallow.
That has changed. AI has moved from a feature to a dependency. A support team running an AI agent on WhatsApp, an ops team with an invoice-reading pipeline, a sales team whose CRM enrichment runs on an LLM: those are load-bearing systems now. When the vendor raises prices 40 percent, deprecates a model you built on, or changes a safety filter so your legitimate use case starts getting refused, you do not have a technical problem. You have a business continuity problem.
Model deprecation is the one people underestimate. Providers retire models on their own schedule, not yours. Even staying with the same vendor can force a migration you did not plan, because the exact model version your prompts were tuned against no longer exists. That is a useful reframe: you will migrate models whether or not you change vendors, so the ability to migrate cheaply is worth building regardless.
How to keep the exit door open without over-engineering
The wrong response to lock-in is to build a vendor-agnostic abstraction layer for everything on day one. That is how six-month platform projects are born for products with 200 users. Portability has a cost, and you should pay it selectively.
A practical rule: abstract what is expensive to redo, accept lock-in where redoing it is cheap. Your embedding choice and your evaluation harness deserve real thought. Your prompt for a one-off internal summariser does not.
Here is the order I would actually work in:
- Own your data before anything else. Prompts, training examples, conversation logs and human corrections should live in your database, not only inside a vendor dashboard you can't fully export.
- Build an evaluation set of 100 to 300 real cases with known-good answers. This is the single highest-leverage anti-lock-in asset you can own, because it turns "will another model work?" from a guess into a two-hour test.
- Route model calls through one thin internal function rather than scattering vendor SDK calls across 40 files. Thin, not clever.
- Keep the raw source text alongside your vectors so you can re-embed without re-scraping or re-parsing anything.
- Run a second provider on 5 percent of traffic for anything business-critical. It costs little and tells you your real migration gap.
- Read the contract for data usage rights, deprecation notice periods and export terms. Notice period matters more than price.
The version of this problem most Indian businesses actually have
For a lot of MSMEs and mid-sized companies, lock-in is not about choosing between OpenAI and Anthropic. It is about a vendor who built an AI workflow for them and now owns the whole thing. The automation lives in someone else's account. The prompts are undocumented. The integration credentials sit with an agency. Nobody internally can explain what happens between the WhatsApp message arriving and the reply going out.
That is worse than model lock-in, because it is people lock-in. The fix is not technical sophistication. It is insisting that automations run in accounts you control, that logic is documented in plain language, and that at least one person on your team understands the workflow end to end.
This is the point where reading stops helping and building starts. If you are designing AI workflows for your own business and want them built so ownership stays with you, that is the shape of work we do through AI Automations, and it usually starts with one honest conversation about your existing process rather than a tool recommendation. If you are the person inside a company who needs to understand this well enough to make the call yourself, the AI Masterclasses are built for exactly that gap.
Lock-in is not something you avoid. It is something you price, and then decide how much of it you are willing to buy.
FAQs
1. Is open-source AI the only way to avoid vendor lock-in?
No. Self-hosting an open-weight model removes provider dependency but adds infrastructure, GPU cost and MLOps burden, which is its own kind of commitment. Most teams get 80 percent of the portability benefit by owning their data and evaluation sets while still using hosted APIs.
2. How much does it actually cost to switch LLM providers?
For a simple integration, a few engineering days. For a production system with a large vector index, fine-tuned models and tuned prompts, budget several weeks of engineering plus re-embedding compute, and expect a period of degraded output quality while you re-tune.
3. Do model routers and gateways like LiteLLM or OpenRouter solve lock-in?
They solve the API-level part, which was never the hard part. They do not make your embeddings portable, your fine-tunes transferable or your prompts model-agnostic, and they add a new dependency of their own.
4. What should I check in an AI vendor contract to limit lock-in risk?
Look for model deprecation notice periods, your rights to export prompts, logs and fine-tuning data, whether your data is used for their training, and price-change clauses. A long deprecation notice is often worth more than a small discount.
5. Is vendor lock-in always bad?
No. Committing deeply to one provider lets you use their best features, negotiate volume pricing and move faster than a team maintaining abstraction layers. The mistake is being locked in without knowing it, or without having priced the exit.
6. What is the difference between AI vendor lock-in and cloud vendor lock-in?
Cloud lock-in is mainly about infrastructure and data egress costs, which are measurable. AI lock-in also includes behavioural dependency, because a different model produces different output even with identical code, so your product quality changes when you switch.