AI Vendor Exit: Prove Portability Before You Need It

An AI service can expose a familiar chat API and still be extremely difficult to leave. The hard dependencies are often outside the model call: hosted conversation state, proprietary retrieval indexes, prompt versions, safety policies, tool semantics, evaluation history, identity mappings and audit evidence. A download of prompts and documents may preserve files while losing the system that made them useful.

The reader decision is therefore not “should we avoid every provider-specific feature?” It is: what level of switching capability does this service need, which assets must remain under organisational control, and what evidence proves the exit works? A low-risk drafting tool can rationally accept more replacement work than a service that supports regulated decisions or customer actions. The cost should be explicit rather than discovered during an outage, price change or contract dispute.

This field guide treats portability as an executable operating capability. Build an exit manifest, separate portable truth from generated artefacts, rehearse a target restore, compare outcomes and close the old provider safely. Contract language matters, but a migration that has never been run is still a hypothesis.

Portability is an outcome, not a contract noun

UK government AI procurement guidelines recommend lifecycle management, knowledge transfer, technical standards and measures to limit vendor lock-in. The Digital, Data and Technology Playbook is more operational: it says the outgoing exit strategy should join to mobilisation of the replacement or in-house service, and that the plan should be reviewed before contract end.

The commercial concern is observable beyond AI. In March 2026 the UK Competition and Markets Authority said its cloud investigation had identified data-egress fees and interoperability barriers that restricted switching and multi-cloud. That finding applies to cloud services, not every AI product. AIEngine's inference is that teams buying managed AI on cloud infrastructure should measure these same frictions in the complete inference, storage and observability path rather than treating model access as the whole service.

Open interfaces reduce some friction, but syntax is not behaviour. An API description can preserve field names while a replacement model handles tools, refusals, structured output or long context differently. An export clause can return rows without their access labels, effective dates or deletion state. Judge portability by a successful receiving system, not the existence of a source-side feature.

Put six asset classes in the exit manifest

Maintain a versioned manifest while the service operates. Each item needs an owner, authoritative location, schema or format, export method, maximum export lag, volume, integrity check, receiving test, retention rule and known provider dependency.

Separate canonical assets from rebuildable artefacts. Source documents, labels, access policy and approval records normally belong in controlled systems of record. Embeddings, provider thread IDs, cached responses and hosted search indexes are derived artefacts: retain enough lineage and configuration to rebuild them, but do not mistake their export for independent source truth.

The manifest also exposes rights problems. A fine-tuned model, adapter or generated dataset may be technically downloadable but restricted by contract or an upstream licence. The open-weight licence field guide shows why possession of an artefact and permission to deploy or redistribute it are separate questions.

Choose the required exit level by consequence

Not every workload needs live multi-provider operation. Use a small capability ladder and approve the residual dependency deliberately.

A contained internal assistant may stop at level 2 if manual fallback is credible and rebuilding within several days is acceptable. A consequential workflow, expiring contract or concentrated supplier dependency may justify level 3 or 4. Avoid claiming “provider agnostic” when only the request wrapper is portable.

NIST's voluntary AI Risk Management Framework Playbook recommends documenting third-party AI components, testing them, monitoring compatibility and verifying contingency processes for mission-critical dependencies. Translate that principle into a named target level, maximum recovery time and evidence owner for each service.

Contract for usable transfer and lawful closure

Define exports during procurement or renewal while both parties have leverage. Specify what is exported, which fields and relationships travel, machine-readable formats, schema documentation, frequency, delivery mechanism, encryption, integrity evidence, rate limits, egress charges, assistance hours and the time allowed. Include configuration, annotations and audit records where the buyer needs them; “customer data” can be interpreted too narrowly.

Require notice before a model, retention rule, export interface or provider dependency changes. State which versions remain available during migration and how the supplier supports a destination-side test. The UK Open Standards Principles connect open formats and APIs with interoperability and lower exit costs, while also requiring an informed assessment of the standard rather than openness by label.

Where a supplier processes personal data, the ICO explains that an applicable processor contract must require return or deletion at the controller's choice and deletion of existing copies, subject to legal retention. The ICO also notes that backup deletion may follow an appropriate destruction cycle when data is put beyond use. This is a privacy closure duty, not proof that prompts, evaluations or operational semantics are portable.

For services in scope, the EU Data Act contains specific switching and interoperability provisions for data-processing services. Jurisdiction, service type, exemptions and contractual facts need qualified review. Do not replace an actual exit test with a broad statement that regulation guarantees migration.

Rebuild provider-bound artefacts from controlled truth

