The AI Exit Plan: Avoiding Lock-In Without Sacrificing Momentum

Lock-in starts in the application, not the contract

AI lock-in is often treated as a procurement problem: negotiate shorter terms, cap price rises and secure an exit clause. Those measures matter, but the harder dependency forms inside the product. A team builds workflows around one provider’s tool-calling schema, safety filters, context limits, embeddings and response formats. Six months later, changing models means rewriting prompts, re-indexing documents, recalibrating thresholds and retraining users. The contract may permit an exit while the architecture makes it unaffordable.

The answer is not to keep every provider at arm’s length. Organisations gain momentum by exploiting useful proprietary capabilities, from managed fine-tuning to prompt caching. The goal is controlled dependence: know which components are portable, which are deliberately provider-specific and what replacement would cost. A practical starting point is a dependency register covering models, APIs, data stores, evaluation tools and operational processes. For each dependency, record the owner, substitute, migration steps and expected recovery time. If replacing a core model would take nine months, leadership should see that risk as clearly as it sees cloud expenditure.

Build a model interface that reflects your needs

Applications should call an internal model gateway rather than scattering vendor SDKs across dozens of services. The gateway translates a stable organisational interface into provider-specific requests. It can standardise messages, authentication, retries, time-outs, rate limits, logging and structured outputs. A support application might ask the gateway for a response with a system instruction, conversation history, allowed tools and a JSON schema; adapters then convert that request for each vendor. This does not make models interchangeable, but it confines most switching work to a controlled layer.

Keep the interface narrower than the union of every provider’s features. A universal abstraction that exposes hundreds of parameters merely reproduces vendor complexity under different names. Define service classes instead: low-cost classification, grounded question answering, high-reasoning analysis, vision extraction and embedding generation. Route each class according to quality, latency, geography and price. That enables a team to replace a £12-per-million-token model with a £2 alternative for routine extraction without changing the business application.

Abstraction has a cost. A lowest-common-denominator interface can block valuable features such as cached context, native computer use or provider-specific reasoning controls. Permit explicit escape hatches, but label them. Code that invokes a proprietary capability should carry an owner, business justification and fallback behaviour. Lock-in then becomes a conscious investment rather than an accidental inheritance.

Treat prompts as portable source code

Prompts embedded in application files are difficult to inventory, test and migrate. Store them in a version-controlled registry with clear inputs, outputs, owners and supported model families. Separate the durable task specification from vendor tuning. The durable layer might define the role, evidence rules, output schema and examples; a provider overlay can add formatting conventions or parameter settings. When a model changes, teams adjust the overlay before rewriting the underlying business logic.

Portability does not mean assuming identical wording will work everywhere. Models interpret instructions differently, and an apparently minor switch can alter refusal rates, verbosity or JSON validity. Use templating sparingly, validate variables and avoid relying on undocumented tokenisation quirks. For a claims-triage workflow, the contract should specify fields such as claim category, confidence and evidence spans, not merely request a ‘helpful assessment’. A rigid output schema reduces downstream coupling and makes model comparisons measurable.

Prompt provenance is equally important. Record the prompt version, model identifier, parameters, retrieval configuration and policy version for every material decision. That record supports incident investigation and regulated audit, while making rollback practical. If a new prompt raises automation from 62% to 74% but doubles incorrect approvals, the organisation must be able to restore the previous combination within hours, not reconstruct it from chat logs.

Make evaluation the centre of the exit strategy

A vendor switch is viable only if the organisation can establish whether the replacement is good enough. Build an evaluation suite before migration pressure arrives. It should combine representative historical cases, adversarial examples, policy-sensitive scenarios and recent production samples. For a customer-service assistant processing 100,000 conversations a month, a curated set of 500 to 2,000 cases can provide a strong regression signal if it covers major intents, languages, edge cases and high-cost failures.

Measure outcomes rather than model personality. Useful metrics include task completion, factual support, schema validity, latency, refusal accuracy and cost per successful transaction. Some tasks permit exact scoring; others need calibrated human review or an independent judge model. Judge models are fast but can favour their own style, so validate them against human ratings and conceal provider identities where possible. A weighted score should reflect business consequences: a fabricated refund policy is more serious than an inelegant sentence.

Set migration gates in advance. A candidate might need to remain within two percentage points of the incumbent’s resolution rate, produce fewer than 0.5% unsupported policy claims, meet a 1.5-second median latency target and reduce unit cost by 20%. Run shadow traffic, then expose perhaps 5% of users before expanding. These gates turn switching from an executive gamble into a controlled release process.

