Category: Model Lifecycle & MLOps

Model Decommissioning

Also known as: Model Retirement, Model Sunsetting, Model Termination

Simply put

Model decommissioning is the controlled process of retiring an AI or analytical model when it is no longer needed, is being replaced, or is no longer fit for its intended use. It involves formally shutting down the model, removing or restricting its access and use, and handling the resulting data, documentation, and dependencies in an orderly way. The goal is to end a model's operational life without introducing new risks or disruptions.

Formal definition

Model decommissioning refers to the planned, documented, and governed termination of a model's operational lifecycle stage, encompassing the retirement of the model, its access and downstream dependencies, and the disposition of associated artifacts. As commonly framed in lifecycle-oriented approaches, decommissioning parallels the controlled retirement concepts used in other asset domains, where a defined process covers the planning, conduct, and termination phases of taking an asset out of service. In model risk management contexts, decommissioning is typically treated as a formal control activity requiring authorization, impact assessment on dependent systems and processes, retention or disposal of records per applicable policy, and confirmation that residual obligations (e.g., ongoing monitoring exit, downstream consumer migration) are addressed. Note: the specific procedural requirements, ownership, and documentation expectations for model decommissioning vary by organization and jurisdiction and are not uniformly standardized; the evidence available here draws on decommissioning practices from adjacent asset domains rather than a definitive AI-specific regulatory definition, so this scope should be treated as indicative rather than authoritative.

Why it matters

Model decommissioning matters because the end of a model's operational life is itself a source of risk, not simply an administrative cleanup step. A model that is switched off without a controlled process can leave behind orphaned dependencies, downstream consumers still calling for outputs, unmigrated processes, or records disposed of prematurely against retention obligations. As with controlled retirement in other asset domains, the planning, conduct, and termination phases each carry distinct hazards, and skipping or underestimating any of them can introduce new disruptions at precisely the moment an organization believes it is reducing exposure.

Evidence from adjacent asset domains illustrates why disciplined decommissioning deserves attention. Studies of coal plant decommissioning describe the drivers, decommissioning types, and the process and financial obligations owners undertake, while analyses of energy assets note that decommissioning risk spans financial, operational, and regulatory dimensions and that residual value can be misjudged when these costs are underestimated. Reporting on UK upstream decommissioning further characterizes it as a fast-growing capital spend area historically marked by cost and schedule overruns. These parallels suggest that treating retirement as trivial tends to produce underestimated cost, unresolved residual obligations, and overruns.

Applied to models, this means decommissioning should be governed with the same rigor as deployment. The specific requirements are not uniformly standardized across organizations or jurisdictions, so the risk is compounded when firms assume a single accepted procedure exists. In model risk management practice, treating decommissioning as a formal control activity with authorization and impact assessment reduces the likelihood that a retired model leaves behind unmonitored dependencies or non-compliant record handling; it does not eliminate that risk entirely.

Who it's relevant to

Model Risk Managers

Model risk managers are typically responsible for ensuring decommissioning is treated as a formal control activity rather than an ad hoc shutdown. This includes confirming authorization, requiring an impact assessment on dependent systems and processes, and verifying that residual obligations such as monitoring exit and downstream consumer migration are addressed before a model leaves service.

AI Governance and Policy Specialists

Governance and policy specialists set the organizational expectations for how retirement is authorized, documented, and owned. Because these expectations are not uniformly standardized across organizations or jurisdictions, this group often has to translate general lifecycle principles into internally defined policy rather than relying on a single external requirement.

Auditors and Compliance Officers

Auditors and compliance officers assess whether decommissioning was conducted in an orderly, documented way—particularly the retention or disposal of records per applicable policy. Given evidence from adjacent domains that residual costs and obligations are frequently underestimated, this group scrutinizes whether all downstream dependencies and record-handling obligations were resolved.

Data Scientists and Model Owners

Data scientists and model owners handle the technical conduct of retirement, including disposition of the model, its data, code, and downstream dependencies. Their role is to ensure the model is shut down and its access removed or restricted in a way that avoids introducing new disruptions to systems that consumed its outputs.

Inside Model Decommissioning

Retirement Decision and Rationale

The documented determination that a model should be removed from active use, along with the business, technical, or risk-based justification (for example, obsolescence, poor performance, replacement by a successor model, or regulatory concerns). This decision is typically subject to appropriate governance approval.

Inventory and Status Update

Updating the model inventory to reflect the model's changed status. In many model risk management frameworks the inventory is expected to capture the full lifecycle, so a decommissioned model is typically marked as retired rather than deleted from the record.

Dependency and Downstream Impact Assessment

