Sovereign AI in Europe: what the 62% actually ask for
When roughly six in ten European organisations name data sovereignty as a top condition for adopting AI, they are not asking for a flag on a landing page. In procurement the phrase resolves into five concrete questions: where the data physically sits, who can technically reach it, which legal regime can compel disclosure, what happens to prompts and outputs after inference, and how you prove the answers a year later. Answer those five with artefacts and the sovereignty conversation ends in one meeting. Answer them with adjectives and it becomes a six-month security review.
What does a buyer mean by sovereignty?
Sovereignty has become a marketing word, which is unfortunate, because the people asking for it usually mean something precise. In every procurement conversation I have sat in, the term collapses into control: control over location, control over access, and control over the legal exposure that comes attached to both. Nobody in a security review asks whether your platform is sovereign. They ask which entity can technically read the prompt, and under whose law.
That is why generic assurances fail. A European region on a hyperscaler answers the location question and leaves the access and jurisdiction questions untouched. A private cluster in your own rack answers all three and opens a new set about operations and continuity. Both can be the right choice. What decides the deal is whether you can show which question your architecture actually answers.
The five requirements behind the number
Strip the vocabulary away and the same five requirements appear in questionnaire after questionnaire. They map cleanly onto the layers of the regulatory stack, which is not a coincidence: procurement teams write their questions from the duties they themselves carry under NIS2, GDPR and DORA.
| Requirement | The real question | What closes it |
|---|---|---|
| Data residency | In which countries does data rest, and where does it transit during inference? | A region and routing diagram naming every processing location, including logging and monitoring |
| Access control | Which humans and which entities can technically reach plaintext data? | A named list of administrative roles, key custody model and a support access procedure with logging |
| Jurisdiction | Which legal regime can compel disclosure, and through which parent company? | Corporate ownership chain, subprocessor list and a documented position on third-country access requests |
| Data usage | Are prompts, outputs or documents retained, used for training, or shared? | A retention table per data class plus a contractual no-training clause with a technical control behind it |
| Exit and portability | How do we leave, how long does it take, and what does it cost? | An exit plan with a tested export format, timeline and the Data Act position on switching costs |
Note what is absent from that list: model quality, benchmark scores, feature comparisons. Those decide whether you get shortlisted. Sovereignty decides whether the shortlist survives the security review, and it is answered by documents rather than demos.
Jurisdiction is the question vendors dodge
Residency is easy to answer and easy to verify, so most vendors lead with it. Jurisdiction is harder, because it is a question about ownership rather than infrastructure. A European data centre operated by a subsidiary of a non-European parent sits in a different legal position than an independently owned one, and buyers in public administration, defence supply chains and health increasingly ask the question in exactly those terms.
The workable answer is not a claim of immunity. It is a documented position: who owns the operating entity, which subprocessors exist, what your process is if a third-country authority makes a request, and what the customer is told and when. Vendors who write that page once stop losing weeks to it. Vendors who improvise it in a call lose the deal to whoever wrote it down.
Which deployment model answers which question?
There are three honest models, and each buys a different slice of the requirement list. Choosing one and being explicit about its limits is more persuasive than claiming the strongest label available.
- Public cloud in an EU region: answers residency, partially answers access, leaves jurisdiction open where the operator has a non-European parent. Fastest to deploy, cheapest to start, hardest to defend in high-sensitivity sectors.
- European sovereign cloud or a regional provider: answers residency and jurisdiction, answers access if the key custody model is customer held. Costs more, narrower service catalogue, usually the pragmatic middle for regulated buyers.
- On-premise or customer-controlled private infrastructure: answers all five by construction, and shifts the burden to operations, GPU capacity planning and lifecycle. The right answer when documents cannot leave the building, and an expensive one when they can.
The economics change the conversation less than people expect. Over a three-year horizon a private deployment with steady utilisation is frequently competitive with metered inference, and the sovereignty properties come as a side effect rather than a premium. Where it stops being competitive is bursty, low-volume usage, where paying per token is simply cheaper than owning idle accelerators.
Sovereignty is not a tier in a price list. It is a set of answers a buyer can hand to their auditor unchanged.
How to make the claim provable
A sovereignty pack is a short document set, not a whitepaper. Five pages, one per requirement, each dated and owned by a role. Residency diagram. Access and key custody model. Ownership and jurisdiction position. Data usage and retention table. Exit plan with a tested export. Add the review date and the release the pack describes, because an undated answer reads as an absent one.
The same pack does double duty. Four of the five pages are also evidence in a NIS2 supplier audit, and the retention table is the input a buyer needs for their own record of processing under GDPR. Teams that build it once for sovereignty questions find they have pre-answered most of the security questionnaire that arrives two weeks later.
Frequently asked questions
- Does an EU data centre make our AI deployment sovereign?
- It answers the residency question only. Buyers also ask who can technically access plaintext data and which legal regime governs the operating entity. An EU region run by a subsidiary of a non-European parent answers the first question and leaves the other two open, which is why the ownership chain belongs in your documentation.
- Is on-premise AI the only truly sovereign option?
- No. On-premise answers every requirement by construction, but a European provider with customer-held keys and a documented ownership chain answers them too. On-premise becomes the necessary choice when data legally or contractually cannot leave your own infrastructure.
- What should a no-training clause actually say?
- That prompts, outputs and uploaded content are not used to train or fine-tune any model, that retention is limited to a stated period per data class, and that subprocessors are bound by the same terms. A clause without a technical control and a retention table behind it is a promise, not evidence.
- Do sovereignty requirements come from the AI Act?
- Not directly. The AI Act regulates the system, while sovereignty questions come from GDPR transfer rules, NIS2 supply-chain duties, DORA for financial buyers and the Data Act on switching. That is why the answers live in one shared evidence pack rather than in four separate compliance projects.
Related articles
EU AI Compliance Stack 2026: One Map
One dated map of the AI Act, NIS2, GDPR/DORA and CRA obligations that hit AI vendors between August 2026 and August 2028, with EUR-Lex sources.
Passing an NIS2 Supplier Audit as an AI Vendor
NIS2 reaches AI vendors through the customer contract. The five evidence artefacts buyers request, the incident clocks, and what to prepare before the questionnaire.
AI Act Article 50: What to Label and Who Signs
Article 50 has applied since 2 August 2026. Which outputs need a label, where the disclosure sits, and who owns the sign-off record.
Next step
Need this as an outcome, not an article? Sovereign deployment.
Sovereignty is a buyer's problem stated as a hosting question. We answer it as an architecture decision: which layer must stay in your jurisdiction, what that costs over three years, and what an auditor accepts as proof.
Explore Sovereign deployment