The Model Retirement Problem: Decommissioning ML Systems Nobody Owns

Most ML platform teams have deployment down to a science. A model passes validation, gets containerized, ships behind an endpoint, and starts serving traffic within hours. Decommissioning that same model years later is a different story — one that involves hunting through a model registry, guessing which downstream services still call an API nobody documented, and eventually escalating to a VP to approve deleting something that might still matter.

This is the model retirement problem: machine learning models routinely outlive the teams, projects, and business cases that created them. A churn model built by a data scientist who left two years ago still runs a nightly batch job. A recommendation endpoint from a discontinued product line still accrues hourly GPU charges. The model registry swells with artifacts that are technically "live" but functionally orphaned.

The stakes are concrete: unbudgeted cloud spend, forgotten endpoints running on over-privileged credentials, compliance exposure from models trained on data you can no longer legally justify, and a registry so cluttered that nobody trusts it as a source of truth. This article lays out why retired models keep running and how to build model decommissioning into the ML lifecycle so it stops being an emergency.

Why Retired Models Keep Running

Models don't stay alive because someone decided they should. They stay alive because nothing forces a decision. No alert fires when a model's business case evaporates. No ticket opens when its owner changes teams. The default state of any deployed artifact is "still running," and defaults win in the absence of process.

The Ownership Vacuum

Ownership erodes quietly. A data scientist leaves, and her models transfer to "the team" — meaning no one. A reorg splits a platform group, and half its models end up in a cost center that has never heard of them. A contractor ships a forecasting pipeline, the contract ends, and the pipeline keeps scoring.

The pattern is consistent: "everyone's model" becomes nobody's model. Once that happens, no one has the authority to retire it, because retirement requires someone to decide that the model no longer earns its keep — and that decision is politically expensive when the model's purpose is unclear. (See [model ownership and accountability models](internal-link: model-ownership).)

The Silent Cost of Orphaned Inference

Orphaned models bill quietly and continuously. Idle endpoints keep provisioned instances warm. Scheduled batch jobs run nightly against data that no longer changes. Stale pipelines write predictions into tables nobody reads. None of this shows up on a roadmap, and none of it triggers an alert, because it's all technically working as designed.

The cost compounds. A single small always-on endpoint might run a couple hundred dollars a month; a GPU-backed inference endpoint can run into the thousands. Multiply either across dozens of orphaned models in a large organization and you're funding meaningful compute for models that produce nothing. Add the technical debt — dependency upgrades, security patches, monitoring overhead — and orphaned inference becomes one of the most reliably invisible line items in the ML budget. (Related: [cutting ML infrastructure waste](internal-link: ml-cost-optimization).)

Orphaned models don't fail loudly. They fail as a line item nobody can explain in the quarterly cloud review.

What Model Retirement Actually Requires

Retirement is not a single action. It's a sequence of verifiable steps, and skipping any one of them creates the kind of half-retired model that's worse than a fully live one — deleted endpoints with live consumers, or archived artifacts still referenced by a training pipeline.

It helps to separate two distinct operations:

• Soft deprecation: the model is marked deprecated, set to read-only, and given a firm end-of-life date. Consumers can still call it, but they get warnings and a deadline.
• Hard decommissioning: endpoints are deleted, credentials revoked, artifacts archived, and the registry entry closed out with a final status.

Soft deprecation buys time for migration. Hard decommissioning reclaims the spend. Most organizations attempt the second without doing the first, which is why retirements stall.

The Retirement Checklist

A complete retirement touches every layer the model touched:

1. Deprecation notice published to all known consumers with a firm end-of-life date.
2. Consumer impact assessment — what breaks, and who signs off on the breakage.
3. Replacement validation — the replacement (or documented fallback) runs in shadow mode against live traffic, with parity confirmed over a defined soak period before cutover.
4. Traffic migration to the replacement, with a rollback path held open until the soak period passes.
5. Credential revocation for service accounts, API keys, and pipeline tokens — ideally made redundant by short-lived workload identity, so an orphaned service loses access the moment its owning identity is removed.
6. Data retention handling — see the note below on inputs/outputs versus the model artifact itself.
7. Registry status change to a deprecated state and then a terminal decommissioned state, using your registry's own status model (or, better, a dedicated retirement_state field), with an audit trail.
8. Post-retirement verification confirming spend dropped and no consumer errors appeared.

The hardest step is almost always number two. Identifying downstream consumers of a model API is genuinely difficult when calls arrive through shared service accounts, internal SDKs, or copy-pasted code. Without request-level logging that attributes traffic to a calling service, you're retiring blind. (See [request-level logging for ML services](internal-link: ml-observability).)

A note on data retention. Two obligations get conflated here. First, inference data — inputs and outputs — must be deleted or aged out under your retention policy and, where applicable, data-subject deletion requests. Second, the model artifact itself may encode personal data from its training set; regulators increasingly treat trained models as in-scope for deletion and access requests. Archiving an artifact to cold storage is not deletion — it can itself violate a retention policy. Confirm with legal which regime applies before you archive, and document the decision.

Building Retirement Into the Model Lifecycle

The only reliable way to retire models is to make retirement a first-class lifecycle stage rather than an afterthought. That means treating the model lifecycle as four equal stages — deploy → monitor → deprecate → decommission — and enforcing the mechanisms that force a decision at each transition.

Three mechanisms do most of the work:

• Required ownership at registration. Every registry entry carries a named owner (a person, not a team alias) and a business justification. Registration fails without them. This is what closes the ownership vacuum at the source.
• Expiry by default. Every deployed model gets a TTL at registration — say, twelve months — that triggers a review, not an automatic deletion. The review asks one question: does this model still earn its keep? If no one answers, the model escalates to the owner and then to their manager. The default flips from "still running" to "must be re-justified."
• A recurring zombie audit. A quarterly sweep cross-references registry entries against live endpoints, billing line items, and request logs. Anything billing without recent attributed traffic, or running without a live owner, goes on a decommission queue. This catches the models that predate your process.

On top of the mechanisms, make retirement auditable with a small set of metrics: mean time to retire (deprecation notice to endpoint deletion), orphaned-endpoint count, reclaimed spend per quarter, and retirements that caused a consumer incident (target: zero). The last one matters most — it's the number that tells you your consumer-impact assessment is actually working, and it's the number that earns platform teams the political cover to retire aggressively.

None of this is glamorous. But a registry where every entry has an owner, an expiry, and a trustworthy status is worth more than any model in it — because it's the only version of the registry anyone will believe.