What are the key model decommissioning best practices?

What decommissioning has to prove before a model is truly retired

Model decommissioning is not just a toggle-off event. The practical test is whether you have identified every place the model can still be invoked, every integration that can still call it, and every dependent secret or session that can still reach it. If any one of those paths remains, the model is not fully decommissioned, only hidden from some users.

A good retirement process therefore starts with a full usage map: production endpoints, internal tools, batch jobs, UI hooks, API consumers, notebooks, and any automation that wraps the model. That inventory should include indirect access paths, because teams often remove the obvious endpoint while leaving scheduled jobs, cached clients, or shadow integrations untouched.

For governance-heavy programmes, AI Governance Guide is the most natural home for the broader control side of this work, because decommissioning sits inside model inventory, ownership, approval, and retirement discipline rather than being an isolated operations task.

Which access paths and dependencies must be removed first?

The first removals should be the ones that can still produce live impact. Disable or remove production access before you clean up archives, documentation, or historical artefacts, because a live invocation path is the highest-risk residue. Then revoke the credentials, tokens, keys, service accounts, and third-party integrations that were allowed to call the model.

This is where dependency tracing matters. A model may be retired in one platform but still reachable through a gateway, SDK wrapper, plugin, CI job, or upstream application. Teams should also check whether downstream systems still expect responses from that model, because a silent retirement can break business flows or cause fallback behaviour that is harder to detect than an obvious outage.

For machine and service access, the retirement pattern is the same as lifecycle control for other non-human access paths: discover what still authenticates, remove what no longer should, and confirm the inactive path is actually dead rather than merely unused. The NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that offboarding only works when discovery, ownership, and revocation happen together.

How should teams handle records, artefacts, and retained outputs?

Decommissioning should preserve what is needed for audit, incident review, and rollback, but nothing more. Keep the minimum set of records that prove what was retired, who approved it, when access was removed, and what version or configuration was in service at the time. That makes the retirement defensible without leaving the model environment partially live.

After that, dispose of training data references, cached outputs, temporary files, embedded prompts, and model artefacts according to retention rules and legal holds. The key judgement is to separate evidence that must remain from working material that should not continue to exist in a usable state. If the model touched regulated or sensitive data, the disposal step should be treated as part of the security boundary, not just a housekeeping exercise.

Where model artefacts or cached outputs are stored in shared infrastructure, teams should also look for secondary exposure such as copied artefacts in notebooks, backup stores, or experiment tracking systems. The Shadow AI and AI Agent Discovery Guide is useful here because retirement often fails when the organisation forgets where the model was copied, embedded, or reused outside the formal platform.

Risk and Threat Considerations

Retired models can remain exploitable if one call path, secret, or cached dependency survives. The main risk is not that the model still exists somewhere, but that someone else can still reach it after the business believes it has been taken out of service.

Failure mechanism: Partial decommissioning leaves valid credentials, residual integrations, or stale replicas in place, which lets callers continue invoking the model or retrieving its outputs. Attackers and insiders can abuse those remnants for unauthorised access, data exposure, or unexpected spending.

Impact: The organisation can end up with a model that is “retired” on paper but still operational in practice, creating audit failure, residual data exposure, and a delayed incident response problem if compromise occurred before shutdown.

Practitioner Guidance

What to verify: Confirm that the model cannot be invoked through any production, test, automation, or indirect integration path before you declare decommissioning complete. Verify revocation as an observed state, not as a ticket closure.

Decision rule: If a secret, token, or integration can still authenticate to anything that reaches the model, rotate or revoke that path first and treat the model as still exposed until the call fails cleanly.

Practitioner takeaway: Good decommissioning is measured by the absence of reachable access, not by the absence of user traffic; if the invocation path still exists, the model is not retired.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• What are the key model explainability best practices for fraud?
• What are the key Model Registry Security best practices?
• What are the key Model Scanning best practices?