Your AI Has a Retirement Date

Sometime in the next few weeks, a family of models that a great many AI products were built on will be switched off. The provider published the date months ago. Developers have been asking on the provider's own forum whether the date shown for one of its platforms applies to the other, since one page names October 20 and the other names nothing. None of that will reach a clinic. The clinic will find out the way clinics find out about software: something that worked on Friday will not work on Monday, and the vendor will say they are looking into it.

This is not a complaint about the provider. Models get better, and the old ones have to go. The same provider retired the previous generation on the same kind of schedule. It is a condition of the field, like the one I wrote about in Security Is a Moving Target: an ongoing state, not a finished one. What I want to do here is name the condition for clinics, who are the ones living with it without being told.

What a retirement actually is

Almost every AI product a clinic buys is built on a model someone else hosts. The product sends your words to that model and shows you what comes back. When the provider retires the model, every product built on it has to point at a different one, and the different one is not the same. It answers differently. It follows instructions differently. The careful tuning a vendor did against the old model — the prompts, the examples, the guardrails — was done against a thing that no longer exists.

A good vendor tests the successor before the cutover and tells you what changed. A busy vendor changes one line of configuration the night before the deadline and hopes. From the clinic's side the two look identical until they don't. The provider's own documentation is candid that the published dates are the earliest a model might go, and this week one model in the family had its date moved out by months, which tells you how firm the calendar is. A vendor who waited for the date has already waited too long.

Four questions

• Which model, exactly, is behind this? A vendor who cannot name it does not control it.
• Where does it run? Retirement dates differ by platform and region; so does the law that applies to your records.
• What happens on the day it is retired? The honest answer names a successor and a test, not a hope.
• How would you know if it had quietly changed? If the vendor cannot answer this one, neither of you would.

How we answer them

I will answer for us, because I think a vendor who writes a post like this owes the reader its own homework. We moved every assistant role off the retiring family in September; the roles we still rent from the provider — search vectors, dictation transcription, the phone line, and the background roles still in migration — sit on models outside it. Each of those is a literal written into the code, with the exact model name and the exact region, and a check that runs before every deployment refuses to ship if anyone changes either without declaring it. There is no setting on a server that can drift away from what the code says.

Then, every night, the platform runs itself against those declared models and records what served. If a model stopped answering, or started answering as something else, the morning record would say so, with the model's name beside the failure. The retirement of the family going this month was on our calendar for months; the migration was deliberate work, tested against the successor, and the nightly runs since then are its proof. The clinic did not need to know about it. That is the point: it should never need to know, and it should always be able to ask.

Here is the shape of a good answer to the fourth question, for anyone evaluating a vendor: the model is named, its location is named, both are held by something mechanical, and something checks them every day. Ask for that. If you get it, the retirement date on the provider's calendar is the vendor's problem, which is where it belongs.

---