Enterprise AI adoption is accelerating, but so is the lock-in risk. Unlike traditional SaaS where lock-in is primarily about data and workflow, AI creates four distinct lock-in vectors: prompt engineering investment, fine-tuned model dependency, embedding infrastructure, and platform workflow integration. Each requires a different mitigation strategy.
This guide is part of our comprehensive AI procurement guide. The VMware-Broadcom acquisition — where perpetual licences were eliminated and prices increased 340% — remains the most instructive cautionary tale for enterprise technology buyers. The AI market is less mature, more volatile, and even more susceptible to sudden commercial disruption through consolidation, bankruptcy, or strategic repositioning.
1. The Four Types of AI Vendor Lock-In
| Lock-In Type | How It Forms | Portability Difficulty | Mitigation Approach |
|---|
| Prompt Lock-In | System prompts engineered for specific model behaviour | MODERATE | Model-agnostic prompt design, abstraction layers |
| Fine-Tuned Model Lock-In | Custom fine-tuned models on vendor infrastructure | HIGH | Own your training data; demand model export rights |
| Embedding Lock-In | Vector stores built with vendor-specific embeddings | HIGH | Re-embedding strategy; open embedding models |
| Platform Lock-In | Copilot Studio, Vertex AI Agents, Bedrock agents | MODERATE–HIGH | Thin platform layer; open orchestration frameworks |
2. Prompt Lock-In
Prompt engineering is a significant enterprise investment. Large production applications may have hundreds of carefully optimised system prompts, few-shot examples, and evaluation suites. These represent months of engineering and domain expert work — and they don't transfer cleanly between models.
Expert Advisory
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
Lock-In Risk
Model-Specific Prompt Behaviour
GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro respond differently to identical prompts. A prompt optimised for GPT-4o's instruction-following patterns may produce significantly worse results on Claude or Gemini without re-engineering. Enterprises that invest deeply in model-specific prompt optimisation accumulate switching costs that grow with every production application.
Mitigation: Model-Agnostic Prompt Design
- Avoid model-specific formatting hacks: Some models respond better to specific XML tags, JSON schemas, or markdown formatting. Where possible, use model-agnostic instructions rather than exploiting vendor-specific prompt quirks.
- Build evaluation suites before optimising: Maintain a test suite of representative inputs and expected outputs. This lets you benchmark any model against your requirements before committing to a switch — and quantifies the re-prompting cost if you do switch.
- Use abstraction layers: Framework libraries like LangChain and LlamaIndex provide model-agnostic interfaces that make switching the underlying model a configuration change rather than a code rewrite. The abstraction overhead is worth it for production systems.
- Keep your prompts in your codebase: Do not store critical system prompts only within a vendor's platform console. Your prompts are a core intellectual asset — version-control them in your own systems.
3. Fine-Tuned Model Lock-In
Fine-tuning a model to your domain creates powerful capabilities — but also the deepest form of AI vendor lock-in. A fine-tuned GPT-4o model cannot be exported or transferred to Anthropic or Google. The fine-tuning investment is entirely vendor-specific, and if you lose access to the vendor, you lose the model.
Lock-In Risk
Fine-Tuned Model Abandonment
OpenAI deprecated fine-tuned GPT-3 models in January 2024 with 6 months' notice. Enterprises that had fine-tuned models for customer service, document extraction, or classification faced complete model loss and required full retraining on new model architectures. This will happen again — model deprecations are a permanent feature of the AI landscape. Without contractual protections, your fine-tuning investment is entirely at the vendor's discretion.
Contractual Protections for Fine-Tuned Models
- Model export rights: Negotiate the right to receive a copy of your fine-tuned model weights in a standard format (safetensors or GGUF) upon request or contract termination. Most vendors will resist this — but it is achievable for enterprise-scale relationships.
- Minimum model availability period: Require a minimum 24-month notice period before any fine-tuned model is deprecated, with a migration path to an equivalent capability at equivalent cost.
- Training data ownership: Ensure your contract explicitly confirms that the training data used to fine-tune your model remains your property and you can use it to fine-tune equivalent models on any other platform.
- Platform-agnostic fine-tuning strategy: Consider fine-tuning open-source models (Llama 3, Mistral) that you host on your own infrastructure or a cloud platform. You own the fine-tuned weights outright and can migrate them to any hosting environment.
4. Embedding and Vector Store Lock-In
Many enterprise AI applications use embeddings — numeric vector representations of text created by a specific model — stored in vector databases for semantic search and RAG. The critical problem: embeddings created by OpenAI's text-embedding-3-large are not interchangeable with embeddings from Anthropic's or Google's embedding models. Switching embedding models requires re-embedding your entire corpus.
Free Resource
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
| Embedding Model | Dimensions | Cost (per 1M tokens) | Portability |
|---|
| OpenAI text-embedding-3-large | 3,072 | $0.13 | OpenAI only |
| OpenAI text-embedding-3-small | 1,536 | $0.02 | OpenAI only |
| Google text-embedding-004 | 768 | $0.025 | Google only |
| Cohere embed-english-v3 | 1,024 | $0.10 | Cohere only |
| BAAI/bge-large-en (open source) | 1,024 | Self-hosted (infra cost) | Fully portable |
| sentence-transformers (open source) | 384–1,024 | Self-hosted (infra cost) | Fully portable |
| Nomic embed-text-v1 (open source) | 768 | Self-hosted or API | Mostly portable |
Re-Embedding Cost for a 10M Token Corpus
Moving from OpenAI embeddings to an alternative requires re-embedding your entire knowledge base. At $0.13/million tokens (text-embedding-3-large), re-embedding a 10M token corpus costs $1.30 in direct API costs — trivial. But the real cost is engineering time, validation, and downtime during migration. Open-source embedding models (BGE, sentence-transformers) eliminate vendor dependency entirely for the embedding layer and perform competitively on most retrieval benchmarks.
AI platforms like Microsoft Copilot Studio, Google Agentspace, and AWS Bedrock Agents offer powerful agent-building capabilities — but each has proprietary workflow definitions, trigger mechanisms, and integration patterns. Workflows built natively on one platform require significant rearchitecting to move to another.
Architecture Recommendation
Use open orchestration frameworks (LangChain, LlamaIndex, CrewAI, AutoGen) as the primary agent architecture layer, with vendor platform APIs as interchangeable backends. This creates a thin, portable agent layer above vendor-specific APIs rather than building agents natively in Copilot Studio or Bedrock Agents. The performance difference is negligible; the portability benefit is substantial.
6. Portability Architecture Principles
Architecture Principle 01
Model Abstraction Layer
Never call AI vendor APIs directly from application code. Implement an internal AI gateway or abstraction layer that routes requests to the appropriate model. This gateway can be as simple as an internal library with a consistent interface, or as sophisticated as a full LLM gateway (LiteLLM, PortKey, or OpenRouter). The key requirement: switching underlying models should be a configuration change, not a code change.
Architecture Principle 02
Vendor-Agnostic Data Storage
Store all AI-related data — prompts, conversation history, fine-tuning datasets, evaluation results — in infrastructure you control, not the vendor's platform. Your prompt library belongs in your version control system, not in OpenAI's Playground. Your fine-tuning datasets belong in your data lake, not just on the vendor's training infrastructure. Your evaluation benchmarks belong in your CI/CD pipeline, not in a vendor's evaluation console.
Architecture Principle 03
Portable Embedding Strategy
For new RAG deployments, default to open-source embedding models unless vendor-specific models offer demonstrably better retrieval performance for your use case (benchmark before deciding). BGE-large, E5-large, and Nomic embed-text-v1 perform competitively with commercial alternatives on most enterprise retrieval benchmarks. If you use commercial embeddings, maintain the source text corpus so you can re-embed with an alternative model if needed.
Architecture Principle 04
Shadow Deployment for Continuity
For mission-critical AI workloads, maintain a shadow deployment on an alternative model that runs in parallel, receives the same inputs, but does not serve primary production traffic. This keeps a fallback path operational and continuously validated. Shadow deployments cost 10–20% of primary inference costs, but provide immediate failover capability and an always-current migration path — valuable insurance given how frequently AI vendors deprecate models, change pricing, or experience outages.
7. Contractual Portability Protections
| Contractual Protection | Vendor Resistance | Why It Matters |
|---|
| Termination for Convenience (T4C) | MODERATE | Exit right without cause — essential for any multi-year AI commit |
| Fine-tuned model export rights | HIGH | Preserve fine-tuning investment if vendor changes or fails |
| Training data return on termination | LOW | Recover all data submitted for fine-tuning or RLHF |
| Model deprecation notice (180+ days) | MODERATE | Time to migrate integrated applications before model disappears |
| Equivalent capability guarantee | MODERATE | Replacement model must match performance benchmarks you specify |
| Change of control termination right | MODERATE | Exit right if vendor is acquired by a competitor or PE firm |
| API compatibility guarantee | LOW | API interface changes require 90+ days notice and compatibility period |
8. Acquisition and Change-of-Control Risk
The AI market is consolidating rapidly. Every major technology company is acquiring AI capabilities. The risk of your chosen AI vendor being acquired by a competitor, a private equity firm, or an entity with conflicting interests is material and growing. The VMware acquisition by Broadcom provides the definitive cautionary tale: a technology with deep enterprise lock-in, acquired by a new owner who immediately eliminated perpetual licensing and increased prices 340%.
Acquisition Risk Assessment
Current AI market acquisition targets of concern: smaller AI vendors with narrow specialisations (document processing, code generation, customer service) are most at risk. Foundation model providers (OpenAI, Anthropic) are also M&A targets — Microsoft's equity stake in OpenAI and Google's significant investment in Anthropic create complex governance dynamics. Any enterprise AI vendor can change ownership. Plan for it contractually.
For guidance on negotiating change-of-control protections, see our comprehensive guide on change-of-control clauses in software contracts and protecting your rights during vendor acquisitions.
9. Migration Planning Framework
Every enterprise AI deployment should have a documented migration plan from day one. This is not a sign of lack of confidence in your vendor — it's standard risk management practice that experienced technology leaders implement for all critical dependencies.
Four-Phase AI Migration Readiness Framework
- Asset inventory: Document all AI-dependent applications, the models they use, the prompts they rely on, any fine-tuned models, and the embedding models backing their RAG systems. Estimate the migration cost for each.
- Portability assessment: Rate each application on portability difficulty (LOW / MEDIUM / HIGH) based on its lock-in type. Prioritise architectural changes to reduce HIGH-rated lock-ins to MEDIUM or LOW.
- Alternative identification: For each primary AI vendor, identify a credible migration target — alternative model provider, open-source model, or cloud-based alternative. Keep migration targets evaluated and benchmarked, not just theoretical.
- Trigger definition: Define the conditions that would trigger migration: price increase above X%, service degradation below Y% uptime, acquisition by a specified category of acquirer, or product deprecation without equivalent replacement. Review triggers quarterly.
10. Ten Lock-In Prevention Tactics
Tactic 01
Never Deploy a Single-Vendor AI Strategy
Use at least two AI providers for different application categories. A typical enterprise strategy: OpenAI or Anthropic for complex reasoning and code generation, Google Gemini for document and Workspace integration, and an open-source model (Llama 3 or Mistral) for high-volume, cost-sensitive workloads. Multi-vendor deployment creates continuous competitive pressure that translates to better renewal pricing and prevents dependency on any single vendor's roadmap.
Tactic 02
Negotiate Termination for Convenience for Every Multi-Year AI Commitment
This is non-negotiable for enterprise AI contracts given market volatility. Negotiate T4C rights after year 1 at minimum, with a wind-down fee schedule (25–40% of remaining TCV in year 2, declining each subsequent year). Without T4C, you are contractually locked in regardless of how dramatically the AI landscape shifts. The Broadcom/VMware scenario shows that even deep technical integration doesn't mean you have to accept punitive commercial terms — but you need the contractual right to exit.
Tactic 03
Demand Model Deprecation Rights Before Signing
Negotiate a minimum 180-day advance notice for any model integrated into your production systems. The notice must specify the replacement model, confirmed performance equivalence on your benchmarks, and a migration path at no additional cost. Include a provision that if no equivalent replacement is available within the notice period, you have the right to terminate the affected workload's commitment without penalty. Model deprecations are inevitable — protect yourself contractually before they happen.
Tactic 04
Prefer Open Standards for Orchestration and Tool Definitions
OpenAI's function calling format has become a de facto standard adopted by Anthropic, Google, and most open-source models. Use OpenAI-compatible tool definitions in your agents even if you're running on a different primary provider — this makes the tool definitions portable. Similarly, use OpenAI-compatible API endpoints where possible (many providers support this). The goal is infrastructure where the model endpoint is a URL swap, not a code rewrite.
Tactic 05
Route AI Through Your Cloud Committed Spend
Using Azure OpenAI or AWS Bedrock instead of direct API access reduces lock-in to a specific AI vendor while maintaining cloud spend efficiency. If OpenAI's terms or pricing become unacceptable, you can migrate to a different model on the same cloud platform without changing your commercial relationship. Azure's MACC and AWS's EDP remain constant regardless of which foundation model you use. This also gives you leverage with the cloud provider for better platform terms.
Tactic 06
Build Internal AI Competence, Not Just AI Consumption
Enterprises that only consume AI through vendor interfaces are entirely dependent on vendor decisions about model quality, availability, and pricing. Invest in internal AI engineering competence — the ability to evaluate models, adapt prompts, fine-tune open-source models, and run benchmarks. This internal capability dramatically reduces lock-in by making switching a manageable engineering task rather than an existential project. Even a small AI platform team of 3–5 engineers changes the dynamic with AI vendors significantly.
Tactic 07
Conduct Annual AI Vendor Benchmarking
Schedule a formal annual benchmark of your current AI vendors against alternatives. Run the same evaluation suite that you used at initial selection, plus any new requirements that emerged during the year. Document the results and share them with your vendor during annual reviews. This signals that you maintain an active alternative assessment programme — a credible threat that keeps vendors competitive on price and service. It also ensures you capture quality improvements from emerging models that may outperform your current vendor.
Tactic 08
Maintain an Open-Source Fallback for Each Critical Workload
For every business-critical AI application, validate that an open-source model (Llama 3 70B, Mistral Large, or equivalent) can serve as a fallback with acceptable quality. The open-source fallback doesn't need to match the primary model's quality exactly — it just needs to be "good enough" to maintain operations during a forced migration. Validate this quarterly by running your evaluation suite against the open-source fallback. The existence of a validated fallback also strengthens your negotiating position at renewal.
Tactic 09
Negotiate Change-of-Control Termination Rights
Include a clause allowing you to terminate without penalty if the AI vendor is acquired by: (a) a direct competitor of your organisation, (b) a private equity firm that changes the vendor's commercial model materially, or (c) any entity that materially changes pricing, terms, or service levels within 12 months of the acquisition. This is particularly important for AI vendors with deep investor entanglements — Microsoft's OpenAI relationship and Google's Anthropic investment create commercial conflicts of interest that may surface in ways disadvantageous to customers.
Tactic 10
Maintain Shorter AI Contract Terms Than Traditional Software
The AI market is evolving too fast for 3–5 year IT software contract terms. Limit AI vendor commitments to 12–18 months where possible, accepting slightly worse per-unit pricing in exchange for flexibility. If 2–3 year terms are required for commercial efficiency, ensure they include: T4C rights, annual market-rate reviews, model deprecation protections, and change-of-control termination rights. The contract term for AI should be shorter than equivalent traditional software given the greater market uncertainty.
Concerned About AI Vendor Lock-In?
Our advisors assess your current AI portfolio for lock-in risks and help negotiate contractual protections before you're committed.
FAQ: AI Vendor Lock-In
Is AI vendor lock-in really worse than traditional software lock-in?
In several dimensions, yes. Traditional software lock-in is primarily about data format and workflow. AI lock-in adds model-specific prompt optimisation (engineering investment that doesn't transfer), fine-tuned model weights (entirely vendor-specific), and embedding infrastructure (requires re-processing entire knowledge bases to switch). Additionally, the AI market is substantially less mature and more volatile than established enterprise software — model deprecations, company acquisitions, and dramatic pricing changes happen on timescales of months, not years.
Can I export my fine-tuned model if I want to leave an AI vendor?
By default, no — fine-tuned models on vendor infrastructure are stored and operated by the vendor, and most vendors do not offer model weight export. This is a contractual negotiation point rather than a technical limitation. For enterprise-scale relationships, model export rights (in safetensors or GGUF format) are achievable but require explicit negotiation. Alternatively, fine-tuning open-source models (Llama 3, Mistral) hosted on your own infrastructure eliminates this risk entirely — you own the weights from the start.
How do I migrate from one AI vendor's embeddings to another?
Migrating embeddings requires: (1) maintaining the source text corpus that was originally embedded — ensure you have this; (2) re-embedding the full corpus with the new embedding model; (3) updating your vector database with the new embedding vectors; (4) running retrieval quality benchmarks to confirm the new embeddings perform equivalently; (5) A/B testing in production before full cutover. The direct API cost of re-embedding is usually small ($1–$50 for most enterprise knowledge bases). The engineering and validation time is the main cost — typically 2–8 weeks depending on corpus size and retrieval complexity.
What happened to enterprises that were deeply locked into specific AI vendors that deprecated their models?
OpenAI's GPT-3 fine-tuning deprecations in 2024 affected enterprises with custom models for customer service, content moderation, and document extraction. Those without contractual protections had to: re-engineer prompts for new model architectures, retrain fine-tuned models from scratch on new base models, and rebuild evaluation suites — typically 3–6 months of engineering work per affected application. Those with model deprecation notice clauses had 6+ months to plan and execute migrations with vendor support. The lesson: contractual notice periods are worth fighting for in negotiations.