Yes, depending on what the sovereignty commitment covers and how the model is supplied. A powerful model does not have one inevitable hosting arrangement, and a product offering several models does not necessarily send every customer's information to every provider.
The practical question is not whether the words sovereign and frontier can appear on the same page. It is which services handle a particular request, under which controls, and whether those arrangements meet the organisation's stated requirement.
Tandem's Sovereign Health description, checked on 19 October 2026, includes optional frontier-model access alongside Tandem-hosted open-weight models. The public material does not establish the complete routing or fallback behaviour for every deployment. This article explains what an organisation should determine rather than inventing that missing architecture.
Begin with a requirement that can be tested
"We need sovereign AI" leaves too much unstated. One organisation may require all specified processing to occur in an approved region. Another may require a European-owned infrastructure operator. A third may prioritise the ability to keep operating a fixed model version without dependence on an external API.
Those requirements can lead to different choices. An externally supplied regional endpoint might meet a location requirement while not meeting an ownership requirement. A supplier-operated model may offer version control while remaining dependent on the supplier's application and cloud account.
Write the requirement as an operational statement: identify the data, the allowed processors, the permitted locations and the authority needed to change the arrangement. That gives both parties something to assess beyond a broad marketing category.
Available, enabled and used are three different states
A model can appear in a supplier's catalogue without being enabled for a customer. It can be enabled without being used for every function. It can also be used for a supporting process that is less visible than the main chat response.
The deployment record should therefore distinguish the catalogue from the approved configuration and the actual processing history.
For example, a fictional service might use one model for note generation and a different component for document classification. Its front-end model selector would not necessarily describe the second component. A buyer asking only about "the model" could miss a relevant dependency.
This is an architecture example, not a claim about Tandem's routing. The appropriate response is to request a function-level account rather than assume that all processing follows the visible selection.
Four possible arrangements, four different questions
| Hypothetical arrangement | What the organisation would need to establish |
|---|---|
| Supplier-operated open weights | Licence, hosting, model version and operational responsibilities |
| A third party's regional model service | Contracted region, related processing, support access and subprocessors |
| An optional externally hosted feature | Whether it is disabled by default, who may enable it and what information it receives |
| A replacement route during disruption | Whether substitution is permitted, how users are informed and which evidence supports it |
These are alternatives that a procurement exercise may encounter. They are not four features confirmed in Sovereign Health.
The distinction is useful because each arrangement can be acceptable under one set of requirements and unacceptable under another. A diagram should show the actual choice, not combine every possible route into a reassuring picture of flexibility.
A regional endpoint still needs its processing terms
Mistral's 11 August 2026 announcement provides a concrete example outside Tandem. It describes regional inference choices while also identifying limited safeguarded transfers to subprocessors that may occur outside the selected region.
That disclosure illustrates why the headline location and the associated processing terms should be read together. It does not establish that Mistral supplies Tandem, nor that Tandem uses the same exceptions.
A buyer should ask about ancillary activities such as abuse monitoring, support and incident investigation. The correct question is whether those activities process relevant information and fall within the approved terms, not whether every associated company has the same address.
The UK cloud-data guide discusses the resulting information-governance questions in more detail.
Make the restriction enforceable
An organisation with a strict processing requirement needs more than a promise that users will normally choose the preferred model.
Ask whether an administrator can disable unapproved routes and whether ordinary users can override that restriction. Establish whether the restriction applies to every enabled feature, including background operations. Request a record of changes and a clear route for authorising exceptions.
A useful demonstration uses synthetic material. Attempt to select a disallowed service, invoke a feature requiring that service and change the configuration using an account without the relevant authority. Record what the application permits and what explanation it gives.
These tests are proposed controls to assess. Passing a demonstration once does not establish continuing compliance after a product update; configuration management needs to preserve the result.
What should happen when the preferred model is unavailable?
There is no universal answer. The service might pause, keep a task pending, offer a reviewed manual process or use a separately approved alternative. The decision should follow the clinical task and the contractual requirement.
Silent substitution is particularly important to clarify. A buyer could otherwise believe a request followed one approved route while the system used another in order to maintain availability.
The alternative may also produce different outputs. It could preserve the processing location while changing the model's behaviour, or preserve a familiar model while changing the processing arrangement. Those are different forms of degradation.
The continuity article sets out a practical exercise for those situations. It does not assume that an automatic fallback exists in any named product.
Evaluate each configuration that can reach a clinician
A performance claim should identify which model and surrounding configuration produced the result. A note-generation evaluation should not be assigned to an optional model that was not tested under the same conditions.
This does not require treating every permitted wording change as a new clinical product. It requires a proportionate account of material differences: output quality, latency, uncertainty handling and the review process.
A proposed test can use the same synthetic consultations across approved configurations. Compare clinically important content and correction work, not merely prose style. A configuration that is slightly slower but produces a more usable record may be preferable for one task, while an interactive task may have different requirements.
The organisation should also know which features become unavailable when it selects a restricted configuration. An omitted capability should be visible rather than quietly replaced by a less-governed route.
Record a meaningful approval statement
A useful local approval might state that specified teams may use specified functions under a named configuration, with identified processors and defined review requirements. It would identify excluded functions and the procedure for considering changes.
That is a proposed structure, not a universal legal template. Its value is that a new team member or incident reviewer can understand what was actually approved.
The weaker alternative is a statement that the organisation has "approved Tandem" or "approved sovereign AI" without identifying the service and settings. Such wording becomes less informative as the product adds capabilities.
For the relevant English NHS setting, DCB0160 provides the adopter-side clinical risk-management framework for deployment and change.
Choice is valuable when its consequences remain visible
Model flexibility can reduce dependence on a single source of capability. It can also increase the number of configurations an organisation must understand.
The strongest arrangement combines choice with explicit boundaries: which option is in use, what it processes, why it is permitted and what happens when it cannot complete the task. A sovereign product need not reject every frontier model. It needs to make the actual meaning of its promise clear enough to verify.
Frequently asked questions
Does frontier-model access necessarily mean processing outside Europe?
No. Model capability, ownership and hosting are different facts. The service's actual processing arrangements must be checked.
Does Tandem's public page confirm automatic fallback to an external model?
The retrievable description does not establish that behaviour. It should be treated as a deployment question, not assumed from the availability of optional models.
Is the model selected in the interface the only model that matters?
Not necessarily. Supporting functions may use other components. Ask for a feature-level processing map and the approved configuration.
Clarify the different forms of control in sovereign healthcare AI