Every AI vendor eventually retires a model version. That's not a hypothetical — it's a published lifecycle, usually with an observed retirement window of around 60 days once a successor ships. What's hypothetical is whether your company finds out about it from the vendor's changelog or from a production system that quietly starts behaving differently.

Most organizations treat this as an IT notification problem: forward the deprecation email, someone updates a config, done. That undersells what's actually happening. A model swap can shift output quality, tone, and edge-case behavior in ways that never show up in a smoke test — they show up three weeks later in a customer complaint or a compliance review, with nobody able to say which model version produced the output in question.

The organizations handling this well treat it the way mature engineering teams treat any dependency upgrade: explicit version pinning instead of silent auto-upgrade, a golden-set regression suite that runs before a new model version goes live, and a retirement calendar tracked by model and by which internal system depends on it. None of this is exotic. It's the same discipline applied to any third-party library — just not yet applied, in most companies, to the model quietly sitting at the center of a production workflow.

Vendor-set lifecycles; auto-upgrade or hard failure depending on deployment type. Retirement dates are explicitly non-extendable.

The gap shows up hardest in regulated environments, where a 60-day observed retirement window simply doesn't fit a revalidation cycle built for slower change. A model that has to be re-approved before it can be trusted with a regulated workflow can't be re-approved on a vendor's clock — which means the pinning and regression discipline isn't optional hygiene, it's the only thing standing between a vendor's release schedule and an unplanned outage in a system nobody thought of as fragile.