Your model retires before your system does
Enterprise systems are built to last a decade and the models inside them are supported for months. Nobody owns that mismatch, and it surfaces as an unplanned migration on a date chosen by a supplier.
The email is short and it is not addressed to anyone in particular. A model your system depends on has a retirement date. There is a recommended successor. After the date, requests to that identifier return an error.
In an estate that has thought about this, the email creates a ticket. In most estates it creates a quarter of unplanned work, because the model identifier is written into application code in eleven repositories, the prompts were tuned against that specific model, and there is no evaluation set to tell anybody whether the successor is better, worse or differently wrong.
The claim: model lifecycle is now a supplier-managed schedule that your change control does not know about, and the cost of that is entirely determined by two architectural decisions.
The mismatch, stated plainly
Enterprise systems are planned around depreciation schedules, five-year contracts and support windows measured in years. Hosted models are not. Providers publish retirement dates and honour them, and the notice periods are measured in months rather than years — OpenAI maintains a public deprecations page listing what is going and when, and Anthropic publishes the same for its model families. Neither is behaving badly. Both are behaving like platforms, and platforms deprecate.
- Day 0 Notice published It arrives on a status page or a developer mailing list, not through your supplier management process.
- Weeks 1–4 Somebody notices Usually an engineer who happens to read release notes, rather than a control that watches for it.
- Weeks 4–12 Re-evaluation and prompt work Every prompt tuned against the old model is now an open question, and answering it needs an evaluation set.
- Retirement date Requests fail Fine-tuned variants built on the retired base stop working with it.
The expensive band is the middle one, and its width is not set by the provider. It is set by whether anybody can measure the difference between two models on work that matters to your organisation.
The two decisions that set the cost
| Built without these | Built with them |
|---|---|
| The model identifier appears in application code | Model choice is configuration behind a gateway — one change, all callers |
| Prompts were tuned by hand against one model | Prompts are versioned artefacts with a recorded evaluation score |
| Quality after migration is judged by trying a few examples | Quality is a number on a held-back set, produced in an afternoon |
| Nobody knows which systems use the retiring model | The inventory lists model dependencies as dependencies |
The fourth row is the one that turns a migration into an incident. Most organisations cannot answer, in a morning, which of their systems call which model. That question is asked for the first time when the notice arrives, and the answer is assembled by searching source control, which finds the systems that are still maintained and misses the ones that are merely running.
What to put in place before the next notice
The pinned version in the trace is worth separating out, because it addresses a different failure. Providers do not only retire models — they update them. A system whose behaviour changed last Tuesday for reasons nobody in the organisation caused is very hard to investigate if the record says only which family answered. It should say which version.
The version of this that reaches procurement
There is a contractual layer to this and it is usually missing. Most AI supplier agreements are silent on lifecycle, which means the notice period is whatever the provider publishes and can change. For a system carrying real consequence, three clauses are worth asking for: a minimum notice period for retirement of a model in use, a commitment that a successor will be made available for evaluation before the retirement date, and an obligation to disclose material changes to a model that remains in service under the same identifier.
Suppliers will not always agree, and the answer to the question is informative either way. A provider that cannot commit to telling you when its behaviour changes is a provider whose behaviour you cannot evidence — which matters most in exactly the systems where evidence is the obligation.
What this does not tell you
None of this argues for self-hosting. Running your own weights removes the retirement schedule and replaces it with an operating burden, a hardware commitment and the same evaluation problem the first time you want to upgrade. It moves the decision inside the organisation rather than removing it.
It also does not claim that every system needs the full apparatus. A prototype does not need a gateway. What it needs is an honest note in the design record saying that the model identifier is hard-coded, so that the person who industrialises it later knows what they inherited.
The reader who acts differently is whoever owns the AI inventory. Add one column: which model, which version, and when does its supplier’s clock run out. The first time that column is populated it will find a system nobody has looked at in a year — and it is much better to find it now than on the retirement date.