AI Decommissioning: Retire Every Avatar Dependency

AI decommissioning is not complete when an avatar is switched off. A regulated organisation must close every route by which the service can still act, authenticate, process data, consume compute, expose content or return from backup. The practical deliverable is a retirement manifest: one controlled record covering channels, integrations, identities, workloads, models, data, evidence and suppliers.

The safest sequence is to freeze new intake, preserve the records that must remain, remove business-action authority, revoke identities, stop workloads, sanitise assets and data, verify every dependency, then monitor for accidental reactivation. That order prevents a dormant-looking service from retaining a live payment API, long-lived credential or scheduled GPU job.

This guide provides eight closure streams, a deployment comparison and twelve resurrection tests for private, sovereign and cloud avatar systems. It extends an AI bill of materials for avatar dependencies: the bill identifies what exists; the retirement manifest proves what happened to it.

Decommission the service, not only the model

A real-time avatar is a service chain. It can include microphones and browser permissions, speech recognition, translation, retrieval, a language model, policy controls, voice synthesis, rendering, WebRTC, identity, business APIs, telemetry and administration. Removing one model endpoint does not close the rest.

Three activities are often confused:

• Session teardown ends one conversation and clears its temporary state. The production service remains available. Yepic’s guide to secure avatar session teardown covers that boundary.
• Vendor exit moves data, configurations or operations to a successor. The business capability may continue. An AI vendor exit plan governs that migration.
• Decommissioning retires a defined service or component and proves that its remaining dependencies are either closed, transferred or deliberately retained.

The scope must therefore be named precisely. “Retire the avatar” could mean one persona, one kiosk, one language, one country service, one model version or the complete platform. Each scope produces a different dependency graph and evidence set.

Plan retirement during design

The UK National Cyber Security Centre’s secure AI development guidance, published on 27 November 2023, says lifecycle plans should include processes to decommission AI systems and should address risks to future similar systems. It also recommends tracking models, data, prompts, software, documentation, logs and assessments.

The NIST AI Risk Management Framework playbook asks organisations to assess impacts from changes in deployment, including decommissioning algorithms and models. The important point is that withdrawal can affect users and workflows as well as technology. A citizen-service avatar may have become an access route; a training coach may hold appeal evidence; a bank assistant may sit inside a customer journey. Retirement needs an owner, an impact assessment and a fallback before engineers remove infrastructure.

Add a retirement section to the architecture decision record before production. Name the trigger, accountable owner, replacement or fallback, dependency inventory, retention rules, evidence standard, supplier duties and post-closure monitoring period. This is cheaper than reconstructing an undocumented service at the end.

Build one retirement manifest across eight streams

The manifest should give each item an owner, target state, evidence source, completion date, exception and approver. Do not mark a stream complete because a ticket was closed; link to evidence that the target state was reached.

1. Intake, channels and user communication

Stop new sessions through websites, mobile applications, kiosks, QR codes, embedded iframes and contact-centre routes. Replace the endpoint with an accurate alternative rather than a silent failure. Remove browser permissions and device-management profiles where relevant. Tell operators, service desks and affected users what changes, when it changes and how unfinished cases will be handled.

Keep a time-bounded drain period if active sessions or queued work must finish. Record the exact point after which no new interaction is accepted.

2. Actions and business integrations

Remove the avatar’s authority to create cases, make bookings, initiate transactions, retrieve customer records or update government systems before stopping its conversational layer. Disable webhooks, API routes, queues and event subscriptions. Check compensating workflows for actions already accepted but not completed.

This ordering matters: an apparently unavailable interface can still leave an asynchronous worker processing messages. The closure evidence should show both denied new actions and resolved in-flight actions.

3. Human and non-human identities

Revoke administrator accounts, support access, service accounts, workload identities, certificates, tokens and secrets. Remove group memberships and trust relationships at both ends of an integration. Rotate any shared credential that cannot be revoked without affecting another service.

Use the identity register described in non-human identity for AI agents to find speech, retrieval, policy, rendering and action services that may not appear in a user directory. Expiry is not proof of revocation if the credential remains valid for days or months.

4. Workloads, network paths and compute

Stop containers, virtual machines, GPU jobs, schedulers, autoscaling groups and serverless functions. Remove load-balancer listeners, DNS records, firewall rules, private endpoints and media relays that exist only for the retired scope. Release reserved capacity and licences after evidence collection.

Look for dormant infrastructure: a disaster-recovery cluster, development copy, overnight indexer or capacity rule can recreate spend and exposure without producing obvious user traffic. Customer-hosted deployment gives the organisation direct control over these resources, but it also makes their discovery and closure the customer’s responsibility.

5. Models, prompts and avatar identity assets

Decide the destination of language, speech, translation, voice and rendering artefacts; adapters and fine-tunes; system prompts; policy bundles; evaluation sets; avatar captures; consent records; and licensed actor assets. Possible outcomes include transfer to a successor, controlled archive, licence expiry, deletion or continued retention under a documented purpose.

Do not assume model deletion automatically removes training influence, cached copies or derived artefacts. Equally, do not destroy a consent or provenance record that may be needed to prove why an identity asset existed. The organisation’s model licences, contractual rights, records policy and applicable law determine the correct outcome.

6. Operational data and backups

