What happens when your cloud AI model is deprecated?

Your workflows change on someone else's schedule. When a cloud provider retires the model version your prompts, evaluations and downstream checks were tuned against, behaviour shifts overnight, and every validated process built on that version needs re-validating. For a regulated deployer this is a model-risk event, not a routine upgrade, and it should be planned for before the first workload goes live.

The question matters in 2026 because AI has moved from pilots into validated business processes. Organisations that spent months tuning prompts, calibrating evaluation suites and signing off controls are discovering that what they validated was a version, and versions are retired on notice windows the provider controls.

Why do cloud providers deprecate models?

For defensible reasons, and it is worth being fair about them. Newer models are more capable, often safer and less costly for the provider to serve. Old versions carry security exposure, operational overhead and a shrinking user base, and providers publish deprecation policies and migration guides rather than pulling versions without warning. The problem is not malice and it is not negligence. The problem is control: the retirement date, the notice window and the migration path are all decided by the provider, and the deployer's validation calendar does not enter the calculation.

What actually breaks when a model version is retired?

More than most teams expect, because production systems are tuned to a specific version's behaviour rather than to a brand name.

• Prompt behaviour: instructions tuned against one version can produce different output on its successor, from formatting drift to changed refusals.
• Evaluation results: a test suite scored against the old version no longer describes what is running in production.
• Downstream logic: parsers, guardrails and validation checks built around the old output patterns can fail silently rather than loudly.
• Security posture: prompt injections that failed against the old version may succeed against the new one, because the attack surface moves with the model.

None of these are hypothetical. They are the standard contents of a migration exercise, compressed into whatever notice window the provider allows.

Why is deprecation a model-risk event for regulated deployers?

Because the regulated question is never only whether the new model is better; it is whether the deployer can evidence what the system did and why. Model-risk expectations in regulated sectors assume versioned models, documented validation and controlled change. A forced migration strains all three at once: the version changes, the validation goes stale and the change is scheduled externally. The audit story fragments too. If a decision made under one version is challenged years later, the deployer may no longer be able to run the version that made it, which turns reconstruction into speculation.

What is version permanence?

The property a regulated deployer actually needs. Version permanence means the organisation can pin a model version and keep it runnable for as long as its evidential life requires, rerun it later bit-for-bit to reproduce past behaviour, and retire it on its own schedule as a deliberate, recorded change. On Mickai, a Sovereign Intelligence Operating System, models arrive as signed, versioned artefacts and run offline on operator-owned hardware, and we seal every model change to the audit ledger, so the record shows which version acted, when it was replaced and who approved the replacement.

Can a contract give you the same guarantee?

Only partially, and the structure explains why. A provider can promise longer notice or extended availability of a version, and some do for large customers. What no multi-tenant service realistically offers is indefinite availability of every version to every customer, because serving retired versions is an overhead carried for a shrinking audience. A contractual promise is also only as durable as the provider's commercial position. Version permanence becomes structural when the weights live on infrastructure the operator owns, because then continuing to run a version is a local decision that requires nobody's permission and expires on nobody's timetable.

How should a model be retired on your own schedule?

With the same controls as any regulated change. A sovereign deployment retires a version when its successor has been validated, not when a notice window closes. The incumbent and the successor run side by side during transition, and cross-model consensus can cross-check material outputs between them, turning migration from a cliff edge into a controlled comparison. The retired version is retained runnable for its evidential life, and the change itself is approved, recorded and sealed, so the version history of the deployment reads as a series of decisions rather than a series of surprises.

“Version permanence is the difference between reconstructing a regulated decision and speculating about it.”

The architecture that makes version permanence structural rather than contractual is set out at /sovereign-ai, and the film at /film shows the interface through which those recorded, deliberate changes are made.

Frequently asked questions

How much notice do cloud providers give before deprecating a model?

It varies by provider and by service, and each publishes its own deprecation policy. The length of the window matters less than its ownership: however generous the notice, the retirement date is set by the provider, and the deployer's re-validation workload has to fit inside it.

Can I avoid the problem by pinning a model version in my API calls?

Pinning defers the problem rather than removing it. A pinned version is still hosted by the provider and still reaches end of life on the provider's schedule. Pinning is good practice for stability between releases, but it is not version permanence, because the ability to run the version eventually expires.

Is model deprecation a compliance issue or just an engineering task?

Both. The engineering work is migration and re-testing. The compliance question is whether validated processes were re-validated before behaviour changed, and whether past outputs remain reproducible. For organisations under model-risk expectations, or under the ICT change disciplines DORA has required since 17 January 2025, an externally scheduled behaviour change is squarely a risk event.

Does running models on our own hardware mean we fall behind on capability?

No. Updates arrive as signed, versioned artefacts and are adopted once the organisation has validated them. The difference is the direction of control: capability improves on the operator's schedule, previous versions remain runnable for their evidential life, and every change is sealed to the audit record.

What happens to our prompt library when a model changes?

It becomes a re-validation backlog. Prompts encode assumptions about one version's behaviour, so each materially important prompt needs re-testing against the successor alongside the evaluation suite that scored it. Treating prompts, evaluations and the model version as one versioned unit is the discipline that makes any migration measurable.