Own the data layer and retrieval pipeline

The model is replaceable only when the information feeding it is portable. Keep authoritative documents, permissions, conversation records and annotations in systems the organisation controls. Managed vector databases can be useful, but retain the original content, chunk metadata and access-control rules outside them. Export vectors and indexes where possible, while assuming embeddings may need to be regenerated. A corpus of ten million chunks can cost thousands of pounds to re-embed and days to validate; that is manageable when budgeted, disruptive when discovered during an outage.

Decouple retrieval into observable stages: document ingestion, parsing, chunking, metadata enrichment, embedding, candidate search, reranking and context assembly. Each stage should have testable outputs. If a new embedding model reduces recall for product codes, the team should identify that loss before blaming the generative model. Store stable document identifiers and citations so that regenerated indexes remain traceable to the same source material.

Data portability also requires deletion and retention discipline. Verify that providers do not train on submitted data unless explicitly authorised, and establish how prompts, files, fine-tuning records and logs are exported or erased. Encryption and regional processing are not substitutes for an exit process. The contract should specify formats, deadlines and assistance, while engineering should rehearse an export. A theoretical CSV export is of little value if attachments, permissions and lineage disappear.

Design for failure, not permanent multi-cloud symmetry

Running every workload across three model providers sounds resilient, but it can impose a permanent tax. Teams must tune prompts repeatedly, reconcile different safety behaviour and maintain several observability stacks. For many organisations, active-active model portability is unnecessary. A primary provider, a tested secondary route and a documented degraded mode offer a better balance between resilience and delivery speed.

Fallback behaviour should match the workload. If an email summariser fails, queueing requests may be acceptable. If an AI system assists an emergency call centre, the fallback may need a smaller local model, keyword search or immediate human escalation. Test provider failures, quota exhaustion, regional disruption and sudden policy changes. A secondary model that has not seen production-shaped traffic for six months is not a fallback; it is an assumption.

Operational controls belong in the gateway: circuit breakers, budget limits, rate controls and routing rules. Monitor quality as well as uptime. A provider can remain technically available while a model update changes tone, tool use or extraction accuracy. Canary tests using fixed probes can detect drift, but they should supplement production metrics. The strongest exit plan catches gradual degradation before a crisis forces a rushed migration.

Use commercial leverage without slowing delivery

Architecture cannot compensate for weak commercial terms. Contracts should address model retirement notice, price-change notice, data use, audit rights, export support, service levels and transition assistance. Seek at least 90 days’ notice for material model deprecation where feasible, but do not rely on it: popular model versions can change faster than enterprise procurement cycles. Avoid minimum-spend commitments that exceed credible demand, particularly when unit prices are falling and smaller models are improving.

Ask vendors for precise answers. Can fine-tuning data and outputs be exported? Are embeddings reproducible? How long are abuse-monitoring logs retained? Do regional endpoints invoke services elsewhere? What happens to provisioned capacity when a model is retired? A contractual right to retrieve data in a ‘standard format’ is ambiguous unless the format, metadata and delivery timetable are named.

Commercial diversification should follow workload importance. A low-risk internal drafting tool may justify deep integration with one vendor. A revenue-critical underwriting workflow deserves a tested alternative and stronger termination assistance. Quantify concentration: if one provider supports 80% of AI transactions and every high-severity process, the risk is not captured by transaction share alone. Report spend, critical workloads and estimated migration time together.

Rehearse the exit before it becomes urgent

An exit plan is credible when a team has executed it. Choose one bounded workload each quarter or half-year and run it on an alternative model. Rebuild the relevant index, execute the evaluation suite, compare costs and document engineering effort. A two-week rehearsal may reveal that the gateway works but the moderation workflow, analytics schema or procurement approval does not. Those discoveries are the purpose of the exercise.

Track portability as an operational objective. Useful measures include the percentage of prompts held in the registry, workloads covered by regression tests, data stores with verified exports, provider-specific code paths and time required to shift 25% of traffic. Set tolerances rather than pursuing purity. An organisation might accept that 15% of workflows use proprietary features because they deliver disproportionate value, while requiring every tier-one system to have a validated fallback within 30 days.

The strongest organisations do not avoid vendor advantages; they price them correctly. They move quickly with a leading model, but surround that decision with owned data, explicit interfaces, reproducible prompts, independent evaluations and rehearsed recovery. That discipline preserves bargaining power and resilience without condemning teams to build every capability themselves. Momentum and optionality are not opposites, provided portability is engineered continuously rather than purchased during a crisis.