Why is a model version change a compliance event rather than an engineering one?

Because almost every AI obligation currently in force is phrased as evidence about a specific system. A bias audit is a measurement of a particular model on particular data at a particular time. Technical documentation describes an artefact. An accuracy or robustness claim is a property of weights. A published notice tells people how a system makes decisions. When the weights behind the endpoint change, each of those statements becomes a claim about something that is no longer running, and the organisation has not noticed because nothing in its change-management process treats a vendor-side update as a change. The operational tell is simple: if your model inventory lists a product name rather than a version identifier and a date, you cannot currently demonstrate that anything you tested is what you are serving.

Does a vendor model update count as a substantial modification?

It can, and the answer depends on effect rather than on who performed the update. Frameworks that use a substantial-modification concept ask whether the change affects compliance with the requirements or alters the intended purpose. A same-family point release with equivalent measured behaviour on your evaluation set is ordinarily not that; a new generation with different refusal behaviour, different calibration or different output formatting plausibly is. The uncomfortable structural point is that the party best placed to assess it is you, and the party who made the change is the vendor. That is exactly why notice and evaluation-window terms matter: without them you are asked to classify a change you learned about from a changelog after it shipped.

What notice period is reasonable to ask for?

Differentiate by change class instead of negotiating one number. A reasonable structure: immediate notice for security or safety-driven changes, with a post-hoc evaluation right; thirty days for behavioural changes within a version family; ninety days minimum before a version you have pinned is retired; and a longer window — six to twelve months — where the system supports a regulated or high-risk use with periodic audit obligations. Tie the clock to the date you are actually notified through the contract's notice mechanism, not to a blog post or a console banner, and require the notice to state what changed in terms you can test rather than a marketing summary. The version-retirement window is the one that matters most, because it is the only one that forces an unplanned revalidation project on your schedule.

Is model pinning enough on its own?

It is necessary and it is not sufficient. Pinning gives you a stable artefact to test against and a clean evidentiary story, but pinned versions are retired on the vendor's timetable, so pinning without a retirement-notice term just converts a silent change into a scheduled cliff. It can also work against you: a pinned model does not receive safety improvements, which is an awkward position if a known failure mode shows up in your system and the fix has been available for months. The workable posture is to pin, subscribe to the vendor's change feed, maintain an evaluation suite you can run against a candidate version in days rather than quarters, and treat migration as routine maintenance with a budget line — not as an emergency that arrives once a year.

What evidence should we retain, and for how long?

Retain enough to reconstruct any individual decision for as long as someone can challenge it, which is usually longer than any inference log's default retention. At minimum: the model and version identifier and the date range it served; the prompt or feature template version; the evaluation results for that version on your own test set; the inputs and outputs for consequential decisions; and the human action taken. Store that with the record of the decision itself rather than in an observability platform, which is optimised for recent debugging and is routinely trimmed. The failure mode this prevents is the common one — a complaint about a decision made fourteen months ago, against a model that no longer exists, with no retained evaluation showing how it behaved.

How do our own customer commitments get caught in this?

Most AI terms of service were written with the vendor's flexibility in mind and the customer's expectations left implicit. If you have told customers that outputs are generated by a named model, that a stated accuracy holds, that data is processed in a given region, or that no customer data trains a model, each of those can be broken by an upstream change you did not make. Regional processing and training-use commitments are the two that break most often, because a new model generation is frequently available in fewer regions at launch and under different data terms. The fix is to mirror upstream: never promise downstream what you have not secured upstream, describe capabilities functionally rather than by vendor model name, and reserve a change right for yourself that is no weaker than the one your vendor holds over you.

AI Model Deprecation and Version Changes 2026: The Compliance Clauses Nobody Negotiated

Compliance Assumes a Stable Artefact. Nothing Else in the Stack Does.

Regulatory frameworks for AI were drafted around an object: a system that is built, documented, tested, placed on the market and monitored. Commercial model platforms were built around a service: an endpoint whose behaviour improves continuously and whose old versions are retired to control cost. Those two worldviews are not compatible, and the incompatibility is absorbed almost entirely by the deploying organisation, which owns the obligations and controls none of the changes.

The practical result is a documentation set that quietly stops describing production. Nothing announces it. The audit was real, the documentation was accurate, and some weeks later the endpoint began routing to something else. The organisation only finds out when someone asks for evidence about a decision, and the honest answer is that the model which made it cannot be queried any more.

Four Ways a Version Change Breaks Something

Audit invalidation. A bias audit measures a model. Replace the model and the audit describes history, not production — and the periodic-audit regimes assume you know when the clock restarted.
Documentation drift. Technical documentation naming capabilities, limitations and performance characteristics silently stops matching the artefact it documents.
Broken downstream promises. Region of processing, training-data use, model identity and accuracy commitments to your own customers can all be broken upstream.
Unreproducible decisions. A complaint about a past decision cannot be examined if the model that produced it has been retired and nothing was retained.

