Your Validated Model Has a Retirement Date

On a Standard or Global Standard deployment in Microsoft Foundry, the property that decides whether your model changes is called versionUpgradeOption. If nobody set it, it is null, and Microsoft's own documentation states that null is equivalent to OnceCurrentVersionExpired. At the retirement date the deployment upgrades itself to the current default version. The endpoint, the deployment name and the key do not change. The weights do.

Microsoft is explicit about the mechanics. For Global Standard, Data Zone Standard and Standard deployment types, auto-upgrades are "scheduled on a rolling, region-by-region basis", and "upgrades can occur even if the new model version isn't yet separately available in that region, or for that SKU — the upgrade process will make it available". Provisioned deployments are excluded and must be migrated by hand. So two instances of the same validated application, one in Sweden Central and one in East US, can be running different models for a period whose length you do not control.

The rule that makes this a quality problem is not new and not draft. Annex 11 of EudraLex Volume 4, in operation since 30 June 2011 and still the binding EU text on 30 August 2026, says it in one sentence at clause 10: "Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure." There is no exemption for changes made by a service provider, and clause 3.1 already makes the manufacturer responsible for third parties that maintain or modify the system.

The property that decides whether your model changes

There are three values, and the difference between them is three different quality outcomes. OnceNewDefaultVersionAvailable upgrades "within two weeks of that designation change being made" — a change you did not initiate, on a clock you cannot see. OnceCurrentVersionExpired upgrades at the retirement date. NoAutoUpgrade never upgrades, and per Microsoft, "once the retirement date is reached the model deployment stops working".

Two operational details matter. First, the read and write paths are asymmetric: Microsoft's own table records that the Azure CLI can show versionUpgradeOption but that it is "currently not possible to update the version upgrade option" from the CLI. You set it through REST, PowerShell or the portal. Any infrastructure-as-code pipeline built on az cognitiveservices will therefore read a property it cannot write, which is exactly how a control ends up documented in a validation package and absent from the deployment.

Second, if the value has never been set explicitly, the portal does not display it at all: Microsoft notes that if the version update policy option "isn't present in the properties for a model that supports model upgrades this indicates the value is currently null". An auditor asking to see the setting is shown an empty space that means "auto-upgrade at retirement" — and that is the state most deployments are in unless somebody deliberately changed it.

Which rule this breaks on 30 August 2026

Be precise about the instruments, because three of them get quoted interchangeably and only one is law.

Binding: Annex 11 (2011) clause 10, quoted above, plus clause 11 on periodic evaluation, which already lists "upgrade history" among the inputs a periodic review must examine. A model version swap is upgrade history. If your periodic review of a GMP-critical AI system holds no list of the model versions that system has actually run on, clause 11 is not satisfied, and no new guidance is needed to say so.

Draft, published 7 July 2025 for a consultation that closed 7 October 2025, not law: Annex 22 clause 10.1 requires any change to the model to be "documented and evaluated to determine if the model needs to be retested", with "any decision not to conduct such retest" fully justified. Clause 10.2 adds that a tested model "should be put under configuration control before being deployed in operation, and effective measures should be used to detect any unauthorised change". A platform-initiated version swap is the textbook case that phrase describes. Mind the scope limit: the same draft says generative AI and large language models "should not be used in critical GMP applications", so for a critical-application LLM the annex does not apply at all — it applies to the static classifier deployed through the same cloud plumbing.

Also draft: the revised Annex 11 published the same day requires at clause 14.2(iii) that "undocumented (unapproved) changes should be effectively identified, e.g. by means of configuration auditing", and at clause 7.5(ix) that the regulated user agree with the service provider "on the process for release of new system versions and on the regulated user's possibility to test these prior to release". No hyperscaler grants that right on a shared-capacity deployment today. That gap belongs in a risk assessment now rather than on the day the clause is final.

3 upgrade options, 3 different change-control problems

The fourth row is where most quality teams land, and it deserves a warning: NoAutoUpgrade converts a silent change into a scheduled failure. Asked whether a retirement date can be extended by exception, Microsoft's FAQ answers "No. Retirement dates aren't extendable." On a system that releases batches, that setting is defensible only if the migration project is funded on the day it is applied.

The retirement dates already on the calendar

Microsoft's model retirement schedule, as published on 26 August 2026, puts several widely deployed models inside a 3-week window this autumn.

Read the last column carefully. The gpt-4o deployment does not upgrade to a newer gpt-4o; it crosses model families to gpt-5.1, and an o3 deployment becomes gpt-5.6-sol. These are not patch releases. They are different models with different reasoning behaviour, parameter support and defaults, arriving at an endpoint whose validation package describes the old one.

Two rows list no replacement, which is not an oversight: Microsoft names the official replacement "approximately 90–120 days before the retiring model's retirement date — not sooner". For a regulated user that means the target of a change you have already accepted can still be unknown when you plan the revalidation.

The same model retires on 2 different dates

Pinning a model name is not the same as pinning a lifecycle. The dates on Anthropic's deprecation page apply to the Claude API, Claude Platform on AWS and Microsoft Foundry; partner-operated platforms set their own. Amazon says the same from the other side: "Model lifecycle dates on this page are specific to Amazon Bedrock and may differ from dates published by model providers... For Amazon Bedrock usage, only the dates on this page apply."

