AI Vendor Lock-In: Build an Exit Plan for Avatar Systems

The time to design an exit from an AI avatar supplier is before the production contract is signed. A credible plan should let a bank, government department or regulated enterprise replace one component, move the service to another hosting model, transfer it to a new supplier or retire it without losing authorised knowledge, identity assets, audit evidence or service continuity.

Do not reduce this to “Can we export our data?” A real-time avatar is a chain of speech, language, retrieval, identity, tools, rendering, streaming and operational processes. Customer-hosted deployment may give the buyer more infrastructure control, yet still create lock-in through licences, undocumented configuration, vendor-operated updates or non-transferable avatar and voice rights.

This guide turns AI vendor lock-in into something architecture and procurement teams can inspect: an eight-layer exit register, four portability states, five exit scenarios, contract evidence and a production-like exit drill.

Some dependency is rational; invisible dependency is not

Zero lock-in is rarely a sensible goal. A managed speech service may accelerate delivery. A proprietary rendering model may produce a better experience. A deeply integrated private deployment may be more valuable than a theoretically portable but weaker service.

Current UK government guidance on technical lock-in, updated on 1 April 2025, makes the trade-off explicit: organisations should balance a service's value against switching cost, and recognise that technical lock-in cannot be eliminated completely. The useful question is therefore not “Is this proprietary?” but “Which dependency are we accepting, what value does it create, and how will we leave if that value disappears?”

Record the answer while the buyer still has negotiating leverage. Once prompts, identity flows, knowledge indexes, operating procedures and staff skills have accumulated around one supplier, the commercial contract is only one part of the switching cost.

Map eight layers of avatar lock-in

Build an exit register alongside the production architecture. Give every dependency an owner, portability state, export method, replacement route, estimated transition effort and proof date. The NCSC's machine-learning supply-chain guidance recommends understanding external dependencies and points to a machine-learning bill of materials as one way to assess open-source and third-party components.

1. Data and records

List source documents, embeddings, transcripts, conversation outcomes, user feedback, consent records, audit trails, evaluation results and operational telemetry separately. They have different owners, formats and retention rules. An export of raw documents is not an export of the permission model or evidence linking a generated answer to the sources used.

Government Digital Service guidance says supplier contracts should preserve access to data and define exit and renewal arrangements, including return through open-standard formats or suitable APIs. The broader principle is useful outside government too: data must not become dependent on the lifecycle of one service. See the current guidance on how to manage data across a technology lifecycle.

2. Knowledge and retrieval

Capture the source connectors, chunking rules, metadata, access-control mapping, embedding model, index schema, ranking settings, citation format, freshness jobs and revocation process. Some of these can be exported; others must be reconstructed. Test whether a replacement index returns authorised evidence—not merely similar text. Yepic's permission-aware RAG architecture explains why source entitlements must survive the move.

3. Conversation behaviour

Version system instructions, personas, tool descriptions, policy rules, refusal patterns, handover triggers, locale settings and evaluation corpora. Prompts are not automatically portable behaviour: a new model may interpret the same instruction differently. The exit asset is therefore the configuration plus the tests and approved outcomes used to rebuild it.

4. Avatar, voice and identity rights

Separate the human subject's consent from the technical asset. Record who may use the likeness and voice, for which purposes, territories, channels and period; whether derived assets may be transferred to another processor or supplier; and what must be deleted at exit. A buyer should not assume that paying to create an avatar grants ownership of source footage, trained weights or an unrestricted right to recreate the person elsewhere.

Link these terms to the organisation's consent and provenance register, not to an employee's inbox. Yepic's AI avatar disclosure and consent framework provides a practical record structure.

5. Models, runtimes and GPUs

For speech recognition, language, voice and rendering components, record whether the buyer receives model weights, a container, an API, a compiled runtime or only an outcome. Document supported GPU families, drivers, libraries, licence checks, update channels, performance envelope and right to use the last approved version after termination.

“Runs on our GPUs” does not necessarily mean “runs without the supplier”. A customer-hosted component may still require a remote licence server, signed updates, proprietary orchestration or specialist support. Equally, a hosted API may be replaceable behind a well-defined interface. Use the on-premise avatar component guide to expose these interface contracts.

6. Integrations and action contracts

Inventory identity providers, APIs, event schemas, tool definitions, policy gateways, browser embeddings and media interfaces. Preserve interface specifications, test fixtures, sample payloads, error semantics and least-privilege service identities. If a model-specific tool format leaks into every business integration, changing the model becomes a rewrite.

Keep consequential actions behind a deterministic gateway so the conversational layer can be replaced without redesigning authorisation. Yepic's safe action-gateway architecture shows that separation.

7. Deployment and operations

Include infrastructure definitions, network policies, certificates, secrets references, observability, capacity assumptions, backup and recovery procedures, deployment manifests, release approvals and support routes. A container image without the configuration, dependency bill, alert thresholds and restore process is not an operable service.

8. Skills and decision history

Identify the people who know why the system behaves as it does. Record architecture decisions, accepted risks, tuning rationale, known failure modes and manual recovery steps. Require knowledge transfer that lets the buyer or successor operate the service, rather than a folder of unexplained documents on the final day.

Give each asset one of four portability states

