AI vendor lock-in is faster than cloud’s was — here’s why

I think AI vendor lock-in is arriving faster than cloud lock-in ever did, and I don’t think that is an accident of immature tooling. Once enterprises absorb pricing shocks, model-specific rewrites, and workforce retraining costs, the trap is already sprung.

The trap is already sprung

My contrarian view is simple: AI lock-in is not a future risk. It is a present-tense budget reality, and it is moving faster than cloud lock-in did in the 2010s. The combination that matters is not just model quality. It is pricing power plus migration friction plus an implementation workforce trained around a handful of vendors.

The recent debate did not appear out of nowhere. The Register, InfoWorld, Kai Waehner, Cloud Pro, TensorMesh, Data Center Planet, and SoftwareSeni are all circling the same issue from different angles: enterprises are discovering that the cost of switching AI vendors is much higher than the sales deck implied.

What changed is that the market now has enough evidence to stop treating AI vendor lock-in as a theoretical governance talking point. When pricing moves sharply after enterprises have already built prompts, evals, tool schemas, guardrails, and internal training around one provider, that is not just normal vendor behavior. It is the moment customers discover how inelastic they have become.

The pricing shocks are the tell

Two pricing events are why I think this debate has moved from architecture theory to procurement fact. Per the editor’s source set, Anthropic announced a price increase for Claude enterprise edition on April 15, 2026, shifting from fixed pricing to a dynamic usage-based model that could double or triple costs for heavy-duty users. The second data point is even starker: OpenAI GPT-5.2 input token pricing moved from $1.25 per million to $5.75 per million, a jump of more than 4x.

I am not arguing that vendors should never raise prices. Cloud providers did that too, often through packaging, egress, premium support, and managed-service creep. What makes this different is the speed. If a buyer signed enterprise AI contracts in 2024 or 2025 and is already facing major pricing pressure by 2026, AI vendor lock-in is not unfolding on a leisurely cloud timeline. It is compressing into months.

There is a standard defense here: pricing changes are just elasticity testing in a young market. I don’t buy that framing once the increase is this sharp and the surrounding migration costs are this high. A 4x-plus input-token increase in a year is not a harmless experiment if customers have already embedded that model into agent workflows, internal copilots, evaluation baselines, and compliance processes. It looks much more like a vendor recognizing that many customers cannot move quickly enough to discipline pricing.

Switching costs are not just technical anymore

The editor’s source set pegs the average vendor migration at $315,000. Even if that number varies by deployment size, the direction of travel is obvious. Moving an AI stack is not like swapping a database driver. You have to revisit prompts, system instructions, tool-calling conventions, safety settings, eval thresholds, latency assumptions, and often the business logic that grew around one model’s quirks.

This is where the cloud analogy starts to break down. Early cloud lock-in was painful because of infrastructure primitives, managed databases, IAM, and data egress. Enterprise AI adds another layer: prompts, eval suites, fine-tunes, and interaction traces accumulate in vendor-specific ways. That is data gravity, but with behavioral dependencies attached. The more your team tunes an agent to one vendor’s API behavior, the less portable your application becomes even if the code compiles against another endpoint.

That is why AI vendor lock-in feels stickier than the old cloud story. In cloud, a workload could often be replatformed while preserving the application’s functional behavior. In AI, changing the model can change the product itself. Same task, same prompt, same tool, different output distribution. Enterprises do not just migrate code; they re-validate behavior.

{
  "switching_cost_components": [
    "prompt and system instruction rewrites",
    "tool schema and function-calling changes",
    "evaluation baseline rebuilds",
    "fine-tune or retrieval retesting",
    "security and compliance re-approval",
    "staff retraining"
  ]
}

The consultancy pincer is making lock-in happen faster

The most underappreciated part of this story is the workforce layer. Vendors are not building lock-in alone. Consultancies are accelerating it by standardizing delivery talent around specific model ecosystems. PwC said in 2024 that it would roll out Anthropic‘s Claude to 100,000 employees and train 30,000 employees as the firm’s first Claude-powered workforce. That is not collusion. It is alignment. But the market effect is the same: future enterprise projects inherit a default.

OpenAI has made a similar enterprise push through its services and partner ecosystem. The editor notes an OpenAI Deployment Company backed by more than $4 billion in initial investment; more broadly, OpenAI’s enterprise strategy has leaned heavily on implementation partners and systems integrators. Accenture and Deloitte have also announced major generative AI practices and alliances with leading labs and hyperscalers. Once those firms hire, certify, and template around a stack, buyers are not just choosing a model. They are choosing the labor market attached to it.

That is why I think AI vendor lock-in is being amplified deliberately, even if not conspiratorially. A consultancy wants repeatable delivery. A model vendor wants durable revenue. A buyer wants a large pool of implementers. Those incentives line up around standardization. Then, when prices rise or terms change, the buyer discovers that switching vendors also means retraining the implementation army it just paid to assemble.

