How should European companies evaluate AI sovereignty claims?
AI sovereignty is the demonstrable ability to control who can process, access, operate and legally compel access to a workload—not merely the location selected for compute.
The phrase European AI can describe a data-centre location, a company, a support organisation, a legal jurisdiction or a political ambition. Those are different properties. A useful evaluation separates them before scoring the result.
Use a six-part test
- Workload region
- Where inference and storage are configured to run, including any failover path.
- Provider ownership
- Who owns and controls the companies delivering the service and its critical infrastructure.
- Support access
- Which people and entities can access systems or data for operations, security and troubleshooting.
- Subprocessors
- Every external organisation that may process data or operate a material part of the service.
- Legal transfer basis
- The legal mechanism and safeguards used when personal data may be accessed from outside the EEA.
- Operational control
- The customer’s practical ability to set policy, restrict routing, approve tools, inspect evidence and stop processing.
1. Workload region
Confirm the region for inference, storage, backups, telemetry and disaster recovery. Ask whether failover can leave the selected geography and whether the request fails closed when the approved deployment is unavailable. A region is meaningful only when every material path is documented.
2–3. Ownership and support access
Identify the legal entities that own and operate the service, then identify who can access it. A European subsidiary or data centre does not remove the influence of a non-European parent, global support team or central control plane. The relevant question is who can do what, from where, under which controls.
4–5. Subprocessors and legal transfer basis
Read the live subprocessor register, not just the marketing page. Map each subprocessor to purpose, data category and access location. Where access may involve a third country, inspect the transfer mechanism, supplementary measures and assessment. Legal compliance and sovereignty are related, but they are not interchangeable labels.
6. Operational control and evidence
- Exact model and version selection with fail-closed routing.
- Deny-by-default tool execution and explicit egress policy.
- Tenant-scoped identity, permissions and approvals.
- Metadata-only audit records that do not copy prompts, responses or files.
- Signed receipts or equivalent evidence tied to each material execution.
- A tested way to stop processing, revoke access and export evidence.
Turn the assessment into a decision record
For every use case, record the data class, approved models, allowed regions, support-access constraints, subprocessors, transfer basis, tool permissions and required evidence. Add an owner and review date. The result is not a permanent certification; it is a controlled decision that can be revisited when providers, law or architecture change.
A credible sovereignty claim is multidimensional, evidence-backed and specific to a workload. If the answer is only “hosted in the EU”, the assessment has barely begun.
Common questions
- Is EU hosting enough for AI sovereignty?
- No. It establishes a workload-location property. A complete assessment also covers provider ownership, support access, subprocessors, legal transfer basis, operational control and the evidence behind each claim.
- Does GDPR compliance mean a service is sovereign?
- No. GDPR compliance concerns lawful personal-data processing. Sovereignty is a broader control question that can include corporate control, operational access, technology dependencies and the ability to verify and stop processing.
- How often should an assessment be reviewed?
- Review it whenever the use case, data class, model, provider, subprocessor list, access model, legal basis or architecture changes, and on a fixed periodic schedule even when no change has been announced.