“Works with every leading model” has become a standard line in AI product marketing. It usually means that a drop-down lists several providers. For a regulated organisation, that is the least interesting part of the question. The harder part is whether the organisation can govern those models consistently: decide which are allowed for what, prove which one was used, and remove one quickly when it has to.
Seen that way, model independence is not a feature list. It is a property of the governance layer.
Why regulated organisations need it
Models and providers change faster than the approval processes of most regulated organisations. Terms of service are revised, data-handling commitments differ between products from the same provider, new models appear monthly, and occasionally a provider has an incident that an organisation needs to respond to on the same day.
If each model is governed inside its own vendor’s interface, every change means re-implementing controls in a different place, with different evidence and different gaps. If governance sits above the models, a change is a policy decision in one place.
What governing models actually involves
Approval is per provider and per model
Approving a provider is not the same as approving every model it offers. Data-handling terms, hosting regions and capabilities can differ between models from one provider. The unit of approval needs to be the specific provider and model pair, with explicit allow and deny rules.
Entitlements differ by person, group and agent
A research team may need a large-context model for long documents; a client-facing team may be restricted to models with particular contractual commitments; an agent may be allowed one model for one task only. Entitlements should apply to agents as well as people, and an agent should never inherit more than it was given.
Disabling must be fast and enforced
When a model or provider has to be switched off, what matters is not how quickly it disappears from menus but how quickly requests to it are refused, including from clients that have not yet refreshed. That is an enforcement question, not an interface one.
Usage and cost are governance data
Budgets and quotas are a way of expressing policy: how much of which model a team may use. Usage, token counts and estimated or provider-reported cost belong in the same governance view as policy outcomes, so that decisions about models are made with evidence rather than invoices.
Evidence must name the model
If a supervisor or client asks which model produced a piece of work, the answer should come from the record of the decision, not from someone’s memory. Model identity, as the organisation approved it, should be part of every decision record.
Independence has costs, and they are worth naming
Supporting several providers properly is real work. Each one needs an adapter that behaves consistently under the same policy, testing against its specific behaviour, attention to how it reports usage, and ongoing maintenance as its interfaces change. Customer-managed keys add their own requirements for protecting credentials on the device. A product that lists many models without that work is offering choice without governance.
That is why Synainesi treats provider selection as a deliberate, gated decision. Its design governs approved providers and models, allow and deny rules, entitlements for users, groups and agents, budgets, emergency disablement, and usage and cost monitoring from one control plane, with enforcement by Guard on the device. Every provider is assessed for contract fit, data handling, support for customer-managed keys, model identity, usage and cost reporting, and maintenance before it is supported.
Questions to ask about model independence
- Is approval per model, or only per provider?
- Can different people, groups and agents have different model entitlements?
- How is disabling a model enforced, and how long does it take to reach every device?
- Is the model named in the evidence of each decision?
- What work stands behind each supported provider? Testing, usage reporting and maintenance, or just a menu entry?
The point of model independence is not to use every model. It is to be able to choose, restrict and change models without losing control of any of them.
Related: Desktop for work, Cloud for control and the principles behind Synainesi.