Your model's deprecation date is a risk you do not control

Trackers counted dozens of model updates in the first week of September alone. Under that cadence, every model in production is on a clock — and the clock is owned by the provider.

Deprecation is not a technical event

For an unregulated product, a forced migration is inconvenient: test, swap, ship. For a system operating under obligation, the qualified model is part of the evidence base. Replacing it invalidates that evidence and requires re-establishing it, on a timeline the provider set and you did not agree to.

The asymmetry is the problem. Your assurance cycle is measured in months; the notice period is measured in weeks; and the decision was made for reasons entirely unrelated to your deployment.

You can qualify a model thoroughly. You cannot qualify it for longer than someone else intends to serve it.

The three real options

Self-host an open-weights model and own the lifecycle. You gain control over timing and take on serving, security patching and hardware. For long-lived regulated systems this is frequently the right trade and it is consistently underestimated in effort.

Contract for longevity. Enterprise agreements can include extended support windows and notice periods. This is negotiable more often than teams assume, and almost never asked for because procurement is focused on price per token rather than on how long the thing will exist.

Or engineer for substitutability, which is the approach we would default to. Keep a fixed evaluation set representing your actual task distribution, hold the guarantees outside the model in authority limits and output validation, and make swapping a regression run rather than an assurance project.

The question to ask now

For every model in production: what is the announced support horizon, what is the notice period, and how long would a qualified replacement take? Where the third number exceeds the second, you have a live exposure that no amount of evaluation work addresses.

It is a supply-chain risk wearing a technical costume, and it belongs in the risk register next to any other single-source dependency.

Written by the Devence Lab research team.