Models are updated, replaced and withdrawn on the supplier's schedule, not yours. If your assurance is tied to one model, every change restarts your validation. If the control layer, the acceptance criteria and the test set belong to the use case rather than the model, a new model is simply re-tested against criteria you already have.
The problem with tying assurance to a model
A model version that passed your tests in the spring may be retired by the supplier before the end of the year. New versions behave differently, sometimes better and sometimes worse on exactly your documents. If your validation evidence is about a particular model, each change forces you to start again, and the pressure to skip the work grows with every release.
What should stay constant, and what can change
- Stays constant: the intended use, the acceptance criteria, the approved content, the rules that check each output, the risk tiers, the audit trail and the human review.
- Can change: the model that generates the output.
That split is the whole idea. The model is a replaceable component. The control, and the evidence that it works, belong to you.
The gateway
Every model is reached through one gateway. The application never talks to a model directly. That gives you a single place to enforce which models are permitted, to record which model produced which output, to apply the same rules whichever model is used, and to switch by configuration rather than by rewriting code.
The evaluation harness
A fixed set of test cases, with expected results and acceptance criteria drawn from the intended use, is kept as an asset of the use case. When a candidate model is proposed, you run the whole set against it and compare. The test set needs to be independent of anything used to tune the model, and kept current as the use evolves, including cases that have gone wrong before.
What a model change looks like under change control
- Raise a change: the proposed model, the reason and the use cases affected.
- Run the evaluation harness against the candidate and compare with the incumbent.
- Check the result against the acceptance criteria. If it falls short, stop.
- If the use is above the lowest tier, run it in shadow mode for a period.
- Approve through your normal change process and record the decision.
- Switch by configuration. The audit trail shows from which date the new model produced outputs.
Provenance and where the model runs
Model agnostic does not mean model indifferent. Regulated procurement asks where a model came from and where it runs. For the strictest environments, open weight models can be served on your own premises with no data leaving. Where policy allows, frontier models can be used inside your own cloud tenancy under terms that prohibit retention and training on your data. The gateway lets you choose per use case.
The limits of the idea
Model agnostic does not mean a swap is free. A new model still has to be tested, reviewed and approved, and it may fail. What changes is that the work is a bounded re-test against criteria you already hold, rather than a new validation project, and that the control layer your evidence depends on stays the same.
Frequently asked questions
Do we need to revalidate when the AI model changes?
You need to re-test the new model against your acceptance criteria and approve the change under your change control. The deterministic control layer is unchanged, so you do not repeat its validation.
Can we use open weight models as well as commercial ones?
Yes. Any model you approve can connect through the gateway, including open weight models run on your own premises and commercial models running inside your own cloud tenancy.
What stops a model change from weakening our controls?
The same rules, tiers and audit trail apply to every output whichever model produced it, and a model is only switched on after it meets the acceptance criteria for each use case it will serve.
Sources and further reading
- ISPE GAMP 5 Guide, Second Edition
- European Commission: consultation on draft Annex 22 (Artificial Intelligence), revised Annex 11 and Chapter 4
- ICH quality guidelines, including Q9(R1) Quality Risk Management
This article is general information, not legal or regulatory advice. Regulatory texts change, and some discussed here are drafts: check the current official text before relying on any detail.