Map raw audio and video, transcripts, prompts, outputs, retrieved passages, embeddings, vector indexes, feedback, caches, object stores, databases and support attachments. Assign a retention or destruction decision to each copy, including backups and replicas.

The ICO’s current storage-limitation guidance says personal data should not be kept longer than necessary, requires organisations to justify retention periods, and distinguishes permanent deletion from merely taking data offline. It also recognises that legal, regulatory, complaint or archiving needs may justify retaining selected records. The guidance is under review following the Data (Use and Access) Act, so teams should check the current position for their processing.

For media being reused or disposed of, NIST SP 800-88 Revision 2, finalised on 26 September 2025, defines sanitisation as making access to target data infeasible for a given level of effort. The appropriate method depends on the medium, sensitivity and architecture. Deleting a database row is not the same as sanitising physical media, and cryptographic erase is not suitable for every design.

7. Evidence, monitoring and support

Preserve the minimum evidence required for audit, complaint handling, incident investigation and regulatory duties before telemetry is removed. Then retire dashboards, alerts, synthetic tests, runbooks, support queues and on-call routes that are no longer needed. Update the service catalogue and configuration database.

Keep one narrow post-closure monitor where practical: unexpected authentication, DNS requests, queue traffic, GPU allocation or outbound calls should trigger investigation. A retired service that becomes active again is a configuration incident, not a successful recovery.

8. Suppliers, contracts and closure acceptance

Assign every supplier action: tenant closure, data return, deletion, licence termination, support-access removal, hardware return and evidence delivery. A supplier’s generic deletion statement may not cover backups, subprocessors, diagnostic logs or customer-controlled storage. Define what its evidence proves and what remains outside its scope.

Finish with a signed closure record listing completed controls, retained assets, unresolved exceptions, residual risk, monitoring end date and accountable approver. Decommissioning is complete only when the service owner accepts that record.

Use a safe order of operations

1. Freeze: stop new releases, intake and configuration changes for the retirement scope.
2. Preserve: capture required evidence, inventories, decisions and in-flight work.
3. Disarm: remove business-action authority and external integrations.
4. Revoke: close human and workload identities, secrets and trust paths.
5. Stop: terminate workloads, schedules, network routes and compute.
6. Sanitise: transfer, retain, anonymise or destroy data and artefacts according to policy.
7. Verify: run independent closure tests and reconcile the manifest.
8. Observe: monitor the agreed period for residual traffic or unintended restoration.

There can be justified variations. An emergency security shutdown may stop workloads before evidence collection; a legal hold may prevent deletion; a public service may need a parallel replacement before intake closes. Record the exception and its risk rather than disguising it as the standard sequence.

Deployment model changes the retirement burden

Managed public cloud can make tenant closure and infrastructure disposal operationally simple, but the customer depends on provider evidence for hidden copies, backups and subprocessors. Confirm export, retention and deletion terms before onboarding.

Private or sovereign cloud may improve location and tenant control while splitting duties among the customer, cloud operator, avatar provider and integrator. The retirement manifest must cross those boundaries.

Customer-hosted inference can keep selected models, media and data inside the customer environment on customer-controlled GPUs, subject to a properly scoped implementation. It also leaves the customer with local replicas, registries, credentials, backups and hardware sanitisation. On-premise is not automatically easier to retire; it provides more direct control in exchange for more direct work.

Twelve resurrection tests

1. Can any public, private or kiosk endpoint still start a session?
2. Can an old user, administrator or support account still sign in?
3. Can any service credential obtain a token or reach a protected API?
4. Can queued, scheduled or event-driven work still execute?
5. Do DNS, load balancers, firewalls, webhooks or media relays still route traffic?
6. Can autoscaling, orchestration or infrastructure-as-code recreate the workload?
7. Would a routine backup restore recreate data, secrets or a runnable service?
8. Do container registries, model stores or artefact repositories retain unauthorised copies?
9. Can the retired avatar identity, voice or prompt still be selected in another environment?
10. Are monitoring, billing or GPU-allocation signals still appearing after closure?
11. Can suppliers prove completion for their scope, including declared subprocessors?
12. Can an independent reviewer reconcile every retained item and exception to the retirement manifest?

Run these tests from multiple viewpoints: an unauthenticated user, a former administrator, a workload, an operator and a recovery team. The strongest closure evidence combines denied access, absent resources, supplier confirmation and manifest reconciliation.

Apply integration evidence without overstating it

Yepic’s Abu Dhabi Aviation and Oracle enterprise avatar integration involved separate development and production environments, API and iframe integration, real-time streaming, captions and microphone behaviour, WebRTC and network testing, browser remediation, cybersecurity support and ongoing maintenance. That work illustrates how many dependencies sit around a live avatar and therefore need ownership at retirement.

It is not presented as a completed customer-hosted decommissioning project. For private, sovereign and on-premise deployments, Yepic can work with the customer to scope which proprietary avatar components run in its environment, what remains externally managed and how lifecycle duties are divided. Cloud or private-cloud deployment may be the better choice where managed closure, elastic capacity or faster updates outweigh the need for direct infrastructure control.

The production gate is simple: if the organisation cannot state today how each avatar dependency will be transferred, retained, revoked, stopped, sanitised and verified, the service is not yet designed for retirement.