The Last Release: Retire an AI System Without Leaving It Running

A company replaces an invoice-exception assistant. The new service receives traffic, the old chat page disappears, and the migration ticket is closed. Two weeks later, the old scheduler retries a delayed batch. Its service account can still draft entries in the accounting system. A regional office still calls the retired endpoint from a spreadsheet macro, and accepted outputs continue entering a feedback dataset. The interface was switched off; the system was not retired.

That creates the reader decision for this guide: should the old AI system be retired now, replaced under a controlled handover, or contained while unresolved obligations are closed? The answer depends on more than whether a model endpoint responds. It depends on new intake, delegated authority, in-flight work, upstream and downstream dependencies, records, data-bearing artifacts, the replacement's behavior, and traffic that nobody knew still existed.

The central rule is: decommissioning is complete only when the organization can prove a closed operating state. No new work can enter, no old authority can produce effects, every pending obligation has a disposition, required evidence remains governed, prohibited remnants are inaccessible, the successor has earned its scope, and residual monitoring finds no unexplained use.

Retirement is a system state, not a deployment event

An AI service is an assembly. It may include a model or provider alias, prompt policy, retrieval corpus, vector index, memory, cache, evaluation set, human queue, scheduled job, webhook, API client, workload identity, tool connector, analytics stream, and downstream decisions. Removing one endpoint changes only one node.

Use distinct end states:

“Disabled,” “scaled to zero,” and “contract ended” are implementation facts, not closure states. A dormant credential, DNS route, queue consumer, local model copy, or human workaround can reopen the path.

What the sources establish—and where analysis begins

The NIST AI RMF Core makes safe decommissioning explicit in Govern 1.7 and includes decommissioning in post-deployment planning. NIST also notes that AI RMF 1.0 is being revised, so teams should track the framework's status rather than freeze its current wording into policy. The companion AI RMF Govern Playbook warns that indiscriminate termination can increase risk and calls out dependencies, retention, investigations, business continuity, and migration to a replacement.

UK guidance reaches the same lifecycle boundary from security practice. The NCSC secure AI development guidance says lifecycle plans should cover decommissioning and risks to future similar systems. Its machine-learning end-of-life principle distinguishes destruction from archiving and asks what model, training material, and logs may be needed to explain past actions. The broader NCSC decommissioning guidance emphasizes linked assets, a working replacement before irreversible destruction, evidence of completion, inventory updates, and monitoring after closure.

These sources establish outcomes, not a universal sequence or retention period. ZharfAI's analysis is to represent retirement as a closure graph and require evidence for each open edge. That turns “we shut it down” into claims that operations, security, data, legal, product, and affected users can test.

Choose retire, replace, or contain before setting a date

Start with the consequence of stopping and the consequence of continuing.

Choose replace when the obligation remains and a successor can be evaluated; retire when the purpose has ended or a non-AI process absorbs it; and contain when continued use is unacceptable or dependencies remain unknown. Containment still needs an owner, preservation rule, and exit criteria.

Write one decision record with the retiring assembly's exact release identity, business purpose, affected populations, reason, owner, target state, successor or fallback, last-admission time, last-action time, preservation duties, irreversible actions, rollback boundary, and closure approver. An AI release passport supplies much of the artifact identity; the retirement record adds the final disposition of every component.

Do not set a destruction date before identifying holds, appeal windows, open transactions, investigations, contractual returns, and recovery needs. Do not let “we might need it” become indefinite retention or production access.

Build the closure graph

Draw nodes and directed edges for everything that can send work, confer authority, receive an effect, preserve state, or learn from an output:

users / APIs / schedules / webhooks -> router -> old AI assembly -> tools / human queue
                                             -> cache / logs / decisions
tools -> external systems -> confirmations / disputes
accepted outputs -> analytics / evaluation / feedback / training snapshots
old identities -> secrets / tokens / roles / vendor consoles
backups / images / edge copies -> restore or redeploy paths

For each node record its owner, environment, artifact ID, data class, identity, retention rule, successor, and closure evidence. For each edge record the trigger, retry and dead-letter behavior, and method to block or observe it. Search beyond the central deployment: spreadsheets, copied keys, edge devices, partner integrations, recovery images, notebooks, vendor dashboards, and manual runbooks. Access, billing, DNS, queue, secret-scan, and vendor-usage evidence can reveal what the inventory missed.

Close intake, then drain and reconcile work

