Sovereign AI: running enterprise models without handing your data to a US cloud

"Sovereign AI" is the label of the year, and most of what carries it is a US frontier model behind an "EU region" toggle. That covers where the bytes sit at rest. It says nothing about who can compel access, who controls the runtime, or whether you can keep operating if the vendor changes terms. Sovereignty is a spectrum, and the marketing version only covers the easiest part of it.

The three things "sovereign" actually means

When a vendor says sovereign AI, ask which of these three they are selling, because they are usually selling one and implying all three.

Data residency. Where the data physically sits. An "EU region" gives you this and nothing else. It is the cheapest property to claim and the one every hyperscaler now advertises.

Operational control. Who runs the inference, who can see the prompts and outputs in transit, who holds the keys, who can be served a legal order. A US-operated Frankfurt region gives you EU residency with US operational control. Those are not the same axis.

Technology independence. Whether you can keep running if the vendor triples the price, deprecates the model version you validated, or gets cut off from you by export rules or a sanctions regime. A closed API is a single point of failure you do not own.

Our broader piece on European data sovereignty for cloud AI covers the legal terrain across all cloud workloads. This article is narrower: what sovereignty specifically demands once the workload is a large language model, where the data is not just stored but actively sent to a model on every call.

The CLOUD Act problem, applied to inference

The US CLOUD Act (2018) lets US authorities compel US-based providers to produce data they control, including data physically held in Europe. The jurisdiction follows the operating legal entity, not the data center postcode. Frankfurt, Dublin, and Paris regions run by US companies carry the same exposure as us-east-1.

For storage this is already uncomfortable. For an LLM API it is worse, because the sensitive content is not sitting in a bucket you encrypted: it is the live prompt stream. Every document you summarize, every contract you extract from, every internal question your staff ask the assistant passes through the provider's runtime in a form the model has to read. "Customer-managed keys" do not help when the plaintext is, by definition, what the model processes.

The EU-US Data Privacy Framework patched part of the transfer problem in 2023, but it has been challenged in front of the CJEU, the way Schrems I and II were before it. Building a multi-year AI program on a legal mechanism that has fallen twice is a posture your DPO will not sign off on quietly.

Open-weight models have made this a real choice

Five years ago, sovereign AI meant accepting a large capability gap. That argument is mostly gone. Open-weight models, the kind you can download and run on infrastructure you control, are now genuinely capable: Mistral's models out of France, Meta's Llama family, and a steady stream of strong open releases. A private LLM is no longer a toy you settle for. It is a deployment decision.

You run these in one of two places. On infrastructure you control: your own GPUs, on-prem or colocated. Or on EU sovereign cloud, meaning European-owned providers (OVHcloud, Scaleway, IONOS, Hetzner) or sovereign joint ventures (Bleu, S3NS), where the operating entity is in EU jurisdiction. Either way the weights are yours, the runtime is yours, and there is no third party in the prompt path who can be compelled to hand over what passes through.

The honest caveat: this is real engineering, not a checkbox. You own GPU capacity planning, model serving, autoscaling, evaluation, and the upgrade treadmill. That is exactly the gap between a notebook prototype and a production system, which is its own discipline (see from notebook to production).

The capability gap, and when it does not matter

There is still a gap between the best open-weight model and the best US frontier API, on the hardest reasoning, the longest context, and the most open-ended generation. Pretending otherwise is dishonest. The useful question is not "is there a gap" but "does the gap touch my use case."

For a large share of enterprise work, it does not:

RAG over internal documents. The model's job is to read retrieved passages and answer faithfully from them. The hard part is the retrieval and the grounding, not raw model brilliance. A mid-sized open-weight model with good retrieval beats a frontier model with bad retrieval every time.

Classification and routing. Tagging tickets, triaging emails, labeling documents by type, sorting by risk. These are well within open-weight capability and are exactly the high-volume tasks where sending everything to an external API is most expensive and most exposed.

Extraction. Pulling structured fields out of contracts, invoices, claims, and reports. Constrained, schema-bound output is something open-weight models do reliably.

Where the gap still bites: open-ended drafting at the top of the quality curve, complex multi-step agentic reasoning, and frontier-only context lengths. For those, a public API may genuinely be the better tool, provided the data going into it permits that.

That last clause is the whole decision.

A decision framework that survives an audit

Stop asking "sovereign or not" as a binary. Split the work by data class and route each class deliberately.

Step 1: classify the data, not the use case. For each workload, what actually goes into the prompt? Public marketing copy and anonymized telemetry are one class. PII, financial records, health data (GDPR Article 9), trade secrets, and anything under a customer's EU-only processing clause are another.

Step 2: route by class.

• Non-sensitive, public, low-volume: a public frontier API is fine. Do not over-engineer sovereignty you do not need.
• Sensitive, regulated, or high-volume: a private LLM on infrastructure you control or on EU sovereign cloud. Here sovereignty is not ideology, it is the only posture that keeps the prompt stream out of foreign jurisdiction.

Step 3: check the contracts you already signed. Many B2B contracts now mandate EU-only processing. Routing those prompts through a US API silently breaches agreements most CTOs have never read. This is the cheapest sovereignty problem to fix and the easiest to miss.

Step 4: keep the option open. Even where you use a public API today, build behind an abstraction so you can swap to a private model without rewriting your application. Technology independence is a design choice you make before you need it, not a migration you start under pressure.

The EU AI Act sharpens all of this. High-risk systems (credit scoring, hiring, insurance pricing, medical contexts) carry logging, transparency, and human-oversight obligations that are far easier to meet when you control the model and the inference logs than when both live inside a vendor you cannot fully audit. By the time those requirements bind in regulated sectors, the teams who built on controllable infrastructure will be demonstrating compliance, and the teams who did not will be renegotiating with their vendor under a deadline.

How DNA helps

We assess your AI workloads by data class, separate the ones that genuinely need sovereign infrastructure from the ones that do not, and design the split so you are not over-paying for sovereignty where it adds nothing or under-protecting where it counts. Then we build it: open-weight models on infrastructure you control or on EU sovereign cloud, production-grade serving, and an abstraction layer that keeps your options open. If sovereign AI is on your 2026 roadmap, talk to us before the EU AI Act timeline makes it a deadline instead of a decision.