Sovereign AI in healthcare concerns the control an organisation can exercise over the information, models and infrastructure on which a service depends. It is not adequately described by the country printed beside a data centre, and it is not a clinical-quality certificate.
A useful sovereignty claim should answer several questions: where does the work happen, who can access it, who can change the system and what happens when the organisation needs to leave? Different deployments can provide different answers. There is no need to pretend that every hospital requires the same architecture.
The terminology has immediate relevance after Tandem's Sovereign Health announcement, but the distinctions below apply to any supplier. They provide a way to read a proposal rather than a ranking of European and non-European companies.
Data residency: where the information is located
Residency describes location. For an AI service, the question should cover more than the main database: captured audio, transcripts, model inputs, generated text, backups and operational records may pass through different systems.
An organisation might keep approved notes in its own clinical record while the documentation supplier processes temporary material elsewhere. Another might use a regional model endpoint but retain troubleshooting extracts in a separate support system. These are possible architectures, not descriptions of a particular supplier.
The practical request is a data-flow diagram with named stages. "Hosted in Europe" is too broad when it does not identify which information and which operations the statement covers. A useful diagram also shows deletion or onward transfer rather than ending at the first storage location.
Legal ownership: which organisations control the service?
Corporate ownership and data residency are distinct. A service can operate in a country while its controlling company is established elsewhere. A provider based in Europe can also depend on software, hardware or services from other jurisdictions.
The buyer should identify the contracting entity, infrastructure operator and material subcontractors. Legal advisers can then assess the implications of those relationships for the proposed service. A map of headquarters alone is not a complete legal assessment.
The ICO's international-transfer guidance makes another distinction important for UK organisations: making personal information accessible to a separate overseas organisation can engage transfer rules even without moving the primary database. The exact arrangement matters, including who initiates the transfer and the legal entities involved.
Model control: can the intelligence be operated or replaced?
A hosted model API gives access to a service. Access to open weights can make independent operation possible, subject to the licence and the practical ability to run the model. These are different forms of control.
Open weights do not necessarily provide the training data, every development tool or unrestricted commercial rights. They also do not explain why every output was produced. Inspecting a model's parameters is not equivalent to obtaining an intelligible clinical rationale.
For healthcare buyers, the more useful question is what the supplier can actually control: version selection, adaptation, serving location, testing and replacement. For a hospital buying a finished application, those rights may remain with the application supplier rather than transfer to the hospital.
Model control can consequently increase the supplier's independence without making the customer independent of that supplier. Both perspectives belong in the assessment.
Operational control: who can keep the service working?
Operational sovereignty concerns practical authority and capability. Who administers accounts? Who controls encryption keys? Who can restore a backup, disable a compromised connection or authorise a different processing route?
The NCSC's cloud shared-responsibility model explains why responsibilities differ according to the service being purchased. Buying managed software is not the same as operating infrastructure directly.
More direct control also means more work. A hospital running its own model must maintain suitable security, staffing, capacity and recovery arrangements. Outsourcing those tasks may be sensible when the contract and controls meet the organisation's needs.
The goal is not maximum ownership for its own sake. It is sufficient, usable control over the dependencies that matter to the clinical service.
Continuity and exit are tests of whether choice is real
An organisation may have a choice of models at procurement and little practical choice after several years of integration. Local templates, record connections, staff routines and unfinished work can make switching difficult even when the underlying model is replaceable.
A meaningful exit plan identifies the records that must remain available, the format in which they will be exported and the assistance needed to move them. It also addresses what cannot be transferred, such as proprietary workflow logic, and what must instead be rebuilt.
The government's technical lock-in guidance supports assessing exit costs and accepting some dependence where its benefits justify it. The sensible standard is an informed trade-off, not a promise that a sophisticated clinical service can have no switching costs.
What the European Commission framework contributes
The European Commission's Cloud Sovereignty Framework explanation, published on 1 June 2026, describes an assessment spanning 48 criteria across eight categories. Its approach considers several dimensions of control rather than treating geography as a binary answer.
That makes it useful background for procurement vocabulary. It is a cloud-assessment framework, not an evaluation of clinical notes, a medical-device certificate or an automatic requirement satisfied by every supplier using the word sovereign.
A clinical organisation can borrow the discipline of asking for substantiation without inventing its own official certification. Any locally designed scorecard should be labelled as such and should not imply that a company has received an external grade that has not been verified.
Translate the claim into something inspectable
| Supplier claim | What it could mean | Evidence that makes it useful |
|---|---|---|
| Regional residency | Specified information remains in a stated region | A complete data-flow and retention schedule |
| European ownership | Identified operating entities have a particular ownership structure | Corporate and contractual documentation |
| Customer control | The customer can exercise defined permissions | A demonstration of access, configuration and key-management rights |
| Open-model choice | An approved model can be operated or substituted | Licence terms, supported configurations and replacement procedures |
| Independent operation | Defined functions can continue without a named external service | An exercised continuity plan and dependency record |
| Portability | Required information can be used after leaving | A sample export and successful destination-side test |
This table is an editorial aid. It does not assign legal status or certify a deployment. Its purpose is to make a supplier meeting produce evidence rather than a collection of reassuring adjectives.
Three organisations can reasonably choose differently
A fictional research hospital may already have the staff and infrastructure to operate selected models internally. It could value adaptation and direct operational control enough to accept the additional maintenance burden.
A small practice may need a managed application with clear information handling and a reliable manual alternative. Owning the model infrastructure could create obligations it cannot support, without improving the immediate clinical workflow.
A regional provider may prefer a contract that restricts processing to approved routes while allowing more than one model. Its priority could be continuity and negotiating leverage rather than running the system itself.
None of these choices can be judged solely by a sovereignty label. The requirement, resources and consequences of dependence differ.
The European application, model and infrastructure comparison shows how these forms of control can sit with different organisations. Its examples should be read as distinct roles, not as evidence that every named company supplies the others.
Clinical locality remains a separate question
A model can run locally while presenting guidance from the wrong healthcare system. Conversely, a remotely operated service can retrieve highly relevant local evidence through an appropriately governed arrangement.
The clinical assessment should therefore examine source selection, jurisdiction, current local pathways and the user's role. iatroX's methodology is relevant to that evidence-selection discussion, not a claim that iatroX supplies sovereign infrastructure or escapes the same processing questions.
The strongest procurement conclusion is specific: the organisation understands which dependencies it has accepted, which controls it can exercise and which clinical evidence supports the resulting use. Sovereignty becomes useful when it changes those answers, rather than merely changing the language on the proposal.
Frequently asked questions
Is data residency the same as data sovereignty?
No. Residency concerns location. Sovereignty additionally raises questions about legal relationships, access, model operation and the ability to maintain or replace the service.
Does an open-weight model make an application open source?
Not necessarily. The model licence, application code, integrations and operating arrangements are separate. Access to one component does not grant rights over the others.
Does the European Commission framework certify clinical safety?
No. It assesses cloud sovereignty considerations. Clinical performance, medical-device scope and local deployment assurance require their own evidence.
Take twelve evidence-focused questions into your next supplier meeting