AI Vendors Can Lock Enterprises In: Test Exit Costs in One Day
Whether an enterprise is locked into an AI vendor is a measurable fact, not a feeling: the first step is to calculate the exit cost for one production workload and run a one-day second-source test. If that test cannot be run in a day, dependency has already compounded. The terms that matter here, exit cost, MCP, A2A, describe a discipline we return to throughout this piece: treating portability as evidence, not a promise.
TL;DR:
Switching costs often accumulate in prompts, embeddings, connectors, evaluation suites, and contract terms, so replacing a model can leave deeper dependencies untouched.
Measure portability through three figures: weeks to port, migration cost, and capability loss on the first day before retuning; record model versions and test date.
An AI gateway centralizes routing, credentials, fallbacks, cost controls, and audit logs, while MCP standardizes tool access and A2A supports agent communication.
Before signing, require export formats and delivery timelines, capped termination assistance, portable evaluation support, and clear ownership terms for custom model artifacts.
Run the second source test against live production traffic, because synthetic benchmarks can understate the capability loss customers experience after switching.
Table of Contents
What AI vendor lock-in means and where it accumulates
AI vendor lock-in differs from classic cloud or SaaS lock-in because the dependency is not confined to infrastructure contracts. A SaaS switch usually means re-training staff and migrating records. An AI switch can mean losing model behaviour, prompt logic, evaluation history and integration plumbing all at once, because these elements are tuned to one provider’s quirks rather than to an open interface.
Lock-in builds up across several layers, often invisibly:
Model weights and behaviour: prompts tuned for one model’s output style rarely transfer cleanly to another.
Orchestration and prompts: agent frameworks and prompt chains often assume provider-specific tool-calling formats.
Embeddings and data: vector stores built around one embedding model require re-embedding the entire corpus to switch providers.
Runtime and infrastructure: specialised accelerators and managed inference endpoints tie workloads to a single cloud.
Integrations and connectors: bespoke API glue code accumulates provider assumptions that are expensive to unwind.
Evaluation and governance: without a portable evaluation suite, there is no way to prove a replacement model performs as well.
Industry analysis increasingly argues that the real risk sits in these surrounding layers rather than in model choice itself. Lock-in frequently resides in context, memory, evaluation suites, identity and integrations rather than the model itself, and these are the hardest pieces to move, according to recent industry analysis. Contractual terms add a final layer: data export rights, termination notice periods and ownership of fine-tuned artefacts are commercial decisions, not technical ones, and they often go unexamined until a renewal deadline forces the question.
The hidden costs enterprises underestimate
The sticker price of an AI contract rarely reflects the full cost of staying with, or leaving, a vendor. Direct costs are the visible layer: API metering, data egress fees and charges for specialised accelerator access. These are the numbers procurement teams negotiate hardest, yet they are often the smallest part of the total.
The larger costs sit underneath:
One-off migration costs: re-embedding a corpus, retuning prompts and rewriting connectors for a new provider.
Operational overhead: the platform engineering and SRE time needed to monitor, patch and maintain fallback paths.
Compliance and governance remediation: preparing audit evidence, revalidating data residency claims and re-certifying models after a switch.
Opportunity costs: a team anchored to one vendor’s roadmap loses the ability to adopt faster-iterating alternatives.
Buyers should express independence as exit-cost figures rather than qualitative assurances. Procurement guidance on AI vendor independence recommends converting portability into three measurable figures: weeks to port, one-off migration cost and the percentage of capability lost on day one. Until those figures exist for a given workload, the true cost of switching, or of staying, remains a guess rather than a number finance can budget against.
How to measure your dependency: the exit-cost test and dependency audit
Portability only becomes credible once it is expressed as a number. The exit-cost trio gives enterprises a consistent way to do that for any production workload:
Elapsed weeks to port: how long would a competent team need to move the workload to an alternative provider, end to end.
One-off migration cost: the engineering, re-embedding and retesting spend required to complete that move.
Day-one capability delta: the percentage of functional quality lost when the workload first runs on the alternative, before any retuning.
The same guidance frames this as the practical litmus test for independence: pick one critical workload, run it for a day on an alternative provider, and document the delta, converting abstract risk into a board-grade artefact, as described in guidance on proving vendor independence.
Before running that test, complete a dependency audit covering:
Model versions and fine-tuning artefacts in active use.
Prompt libraries and orchestration logic, with provider-specific assumptions flagged.
Embedding models and vector store formats.
Connectors, authentication flows and identity dependencies.
Evaluation suites and whether they are portable across providers.
Contract clauses covering export rights, notice periods and data ownership.
Pro Tip: Run the second-source test on a workload with real production traffic, not a synthetic benchmark; synthetic tests understate the capability delta that matters to users.
Record results in a format procurement and audit teams can reuse at renewal: a short memo stating the three exit-cost figures, the date tested, and the model versions compared. That memo becomes the evidence base for the next contract negotiation, rather than a one-off exercise nobody revisits.
Engineering patterns that reduce lock-in
Architecture choices determine how expensive the exit-cost test turns out to be. An AI gateway sitting between applications and model providers is the single highest-leverage pattern: it handles model routing, credential management, cost controls, fallback logic and audit logging from one place, so switching providers means updating routing rules rather than rewriting application code. Guidance on AI vendor lock-in describes this abstraction as what lets enterprises change providers without rewriting the applications sitting on top.
Technology choices alone do not prevent lock-in; a governance-first approach with central observability is required to make portability real rather than theoretical.
Open standards reduce the surface area further. A2A has been adopted by over 150 organisations and moved into enterprise production use on major cloud platforms within its first year, a sign that standardised agent-to-agent communication is maturing fast enough to rely on. MCP addresses a related but distinct problem: standardising how models access context and tools, so switching a model does not mean rebuilding every tool integration around it. For document-heavy workloads, the Linux Foundation’s work on a vendor-neutral document specification aims to do the same for document representations, while OPI pursues comparable neutrality at the infrastructure layer.
Other patterns worth building in from the start:
Portable data formats: store embeddings and document representations in open formats, and keep a documented re-embedding runbook ready to execute.
Hybrid and multi-cloud placement: reserve on-premises or multi-cloud deployment for workloads with strict data residency or latency requirements, where the operational overhead is justified.
Semantic caching and token budgets: reduce both cost and provider-specific tuning debt.
Central observability and audit logging: a single pane of visibility across providers makes the next exit-cost test faster to run, not just the current one.
Governance for agentic systems adds a further wrinkle worth planning for before these systems reach production, as covered in our earlier look at agentic AI governance.
Procurement and contract levers to demand portability
Architecture reduces technical lock-in; contracts reduce commercial lock-in. A usable export specification states the exact formats data will be delivered in, the timeline for delivery after a termination notice, and any exclusions, such as derived model weights the vendor will not release.
Negotiate these clauses before signature, not at renewal:
Termination assistance: a defined window, typically measured in weeks, a capped fee for the work, and a named contact responsible for delivery.
Runbook deliverables: a contractual requirement that the vendor supports a second-source test and maintains a portable evaluation suite.
Measurable SLAs: response times and data delivery formats specified numerically, not described as “reasonable efforts”.
Clauses to avoid: auto-renewal with short cancellation windows, and silence on fine-tuned model ownership.
Standard contract drafting practices, including clear clause language for NDAs and data handling commitments, are worth reviewing with legal counsel; practical clause examples built for software engagements offer a useful starting point for procurement teams drafting similar exit and confidentiality terms with AI vendors.
A practical example: audit, architecture and test in sequence
End-to-end accountability makes exit readiness testable because one team carries responsibility from strategy through to operations, rather than handing the problem to whoever owns the contract at renewal time. The sequence typically runs in a consistent order: readiness and data diligence first, to produce the dependency inventory described above, followed by establishing a portable evaluation suite before any architecture decisions are locked in.
With that groundwork in place, running a one-day second-source test on a live workload becomes routine rather than exceptional, and an AI gateway can be operationalised with confidence that switching providers later will not mean rebuilding the application layer. Document-heavy workloads, of the kind covered in our guide to document automation, and operational workloads such as warehouse slotting or mortgage document processing, are good candidates for the exit-cost litmus test, because their production traffic makes the day-one capability delta immediately visible.
Portability as compliance and resilience
Portability only earns trust once it is measured, which is why we treat it as an operational KPI rather than a claim in a vendor’s sales deck. A dependency that cannot be quantified cannot be managed, and regular testing with documented evidence reduces both contract disputes and procurement risk at renewal. Every enterprise running a critical AI workload should name an owner responsible for that workload’s exit readiness, the same way they would name an owner for uptime or security.
— Thomas Samuel
How we help enterprises measure and reduce AI vendor lock-in
Measuring exit cost and running a second-source test takes focused engineering time most internal teams are already stretched thin on. We provide support through the whole cycle, from readiness and data diligence through architecture and into managed operations, so portability stays an answerable question rather than an assumption nobody has tested.
Readiness & Data Diligence: inventory models, prompts, embeddings and contracts before any architecture decision is made.
AI Strategy & Roadmap: build exit-cost measurement into the plan from day one, not as an afterthought.
Deployment & MLOps: operationalise an AI gateway and portable evaluation suite as part of the build, not a later retrofit.
Managed AI Operations: keep observability and second-source testing running as routine operational practice.
If a dependency audit and exit-cost test for a critical workload would help your team walk into the next vendor renewal with evidence instead of assumptions, get in touch through our services page.
FAQ
What is AI vendor lock-in?
AI vendor lock-in is the state where switching AI providers becomes costly or impractical because models, prompts, embeddings, integrations and evaluation data have all been tuned to one vendor’s specifics. It differs from classic cloud lock-in because the dependency often sits in behavioural and data layers, not just infrastructure contracts.
What is an AI vendor?
An AI vendor is any provider supplying the models, infrastructure or platform services an organisation builds AI applications on, from foundation model APIs to managed inference and orchestration platforms. The term covers both the underlying model supplier and the platform layer that wraps it.
How to make AI agents secure?
Securing AI agents starts with identity and access controls scoped to each agent’s actions, combined with audit logging that records every tool call and decision. Adopting standardised protocols such as A2A for agent communication also reduces the risk of undocumented, provider-specific behaviour slipping into production.
What is AI-enabled shopping?
AI-enabled shopping refers to retail experiences where conversational agents, recommendation models or automated checkout flows handle part of the buying journey. These systems carry the same lock-in risks as other AI deployments, since recommendation models and conversational agents are frequently tied to a single provider’s infrastructure.
What should enterprises check before relying on a single AI provider?
Enterprises should check whether they can produce the exit-cost trio, elapsed weeks to port, migration cost and capability delta, for their critical workloads before relying on one provider. If that figure cannot be calculated quickly, it is a sign that contracts, architecture or evaluation data need attention first.
Sources
Recommended