Your controls should survive a change of model. If an agent's bounds live in one provider's settings, and its evidence lives in that provider's logs, then a model update or a switch of provider quietly removes both. Model independence keeps the rules, the proof and the record in a layer you own, so governance outlasts any single model.
Why is this a governance question rather than a procurement one?
Model independence is usually discussed as a commercial matter: avoid lock-in, keep negotiating power, switch if prices rise. Those are fair points, but they are not the main one. The main one is that AI agent governance depends on three things staying stable: what the agent may do, the evidence that it can do it well, and the record of what it did.
If any of those three is held inside the model provider's product, it changes when the provider changes. A safety filter tuned by the provider can be retuned. A log retained by the provider can be retained for less time or in a different format. A behaviour you tested can shift after an update you were not told about in detail. None of this needs bad faith. Providers improve their models, and improvement means change.
A governance framework that rests on something you do not control is not your framework. It is a description of someone else's settings on the day you wrote it down.
What breaks when the model changes underneath you?
Consider what each kind of control looks like when it is tied to the model, and what happens when the model moves.
| Control | Tied to the model | Held independently |
|---|---|---|
| What the agent may do | Expressed as instructions in the prompt or provider-side policy settings | Expressed as bounds the platform enforces at the moment of action |
| Evidence of competence | A test run once against the model version at launch | A certification set replayed against each new model before it takes over |
| The record | Provider logs, in the provider's format and retention | An append-only record in your own store, in your own schema |
| Escalation and refusal | Learned behaviour you hope persists | Platform rules that hold regardless of model output |
In the left column, a model update is a governance event that nobody notices. In the right column, a model update is a change you can test, approve and evidence like any other.
How do supervisors think about this?
Supervisors in most banking markets already expect firms to manage model risk, which includes knowing when a model changes and validating it before reliance. The UK's PRA sets out model risk management principles in SS1/23, including clear ownership of models and controls over their use. A foundation model accessed through an API, updated on the provider's schedule, sits awkwardly in that picture unless the firm has its own layer that detects and tests the change.
Outside banking, voluntary frameworks point the same way. Singapore's Model AI Governance Framework from IMDA stresses accountability and human involvement proportionate to risk. Neither of those can be delegated to a provider's defaults. The firm deploying the agent is accountable for its conduct whatever model sits underneath.
This is an explanation of the direction of supervisory expectations, not legal advice; confirm how they apply to you with counsel.
What does model independence actually require?
It does not require running your own model or avoiding commercial providers. It requires that the things you govern sit outside the model.
- Bounds enforced outside the model. The decision about whether an action is allowed is made by a rules layer that reads the agent's role, certificate, sources and limits. The model proposes; the platform decides.
- Certification against your own cases, repeated per model. When a new model is a candidate, it is replayed against the same cases as the old one and must clear the same floors before it takes any depth.
- A record you own. Every verdict is written to your own append-only store, in a format that does not depend on which model produced the proposal.
- Briefs that are model-neutral. The agent's role, sources and connections are written in terms of the job, not tuned to one model's quirks.
With these in place, changing models becomes routine change management rather than a leap of faith.
What is the trade-off?
Model independence has a cost. A brief written to suit no particular model may get slightly less out of any one of them. Recertifying for each model change takes time and labelled cases. Keeping your own record means storing and securing it.
The alternative cost is larger but less visible. Without independence, each model change resets your evidence to zero without anyone noticing, and the first sign is an incident. The broader discipline of AI governance is largely about turning invisible risks into visible decisions, and this is one of the clearest examples.
Where Pryme fits
Pryme is model-agnostic by design. Bounds are enforced at the moment of action, outside the model. Attest replays each candidate, including a new model behind an existing agent, against cases from your own operation, so behaviour that has shifted shows up in the results, and the stable gate checks that the same question still gets the same answer across runs. We never update model weights for a customer; we change the brief, sources, bounds and certification. See the governed agentic operating system, explained.
What should you do differently?
Find every control in your agent estate that depends on a specific model or provider: prompt-based rules, provider safety settings, provider-held logs, one-off launch tests. For each, ask what happens the day the model changes. Move the ones that matter into a layer you own, and treat any model change as a change that must be recertified before it carries authority.
Questions people ask
Does model independence mean using several models at once?
Not necessarily. You can use one model and still be independent, as long as your bounds, evidence and record do not depend on it. Using several models is an option that independence makes safe, not a requirement.
How do we know when a provider changes a model?
Pin versions where the provider allows it, and monitor behaviour against a fixed set of cases where it does not. A shift in scores on unchanged cases is the signal to recertify.
Is a provider's own safety testing enough?
It covers the model in general, not your agent on your work. It is useful context, but it cannot stand in for evidence from your own cases and your own bounds.