The standard enterprise software contract includes service level agreements, support commitments, and end-of-life notice periods measured in years. Oracle gives 5 years of Premier Support. Salesforce gives advance notice periods for major platform changes. Microsoft supports Windows releases for a decade.

AI model providers do not operate by any of these conventions. There is no contractual obligation to keep your model available, at its current price, with its current capability, for any defined period. The deprecation notice period that OpenAI gave for GPT-4o's API retirement — 90 days — is shorter than many organisations' standard release planning cycle. The restriction of GPT-5.6 to invite-only access happened with no transition window at all. Both events demonstrated a fundamental asymmetry that most enterprise AI planning has not yet accounted for: you are building production-critical infrastructure on a platform whose availability, pricing, and access conditions are entirely outside your control.

90
days notice for GPT-4o API retirement — shorter than most enterprise release cycles
OpenAI, November 2025
$315K
NexGen Manufacturing's migration cost across 40 AI workflows — 3 months of engineering time
Swfte AI, June 2026
34%
maximum AI vendor lock-in switching cost as a share of original implementation
ADVISORI, June 2026
85%
potential inference cost reduction from intelligent routing through an abstraction layer
RouteLLM / UC Berkeley

The 2026 incident record — what actually happened

The business continuity risk of AI model dependency is not hypothetical. The 2026 calendar already contains multiple documented incidents where AI model access was restricted, deprecated, or made unavailable in ways that disrupted enterprise operations. Each one demonstrates a different dimension of the same underlying risk: building on infrastructure you do not control, with no SLA protecting you when that infrastructure changes.

Feb 17
2026
GPT-4o API retired — 90 days notice, immediate failure for hard-coded integrations
OpenAI notified developers on November 18, 2025 that chatgpt-4o-latest would be retired on February 17, 2026. Preview endpoints (gpt-4-0125-preview, gpt-4-1106-preview) were deprecated by March 26, 2026. Applications with hard-coded model name references immediately returned errors on the retirement date. Teams without abstraction layers faced emergency engineering sprints to update API calls across their entire codebase.
Lesson: 90 days is shorter than a typical enterprise sprint-to-deployment cycle. Hard-coded model names are a single-point-of-failure.
Jun 25
2026
GPT-5.6 restricted to invite-only — most enterprise customers lost access without transition period
On June 25, 2026, OpenAI published the GPT-5.6 family (Sol, Terra, Luna) as a limited, invite-only preview at the US government's request. The most capable models in OpenAI's current portfolio became unavailable to most existing enterprise customers — through a policy decision entirely outside the enterprise customer's control, with no announced general-availability date and no public waitlist.
Lesson: Access restrictions can come from non-commercial forces (government, regulatory) with zero transition period. Enterprises without a fallback model had no path to the same capability level.
2026
ongoing
Builder.ai collapse — enterprises stranded, NexGen Manufacturing: $315K migration cost
Builder.ai, once valued at $1.3 billion and backed by Microsoft, collapsed — leaving enterprises across multiple industries unable to access their own AI-powered products. NexGen Manufacturing, which had 40 AI workflows built on a provider that subsequently failed, spent $315,000 and three months migrating to a new platform. Customer-facing AI features were degraded or unavailable during the migration. The CTO later stated that a provider-agnostic abstraction layer from the start would have reduced the migration from months to days.
Lesson: Provider business failure is a distinct risk from model deprecation. The migration cost — $315K and 3 months — is the documented cost of building without an abstraction layer.
Jun–Jul
2026
Sora video API sunset announced — September 24, 2026 deprecation for all Sora 2 snapshots
On March 24, 2026, OpenAI notified developers using the Videos API and Sora 2 video generation model aliases of their deprecation and removal from the API on September 24, 2026. Organisations that built video generation workflows into customer-facing products now have six months to migrate to an alternative — or rebuild features from scratch. The pattern is identical to the GPT-4o retirement: a specific, named deprecation date after which a production-tier API becomes unavailable.
Lesson: Deprecation cycles are accelerating and expanding across modalities. Text, image, video, and audio model APIs are all subject to the same lifecycle pressure.

Why AI model risk is categorically different — from every other infrastructure dependency

Every enterprise technology stack involves vendor dependencies. Cloud hosting, payment processing, CRM, email infrastructure — all of them introduce some degree of vendor risk. AI model dependency is different in kind, not just degree, for three specific reasons that do not apply to other infrastructure components.