“Portable” is too vague for a procurement scorecard. Use four states:

• Portable: the asset can be exported in a documented format and imported into the target with no material transformation.
• Replaceable: the asset itself does not move, but a stable interface, test suite and migration route allow another component to take its place.
• Reconstructable: the asset must be rebuilt, but the buyer holds sufficient source material, rights, configuration and acceptance evidence to do so.
• Retained dependency: continued supplier involvement or licensing is required for an agreed period, with cost, support and termination conditions documented.

This classification avoids two false promises. Proprietary technology is not automatically an unacceptable dependency, and open-source code is not automatically portable if the organisation lacks weights, skills, hardware support or operational evidence.

Plan for five different exits

A single “termination plan” is insufficient because the target state changes the work.

1. Component substitution: replace an LLM, speech service, voice or rendering component while preserving the rest of the stack.
2. Hosting move: retain the application but move between public cloud, private cloud, sovereign cloud or customer infrastructure.
3. Supplier transition: transfer support, configuration and operations to a successor without changing every component at once.
4. Minimum viable continuity: operate a reduced, approved service while a replacement is built—for example, information-only responses and human handover.
5. Retirement: close the service, preserve required records, revoke identities and rights, and verify deletion across suppliers and subcontractors.

The existing deployment-model comparison for AI avatars helps define what changes during a hosting move. Do not assume an on-premise target is always the answer: it may increase operational burden, hardware dependency and migration time even as it improves direct infrastructure control.

Put twelve exit requirements into procurement

Ask suppliers to provide evidence and pricing for:

1. a complete asset and dependency inventory, including subcontractors;
2. buyer ownership and access rights for each data class;
3. documented export formats, APIs, schemas and frequency;
4. rights governing persona, voice, footage and derived assets;
5. configuration, prompt, policy and evaluation export;
6. licence survival, offline operation and last-approved-version rights where applicable;
7. transition assistance, service levels, named roles and maximum charges;
8. continued security patches and incident support during transition;
9. knowledge transfer, runbooks and successor access;
10. credential revocation, data return and deletion evidence;
11. early termination, supplier failure and change-of-control procedures; and
12. a funded, timed exit test before the service becomes critical.

These are commercial requirements as well as technical ones. Engineering cannot create a transfer right that the licence prohibits, and a contract cannot make an undocumented system operable.

Understand what current cloud-switching rules do not solve

The EU Data Act has applied since 12 September 2025 and includes measures intended to make switching between data-processing services easier. The European Commission's current Data Act explanation also addresses interoperability and cloud-market fairness.

Do not infer that this makes an entire AI avatar portable. Scope, provider role, contract date and jurisdiction require legal review, and cloud-switching provisions do not by themselves transfer likeness rights, proprietary model weights, prompts tuned for another model, business integrations or operational expertise. Treat legal switching rights as one input to the exit plan, not the plan itself.

Run an exit drill before production approval

A document can hide a missing export, expired right or unknown dependency. Test the plan in a production-like environment:

1. freeze and identify the approved component and configuration versions;
2. export data, knowledge metadata, prompts, policies, evaluations and audit references;
3. restore those assets into a clean target environment;
4. replace one model or service behind its interface and rerun behavioural tests;
5. rotate supplier credentials and prove buyer-controlled identities continue to work;
6. operate the agreed minimum service with supplier control-plane access unavailable, where the scoped architecture supports this;
7. reconcile record counts, permissions, citations and retention states;
8. exercise human handover, rollback and disaster-recovery routes;
9. verify deletion or return from the old environment; and
10. record elapsed time, disruption, engineering effort, residual dependencies and cost.

Repeat the drill after material architecture, licence or supplier changes. The model-update and rollback framework can supply the version manifest and behavioural regression pack needed for a controlled transition.

Use delivery evidence without overstating portability

Yepic's Abu Dhabi Aviation and Oracle integration demonstrates why the exit boundary extends beyond the avatar model. Delivery included development and production environments, APIs, iframe integration, real-time streaming, caption and microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance.

Those are the kinds of interfaces, environments and operational decisions an exit register must capture. The case is not presented as proof of a completed supplier-exit exercise or customer-hosted migration.

Take this exit test to the approval board

Before approving production, ask:

1. Which dependencies are portable, replaceable, reconstructable or deliberately retained?
2. Can the buyer export permissions and evidence, not only raw content?
3. Do avatar and voice rights permit the intended transition?
4. What stops working if supplier connectivity or licensing disappears?
5. Can a component change without rewriting identity and business APIs?
6. Who can operate the last approved version, on which hardware and for how long?
7. What reduced service protects users during a transition?
8. How are records retained and old copies securely deleted?
9. What did the last exit drill cost, and which assumptions failed?
10. Which contract, architecture or supplier change triggers another drill?

Yepic can scope public-cloud, private-cloud, sovereign and customer-hosted avatar architectures, including deployment on customer-controlled GPUs where the models, hardware and implementation support it. That flexibility should be made concrete through interfaces, rights and tested operational evidence—not presented as a blanket promise that every component can move anywhere.

A strong supplier should be able to explain both how the system enters production and how it will leave. Buyers should insist on seeing both plans before either becomes expensive.