AI Vendor Lock-In Starts Early
The model may be replaceable. The system wrapped around it creates the bill.
5
dependency layers to track before a vendor change
1
owned contract between your workflow and any model
Jan 2027
EU Data Act switching-charge phaseout for cloud services
What you actually bought
A chatbot is easy to replace in a slide deck. A working agent is different. By the time it touches a CRM record, writes a brief, routes a refund, drafts a campaign, or hands work to a person, the vendor choice has become part of your operating model.
The old version of this article treated that risk like a neat cost curve. That was too tidy. The better version starts with a less convenient truth: switching costs are mostly the things no one recorded while the system was getting useful. Prompt edits. Tool exceptions. Safety workarounds. Quality rubrics. Human override rules. Vendor support notes. The invoice is easy to export. The behavior is not.
Cloud buyers already know the pattern. The UK Ofcom cloud referral named egress fees and technical barriers to interoperability as features that can discourage switching or multi-provider use. The CMA cloud services investigation kept that question alive through a final decision in July 2025. AI does not erase that old lock-in problem. It adds behavior on top of infrastructure.
The work around the model
Modern AI vendors are no longer selling raw completion boxes. OpenAI's Responses API migration guide describes a single interface for agent-like applications, built-in tools, multi-turn state, multimodal inputs, and remote MCPs. Its tools documentation adds web search, file search, function calling, programmatic tool calls, and third-party services into the same workflow surface.
That is useful. It is also sticky. Once your agent's behavior depends on built-in retrieval, tool selection, stored context, or one provider's streaming format, a swap means more than changing the model name. You have to prove the new system calls the right tool, stops at the right point, preserves the right context, and gives the human reviewer enough evidence to trust it.
Anthropic's Sonnet 5 migration notes show why this is normal even inside one vendor family. The page lists behavior changes such as adaptive thinking, unsupported sampling parameters, tokenizer differences, and toolset changes. Google's Gemini migration guide recommends thorough prompt testing and, for some apps, online comparison through A/B tests, canary deployments, or shadow mode. The safest reading is simple: model movement is product work.
The dependency stack
The lock-in stack has five layers. They arrive in a predictable order because teams start with the model, then wrap it in the work needed to make the model useful.
First comes model behavior: prompt tone, reasoning budget, output shape, refusal rate, latency, and cost. Then comes tool shape: function schemas, authentication, error handling, retries, permissions, and data scopes. After that comes memory and retrieval: embeddings, indexes, source records, user context, and the logs that explain a past answer. Fourth comes evaluation: accepted examples, rejected examples, graders, human review notes, and release thresholds. Last comes approval: procurement, security, legal, brand, and operations agreeing that a replacement can act.
Where the exit gets expensive
The first month of an agent program feels portable because the code still fits in one mental model. By month six, the system has learned from every exception. A marketer edits the brand voice. A support lead adds a refund guardrail. Legal narrows what the agent can say. Sales asks for a custom handoff. Each fix is reasonable. Together, they become a private operating system.
Evaluations are where the private system either becomes portable or turns into folklore. OpenAI's evaluation guidance says generative AI variability makes traditional software testing insufficient, then points teams toward task-specific tests, logs, metrics, comparison, and human agreement. NIST's Generative AI Profile frames AI risk work across the lifecycle, including design, development, use, and evaluation.
Those are the parts that keep switching from becoming superstition. If the team can replay real work, compare outputs, inspect tool calls, and show why a replacement cleared the bar, migration becomes an operating decision. If the proof only lives in the current vendor's dashboard, renewal has already won the argument.
The useful artifact is a migration rehearsal, even when no migration is planned. Pick ten real tasks from the last month: a messy support exchange, a high-value lead qualification, a refund request, a regulated claim, a campaign brief, a data lookup, a multilingual response, an escalation, a failed tool call, and a human override. Run them through the current stack and a candidate stack. Compare the output, the trace, the reviewer decision, and the time to fix the miss. That exercise turns lock-in from a mood into a backlog.
Vendors can move the floor
Model retirement is ordinary infrastructure risk. Amazon Bedrock documents models as Active, Legacy, or End of Life, and says a model stays on Bedrock for at least 12 months before EOL. Its FoundationModelLifecycle API exposes fields such as status, legacy time, and end-of-life time.
Microsoft is just as direct. Its Foundry Models lifecycle policy says retired models return `410 Gone`, provisioned deployments are not auto-upgraded, and customers should evaluate candidate models against their own prompts, data, quality, latency, and cost. OpenAI's deprecations page lists shutdown timelines for products such as reusable prompts, the Evals platform, Agent Builder, and older model snapshots. Google Cloud's Vertex AI release notes include product and endpoint deprecations with migration windows.
None of that makes these vendors careless. It proves the category moves fast enough that lifecycle management has to be part of the buyer's architecture. A good vendor gives notice. A disciplined buyer has a place to put that notice.
The place to put it is boring by design: an owner, an inventory, a retirement calendar, and a replacement lane that can be tested before the deadline is emotional. When a model moves from active to legacy, the question should be procedural. Which workflows use it? Which prompts changed since the last evaluation? Which logs prove quality? Which contract clause controls support during migration? If those answers require a rescue meeting, the system was already too dependent.
Build the portability boundary
Portability does not mean pretending every model is the same. It means your application talks to an owned contract first, then lets adapters translate into whichever provider is approved for the job.
Cloudflare's AI Gateway REST API announcement describes one API for models from OpenAI, Anthropic, Google, and Workers AI, with logging, caching, rate limits, and guardrails applied through the gateway. Its fallback documentation shows model or provider fallbacks triggered by request errors or timeouts. Portkey's AI Gateway docs describe a universal API, fallback, conditional routing, load balancing, canary testing, and budget controls.
Those tools can help, but they are not a strategy by themselves. A gateway with no eval suite only centralizes uncertainty. A router with no owner can send work to a cheaper model while quietly changing the customer experience. Treat multi-LLM routing as a control layer, not a souvenir from a vendor demo.
Procurement has one job
The buyer's job is to make exit terms visible before performance gets addictive. That means notice periods, data export, log access, model lifecycle alerts, support during migration, price-change rules, and a written list of features that will not be portable.
Regulators are already pushing that direction in cloud. The European Commission's Data Act explainer says providers of software and platform services must make open interfaces available and export data in a commonly used, machine-readable format. It also says switching charges, including data egress charges, are set to be removed from January 12, 2027. AI buyers should not wait for every model platform to be forced into the same discipline.
Ask the awkward questions while the vendor still wants the deal. Which artifacts can we export? Which logs do we own? Can we test a replacement in parallel? Can we keep our fine-tune or eval data? What happens if a feature moves, a model retires, or a safety rule changes the output? The answer does not need to be perfect. It needs to be written down.
The quarterly audit
Do the audit every quarter, and do it before renewal season. The goal is not to prove the vendor was a mistake. It is to keep the company aware of where the dependency is getting heavier.
A useful audit ends with three lists: dependencies we accept, dependencies we will reduce, and dependencies that need contract protection. Pair that with a live replacement test for the workflows that matter. If the agent supports revenue, customers, compliance, or paid media, a dry-run migration is cheaper than improvising during a sunset.
Model behavior
Which prompts, examples, schemas, or style rules only pass because the current model behaves a certain way?
Tool contract
Which internal tools assume one vendor's function format, error shape, retry behavior, or state model?
Memory and retrieval
Where do logs, embeddings, files, citations, and customer context live, and how fast can they be exported?
Evaluation proof
Can the team replay real work against a replacement and compare quality, latency, cost, and approval rates?
Human authority
Who can approve a model swap, freeze a risky release, or accept a temporary quality drop during migration?
Commercial exit
What notice, migration help, price protection, support, and data return are actually written into the agreement?
Vendor risk and product-sunset risk belong in the same conversation. Read this with the AI vendor discontinuance playbook and the multi-LLM routing guide before the next renewal turns optionality into a line item.
FAQs
What is AI vendor lock-in?+
AI vendor lock-in is the cost of leaving a model or agent platform after prompts, tools, memory, data flows, evaluation rules, approvals, and team habits have been built around it.
Are agentic AI switching costs different from SaaS switching costs?+
Yes. A SaaS migration usually moves records and business process. An agentic AI migration also has to requalify behavior, tool calls, memory, retrieval, policy controls, and human review thresholds.
Should every company use multi-model routing?+
No. Routing adds engineering, testing, security, and vendor-management work. It pays off when a workflow has enough volume, risk, variation, or uptime pressure to justify a controlled model boundary.
What is the first move to reduce lock-in?+
Write down the portable contract for the workflow: inputs, allowed tools, expected outputs, evidence requirements, handoff rules, quality checks, and the owner who can approve a replacement model.
What should procurement ask an AI vendor?+
Ask for model lifecycle notice, export rights, log access, data portability, feature parity limits, price-change rights, support during migration, and what happens if a model or product is retired.
The cheapest time to build the exit
is before the agent is good.