Most lifecycle phases are entered deliberately. Retirement is usually entered because somebody else set a date and the first sign of it is a downstream service returning errors on a morning nobody had marked.
The distinction governing everything after is between retirement and retraining, and the wrong choice is expensive both ways.
Retraining answers a job that still exists and a model that has drifted from it, worked through in the post on how often to retrain.
Retirement answers a job that has changed shape: the business process no longer exists, a successor supersedes the model outright, or the compliance and monitoring perimeter around it costs more than it returns.
Someone else usually sets the date
A fourth trigger has become the most common in practice, and it arrives from outside. Every major provider now runs a published deprecation calendar, and the notice you get is a property of the tier rather than the model.
OpenAI’s published policy commits to at least six months for generally available models, at least three months for specialised variants such as chat, Codex and deep research builds, and as little as two weeks for anything carrying preview in its name.
OpenAI states plainly that preview models are unsuitable for business-critical workloads unless you can migrate at that speed.
Microsoft Foundry works the other way round, fixing the retirement date programmatically at launch, eighteen months out, with no separate announcement to wait for.
A model then sits in a legacy state for at least thirty days and a deprecated state for at least ninety, with the recommended replacement typically not named until ninety to 120 days beforehand.
Provisioned deployments are not auto-upgraded. Some partner-sold models on per-token inference carry a fifteen-day notice period on that same platform, so the commercial arrangement behind a model, not the model itself, determines how much warning you receive.
Map the dependency graph before switching anything off
Retirements break things because the dependency graph is wider than the deployment diagram. A model name propagates into configuration tables, cron jobs, notebooks, dashboards and internal tools and few organisations hold a complete list.
The starting point is a register mapping every feature and pipeline to the model version it calls, maintained continuously rather than assembled under time pressure.
Aliases are where that register usually fails. An unversioned name resolves to a dated snapshot behind the scenes, so a system calling a friendly model name is pinned to a version it never wrote down, and the deprecation notice arrives against a string appearing nowhere in the codebase.
Resolve every alias to its snapshot before trusting the register.
Four classes of dependency are routinely missed:
- Derived data – Embeddings, cached scores, feature-store columns and pre-computed indexes generated by the outgoing model do not become invalid when it is switched off, but they do become incomparable with anything the successor produces. Mixing vector spaces from two model versions in one index degrades retrieval quietly, and nothing in the logs says so.
- Derivatives of the outgoing model – Fine-tuned variants are the sharpest case, because providers typically disable inference on a fine-tune when its base model is deprecated. Distilled and calibrated models inherit the same exposure less visibly.
- Monitoring baselines – Drift thresholds and alert conditions tuned to the outgoing model’s output distribution will either go quiet or fire constantly against a successor.
- Contractual commitments – Downstream consumers, internal or external, were given behaviour guarantees the successor may not reproduce.
Rehearse the failure rather than assuming it. Route a small traffic share to the successor, hold the outgoing version warm behind a feature flag, and deliberately fail requests against the old endpoint in a controlled window.
Where the calendar cannot be met, some providers will sell dedicated capacity to keep a retired model reachable, converting an outage into a cost line.
Tooling for the register itself is covered in the post on governance tools for lifecycle management.
The record-keeping obligation outlives the model
Turning off an endpoint does not end the obligation.
Article 18 of the EU AI Act requires a provider of a high-risk system to keep the technical documentation, quality management system documentation, notified body decisions and EU declaration of conformity at the disposal of national competent authorities for ten years after the system was placed on the market.
Withdrawal neither stops that clock nor restarts it, and Member States must specify how the documentation stays available even where the provider ceases to exist.
Article 19 runs a separate clock for automatically generated logs, retained to the extent they are under the provider’s control for a period appropriate to the intended purpose and at least six months.
Those duties then meet data protection, and the resolution is a sequencing question. Personal data used for training is subject to deletion once its processing purpose ends, while the documentation describing the system carries the longer horizon.
That means deleting the data while keeping the record of the system, which only works if the archive holds evidence about the model rather than copies of the data that produced it.
Retrofitting the separation at retirement is far harder than building it at registration.
What an audit actually asks for
The obligation that catches teams out is reproducibility. A regulator or claimant asking why a decision was made is asking you to reconstruct an inference, and weights alone will not do it.
Reconstruction needs the preprocessing code, the tokeniser or feature extractor version, the thresholds in force on that date, the business rules wrapped around the output, and enough of the runtime that the numbers come out the same.
Any one missing turns a defensible answer into an approximation.
The archive has to be a frozen executable artefact: a container image with pinned dependencies, the model file, the configuration and threshold set, the evaluation results supporting the original approval and a record of who approved the deployment.
Verify it runs before signing off because an archive nobody has executed is an assumption rather than a control.
A sequence that holds
- Declare the criteria, the date and the trigger – A vendor-imposed shutdown and a business-driven sunset need different runways.
- Freeze and verify the archive package – Confirm it reproduces a known set of historical decisions before anything is decommissioned.
- Map dependencies and assign owners – Every alias, derived dataset and downstream commitment needs a named owner and a migration target.
- Run the successor in parallel – Compare against a regression suite encoding the behaviour you promised, then rehearse failure of the outgoing version.
- Withdraw access in stages – Keep the rollback path available for a defined window, and decommission the serving infrastructure last.
Done in that order, retirement is an unremarkable engineering event rather than an incident with a compliance annex.
It rests on the groundwork every other phase requires: accurate inventory and clear ownership, set out on the AI model lifecycle and governance pillar.
Neurotechnology Cloud provides production hosting and lifecycle management on dedicated EU-resident GPU capacity through its AI Cloud and managed GPU services, with monitoring and record-keeping built in from first deployment rather than assembled at the end.
If you are preparing a retirement plan for a system with a live audit obligation, get in touch.
