What Sovereign AI Actually Requires
Sovereign AI means an AI system whose compute, model and operator all sit under a legal regime you accept. Not one of the three is optional. If the hardware is in the EU but the model endpoint is US-operated, the prompt leaves that regime — and the arrangement is no longer sovereign.
For teams whose source cannot flow through US services, this is what decides whether coding agents get adopted or die in review: execution and storage run on EU bare metal. Whether the whole pipeline is sovereign depends on one more choice — the model you point it at — and we would rather be specific about that layer than let a flag on a page stand in for it.
- compute: execution and storage on eu bare metal
- model: eu-hosted, or your own token for a us provider
- operator: covered by the condition below
What sovereign AI means
Most descriptions of sovereign AI answer one question: where does it run. That is the easiest of the three questions and the least decisive. A running agent touches your code in three places, and each one sits under someone's law.
It runs somewhere — on hardware, in a data centre, in a country. It thinks somewhere — every prompt goes to a model endpoint, which is a different machine under a different contract, often a different flag. And it is operated by someone — a company that can be served an order, audited, acquired, or compelled to hand over what it holds.
Sovereignty is a property of that whole chain, not a state you buy. It breaks at the weakest link, and the weakest link is usually not the one on the product page. This is where sovereign AI differs from data sovereignty as it is normally discussed: data sovereignty asks where data rests, and an AI system is defined by data in motion. The moment an agent works, source code leaves storage and becomes a prompt.
That is also why the question is harder for agents than for a chat assistant. An autonomous coding agent reads your repository, holds credentials, and sends what it reads to a model in order to decide the next step. There is no version of this in which the interesting data stays at rest.
So the useful definition is not a label but a test with three parts. Compute: under whose law does the execution environment sit. Model: under whose law does the endpoint that answers the prompt sit. Operator: under whose law does the company running the platform sit. Three answers, three jurisdictions, and sovereignty only where all three are ones you accept.
Sovereign AI, sovereign cloud, private AI
The three terms are used interchangeably and are not the same thing. They cover different layers, which is why a vendor can be accurate about one and silent about the two that decide your case.
| Term | Compute | Model | Operator | Legal jurisdiction |
|---|---|---|---|---|
| Sovereign AI | In scope | In scope | In scope | One you chose, across all three |
| Sovereign cloud | In scope | Not addressed | Usually in scope | Covers infrastructure only |
| Private AI | Your environment or a dedicated tenancy | Usually a model you host yourself | You, or your hosting partner | Whatever you already have |
| EU region of a US-operated service | EU location | The provider's, often US | US company | US law reaches the operator |
Sovereign cloud is an infrastructure category. It answers where the machines are and, in the better cases, who runs them — and stops before the model layer, because it predates the question. An EU sovereign cloud that hosts a US model endpoint is a correct description of the infrastructure and an incomplete description of your exposure.
Private AI is about access, not law. It means the model runs where no third party sees the traffic — typically an open-weight model on your own hardware. That is a strong control and it says nothing about jurisdiction: private and sovereign coincide only if you also happen to be in a jurisdiction you accept.
The fourth row is the one most teams are actually evaluating, and it is the one covered next.
The three layers: compute, model, operator
Sovereignty holds for the whole pipeline only when the compute, the model and the operator are all in scope. Each layer has a control we provide, a way it breaks, and a decision that stays yours.
Compute — where execution and storage happen. What we provide: execution and storage on EU bare metal at an EU provider, one microVM per session, with egress closed by default and open only for the destinations resolved when the session was created. What breaks it: nothing in this layer that you can select wrong — it is fixed by how the platform is built. What you decide: shared or dedicated capacity, which changes physical separation and what you pay for, not the residency. If the isolation boundary itself is the thing under review, start with what a microVM is.
Model — where the prompt goes. This is the layer no one puts in the comparison table, and it is the one that decides most cases. There are two routes:
- An EU-hosted model
Run an EU-hosted model and the prompt never leaves the EU.
- Your own token for a US provider
Bring your own token for a US provider — which you are free to do — and the prompts you send reach that provider under their jurisdiction, whatever our region setting says.
We will tell you which of those two you are in, per route, before you sign anything.
Operator — who can be compelled. Not a setting at all, and the layer that survives every dropdown. The question is not where the machines stand but which legal system the operating company answers to, because that is what a disclosure order attaches to. The test is not the nationality on a letterhead but control: whether any entity outside the regime you accept has possession, custody or control over the data — through a parent company, through contractual rights such as board control or access clauses, or through a technical path such as cross-border support or disaster-recovery backups. A minority shareholder abroad is not the same thing as a foreign parent, and the two are routinely conflated. What you decide: whether a vendor's answer on this layer is something you accept contractually or something you want evidenced. Ask for the operating entity, its parent, and the subprocessors behind it — from us, and from everyone else on your shortlist. Our own subprocessor list is not finished; see the last section.
Why an EU region is not a jurisdiction
Many of the agent platforms on a shortlist are operated by US providers. Selecting an EU region in a dropdown changes neither the law the operator is subject to nor who can be compelled to access what — and it evidences nothing to a data protection officer who asks.
The name for that gap is the CLOUD Act. It amended US stored-communications law so that a US-based provider must produce data in its possession, custody or control regardless of where the data is stored. The obligation attaches to the company, not to the building. A European data centre operated by a US company is still operated by a US company.
The European side of the same question is Article 48 GDPR, which says a third-country authority's order is only recognisable as a basis for transfer if it rests on an international agreement such as a mutual legal assistance treaty. A provider caught between the two is not in a position to promise you a clean answer, and a region selector does not remove it from that position.
For teams already scoping EU AI Act obligations, the same distinction returns as a documentation problem: you have to be able to say who processed what, where, and under whose authority. “EU region” is not an answer to that question. The operator's jurisdiction is.
None of this makes US providers careless. It makes them subject to a legal system that is not yours — which is a structural fact about the arrangement, not a claim about anyone's conduct.
What we can state today
Four statements, each in the form a reviewer can check rather than a claim to trust.
Execution and storage in the EU
Region EU, on bare metal at an EU provider. This covers execution and storage; the model route depends on the token you bring, as set out above.
region: eu · bare metal at an eu providerGuardrails, not surveillance
Our operating policy is guardrails at the boundary of the sandbox instead of content monitoring. We do not read what your agent is working on, we do not evaluate your source, and the controls we run exist to hold the boundary, not to observe the work inside it.
operating policy: guardrails instead of content monitoringThe keys you bring stay out of the agent's reach
The tokens a session needs — the model key you bring, source-control access, tokens for remote endpoints it calls — never reach the agent process as usable secrets. Its environment holds a placeholder; the real token is substituted on the outbound request, and only the destination server sees it. A prompt-injected agent cannot read your provider key out of its own environment. Two limits belong with it: there is no enforced boundary inside the sandbox between the agent and the component that substitutes the token, so the claim is that the secret is not handed to the agent, not that it exists nowhere in plaintext; and it covers the tokens on that path, not every credential your tooling carries.
credentials: placeholder in the guest · substituted on the outbound requestA structured event log per session
A running session emits a structured event feed, boundary decisions included, readable by someone who was not there. The events are kept rather than only shown: each one is stored in the open OCSF schema as it was recorded, wrapped in provenance the host stamps rather than the sandbox. No single event can be edited or picked off, by you or by your users; deletion exists only as a coarse operation at account or sandbox scope, and that operation is itself logged. What is not delivered is the part procurement asks about next. Ageing out runs on a schedule, but the window is currently shared across accounts rather than set per customer; there is no export you can hand to a reviewer; and nothing is cryptographically anchored — so the record is tamper-evident against your own users, not against us. Until that last part changes, this is a strong operational record and not yet an audit trail a regulator would take on its own.
audit: ocsf event log · stored · export & per-customer retention: planned
The safe default is the normal state: egress closed, and open only for the destinations resolved when the session was created.
We hold no certification today, and we will not imply one. What exists is a set of controls that a reviewer can inspect and a list of limits stated in the same words in every conversation. If one of these matters to your review, ask which layer enforces it and what happens when that layer fails — every statement on this page is written to survive that question, and the ones that would not survive it are in the next section instead.
What is still in preparation
The documents procurement actually asks for, with their real status:
| Document | Status |
|---|---|
| Data processing agreement (DPA / AVV) | In preparation. Does not exist yet. |
| Record of processing activities (ROPA / VVT) | In preparation. Does not exist yet. |
| Subprocessor list | In preparation. Does not exist yet. |
| Technical and organisational measures (TOM) | In preparation. Does not exist yet. |
We are building this with a small number of teams rather than for an anonymous market. If these three layers are what your review turns on, the design partner programme is where that conversation belongs.
Bring us your actual requirement
If your DPO has a list, send it. We will answer each line with implemented, planned, or not covered — and we will not blur the middle one into the first.