Category: Model Lifecycle & MLOps

End-of-Life Management

Also known as:

Simply put

The evidence provided for this entry describes clinical end-of-life care, the medical and supportive care given to people in the final stages of life, focused on comfort, dignity, and quality of life. None of the supplied sources address 'End-of-Life Management' as it is used in AI governance or model risk management (for example, the planned retirement or decommissioning of AI systems or models). Because of this, an accurate glossary definition for the AI-governance sense of this term cannot be written from the evidence given.

Formal definition

The supplied evidence packet defines a healthcare concept: end-of-life (EOL) care as the support and medical care provided during the period surrounding death, oriented toward physical and emotional comfort, symptom management, and dignity, and often delivered through palliative or hospice services. This clinical meaning is distinct from and unrelated to any AI/MLOps model lifecycle concept such as model or system retirement, decommissioning, sunsetting, or archival. No sources in the evidence address model lifecycle, MLOps, model risk management, or any regulatory or standards treatment of technology end-of-life; therefore a practitioner-level definition of 'End-of-Life Management' for AI systems cannot be substantiated from this evidence and is not asserted here. To produce a valid AI-governance entry, evidence describing model/system decommissioning practices and any applicable guidance or standards would be required.

Why it matters

The evidence assembled for this entry describes clinical end-of-life care, the medical and supportive care given to people in the final stages of life, and does not address 'End-of-Life Management' as the term is used in AI governance or model risk management (for example, the planned retirement, decommissioning, or sunsetting of AI systems and models). Because the sources concern a healthcare concept rather than a technology-lifecycle concept, no AI-governance rationale for this term can be substantiated from the material provided. Presenting one would require conflating two unrelated concepts, which this entry deliberately avoids.

Who it's relevant to

Glossary editors and taxonomy owners

This entry is flagged as out of scope for the AI-governance glossary because its evidence base is exclusively clinical. Editors should decide whether to (a) recollect evidence describing AI/model decommissioning practices before creating an AI-governance 'End-of-Life Management' entry, or (b) reclassify and rename the material as a clinical 'End-of-Life Care' term outside the glossary's stated scope. The two concepts should not be merged into a single entry.

Model risk and MLOps practitioners seeking the AI meaning

Readers looking for guidance on model retirement, sunsetting, archival, or decommissioning will not find a substantiated definition here, because the supplied evidence does not cover those topics. This limitation is stated explicitly rather than filled with unsupported claims; a future entry built on domain-appropriate evidence would be needed to serve this audience.

Inside EOL

Decommissioning trigger and decision

In a model lifecycle context, End-of-Life Management typically begins with a documented decision to retire a model or AI system, based on triggers such as sustained performance degradation, obsolescence, replacement by a successor model, changed business use, or a determination that the model is no longer fit for purpose. The decision and its rationale are commonly recorded in the model inventory.

Stakeholder notification and dependency mapping

Identifying and informing downstream consumers, integrated systems, and business owners that depend on the model's outputs, so that dependencies can be transitioned or terminated in a controlled way before retirement.

Transition or replacement planning

Where a retired model supports an ongoing business function, End-of-Life Management commonly includes a plan to migrate to a successor model or alternative process, including a period of parallel running or fallback where appropriate.

Data and artifact handling

Determining what happens to associated data, training sets, code, and model artifacts at retirement, including retention, archival, or secure disposal in line with the organization's applicable data retention and records policies.

Documentation and record retention

Retaining documentation of the model, its validation history, and the retirement decision. Retention periods and evidentiary needs depend on the organization's internal policies and any obligations that apply in its jurisdiction and sector; the specific requirements are not asserted here.

Governance sign-off and inventory update

Recording formal approval of the retirement and updating the model inventory or registry to reflect the changed status, so that decommissioned models are not inadvertently used in production.

Common questions

Answers to the questions practitioners most commonly ask about EOL.

Does "End-of-Life Management" in a Model Lifecycle & MLOps context refer to clinical hospice or patient care?

No. Within the Model Lifecycle & MLOps category, End-of-Life Management refers to the planned retirement or decommissioning of AI/ML models and systems, not to clinical end-of-life or hospice care. The clinical meaning is a separate concept from an unrelated domain and is out of scope for this entry. If you are researching clinical hospice or palliative care, that is a distinct term that should be treated separately.

Is decommissioning a model the same as simply shutting off its serving endpoint?

Not typically. Turning off an endpoint stops inference, but End-of-Life Management as commonly defined is broader: it addresses the orderly wind-down of a model across its dependencies, documentation, data handling, downstream consumers, and records retention. Treating it as a single technical switch is a common oversimplification that can leave orphaned dependencies, undocumented decisions, or unmanaged data in place.

How should an organization decide when a model has reached end of life?

Decisions are typically driven by predefined triggers rather than ad hoc judgment. Common triggers include sustained performance degradation, changes in the underlying data or business context, replacement by a successor model, or a determination that the model no longer serves its intended purpose. Note that performance degradation is distinct from model risk more broadly; a model may be retired for risk, cost, or strategic reasons even when performance appears acceptable.

What steps are commonly included in a model decommissioning process?

Processes vary by organization, but common elements include: identifying and notifying downstream consumers and dependent systems; disabling inference and removing the model from production pipelines; handling associated data and artifacts according to the organization's retention policies; and preserving documentation so the decision and its rationale remain auditable. The specific sequence and controls should follow the organization's own governance policies.

Who is typically accountable for end-of-life decisions across the lines of defense?

Accountability is usually distributed rather than held by a single role. In organizations that use a lines-of-defense structure, model owners and operators typically execute the retirement, while independent oversight functions may review that controls were followed. The precise allocation depends on the organization's governance framework, and roles should be defined in internal policy rather than assumed.

What documentation should be retained after a model is retired?

Organizations commonly retain records of the retirement decision and its rationale, the date and scope of decommissioning, and evidence that downstream dependencies and data were handled appropriately. Retention periods and specific record types generally follow the organization's internal policies and any applicable retention requirements it has identified; this entry does not assert a universal retention standard.

Common misconceptions

"End-of-Life Management" for AI systems is the same concept as clinical end-of-life care.

These are distinct concepts that share only a name. In a model lifecycle and MLOps context, End-of-Life Management refers to the retirement or decommissioning of models and AI systems. Clinical end-of-life care (for example hospice and palliative care) is an unrelated healthcare concept and is out of scope for this glossary entry.

Once a model is switched off, no further governance activity is needed.

Retirement is itself a governed lifecycle stage. Organizations typically still need to handle dependencies, retain documentation, address data and artifacts, and update the model inventory so the model is not reintroduced without review. Turning a model off does not by itself discharge these obligations.

Retiring a model eliminates the risks associated with it.

Decommissioning is a control that reduces certain risks (such as use of an outdated model) but does not eliminate risk. Residual concerns can remain, for example around retained data, historical decisions made by the model, or gaps left when a dependent process loses its model without a replacement.

Best practices

Treat model retirement as a formal, approved lifecycle stage with documented triggers, decision rationale, and governance sign-off rather than an informal shutdown.

Map downstream dependencies and notify affected system owners and business users before decommissioning so that dependent processes are transitioned or safely terminated.

Update the model inventory or registry immediately to reflect retired status, preventing accidental continued use of a decommissioned model in production.

Define and follow explicit handling rules for data, code, and model artifacts at retirement, aligned with the organization's own data retention and disposal policies.

Where a retired model supports an active function, plan the successor or fallback process and consider a controlled transition period before full cut-over.

Retain documentation and validation history for the period required by the organization's internal policies and any obligations applicable in its jurisdiction and sector, confirming those requirements rather than assuming them.