“No new work” must cover every admission path: user interface, public and internal API, batch upload, scheduler, webhook, message topic, retry queue, dead-letter replay, human requeue button, and fallback router. Return an explicit retired or migrated response rather than silently dropping requests. Tell users where work now goes and how to reach past decisions or appeal them.

At the admission cutoff, take a consistent inventory of work states: queued, running, awaiting a tool, awaiting a person, externally committed, failed ambiguously, cancelled, or complete. Give each item one terminal disposition:

• finish on the old system under a bounded exception;
• transfer to the successor with provenance and idempotency intact;
• compensate or reverse an external effect;
• place in qualified human review;
• cancel and notify the affected party; or
• preserve under investigation without further action.

Queue depth reaching zero is not enough. A request can have left the queue and created an unconfirmed invoice draft, email, entitlement, or payment instruction. Reconcile against the external system of record and preserve the old request ID, effect ID, decision, and confirmation. Unknown is an open obligation, not a successful drain.

Move contracts, not merely traffic

A replacement that accepts the same JSON can still retrieve another corpus, handle Persian differently, omit reason codes, reorder tools, or send more work to human review.

Define successor equivalence by outcome:

Run shadow comparison only where data use and risk are approved. Start the successor with the smallest earned scope and keep old action authority off. The recovery-cut guide explains why data, code, indexes, prompts, and effects must form a compatible state.

Separate evidence preservation from continued operation

Retirement creates competing duties: delete what no longer has a purpose, retain what must support audit or appeal, and prevent archived material from becoming a hidden production dataset.

Build a disposition matrix by artifact—not one retention number for the service. Cover decisions, inputs, outputs, prompt and policy versions, model identity, evaluations, access and tool logs, incidents, training snapshots, caches, indexes, backups, and vendor copies. For each, name the purpose, basis, minimum fields, owner, access boundary, expiry, deletion method, and restore behavior.

The ICO's storage-limitation guidance is UK data-protection guidance, not a global default. It requires justified retention, regular review, and deletion or anonymization when personal data is no longer needed; taking data offline is still processing. For high-risk systems in scope, the EU AI Act separately requires expected-lifetime information, specified documentation, and purpose-appropriate log retention, including at least six months in Articles 19 and 26 unless other applicable law provides otherwise. Those provisions do not authorize keeping every prompt forever, nor do they apply universally.

Preserve the smallest evidence capable of supporting the approved claim. Keep stable identifiers, release digests, decision metadata, authorized exceptions, and tool confirmations where raw content is unnecessary. Place archives behind separate identities and deny production retrieval, fine-tuning, analytics reuse, and routine administrator access.

Revoke authority and sanitize the right target

Remove service accounts, workload identities, OAuth grants, API keys, certificates, database roles, queue permissions, tool scopes, vendor users, deploy tokens, schedules, and emergency credentials. Test denial from both the retired runtime and a restored image. Deleting one secret does not expire an issued token or supplier-side grant. The credential-brokering guide shows why short-lived, task-bound authority is easier to close.

Then classify each data-bearing artifact as retain under control, return, migrate, sanitize, or destroy. Models and adapters deserve explicit treatment because they can encode information about training data. NCSC's end-of-life guidance calls out that relationship; it does not imply every model can be erased with a file deletion.

NIST SP 800-88 Revision 2, finalized in September 2025, defines media sanitization around making access to target data infeasible for a stated level of effort and recommends a sensitivity-based program. It governs storage media, not whether a model has “forgotten” training influence. Apply a separate lineage-based process to source records, chunks, embeddings, caches, evaluation sets, feedback data, training snapshots, and deployed derivatives; the deletion-graph playbook covers that distinction.

Prove closure before irreversible destruction

Use a closure ledger. Every row needs a claim, test, terminal result, evidence location, owner, and timestamp:

The OECD robustness, security and safety principle says mechanisms should allow systems that risk undue harm or unwanted behavior to be overridden, repaired, or safely decommissioned. A closure ledger is ZharfAI's implementation pattern, not an OECD-mandated form.

Irreversible destruction should wait until the successor works, open effects are reconciled, required evidence is secured, holds are resolved, and the rollback boundary has been consciously closed. Rollback should never mean silently reactivating old credentials or restoring data beyond its authorized use.

Worked example: replacing an invoice-exception assistant

