In March 2026, OpenAI handed its bankers a pre-IPO investor document. On the first page of the risk factors section — ahead of competition, ahead of governance, ahead of the lawsuits — sat a single sentence: if Microsoft modifies or terminates its commercial partnership, OpenAI’s “business, prospects, operating results and financial condition could be adversely affected”.
The most valuable AI company on earth is telling investors, in writing, that it depends on one partner for “a substantial portion of our financing and compute.”
If the company building the frontier model is flagging its own vendor dependency as risk factor number one, what does that imply for every enterprise that built its entire AI strategy on top of that model?
For the team building a workflow, this becomes a practical question: what could keep working if that provider changed its terms or became unavailable? It is easier to ask while the workflow is still taking shape.
The Frontier Is Warning You
The S-1 numbers make the dependency vivid. OpenAI has committed roughly $665 billion in compute spending through 2030, with $250 billion of that locked specifically to Microsoft Azure. The company projects a $14 billion net loss in 2026, driven almost entirely by infrastructure buildout. None of this is hypothetical exposure. It is contractual.
And it has already moved. The OpenAI-Microsoft relationship started in 2019 as an exclusive cloud arrangement. By January 2025 it had become right-of-first-refusal. By 2026 it had opened into a multi-cloud footprint involving Oracle and others. Three structural shifts in six years, between the two most prepared partners in the industry, held together by $13 billion of equity glue. If that relationship moves, smaller ones move more.
Frontier AI companies are not in full control of their own stack. They depend on cloud partners they cannot fully substitute, on a chip supplier (TSMC) flagged explicitly as a concentration risk in the same filing. They face active legal disputes — three lawsuits from Elon Musk and xAI, at least fourteen user class actions — that can reshape product directions overnight. Their governance structure is still being argued over in court.
If they have that much exposure and are warning investors about it, the rest of us are building on a layer that even its operators will not call stable.
Concern Without Action
The market has noticed. A 2026 survey of 540 IT leaders across the US, UK, and Germany found that 94% of organizations express concern about vendor lock-in, with nearly half describing themselves as “very concerned”. Concern has not prevented further dependence on individual providers.
The concentration is structural. Two-thirds of AI startup funding in 2023 came from just three Big Tech companies — Alphabet, Amazon, and Microsoft — and the UK Competition and Markets Authority mapped 90 interconnected partnerships among the major tech firms and AI developers.
It compounds underneath the visible architecture. 79% of IT executives report encountering AI implementations by non-IT employees, while only 20% of companies have mature governance for autonomous AI agents. Dependency accumulates in shadow form — copilots in spreadsheets, GPTs in team folders, prompt libraries in vendor-managed memory — before any architecture board reviews it.
Model performance is only one part of the decision. Your team also needs to know who controls the information and workflows it depends on. Route every workflow, every decision context, every piece of institutional knowledge through one provider’s interface and you make the organization dependent on that provider for more than model access.
Three Failure Modes Worth Naming
Three forms of dependency need separate attention.
Dependency risk is the first and most visible. Operational continuity rests on pricing changes, rate limits, policy shifts, and feature deprecations decided in someone else’s roadmap. Builder.ai is the case I keep coming back to. A UK startup backed by Microsoft and the Qatar Investment Authority, valued at $1.3 billion, with thousands of enterprise customers running their apps on its proprietary AI platform. In May 2025, after revenue overstatements and creditor seizures, the company entered insolvency in roughly 48 hours. Customers lost access to their applications, their data, and their source code — no portability layer, no export path.
Vendor failure can remove access abruptly, leaving no time to migrate.
Legal and platform risk is the second. The AI layer is now contested infrastructure, and legal disputes can change its availability and terms of use. The concentration risk and lawsuits in OpenAI’s own filing can each shift access rules, capability scope, or partnership terms. Couple your architecture tightly to a vendor’s current product surface and you inherit that legal exposure — without the upside if the disputes resolve in the vendor’s favor.
A defense-sector example sharpens this. Operators running AI-assisted logistics report that vendor-imposed guardrails now auto-refuse prompts touching whole categories of operations. The model is technically working. It will not do the work the operator needs done. That is what it looks like when someone else’s policy decision becomes your operational constraint.
Memory and data lock-in is the third, and the least visible. 80% of enterprises now rank data sovereignty as a high priority in infrastructure decisions — but sovereignty has shifted meaning. The Detecon analysis after Davos 2026 reframes it: no longer about where data physically resides, but about who controls the systems that process, analyze, and generate value from it. If your documents, reasoning chains, workflows, and decision context live inside a vendor’s conversation format, your knowledge base depends on continued access to that vendor’s system.
The OpenAI outages of December 2024 were the recursive version of the same lesson. Two outages in fifteen days — one a Kubernetes misconfiguration, one an upstream Azure failure — took down ChatGPT, the API, and Sora for over four hours each. Enterprises with customer-support chatbots and coding assistants on the API had no fallback. Fine-tuned models were trapped inside an offline system. Your vendor had a vendor, and the vendor’s vendor was down.
What if I only want to ship fast?
The first objection is about speed. A team standardizing on one provider gets native tooling, coherent upgrade paths, and vendor support that actually understands the stack. Azure shops using OpenAI or AWS shops using Bedrock ship production AI faster precisely because they skip the integration tax of provider-agnostic architectures. For a 20-person engineering team building their first AI feature, asking them to build airline-grade redundancy is the wrong instruction.
That is a reasonable choice for a team trying to ship its first feature. The thesis here is not for the 20-person team shipping a prototype. It is for CTOs and enterprise architects making strategic platform decisions — the ones who, if OpenAI itself flags its own dependency as material risk, are now compounding that risk by standardizing under it. Multi-vendor does not mean running every model at once. It means designing interfaces that do not hardcode provider assumptions.
The second objection is about portability. Modern AI is not legacy ERP — prompt in, text out is genuinely standardized, so switching models is closer to swapping a utility than migrating an ERP. Unless you have deep proprietary integrations, the switching cost is days.
The API layer is often easier to replace than the systems built around it: knowledge trapped in conversation histories, workflows built on platform-specific agent frameworks, fine-tuned models that cannot be exported, prompt libraries tuned to one model’s quirks. The CMA’s 90-partnership map describes an ecosystem deliberately designed to create dependency at multiple layers at once. The raw API call may be portable. The organization that spent eighteen months building knowledge management on a provider’s proprietary memory features is not.
A third objection concerns engineering cost. Owning your memory layer sounds like architecture-magazine advice that ignores engineering reality. Vector databases, embedding pipelines, retrieval systems — hard work. Providers are spending billions making their proprietary knowledge management seamless. Why compete with that on a non-core problem?
Owning your memory does not mean building a custom vector database. It means a design discipline: your organizational knowledge lives in files, databases, and systems you control — not by default inside a provider’s conversation format. The implementation can be as humble as structured markdown in a shared drive, an existing knowledge base tool, or a standard Postgres instance with embeddings. The first requirement is a deliberate choice about where knowledge accumulates. Keeping it in systems you control does not, by itself, require a specialist machine-learning team.
The last objection is patience. Standards are emerging — the EU Data Act has portability provisions, MCP is establishing tool-integration patterns, OpenAI-compatible APIs are a de facto interface. Wait, and the market will solve interoperability before lock-in becomes painful.
It might. The timeline is the problem. Organizations are making deep architectural commitments right now, while meaningful interoperability standards are years from maturity and enforcement. Waiting risks making further commitments before portability standards are ready. Designing for portability now is insurance — and if standards arrive to make it cheaper, that is upside, not waste.
The Design Principle
If AI strategy has been confused with model selection, the prescription is to put the strategy back at the architecture layer.
Keep persistent organizational state separate from model calls.
Persistent state — conversation history, accumulated context, decision rationale, user preferences, workflow logic — lives in infrastructure you own and can version. Models receive that state as input and produce outputs. They do not become the system of record. If the context that makes your work valuable is visible only inside the provider’s system, continued access to that system becomes part of your competitive position.
Goldman Sachs is the working proof at scale. While most enterprises in 2024 were standardizing on a single provider, Goldman built its GS AI Assistant — rolled out to more than 10,000 employees — on a multi-model architecture spanning OpenAI, Google, Anthropic, and Meta, all behind one unified internal interface. JPMorgan Chase did the same with its LLM Suite, now serving roughly 200,000 daily users. Both put an internal interface between employees and the model providers. By 2025, 37% of enterprise respondents in the a16z survey reported using five or more models in production, up from 29% the year before.
A few practical moves most teams can make this quarter:
- Map your vendor surface. Not just “which model API.” Where does memory live? Which prompts encode provider-specific quirks? Which workflows depend on a proprietary agent framework? Where you cannot yet answer, trace the workflow until you know which system holds the context and who can export it.
- Persist outputs as files, not conversations. The litmus test is whether you can hand the artifact to a different model tomorrow and keep working.
- Build workflows, not prompts. The competitive advantage is in orchestration, quality gates, and domain reasoning encoded in the pipeline. Keep that in code you own.
- Make portability a measurable objective. Quarterly dependency audits, time-to-switch as a KPI, weekly automated tests routing a critical workflow through a backup provider. If no one’s job includes defending independence, it erodes within two quarters.
Keep organizational memory, workflow logic and data in systems you control, so they remain accessible through a provider’s pricing change, policy shift, partnership renegotiation or outage.
Your Real AI Strategy Is What Survives Disruption
Almost four in five enterprises have adopted AI agents. Only one in nine runs them in production. That 68-point chasm between adoption and production is the largest backlog in enterprise technology history — and a window. Architecture set in the experimentation phase calcifies in the production phase. The choices made this year are the ones the next decade has to live inside.
Frontier AI companies are telling you — in investor disclosures, in partnership restructurings, in their own risk management — that even they are not fully in control of their stack. If even OpenAI is diversifying away from single-vendor dependency, the question for every CTO is not whether to follow suit. It is how fast.
The litmus test is one sentence: what still works if the model you depend on disappears tomorrow? The answer tells you where a fallback or export path is missing.
If nothing would work, the provider is a single point of failure that the strategy needs to address.
Start with an inventory of the knowledge, workflows, and fine-tunes that depend on a vendor remaining available. Then prioritize exports, replacement interfaces, and tested fallback workflows. The aim is to give the people relying on those systems a way to keep working through a change they do not control.
References
- CNBC (March 23, 2026). “OpenAI calls out Microsoft reliance as risk in investor document ahead of expected IPO.” https://www.cnbc.com/2026/03/23/openai-risk-factors-microsoft-reliance-elon-musk-and-xai-lawsuits.html (Evidence IDs: E001, E002, E008)
- GlobeNewsWire / Parallels (February 17, 2026). “94% of IT Leaders Fear Vendor Lock-In as AI Reality Check Forces EUC Strategy Reset.” https://www.globenewswire.com/news-release/2026/02/17/3239335/0/en/94-of-IT-Leaders-Fear-Vendor-Lock-In-as-AI-Reality-Check-Forces-EUC-Strategy-Reset-Parallels-Survey-Finds.html (Evidence IDs: E003)
- Stanford Law School CodeX (March 21, 2025). “AI Partnerships Beyond Control: Lessons from the OpenAI-Microsoft Saga.” https://law.stanford.edu/2025/03/21/ai-partnerships-beyond-control-lessons-from-the-openai-microsoft-saga/ (Evidence IDs: E004, E009)
- CTO Magazine (2025). “The Great AI Vendor Lock-In: How CTOs Can Avoid Getting Trapped by Big Tech.” https://ctomagazine.com/ai-vendor-lock-in-cto-strategy/ (Evidence IDs: E005)
- Nutanix (2026). “2026 Enterprise Cloud Index.” https://www.nutanix.com/enterprise-cloud-index (Evidence IDs: E006)
- Deloitte (2026). “State of AI in the Enterprise — 2026 AI Report.” https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html (Evidence IDs: E007, E012)
- Detecon (Deutsche Telekom) (2026). “Digital Sovereignty after Davos 2026: Data, Cloud & AI.” https://www.detecon.com/en/insights/article/digital-sovereignty-after-davos-2026-how-data-cloud-and-ai-control-shape-global-resilience (Evidence IDs: E010)
- Ability.ai (2025). “AI vendor lock-in risks: the operational crisis CEOs must address.” https://www.ability.ai/blog/ai-vendor-lock-in-risks (Evidence IDs: E011)
Case sources (vignettes)
- Builder.ai collapse (May 2025). The Register; Codekeeper.
- OpenAI December 2024 outages. ThousandEyes; TechCrunch; OpenAI status history.
- Goldman Sachs / JPMorgan multi-model architecture. Klover.ai analysis; a16z Enterprise AI 2025.