AI model risk vs traditional software risk — the key differences
AI model API
Traditional enterprise software
Deprecation notice
90 days typical (GPT-4o); 0 days in access restriction events (GPT-5.6)
3–7 years for enterprise software; 5+ years OS support typically
Price change notice
No standard obligation; pricing has changed significantly across all major providers in 2024–2026
Governed by contract; enterprise licensing agreements define price change terms
Access conditions
Provider can restrict access for government, regulatory, or commercial reasons without prior notice
SLA defines uptime commitments with financial remedies for breach
Output consistency
Model updates can change output behaviour for the same prompt — breaking downstream processes that depend on specific output format or style
Software updates are versioned; production environments can pin to specific versions
Lock-in mechanism
Binds simultaneously at model, API, data, and infrastructure layers — making exit structurally expensive
Typically one or two layers; data portability standards exist in most enterprise categories

"When a US export-control directive took certain foundation models offline worldwide, the companies that kept running were the ones that could switch models in minutes. The ones that couldn't went dark. That is AI vendor lock-in — not a theoretical risk, but a Friday night when nothing works."

ADVISORI — AI Vendor Lock-In Enterprise Guide, June 2026

The four layers of AI lock-in — why switching costs compound

Unlike classic cloud lock-in, which typically binds an organisation at the infrastructure layer, AI vendor lock-in binds simultaneously at four distinct layers of the stack. Each layer adds migration cost independently. All four together create the 19–34% of original implementation cost that ADVISORI's 2026 analysis documents as the switching cost for tightly coupled AI systems.

Model Layer

Hard-coded model names and version-specific behaviours

Prompts optimised for one model's specific behaviour, response format, and instruction-following style often produce degraded outputs on a different model — even a newer, more capable one from the same provider. A system prompt that produces perfect structured JSON from GPT-4o may produce inconsistent output from GPT-5.1 without re-engineering. This prompt re-optimisation cost is the most underestimated migration expense.

API Layer

Provider-specific request formats, tool schemas, and response structures

OpenAI, Anthropic, and Google each use different API request formats, tool-use schemas, and response structures. Code that calls `openai.chat.completions.create()` with OpenAI-specific parameters cannot be routed to Claude or Gemini without a translation layer. Every direct API call in a production codebase is a migration task that must be manually updated when switching providers.

Data Layer

Fine-tuning data and model weights that may not transfer

Fine-tuned models — where a foundation model has been trained on proprietary data — have weights that are provider-specific. A model fine-tuned on OpenAI's infrastructure produces weights that run exclusively on OpenAI's infrastructure. Migrating to Anthropic or a self-hosted model requires starting the fine-tuning process from scratch on the new platform, with associated data preparation and training cost.

Infrastructure Layer

Provider-specific orchestration, agent frameworks, and proprietary tooling

Organisations that build agentic AI workflows on a provider's proprietary orchestration layer (OpenAI Assistants API, Google Vertex Agent Builder) compound lock-in at the infrastructure layer. If the agent framework is inseparable from the model provider, switching the model requires rebuilding the entire agent architecture. Kai Waehner's 2026 enterprise AI analysis is explicit: agents built on MCP-compatible infrastructure preserve interoperability; agents built on proprietary orchestration inherit the provider's full lock-in surface.

The architecture that accounts for it — and how to tell if your development partner uses it

The abstraction layer — an LLM router or AI model gateway that sits between application code and provider APIs — is the primary architectural defence against AI model continuity risk. It does not eliminate the risk, but it compresses the migration timeline from months to days when a model is deprecated, restricted, or repriced beyond tolerance.

Hard-coded provider architecture — most common
Direct integration: fastest to build, brittle in production
  • Application code calls `openai.chat.completions.create()` directly — provider name is in every call
  • Prompts use OpenAI-specific system prompt structure, tool schema, and response format
  • No fallback — if OpenAI API is down, the AI feature is down
  • Model deprecation requires updating every provider call across the entire codebase
  • Price increase has no mitigation path — accept the new price or rebuild
  • Fine-tuning runs on provider infrastructure; weights are not portable
Abstraction layer architecture — resilient production standard
Provider-agnostic routing: hours to migrate when a model changes
  • Application code calls a unified internal interface — no provider names in business logic
  • Router layer translates to provider-specific formats; prompt normalisation handles format differences
  • Automatic failover — if primary provider is unavailable, secondary provider handles traffic in milliseconds
  • Model deprecation requires updating router configuration, not application code
  • Price routing — complex queries go to capable models; simple queries route to lower-cost alternatives
  • RouteLLM benchmarks: 85% cost reduction at 95% capability through intelligent routing

The abstraction layer is not just a risk mitigation tool — it is also a cost optimisation tool. RouteLLM (UC Berkeley / LMSYS research) found that intelligent routing — sending complex queries to high-capability models and simple queries to lower-cost models — reduces total inference cost by up to 85% while maintaining 95% of the quality of the most capable model. For organisations with high AI query volume, the cost savings alone justify the architectural investment independently of the continuity benefit.