Some valuable components should not be expected to travel unchanged. Hosted foundation-model weights may be unavailable. Vector spaces from different embedding models are not interchangeable. Conversation stores may use provider-only object IDs. Guardrails, batch semantics, tool-choice rules and token accounting can change even behind similar endpoints.

Keep the boundary explicit:

• store prompts, policies and tool contracts in a versioned organisational repository;
• preserve raw documents and access metadata outside the vector index;
• assign stable business IDs instead of treating provider object IDs as identity;
• export evaluation items, adjudications and failure taxonomy independently;
• record requested model, invoked model, configuration and outcome in portable telemetry; and
• maintain deterministic rebuild jobs for indexes, caches and derived summaries.

The embedding migration guide explains why a new vector model normally needs a new index and reproducible backfill. The model change-control guide provides the related release baseline. Rebuilding is acceptable when inputs, rules and evidence are controlled; irreproducible regeneration is not portability.

The OpenAPI Specification can make an HTTP contract inspectable, while OpenTelemetry semantic conventions provide common meaning for operational telemetry. Neither standard guarantees equivalent AI behaviour, and the generative-AI conventions continue to evolve. Version the profile actually used and test the business semantics above it.

Rehearse the migration as a controlled release

Run the exercise in an isolated target with no live side-effect authority. The source service remains authoritative until reconciliation and approval.

• Freeze a manifest snapshot and record source high-water marks, pending work, model versions and policy versions.
• Export canonical assets and verify counts, stable IDs, relationships, digests, access labels, tombstones and retained exceptions.
• Rebuild provider-bound artefacts from those inputs; do not import old vectors into a new coordinate system or reuse stale caches.
• Replay a protected evaluation across source and target, keeping assessors blind where judgement is involved.
• Shadow representative traffic or dual-run read-only work, then compare accepted outcome, refusal, citation, tool proposal, latency and total cost.
• Reconcile new and changed records since the snapshot. Prevent the backfill from overwriting a newer target revision.
• Cut over one bounded lane behind a versioned route, monitor it, and prove rollback restores the full previous configuration.
• Close access, exports, retained copies, billing and deletion evidence only after the destination is stable and the investigation window is agreed.

Do not execute the same customer communication, payment or record mutation in two systems. Shadow the proposal, not the consequence. The model-routing field guide shows how to compare eligible models without hiding routing regret, while the exit exercise adds state transfer and provider closure.

Worked example: move a support-drafting assistant

Consider a hypothetical assistant that retrieves approved policies, drafts a response with citations and places it in a staff review queue. It cannot send the message. The organisation wants the option to replace its managed AI provider within 30 days. The numbers illustrate the method; they are not an AIEngine deployment.

The system of record holds cases, policy documents, permissions and final replies. The AI estate adds a prompt bundle, embedding and index configuration, citation assembler, evaluation set, provider thread IDs and traces. The exit manifest marks the thread IDs and vectors as rebuildable rather than portable. It maps each conversation to the stable case ID and stores approved context needed for continuity under the organisation's retention policy.

The target receives a frozen policy manifest plus ordered change events. It builds a new index, then runs the protected evaluation across common questions, conflicting policy versions, revoked access, multilingual cases, missing evidence and prompt-injection attempts. Staff compare drafts without seeing the provider. Live cases are shadowed with queue writes disabled.

If the new model improves average style but misses revoked policies, the migration fails. If quality passes but provider-only thread state cannot be related to case IDs, the service is not yet continuous. The exercise turns portability from a procurement adjective into a release decision.

Preserve useful differentiation without hiding dependency

Portability has a cost. Excessive abstraction can suppress a provider's better tool controls, caching, regional features or evaluation hooks. Standardise the stable boundary—business identity, canonical data, policy, tool contract, outcome evidence and evaluation—then allow provider-specific implementations behind declared adapters.

Record every provider-only feature with its benefit, affected workflows, replacement strategy, last target test and estimated exit effort. Accept the dependency when its measured value exceeds the switching cost and an accountable owner approves that trade. Remove or isolate it when it becomes critical but unrehearsed.

Track manifest coverage, age of the last successful restore, export lag, number of provider-only dependencies, target evaluation gap, time to cut over, rollback time, unexported state, deletion backlog and migration cost at realistic volume. Re-run the relevant exercise after a material model, schema, data, policy, contract, subprocessor or retention change.

The final question is concrete: can another controlled system receive the organisation's truth, reproduce the required behaviour within tolerance, preserve continuity, and let the old provider close without lost evidence or lingering authority? Until the answer has been demonstrated, the service has an exit document—not an exit capability.