Sovereign AI

What sovereign AI means

Sovereign AI is the ability to run AI systems under your own jurisdiction, on infrastructure you control, without depending on a foreign provider for access, continuity or confidentiality.

It is usually discussed at national level, but the requirement shows up at organisational level too. A European bank under DORA, a defence contractor, a hospital group, a national statistics office. Each of them has the same question: if the relationship with a foreign vendor ended tomorrow, for commercial or political reasons, does the system keep working and did they ever see the data.

The term covers a range. At one end, data residency: the processing happens in a specified region. At the other, full sovereignty: the models, the infrastructure and the operational control are all domestic, and the system runs with no external connection at all.

Why it is being asked for now

Three things arrived together.

• Regulation. The EU AI Act sets obligations on high-risk systems, including logging, human oversight and documentation. DORA sets requirements on how financial entities manage third-party technology risk, and concentration risk in a single foreign provider is exactly what it targets. GDPR continues to govern transfers.
• Geopolitics. Organisations that were comfortable with a single-country dependency a few years ago are less comfortable now. This is a board-level conversation in European institutions and it is not really about the technology.
• Capable open models. Sovereignty was impractical while the only usable models were closed and hosted. Open-weights models good enough for real work removed that objection, and with it the main reason to say no.

What it requires in practice

Inference you control

Open-weights models running on infrastructure in your jurisdiction, or a provider contractually and technically bound to it. This is the piece most discussions stop at, and it is the least difficult one.

An orchestration layer that is not the dependency

This is the piece that gets missed. Solving the model and then running everything through a foreign SaaS control plane reintroduces exactly the dependency you were removing. The layer that decides what agents run, holds their configuration and records what they did has to be under your control too — that layer is the runtime.

Air-gap capability

For defence, critical infrastructure and some government work, the requirement is no outbound internet at all. That rules out any platform whose agents need to phone home to function. It has to be architecturally possible, not a deployment option in a slide.

An audit trail that satisfies a regulator

Immutable, complete, attributable, retained. Sovereign deployments are almost always regulated deployments, and the two requirements arrive together. What that record has to contain.

A genuine exit

Sovereignty means the system survives the vendor. If your agents only run inside one company’s proprietary format, you have relocated the dependency rather than removed it.

What it rules out

Being direct about this saves everyone time.

• Any platform that proxies model calls through its own provider accounts.
• Any platform where agent execution happens in the vendor’s cloud rather than yours.
• Any architecture that requires outbound connectivity to function, where an air gap is required.
• Any agent format that cannot be exported and run elsewhere.

Most of the current agent platform market fails at least one of these, which is why the pilots in this segment tend to stop at the security review. The first of the four is what model-agnostic actually requires.

The honest trade-offs

Sovereign deployments cost more. You carry infrastructure and operational work that a hosted platform would absorb. Self-hosted open models can lag frontier models on the hardest tasks, though the gap is narrower than it was and is often irrelevant for the workloads in question.

The trade makes sense when the alternative is not deploying at all, which for a large part of the European public sector and regulated industry is the real comparison.

Common questions

Is sovereign AI the same as data residency?

No. Data residency says where data sits. Sovereignty covers who controls the infrastructure, who can compel access, and whether the system keeps working if the relationship ends.

Do I have to use open-weights models?

For full sovereignty and for air-gapped work, in practice yes. For data residency alone, a regional deployment from a commercial provider can be enough.

Can I mix?

Yes, and most organisations should. Sensitive workloads on sovereign infrastructure, everything else on whichever model is best for the job. That only works if your platform is model-agnostic.

Does this apply outside Europe?

Increasingly. US buyers in defence, healthcare and financial services ask the same questions for regulatory rather than geopolitical reasons.

Stackbone

Stackbone runs in two places: Stackbone Cloud, where we run it for you, and your own infrastructure. A sovereign deployment is the second one. The self-hosted install ships the whole stack into your infrastructure, control plane and Studio included, next to the agents. Agents call models with your own keys, including open-weights models you host yourself, and the install runs with no outbound internet access. The agents themselves are a TypeScript repository your IT team holds and changes through pull requests.