AI was supposed to give companies an advantage. It can also create a new dependency
A few years ago discussions about vendor lock-in mainly focused on cloud, ERP systems, databases or key technology platforms.
Companies asked themselves questions: Can we move the application to another cloud provider?, Can we change the database?, Can we leave a specific system?
Today another element is added to that list - artificial intelligence.
Organizations increasingly build systems using language models, generative AI, RAG solutions, process automation and AI agents. Models become part of applications, sales processes, customer support, document analysis, decision systems and the daily work of teams.
In practice this means a company can begin to depend not only on specific software but also on a specific provider of the intelligence used by its systems.
And here the problem appears. Because using an AI service is one thing. Being dependent on it is another.
This is precisely the difference between a conscious technological dependency and vendor lock-in.
What exactly is AI Vendor Lock-in?
Vendor lock-in means a situation in which an organization is so tightly bound to a single technology provider that switching to a competing solution becomes difficult, costly, time-consuming or risky.
In the AI world it can take many more forms than the classic dependence on one API.
A company may be dependent on:
- a specific AI model,
- a specific API provider,
- a particular communication format,
- features available only from one provider,
- an agent system,
- cloud infrastructure,
- the way data is stored,
- a specific embedding mechanism,
- a particular RAG system,
- the way agents call tools,
- prompts optimized for a specific model,
- team skills tied to one ecosystem.
Therefore the question: "Are we using OpenAI?"
is definitely too simple.
A better question is: "How hard would it be for us to change AI providers if we had to do it in six months?"
If the answer is: "We don't know." - that may be the first warning sign.
OpenAI, Anthropic, Google - does provider choice matter?
There are several very strong ecosystems of models and AI services on the market today, including solutions offered by OpenAI, Anthropic and Google.
Each of these providers develops their own models, APIs, tools and additional services.
The problem is not that any of them is "bad". Quite the opposite.
Using ready-made, high-quality models is often the best business solution. Not every company should train its own model. Not every company needs its own GPU infrastructure. Not every company should build the entire AI stack from scratch.
Using an external provider allows faster time-to-market, lower initial costs and access to technology that would be out of reach for most organizations to build on their own.
The problem begins when a company stops treating the provider as a replaceable component and starts designing the entire product as if the chosen provider will remain unchanged for the next 10 years.
And that cannot be guaranteed...
Models are updated, older versions are retired, prices change, limits change, APIs change, new models appear, licensing terms change, competitive capabilities change.
That's a normal part of the technology market.
Therefore AI architecture should consider not only the question: "Which model is best today?"
but also: "What price will we pay if next year we want to use a different one?"
The biggest trap - "we'll just change the API"
At first glance migration may seem trivial.
We have an application. The application sends a request to a model. The model responds. We change the provider. Done...
In reality the situation can look completely different.
Imagine an application that has been developed around one model for two years.
During that time the team has:
- created hundreds of prompts,
- optimized their content,
- adapted the response format,
- built a RAG system,
- configured tool calling,
- created agents,
- designed workflows,
- prepared tests,
- trained users to work with the system.
After two years it turns out the model is no longer available in its current version.
Or its price increases, or a competitor model is significantly better, or the company wants to move some data to another environment.
Theoretically it's enough to change the API - practically it may turn out that the entire system logic needs to be retested.
Why?
Because models are not identical:
- They differ in how they interpret instructions.
- They differ in response quality.
- They differ in behavior over long contexts.
- They differ in how they use tools.
- They differ in handling structured output.
- They differ in multimodality.
- They differ in speed.
- They differ in price.
- They also differ in behavior in edge cases.
Therefore migration between models can be more similar to migrating an entire business component than to simply swapping a URL.
Five levels of AI Vendor Lock-in
It's worth looking at vendor lock-in more broadly.
1. Model lock-in
The simplest level.
The application is optimized for a specific model.
A prompt works great with one model but worse with another.
The system relies on specific capabilities of that model.
Changing it requires retuning.
2. API lock-in
The system uses functions specific to a particular provider.
The more specific features we use, the harder migration can be.
It's not only about generating text.
Also important are:
- structured outputs,
- function calling,
- tool calling,
- multimodality,
- context management,
- security mechanisms,
- agent systems.
3. Data lock-in
Data can be stored in a way tightly tied to a specific ecosystem.
This also applies to:
- embeddings,
- vector indexes,
- metadata,
- interaction history,
- RAG configuration.
Migration may require not only moving data but reprocessing it.
4. Architecture lock-in
This is a much more serious level.
The entire application was designed around one provider.
Its mechanisms are present in many places in the system.
In such a case we do not replace a single component.
We rebuild part of the architecture.
5. Organizational lock-in
This is often the most underestimated problem.
The team knows one ecosystem.
All competencies are focused around one solution.
Documentation, procedures, tests and know-how are tied to one provider.
Even if technically it's possible to change the model, the organization lacks people who can carry out that change.
Then vendor lock-in ceases to be purely a technological problem.
It becomes a business problem.
Does Multi-Model solve the problem?
The natural response is: "If one provider is a risk, let's use several."
However, that's not always the best strategy.
Multi-model architecture has its costs.
You have to manage:
- multiple APIs,
- different limits,
- different pricing models,
- different quality levels,
- different response formats,
- tests,
- monitoring,
- security.
The system becomes more complex.
Therefore the goal should not be: "We must use five providers."
The goal should be: "We must be able to change providers if the business needs it."
That's the crucial difference.
Not every company needs Multi-Model.
Every company should, however, know what migration to another model would look like.
AI Gateway and Model Gateway - a layer that separates the application from the provider
One way to reduce dependency is to use an intermediate layer.
It can serve as an AI Gateway or Model Gateway.
In simple terms the architecture can look like this:
Business application
↓
AI abstraction layer
↓
Model routing
↓
Provider adapter
↓
OpenAI / Anthropic / Google / open-weight model / local model
Thanks to this the business logic of the application does not need to know the details of each provider directly.
We can have our own layer responsible for:
- model selection,
- routing,
- fallbacks,
- cost control,
- monitoring,
- logging,
- security policies,
- quota management.
In case of one provider's outage the system can try to use another model.
If prices rise we can change routing.
If a better model appears we can run tests and decide on migration.
This does not mean the change will always be painless.
It does mean the change has been designed as a real possibility.
Model Router - AI does not always have to pick the same model
An even more interesting solution is model routing.
Imagine a system that receives different tasks.
A simple task: "Summarize this text."
It can be sent to a fast, cheap model.
A more complex task: "Analyze the document and prepare a detailed recommendation."
It can go to a stronger model.
A task requiring image analysis can go to a multimodal model.
The system can therefore dynamically choose the model for each task.
This allows optimizing:
- costs,
- quality,
- response time,
- availability.
In such an approach the AI provider stops being an integral part of business logic.
It becomes one element of the infrastructure.
And that is a very important architectural shift.
Abstraction does not mean all models are the same
Here one trap must be watched for.
You can create your own function: generateText() and assume the problem is solved.
It is not.
Models are not interchangeable LEGO bricks.
If the application uses capabilities specific to a given model, a simple abstraction may only hide the problem.
Good architecture should therefore abstract from the provider while consciously managing differences between models.
In practice that means the AI layer should know that a model can have different:
- capabilities,
- limits,
- costs,
- quality levels,
- features,
- contexts,
- parameters.
Thus designing "provider-agnostic" should not mean pretending every model is the same.
It should mean the system can consciously use differences between models.
Evals - without them AI migration is guessing
One of the most important elements of architecture resilient to change are evals, i.e., systematic tests of model performance.
Assume we have 1000 real use cases. We run them on the current model. Then run them on the new one. We compare results.
We check:
- quality,
- correctness,
- completeness,
- hallucinations,
- compliance with requirements,
- response time,
- cost.
Only then can we say: "The new model is good enough."
Without evals migration can look like an experiment. With evals it becomes an engineering process.
Therefore a company using AI should build its own test suites. Not only test the API. Test the own business case. That's a huge difference.
Prompts can also be a source of vendor lock-in
Prompts are often treated as text. In practice they can become part of business logic.
If over many months a team optimizes instructions for a specific model, a prompt can start to act like a piece of code.
They should therefore be:
- versioned,
- tested,
- documented,
- monitored.
It's also worth knowing which prompts are critical to system operation. If changing the model degrades their effectiveness, we need to know where to look for the problem.
Therefore prompt engineering in mature AI systems should increasingly be treated as part of software engineering.
Open-weight and self-hosted models - is this an escape from vendor lock-in?
Open-weight models and the ability to run models on your own infrastructure increase control over technology.
But that does not automatically mean full independence.
If we move a model to our own infrastructure we still need:
- GPUs,
- infrastructure,
- MLOps,
- monitoring,
- security,
- updates,
- skills.
We can thus reduce dependence on a model provider but at the same time increase dependence on an infrastructure provider. We can also run open-weight models in the cloud. Then the problem partially returns at a different level. Therefore it's worth looking at technological independence more broadly.
No system is entirely free of dependencies.
There is, however, a system in which dependencies are:
- known,
- controlled,
- measurable,
- replaceable.
The most dangerous vendor lock-in may be in the team's heads
Imagine a company that uses one AI provider.
Technically it may be able to change the model. But no one in the company knows how to do it.
The team does not know alternatives.
There are no benchmarks.
There are no evals.
There are no tests.
There is no experience with other models.
All solutions were built around one ecosystem.
This is organizational lock-in.
Therefore resilience to vendor lock-in also requires investing in competencies.
The team should understand:
- how models work,
- what differences exist between providers,
- how to build an abstraction layer,
- how to test models,
- how to measure quality,
- how to control costs,
- how to execute a migration.
It's not about every developer knowing every API.
It's about the organization not being technologically blind outside one ecosystem.
When vendor lock-in may be acceptable?
Vendor lock-in is not always bad.
Sometimes a conscious dependency is a reasonable business decision.
If:
- the provider offers an exceptional feature,
- the solution significantly shortens time-to-value,
- the migration cost is known,
- the risk is acceptable,
- alternatives are weaker,
- the business needs speed,
then a stronger tie to a single provider may be justified.
The problem is not lock-in itself. The problem is unconscious lock-in.
A company should know:
- what it depends on,
- why it depends on it,
- how much changing it would cost,
- how long migration would take,
- what the alternatives are.
Only then can it be called a conscious architectural decision.
How to assess AI Vendor Lock-in in your company?
It's worth conducting a simple audit.
Ask yourself:
Can we change the model without rebuilding the entire application?
Is business logic independent from the AI provider?
Are prompts versioned?
Do we have our own evals?
Do we have regression tests for the most important use cases?
Can we export and move our data?
Can we change embedding provider without losing data?
Do agents use an orchestration layer, or are they directly tied to a specific ecosystem?
Do we have the option to use an alternative model?
Do we have a fallback?
Do we know how much migration would cost?
Do we know how long migration would take?
Do we have people who can carry it out?
The more "no" answers, the greater the dependency.
You can also create your own AI Portability Score. For example, evaluate the organization across five areas:
Architecture - is the provider replaceable?
Data - can we move it?
Models - do we have alternatives?
Evaluation - can we compare models?
Competencies - can the team perform migration?
Such a score does not have to be a formal standard. It can, however, be a very good management tool.
Because sometimes the biggest problem is not vendor lock-in. The biggest problem is that the company does not know it has one.
How to design AI architecture resilient to change?
There is no single universal architecture. However, several practical rules can be applied.
Rule 1 - separate business logic from the AI provider
Don't build the entire system directly around one API.
Rule 2 - use an abstraction layer where it makes sense
An AI Gateway or Model Gateway can reduce application dependency on a specific provider.
Rule 3 - version prompts
Treat them as part of the system, not loose text.
Rule 4 - build evals
Don't assume "the new model works."
Check it.
Rule 5 - test alternatives
You don't have to use them in production.
But it's worth knowing how they handle your use cases.
Rule 6 - control data
Don't let your business data become a hostage of one platform.
Rule 7 - document dependencies
Knowing where the system is tied to a specific provider is part of architectural documentation.
Rule 8 - don't abstract by force
Don't hide differences between models just to get apparent portability.
Rule 9 - measure migration cost
It's not enough to say:
"We can change provider someday."
You must know:
"We need three months and five people for that."
Or:
"We cannot do this without rebuilding the system."
Rule 10 - make conscious decisions
Sometimes the best solution will be a strong tie to one provider.
But it should be a conscious risk.
Not an accident.
The question every CTO should ask
Imagine tomorrow the AI provider:
- doubles prices,
- retires the model we use,
- changes limits,
- restricts a function our product depends on,
- stops meeting our compliance requirements.
What do we do?
If the answer is: "We will change the provider."
the next question should be: "How long will it take us?"
A day?
A week?
A month?
Half a year?
Or maybe we don't know?
That is precisely the measure of our technological resilience.
Summary - it's not about not having a provider
Building a system completely independent of external AI providers can be uneconomical, unnecessary or even impossible.
That's not the point.
The goal is not the absence of dependency. The goal is conscious management of dependencies.
We can use OpenAI. We can use Anthropic. We can use Google. We can use open-weight models. We can combine different solutions.
The most important thing is to know where the boundary runs between: "we use technology" and "we are dependent on it".
In the AI world this boundary can be especially hard to notice. Because vendor lock-in does not appear in one day. It emerges gradually. First we integrate an API. Then we build a feature. Then we add RAG. Then agents. Then we automate a process. Then the whole team begins to work according to that system. And suddenly it turns out that changing the model is no longer a change of a model - it's a change of part of the organization.
Therefore AI architecture should be designed with not only what works today in mind, but also what will happen when the technology world changes tomorrow.
You don't have to build a system that works without OpenAI, Anthropic or Google. But you should build a system that can also work if one of them disappears.
This is precisely the difference between using AI and consciously designing AI technology.