Provider Best for Fallback tier Open-weight alternative
OpenAI GPT-5.x Complex reasoning, code generation, highest-capability tasks Anthropic Claude (same capability tier, different provider) Llama 3.x 70B/405B (self-hosted)
Anthropic Claude Document analysis, long-context tasks, regulated industry (HIPAA BAA available) OpenAI GPT-5.x or Google Gemini Mistral Large (EU data residency), Qwen 2.5
Google Gemini Multimodal tasks, Google Workspace integration, high-volume at competitive pricing OpenAI GPT-5.x or Anthropic Claude Phi-4 (Microsoft, self-hostable)
Open-weight (Llama, Mistral) Data sovereignty requirements, regulated industries, unlimited query volume at fixed compute cost Self-hosted fallback IS the continuity guarantee — no provider can restrict access IS the open-weight option — on client-controlled infrastructure
Looking for an AI development partner?

Find agencies verified on production AI architecture — not just delivery speed

TechRadiant evaluates AI development agencies on technical delivery depth — including whether they build with abstraction layers, multi-model fallback, and provider-agnostic architecture as standard practice. The agencies in our index have been assessed on the criteria that determine whether an AI system is production-grade or portfolio-grade.

Share your AI brief → Browse verified AI agencies

How to evaluate a development partner on this — 5 questions, verbatim

The architectural maturity gap between development partners who account for AI model continuity risk and those who do not is not visible in a proposal or a portfolio. It surfaces only when you ask specific architecture questions during technical evaluation. These five questions have one-sentence answers that immediately reveal whether the partner builds for resilience or convenience.

1. "Do you build AI systems with an abstraction or routing layer by default, or is that an optional addition?"
✓ Passing answer
Describes abstraction as their default architecture with a named tool or pattern they use (LiteLLM, a custom router, a gateway pattern), and explains what it provides in terms of provider switching, fallback, and cost routing.
✕ Walk-away answer
"We can add that if you want" or a blank response. If abstraction is optional rather than default, the partner's standard build is directly coupled to a single provider. That is the architecture that produces $315K migration costs.
2. "What happens to this system if OpenAI restricts access to our primary model tomorrow — how long does it take to route to an alternative?"
✓ Passing answer
Names a specific fallback model, describes the routing configuration change required, and gives a realistic time estimate (hours for abstraction-layer systems, days if some prompt re-optimisation is needed). Has a tested fallback, not just a planned one.
✕ Walk-away answer
"We'd need to rebuild the integration" or an uncomfortable pause. This answer reveals that the system has no fallback path — which is the single largest business continuity gap in AI systems built in 2024–2026.
3. "Which open-weight model do you include in your fallback stack, and can it run on our infrastructure rather than a third-party provider?"
✓ Passing answer
Names a specific open-weight model they have deployed (Llama 3.x, Mistral, Qwen), describes the compute requirements, and confirms it runs on client-controlled infrastructure. Has experience with self-hosted model deployment, not just cloud API calls.
✕ Walk-away answer
"We use OpenAI with Google as a backup" — a second closed-weight API provider is not a true fallback. Both are subject to the same class of risk (government restriction, pricing policy, access conditions). An open-weight self-hosted fallback is the only access risk that is genuinely outside provider control.
4. "How do you handle model deprecation in your post-launch support model — what does your process look like when OpenAI announces a sunset?"
✓ Passing answer
Describes monitoring OpenAI's deprecation announcements, an evaluation process for replacement models, and a migration support commitment in the post-launch SLA. Treats model deprecation as an anticipated maintenance event rather than an emergency.
✕ Walk-away answer
"That would be a new scope of work" or no articulated process. If the partner's post-launch model does not include deprecation management, the migration cost of every future provider change falls entirely on you — without the expertise of the team that built the system.
5. "Do you use MCP-compatible agent frameworks for agentic workflows, or do you build on proprietary orchestration layers?"
✓ Passing answer
Names MCP (Model Context Protocol, now Linux Foundation / Agentic AI Foundation) as their agent connection standard, or describes a provider-agnostic agent orchestration approach (LangChain, LlamaIndex, custom) that explicitly separates agent logic from model provider. Understands why this matters for lock-in.
✕ Walk-away answer
"We build everything in OpenAI Assistants" or "we use Google's Vertex Agent Builder." These proprietary orchestration layers compound lock-in at the infrastructure level — switching the model requires rebuilding the agent framework. Kai Waehner's 2026 enterprise AI analysis identifies this as the most severe form of agentic AI lock-in.

For the broader AI development partner evaluation framework — covering security depth, IP ownership, data handling, and production track record in addition to continuity architecture — see our complete AI agency briefing and evaluation guide and our AI security checklist.