An organization replaces an assistant that reads invoices, retrieves purchase orders, proposes exception codes, and creates draft entries. Month-end work must continue, so the team closes old UI, API, scheduler, and webhook intake at a recorded time, snapshots request states, and routes fresh work to the successor. Posting authority remains with the accounting service, not either model.

Seventeen old items are active. Twelve finish without effects, three transfer with provenance and idempotency keys, one ERP draft is confirmed, and one ambiguous timeout is reconciled against the ERP audit record. A regional spreadsheet still calling the old endpoint is replaced, resetting the residual-use watch window.

The connector identity and vendor tokens are revoked. Required decision manifests, release digests, evaluations, and ERP confirmations move into a restricted archive. Cached invoice text, old index partitions, copied evaluation inputs, and expired vendor storage receive recorded deletion or sanitization results; training feedback rejects the old release ID.

The successor passes Persian and English cases, exception boundaries, tool-denial, reviewer-capacity, and recovery tests. Only then is unrecoverable configuration destroyed. Old DNS, endpoint, identity, queue, vendor-usage, and billing signals remain under watch. Closure requires zero unexplained residual use and a disposition for every ledger row—not merely one successful new request.

What to monitor after the last release

Track counts that expose unfinished closure:

• new arrivals and denied calls on every old entry point;
• live grants, secrets, roles, certificates, sessions, and supplier accounts tied to the retired identity;
• in-flight items and ambiguous external effects by age and owner;
• upstream or downstream references to the old release, endpoint, queue, or artifact;
• retained artifacts without a purpose, access owner, expiry, or tested deletion path;
• sanitization failures, vendor exceptions, restored copies, and unauthorized reuse;
• successor outcome quality, affected slices, fallback volume, and operational limits;
• residual DNS, network, queue, identity, billing, and user-support signals.

Do not average a live production credential into a reassuring completion percentage. Classify gates as terminal, open, excepted with authority and expiry, or failed. Reopen closure if a restore, audit, user report, cost anomaly, or access event reveals another path.

The decommissioning gate

Before declaring an AI system retired or replaced, require affirmative evidence:

• Is the exact assembly and target state named, with one accountable decision owner?
• Are all UI, API, batch, webhook, retry, fallback, and human admission paths closed or migrated?
• Does every queued, running, human-held, and externally committed item have a reconciled disposition?
• Have upstream and downstream dependencies, shadow users, recovery images, and vendor copies been discovered?
• Has every old identity and action path been revoked and tested from both live and restored environments?
• Does each retained artifact have a justified purpose, minimum content, access boundary, owner, and expiry?
• Have source data, derivatives, models, media, caches, indexes, and backups received distinct dispositions?
• Has the successor proven task, population, language, evidence, effect, capacity, and fallback contracts?
• Are irreversible actions held until obligations, evidence, successor behavior, and rollback boundaries are resolved?
• Does a defined observation window show no unexplained traffic, authority, cost, or reuse?

The last release is not the build that replaces the old system. It is the verified state in which the old system can no longer surprise the organization.

Source notes — reviewed August 23, 2026

• NIST AI RMF Core — January 2023; safe decommissioning and lifecycle planning. NIST states that a revision is in progress.
• NIST AI RMF Govern Playbook — current Govern 1.7 companion on deliberate retirement, dependencies, retention, investigations, continuity, and migration.
• NCSC Guidelines for Secure AI System Development: secure development — version 1.0, published and reviewed 27 November 2023; lifecycle documentation, technical debt, and decommissioning risks.
• NCSC Machine Learning Principles: decommission assets appropriately — version 2.0, 22 May 2024; destruction, archiving, model/data exposure, and explanatory evidence.
• NCSC Decommissioning Assets — version 1.0, 20 May 2025; discovery, linked assets, successor readiness, evidence, and post-closure monitoring.
• ICO storage-limitation guidance — current UK data-protection guidance reviewed on 23 August 2026; retention schedules, justification, review, deletion, anonymization, and the limits of taking data offline.
• Regulation (EU) 2024/1689, the EU AI Act — official text of 13 June 2024; the cited high-risk-system provisions cover expected lifetime, documentation, logging, corrective action, and deployer obligations.
• NIST SP 800-88 Revision 2: Guidelines for Media Sanitization — final September 2025 publication; media sanitization, not model unlearning.
• OECD AI Principle on robustness, security and safety — current OECD principle reviewed on 23 August 2026; lifecycle risk management, traceability, and safe override, repair, or decommissioning.