The fourth is the one that bites hardest in practice, because it converts an ordinary defensible decision into an unexplainable one. It is also the cheapest to prevent: it is a retention decision made before the fact, and an impossible problem after it.

Eight Clauses Worth Asking For

Version pinning. A contractual right to specify an immutable version, not merely an API parameter that may be honoured.
Change classification. A defined taxonomy — security, behavioural, generational — with different notice attached to each class.
Notice through the contract. Written notice to a named contact; a changelog and a console banner are not notice.
Deprecation window. A minimum period before a pinned version is retired, extended where the use is regulated.
Evaluation access. Access to the successor version during the window so revalidation can finish before the cutover.
Evidence support. A commitment to supply the documentation a regulator or an enterprise customer will ask you for, on defined timelines.
Regression protection. A remedy where a mandated change measurably degrades performance on your agreed evaluation set.
Exit and transition. Continued service and assistance while you migrate, so a deprecation is not an outage with a compliance report attached.

At small contract values a platform will decline most of this, which is useful information rather than a dead end: it tells you the lifecycle risk is yours to engineer around. Architect for substitution, keep an evaluation suite you can run in days, and avoid making downstream promises that depend on a specific vendor's model identity.

The Evaluation Suite Is the Real Deliverable

Most of this risk collapses if a version change is cheap to evaluate. Organisations that handle deprecations calmly have one thing in common, and it is not a better contract: they maintain a versioned evaluation set drawn from their own traffic, with labelled expectations, disaggregated by the cohorts they care about, runnable against a candidate model in an afternoon. That single asset turns a ninety-day scramble into a scheduled task and produces the documentation the next audit wants as a by-product.

It also changes the negotiation. A team that can show measured regression on a defined suite is asking a vendor a specific, answerable question. A team that can only report that outputs feel different has no claim to make.

Questions Procurement and Engineering Ask

We self-host open-weight models. Does this apply to us?

The vendor-side surprise disappears and the obligations do not. You still need to know which weights served which decision, still need evaluation evidence per version, and still need retention that outlives the version. Self-hosting actually increases the number of version events, because quantisation, serving-runtime upgrades, inference-parameter changes and system-prompt edits all alter behaviour and are usually managed by teams that do not think of themselves as changing the model. Include the runtime version and the prompt template version in the identifier you record — a weights hash alone has not been sufficient to reproduce a result in any environment we have seen.

How do we find out what version we are actually running?

Ask the system rather than the documentation. Log the version identifier the API returns on every call, and reconcile it weekly against what your configuration says you requested. That reconciliation is where the surprises live: aliases that resolve to a new default, a fallback path added during an incident and never removed, a staging configuration promoted to production, a feature flag that routes a fraction of traffic to a candidate model. Teams that add this check routinely discover they have been serving more than one version for months, which is also a quiet explanation for behaviour differences that were being attributed to prompts.

Our vendor says the new version is strictly better. Is revalidation really necessary?

Better on their benchmarks is not the same as equivalent on your decisions, and the failures that matter are distributional rather than average. A version with a higher aggregate score can be worse on a specific cohort, more cautious in a way that suppresses a needed output, or differently formatted in a way that breaks a downstream parser and produces silent nulls. Revalidation does not have to be a project: it is your evaluation suite, run, with the disaggregation you already care about. If that takes more than a few days, the finding is about your evaluation capability, and that is the thing to fix first.

What goes in the model inventory?

One row per deployed model version with: the version identifier as returned by the API, the date range it served, the business decisions it touches, its risk classification, the evaluation evidence and its date, the responsible owner, the retention location for inputs and outputs, and the prompt or feature template version. Product names are not identifiers and 'latest' is not a version. This single table answers the first question of every audit, every enterprise security review and every incident, and it is the cheapest artefact on the entire compliance list to maintain if it is generated from deployment configuration rather than typed into a spreadsheet by hand.

How should we describe the model to our own customers?

Functionally, and with a reserved right to change the implementation — with one important exception. Naming a specific vendor model in a contract or a public claim converts their lifecycle decisions into your breach risk. Describing capability, safeguards and measured performance instead leaves you free to migrate. The exception is where the customer has a genuine regulatory need to know, which is common in regulated sectors: there, give them the identity under a change-notice commitment you can actually meet, which means it must be no stronger than the notice your own vendor owes you. That is the clause chain most organisations discover only when they are already on both sides of it.

Check One Thing Today

Open your most recent AI compliance artefact — the bias audit, the technical file, the security questionnaire answer — and find the model version it describes. Then log the version your production endpoint returned this morning. If those two strings differ, or if either one is a product name rather than a version, that is the whole problem in a single comparison.

Fix the logging first. The contract terms take a renewal cycle; the log takes an afternoon and is what makes the rest of it provable.