Identification of systems, processes, reports, and other models that consume the decommissioned model's outputs, so that dependencies are addressed before use ceases. Overlooked downstream dependencies are a common source of disruption.

Transition or Replacement Plan

Where the model is being replaced, the plan governing cutover to a successor model or alternative process, including any parallel-run or fallback arrangements. This component may be absent when a model is retired without replacement.

Records Retention and Documentation

Preservation of model documentation, validation evidence, and relevant artifacts consistent with applicable retention obligations, so that the model's history remains auditable after it is no longer in use. Specific retention periods depend on organizational policy and jurisdiction.

Access, Data, and Infrastructure Handling

Controlled disabling of the model's access to production data and systems, and handling of associated data and computing resources in line with data governance and security policies. What is deleted versus retained typically depends on retention and privacy requirements.

Governance Sign-off and Accountability

Assignment of ownership and formal approval for the decommissioning through defined governance channels, so that responsibility for the retirement is clear and traceable.

Common questions

Answers to the questions practitioners most commonly ask about Model Decommissioning.

Does decommissioning a model mean it is simply switched off and forgotten?

No. Decommissioning is typically treated as a controlled, governed process rather than a one-time shutdown. In many model risk management frameworks, retirement involves formal approval, documentation of the rationale, and defined handling of associated artifacts and dependencies. Treating it as merely flipping a switch is a common error, because a model that is nominally 'off' may still have downstream consumers, cached outputs, or integrations that continue to rely on it.

Is decommissioning the same thing as deleting the model and its records?

Not usually. Professionals frequently conflate retiring a model with erasing it, but the two are distinct. Decommissioning generally refers to removing a model from active production use, whereas retention of documentation, validation records, and other artifacts is often governed separately by record-keeping and audit expectations. In many contexts, records are retained for a defined period after a model is retired rather than destroyed at decommissioning.

What typically triggers a decision to decommission a model?

Common triggers cited in practice include sustained performance degradation, changes in the underlying data or business environment that undermine model assumptions, replacement by a newer model, changes in regulatory or policy expectations, or a determination that the model's use case is no longer needed. The specific triggers and thresholds are usually defined in an organization's model governance policy rather than being universal.

Who is typically involved in approving a decommissioning decision?

Responsibilities vary by organization, but decommissioning decisions commonly involve model owners or developers in the first line, independent review functions such as model validation or risk management in the second line, and sometimes governance committees. Where a three-lines model is used, the aim is to ensure the decision is not made unilaterally by the model's owner. Exact roles and sign-off requirements should be defined in internal governance frameworks.

How are dependencies and downstream consumers usually handled during decommissioning?

A common practice is to inventory and assess the model's dependencies and downstream consumers before retirement, so that integrations, reporting processes, or other models relying on its outputs are identified and transitioned or terminated deliberately. Failing to map these dependencies is a frequent source of operational risk, since a retired model can leave gaps if consuming systems are not addressed.

What documentation is typically produced when a model is decommissioned?

Organizations commonly document the decommissioning rationale, the approvals obtained, the date and scope of retirement, the handling of dependencies, and arrangements for retaining relevant records. This documentation is often expected to support later audit and to maintain a defensible history of the model lifecycle. The precise content and retention expectations depend on the applicable internal policies and any relevant regulatory or supervisory expectations, which vary by sector and jurisdiction.

Common misconceptions

Decommissioning simply means turning a model off and deleting it.

In many frameworks, decommissioning is a governed lifecycle event that typically requires documented rationale, inventory updates, dependency handling, and records retention. Deleting artifacts prematurely can undermine auditability and conflict with retention obligations.

Once a model is decommissioned it no longer carries any model risk considerations.

Residual considerations can persist after retirement, such as historical decisions made by the model, downstream systems that still rely on its outputs, and the need to retain documentation. Retirement reduces certain risks but does not necessarily end all associated obligations.

Model decommissioning and model replacement are the same activity.

A model can be decommissioned without being replaced, and replacement introduces its own validation and transition requirements. Treating the two as identical can lead to gaps, for example retiring a model while its downstream consumers still expect its outputs.

Best practices

Require documented rationale and formal governance approval before a model is decommissioned, and record the accountable owner for the retirement.

Update the model inventory to reflect a retired status rather than removing the record, so the full lifecycle remains traceable and auditable.

Perform a dependency and downstream impact assessment to identify systems, reports, and other models that consume the model's outputs before use ceases.

Retain model documentation, validation evidence, and relevant artifacts in line with applicable retention policies and obligations rather than deleting them at retirement.

Where a successor model or alternative process is introduced, define a transition plan that addresses cutover and any fallback arrangements.

Control the disabling of the model's access to production data and systems in accordance with data governance and security policies.