Why this is moving faster than cloud lock-in did

My rough comparison is this: AWS launched in 2006, but the sense of real enterprise gridlock around cloud did not fully harden until years later, once managed services, IAM sprawl, data gravity, and organizational habits piled up. You can argue about the exact year, but the editor’s framing of roughly 2006 to 2013 is directionally right. Cloud lock-in took time because enterprises first had to migrate workloads before they could become dependent on the surrounding platform.

AI is compressing that cycle because the dependency starts higher in the stack. The application behavior itself is tied to the vendor from day one. Prompts are tuned to one model’s instruction hierarchy. Tool use depends on one provider’s schema and calling conventions. Evals are calibrated to one output style. Safety and compliance reviews are written against one set of failure modes. Even emerging interoperability layers such as MCP or agent protocols do not erase the fact that model behavior remains vendor-specific.

That is the core reason AI vendor lock-in is faster than cloud’s was. In cloud, the infrastructure was sticky after adoption. In AI, the product logic becomes sticky during adoption. The lock-in clock starts earlier.

Yes, abstraction layers help. No, they do not solve production lock-in.

The strongest pushback is that multi-model portability already exists. And that is partly true. Gateways, abstraction layers, and model routers can reduce switching friction, especially in prototypes. SoftwareSeni makes the portability case directly, and many developers now design for provider optionality from the start. That is a healthy response to the market.

Still, I think this argument gets overstated once systems move into production. In real agent deployments, teams optimize around model-specific behavior: tool-call formatting, context-window assumptions, system prompt conventions, refusal patterns, latency profiles, and evaluation criteria. A portability layer can normalize the API surface. It cannot normalize the underlying model behavior. That is why a demo that swaps models cleanly on Friday often turns into a month of QA and prompt surgery on Monday.

My view is not that abstraction is useless. It is necessary. It just is not sufficient. If your board thinks an OpenRouter-style layer means there is no AI vendor lock-in, your board is confusing endpoint portability with application portability.

def is_portable(api_surface_same: bool, behavior_same: bool) -> bool:
    return api_surface_same and behavior_same

# In production AI systems, the first condition is often achievable.
# The second usually is not.

What enterprise buyers should do now

If I were buying today, I would stop treating model choice as a pure feature comparison and start treating it as a long-term commercial dependency. That means negotiating exit rights, data export terms, usage transparency, and pricing review clauses before rollout. It also means forcing every pilot to maintain a second-model benchmark, even if the primary deployment stays with one vendor.

I would also separate the layers of the stack as much as possible. Keep prompts versioned outside the vendor. Keep evals reproducible. Keep tool schemas and orchestration logic in your own codebase. Use retrieval systems and observability tooling that do not assume one model forever. None of that eliminates lock-in, but it slows the rate at which dependence compounds.

Most of all, I would resist workforce monoculture. If your internal team, your SI, and your governance process all know only one vendor’s patterns, you have already made future switching more expensive than the procurement spreadsheet admits. The practical defense against AI vendor lock-in is not ideological purity. It is preserving enough optionality that a price shock does not become a strategic crisis.

Why I do not expect the market to self-correct soon

There is a comforting theory that competition will solve this. More frontier labs, more open models, more routing layers, more standards. Some of that will help. But the vendor incentive is obvious: once a provider has enough enterprise workflow embedded around its model, raising prices or nudging customers into more proprietary features becomes rational. The consultancy incentive is obvious too: standardization lowers delivery risk and increases billable efficiency.

That is why I do not think this reverses on its own. Buyers will keep choosing the stack with the biggest talent pool, the strongest reference accounts, and the easiest path to deployment. Those are sensible local decisions. Collectively, they deepen concentration. The market can remain highly innovative and still become commercially less portable.

I could be wrong if three things happen at once: model behavior converges enough that portability becomes real rather than cosmetic; enterprise buyers insist on contractual portability before rollout; and the implementation ecosystem stops defaulting to a few vendor-centered playbooks. If those conditions emerge, this take weakens. If they do not, AI lock-in will keep arriving faster than buyers expect. I could be wrong.

Frequently asked questions

Primary sources

• The Register: Locked, stocked, and losing budget? AI vendor lock-in bites — The Register
• InfoWorld: The new AI lock-in — InfoWorld
• Kai Waehner: Enterprise Agentic AI Landscape 2026 — Kai Waehner
• Cloud Pro: Anthropic, OpenAI and Google are all locking in enterprise customers — Cloud Pro
• TensorMesh: Enterprise AI vendor lock-in — Medium
• Data Center Planet: Vendor lock-in, the hidden cost of AI — Data Center Planet
• SoftwareSeni: How to avoid enterprise AI agent platform lock-in with multi-model portability — SoftwareSeni
• Anthropic Enterprise — Anthropic

Last updated: May 22, 2026. Related: Commerce.