Sovereign AI Levels: a shared way to say how sovereign you actually are.
"Sovereign AI" has become a slogan that means five different things in the same meeting. This is our attempt to fix that — five levels and six dimensions that turn "how sovereign are we?" into a question you can actually answer, defend to a regulator, and price. Grounded in the EU Cloud Sovereignty Framework and the plain reality of the CLOUD Act.
Sovereignty is a posture, not a product.
You don't "buy sovereignty." You choose, workload by workload, where you need control, where dependence is acceptable, and where a partner is worth more than ownership. Three principles run through everything below.
It's multi-dimensional
Data, model, compute, operations, jurisdiction and assurance can each sit at a different level. Your real level is the floor across the dimensions that matter for that workload — not the best one you can point to.
Higher isn't better
Every step up costs speed, money, and often model quality. The right level is the one your regulator and your board can defend — and no higher. Over-engineering sovereignty is a real, common mistake.
It's a business decision
Sovereignty belongs on the business side — a question of risk, regulation, and trust — not an IT checkbox. The people who own the P&L and the compliance exposure should own the level.
Five levels, from global default to fully autonomous.
Each level raises the guarantee — and the cost. Read them as a ladder you climb only as far as a given workload requires. The meter on each shows relative sovereignty; the coloured rail marks the line where foreign law stops reaching your data.
Global Default
Public global cloud and foreign proprietary AI APIs. No sovereignty posture.
- Data
- May leave the EU; residency not guaranteed.
- Model
- Foreign proprietary API; no control over weights or hosting.
- Compute / infra
- Global regions, foreign-owned and operated.
- Operations
- Administered from anywhere, including third countries.
- Jurisdiction
- Full exposure to foreign law (e.g. US CLOUD Act).
Fit: public or non-sensitive data, experimentation, speed-first use where sovereignty simply isn't a requirement.
Regional Residency
Data stays in the EU, contractually — but on a foreign-owned platform.
- Data
- EU data boundary; residency guaranteed by contract. Customer-managed keys optional.
- Model
- Foreign or EU-hosted API within the region.
- Compute / infra
- EU regions of a global hyperscaler.
- Operations
- Mostly EU, but remote support paths may exist.
- Jurisdiction
- Still exposed — a foreign-owned provider can be compelled under foreign law even for EU-resident data.
Fit: moderate-sensitivity workloads where residency and GDPR posture are enough, and full jurisdictional independence isn't required.
Operational Sovereignty
An EU-operated sovereign environment with a separate control plane.
- Data
- EU-resident, customer-held keys, transparency over who can access it.
- Model
- Models run inside the sovereign environment; inference stays in-boundary.
- Compute / infra
- Dedicated EU sovereign cloud — e.g. an EU-operated hyperscaler offering or partner-operated region.
- Operations
- Operated and administered by vetted EU personnel; no third-country remote admin.
- Jurisdiction
- Reduced, but bounded by the provider's ultimate ownership.
Fit: regulated workloads (finance, health, critical infrastructure) that need operational control and auditable access without going fully self-hosted.
Jurisdictional Sovereignty
EU-owned, outside foreign law — with models and compute you control.
- Data
- Under EU jurisdiction end to end; no foreign compulsion path.
- Model
- Open or EU-hosted weights you can run, inspect, and move; no lock-in to a foreign API.
- Compute / infra
- Sovereign compute from an EU-owned provider or your own stack.
- Operations
- Full operational and technical independence; documented exit rights.
- Jurisdiction
- Immune to extraterritorial law — the provider entity is EU-owned and controlled.
Fit: highly regulated, critical-infrastructure, or strategically sensitive workloads where foreign legal reach is unacceptable.
Autonomous Sovereignty
Self-hosted, isolated, no runtime dependency on anyone.
- Data
- Never leaves your controlled environment.
- Model
- Weights held and run entirely in-house; full custody.
- Compute / infra
- On-premise or air-gapped; owned outright.
- Operations
- Operated solely by your own cleared personnel.
- Jurisdiction
- No external dependency to compel — sovereignty by isolation.
Fit: national-security-grade, defence-adjacent, or classified workloads. Highest cost and friction, with a real trade-off against access to frontier model quality.
Six dimensions — because sovereignty is never a single number.
A level is a useful shorthand, but the honest assessment runs dimension by dimension. A system can be L3 on data and L1 on operations at the same time. These are the six axes to score.
Data
Where it lives and, more importantly, who has the legal authority to compel access to it.
Model & weights
A foreign proprietary API you can't see inside, versus weights you can host, inspect, and move.
Compute & infrastructure
Where the GPUs and the control plane physically sit — and who ultimately owns and operates them.
Operations
Who administers the system day to day, and whether anyone in a third country can reach into it.
Jurisdiction & law
Exposure to extraterritorial law such as the CLOUD Act, driven by the provider entity's ownership.
Assurance & certification
Provable, not asserted: EUCS level, CSF assurance level, and independent audit.
Which level does your workload actually need?
Start from the regulation and the risk your board carries — not from the technology. As a starting point, this is where typical enterprise segments land. The floor is a minimum, not a ceiling.
The goal isn't the highest level. It's the defensible one — matched to the risk your regulator and your board actually carry, and no higher.
We help you set the level — and stand up the capacity to reach it.
A framework is only useful if it leads to a decision and a working result. That's the part we own.
From "how sovereign?" to a running capability.
We work with the business side to decide the right level per workload, own the requirements and architecture, and govern the build — while vetted sovereign platform partners deliver the physical layer. We don't build the data centre; we make sure the AI opportunity lands on infrastructure that holds the level your board can defend, and we execute until your organization can take it over.
How this maps to the standards
This is WenableAI's synthesis, built to be interoperable with the emerging EU reference points — the EU Cloud Sovereignty Framework (CSF) and its assurance levels, and the EUCS certification scheme (Basic / Substantial / High). Our L1–L3 broadly track the CSF's rising assurance; L4 sits above it as full self-hosting. It is a reference for aligning a conversation, not legal advice — sovereignty obligations should always be confirmed with qualified legal and compliance counsel for your specific case.