The divergence is current. claude-sonnet-4-20250514 was deprecated on the Claude API on 14 April 2026 and retired there on 15 June 2026. The identical model ID on Amazon Bedrock entered Legacy the same day with an EOL date of 14 October 2026, passing on 14 July 2026 into "public extended access", a phase in which AWS warns customers "should expect higher pricing". Same weights, four months apart, with a price change in the gap.

The change semantics differ too, and that belongs in the supplier assessment rather than the architecture diagram. Bedrock auto-upgrades nothing: "You will need to migrate to the latest model by updating your application code before the EOL date. Migration will not happen automatically." Azure Standard deployments do it for you unless told not to. Anthropic's direct API gives at least 60 days' notice and then fails the request. Three platforms, three answers to "what happens to my validated system on the retirement date", and a supplier questionnaire about ISO 27001 surfaces none of them.

Does temperature zero give you reproducibility?

It never did, and on current models it is increasingly not even an available setting — which matters because "inference parameters locked, temperature set to 0" is the reproducibility control in a great many pharma LLM SOPs written between 2023 and 2025.

The vendor says so first. Anthropic's Messages API reference carries the note at the parameter itself: "Note that even with temperature of 0.0, the results will not be fully deterministic." The measurement behind it is public: Thinking Machines Lab sampled 1,000 completions at temperature 0 from one prompt on Qwen3-235B-A22B-Instruct-2507 and got 80 unique outputs, diverging at token 103, because serving kernels are not batch-invariant and the batch you land in depends on other tenants' traffic.

Then the parameter goes away. The same reference marks temperature deprecated: "Models released after Claude Opus 4.6 do not support setting temperature. A value of 1.0 will be accepted for backwards compatibility, all other values will be rejected with a 400 error." The same treatment extends to top_p and top_k from Claude Opus 4.7 onward, and the Python SDK from v1.0 removes the arguments entirely, so passing them raises a TypeError before the request leaves the machine. On Azure, Microsoft's reasoning models guidance lists the parameters "currently unsupported with reasoning models", and temperature is the first entry.

So an SOP clause reading "temperature shall be set to 0 to ensure reproducible output" never delivered what it claims and will now fail the request outright on several current models. Replace it with what is genuinely controllable: model identifier and version, system prompt hash, tool and schema definitions, retrieval corpus snapshot, and a measured stability criterion on the extracted decision field rather than on the prose.

The upgrade that breaks the code, not the accuracy

Revalidation planning usually assumes the failure mode is degraded output quality. There is a blunter one. Microsoft documents that on gpt-5.6 and later models the Chat Completions API and function tools cannot be used together: a request including tools fails with "Function tools with reasoning_effort are not supported for gpt-5.6-sol in /v1/chat/completions". The note that follows is the one to circulate internally: "The request fails even when you don't send reasoning_effort... An application that calls tools through Chat Completions can start failing after you upgrade its deployment from an earlier reasoning model."

Now put that next to the schedule. An o3 deployment on Standard, left at its default upgrade setting, becomes gpt-5.6-sol on 21 October 2026. If that application calls tools through Chat Completions, the outcome is not a subtle accuracy shift for drift monitoring to catch. It is an HTTP error on a GMP system, arriving region by region, triggered by a property nobody in the quality organisation has heard of.

The GA retirement notice does go out — Microsoft commits to at least 60 days, by email and Azure Service Health advisory — but it goes "to subscription owners with active deployments". In most pharma organisations that owner sits in IT with no route into the change-control system for the manufacturing application above them. The routing gap, not the notice period, is the thing to fix.

What this means in practice

This week, run the inventory. For every GxP-relevant AI deployment, record five fields: platform, model name, model version, versionUpgradeOption or the platform's equivalent, and the published retirement date. On Azure the Models API exposes lifecycleStatus, deprecation.inference and per-SKU deprecationDate, so this is a scripted query, not a survey. Expect the upgrade-option column to come back mostly empty.

Set the property deliberately and record the decision. Either value is defensible; an unset one is not, because nobody chose it. If you set NoAutoUpgrade, the same change record names the migration owner and the budget, because you have created a scheduled outage. If you leave auto-upgrade on, the risk assessment has to state why an unvalidated model version entering a GMP process is acceptable — which for a critical application is usually not writable, and that is the point.

Make the retirement date a change-control trigger with a lead time. The replacement is named around 90 days out; the notice arrives 60 days out. A revalidation needing an independent test set, a protocol and a QA-approved report does not fit in 60 days if the test set has to be built first. Build it once, version it with the prompts, and the next swap is a re-execution rather than a project.

Put the platform's change semantics in the supplier assessment. Three questions in writing before signing: does the provider upgrade model versions without customer action; what notice is given and to which named role; can a pinned version be retained past its retirement date. The answers are published and differ by platform. The fourth — the right to test a new version before release — is the one no major provider answers yes to on shared capacity today. Record it as a known limitation with compensating controls rather than leaving an inspector to find it.

Version the prompt like code, because clause 10 already covers it. Clause 10 governs "system configurations", and a system prompt, a tool schema and a retrieval index are configuration by any reading of that word. Store them with the application, tag the release, and record the tag in the batch or document record next to the model version. When someone asks in 2028 which model and which prompt produced a given output, that record is either there or it is not.