The alias is the risk, not the upgrade
Most model providers offer two ways to reference a model: a dated, versioned ID that always points to the exact same weights, and a rolling alias that always points to whatever the provider currently considers the latest release in that family. The alias is convenient for prototyping, but a workflow calling it in production can change behavior the day the provider updates what the alias points to, with no deploy on your end and often no warning in your logs.
Anthropic's model deprecations page documents the distinction directly: dated snapshot IDs like `claude-opus-4-5-20251101` carry a fixed status and a tentative retirement date, while a model moves through active, legacy, deprecated, and retired stages on its own schedule. If a workflow step is calling an alias instead of a dated ID, there's no way to know from the call site alone which side of that lifecycle it's on until something changes.
Pin a dated ID, then inventory every reference
Pin the exact, dated model ID in every production call site, not the family name or an alias. That keeps the model behind a workflow fixed between deploys, which is the baseline a business can actually reason about: the same input produces the same kind of output today as it did last week.
The harder part is usually finding every place a model ID is referenced. It is common for the same workflow to call a model name from an environment variable in one service, a hardcoded string in another, and a config file in a third, with no single source of truth. Before anything else, build that inventory. A pin that only covers the services someone remembered to check is not a real pin.
Treat the pin as temporary, not permanent
Pinning solves drift but creates a different problem if it is never revisited: the pinned model eventually reaches its deprecation date, and the migration becomes a forced, rushed change instead of a planned one. The FINOS AI Governance Framework's guidance on model version pinning is explicit that the practice is not about indefinitely avoiding upgrades, but about a controlled process for evaluating and approving the next version before it goes live.
That means a pin needs an owner and a date on the calendar to re-qualify it, not just a deploy that set it once. Anthropic's own deprecation notices give at least 60 days' notice before a publicly released model retires; that window is only useful if someone is watching for it.
Build re-qualification into the runbook
Re-qualifying a model version is more than checking that the API call still succeeds. Test the candidate model against the same representative cases the workflow already handles, including the evaluation thresholds and prompt wording tuned to the current model's quirks. A newer model can be better on average and still fail cases your current setup was quietly tuned around.
Roll the switch out the way you would any other production change behind this kind of workflow: a staged or canary rollout with a tested path back to the previous pinned version if the new one regresses. The FINOS framework recommends exactly this, paired with an audit log of which model version produced which output, so a quality issue can be traced back to the exact version that generated it.