What is sovereign AI?

Sovereign AI means running artificial intelligence — the models, the data they touch, and the automation built around them — under your own control and your own infrastructure. Not "hosted in an EU region" — control in the literal sense: your infrastructure, your model, your data, your audit trail. You will also hear the neighbouring terms private AI and on-premise AI; those describe deployment models. Sovereignty describes something stricter — who actually governs the system, and what still holds when a provider, a price list, or a foreign legal order changes.

For Dutch and European public-sector organisations, sovereign AI became a procurement question on 3 July 2026, when the Dutch government tightened its rules on central-government cloud use. Here is what sovereign AI actually means, why it just became binding policy, and what to require when you procure it.

A useful test: an AI system is sovereign to the extent that you control four layers — and can prove it.

• Infrastructure. The system runs on hardware and networks you choose: your datacenter, your sovereign cloud, an air-gapped enclave. You decide where compute happens.
• Model. You choose which model runs and when it changes — a hosted model, an EU-hosted model, or a local model doing inference entirely inside your perimeter. A provider deprecating a model does not silently change your system's behaviour.
• Data. Data residency — knowing your data stays inside a jurisdiction — is the floor, not the definition. Sovereignty adds the data path: which systems see your prompts, documents, and outputs as they're processed, and whether the platform can run without external calls at all.
• Audit trail. Every action and decision is logged, attributable to a named principal — a person or service identity your organisation manages — and stored where you store it. If you cannot answer "who did what, when, on whose authority" from your own records, you do not govern the system; you subscribe to it.

Miss one layer and the others weaken. An on-premise model with a cloud-only audit log fails layer 4. A well-governed platform that calls an opaque external API for every decision fails layers 2 and 3.

Across the EU, sovereignty is moving from position papers into procurement rules — the Netherlands is just the clearest recent example. On 3 July 2026, the Dutch government published stricter rules for the use of cloud services by the central government ("Strengere regels voor het gebruik van clouddiensten door de Rijksoverheid", rijksoverheid.nl).

That is a real shift: sovereignty has moved from something governments talk about to something they buy against — and the same pressure is arriving EU-wide through the AI Act and NIS2. Anyone responsible for digitalisation or purchasing now has to answer a concrete question — what does the stricter cloud policy mean for the stack we already run, and for everything we buy next?

The policy lands in a procurement culture that was already primed for it. Verantwoord inkopen (responsible procurement) and regie op algoritmes (keeping control over the algorithms you deploy) are established vocabulary in Dutch public-sector buying, and the government's Algoritmekader gives organisations a shared reference for algorithm governance. Sovereign AI is what those principles translate to at the level of infrastructure and vendor selection — and the direction of travel is EU-wide, with the Dutch cloud rules the clearest recent instance of sovereignty becoming binding.

The same logic reaches beyond government. Regulated mid-market organisations — logistics, industrial, anything with an external IT-controls audit — face their own version: the automation platform your operations team quietly adopted is part of the audit surface now, and "the vendor manages that for us" is a harder answer to defend every year.

Sovereignty is a spectrum, and most organisations sit further down it than their risk register assumes. From least to most control:

Level 1 — Public cloud AI APIs

Fastest to adopt, least control. Your data leaves your environment on every call; the provider controls the model lifecycle, the terms, and the telemetry. Regional endpoints can give you data residency on paper — but residency alone does not answer who can be compelled to disclose your data, what changed in the model underneath you, or what you can prove about a decision afterwards.

Level 2 — Private cloud / dedicated instances

Dedicated capacity in a region you choose improves isolation and residency. But the operator still runs the stack, and where the operator is a non-EU provider, questions about extraterritorial legal reach over that provider remain open. You are renting sovereignty attributes; you do not hold them.

Level 3 — On-premise, proprietary

The model and platform run in your datacenter — a genuine step up for data control, and no longer hypothetical: major AI vendors have begun offering on-premise deployment of proprietary models, including through hardware partners — OpenAI and Dell partnered to bring Codex on-premise via Dell's AI Factory, and Google's Gemini is being brought to on-premise Dell hardware. But proprietary on-premise means you host a black box. You cannot inspect what you run, you depend on the vendor for updates and licence terms, and ownership stays with them. On-premise AI answers where; it does not by itself answer who governs.

Level 4 — Self-hosted and source-available: you own it

The full stack runs on your infrastructure; the source code is available for your security team to inspect; you choose and swap models, including fully local inference; and the audit trail lives in your systems. Nothing structural depends on a vendor's continued cooperation. This is the level that stricter cloud rules and regie op algoritmes naturally point to for sensitive workloads — control you hold, not control you rent.

Writing requirements — for a tender or an internal build-vs-buy? These are the questions that separate sovereign from sovereign-flavoured:

• Governance built in, not bolted on. Role-based access control (RBAC); an audit trail in which every action is attributable to a named principal; single sign-on against your own identity provider (LDAP/OIDC/SAML). Ask whether these ship in the base product or sit behind an enterprise tier — for a public-sector or regulated buyer, attributability is not an upsell, it is the price of entry.
• Data path, not just data residency. Can the platform run with no external calls at all? Which components contact the vendor, for what purpose, and can each one be disabled?
• Model choice, including local. Can you run an EU-hosted model? A fully local model? Can you switch models without re-architecting the workflows built on top?
• Inspectability. Can your security reviewers read the source code of what they are being asked to deploy?
• Exit and continuity. If the vendor disappears or the relationship ends, what keeps running? Sovereignty includes the right to continue operating.
• Compliance support, not compliance theatre. Expect a vendor to show how the platform supports your compliance obligations and evidence needs — and be precise about which certifications a vendor actually holds versus which frameworks it merely references.

On the EU AI Act specifically: the Council adopted the deferral of the high-risk (stand-alone Annex III) obligations to 2 December 2027 on 29 June 2026; the change takes effect once published in the EU Official Journal.

So there is no deadline to panic-buy against — and vendors leaning on one deserve scepticism. The sensible posture is governed-by-design: build attributability, oversight, and logging in now because your auditors and risk owners need them regardless, and the high-risk obligations will find you ready.

Not necessarily — and it is worth being precise, because the terms blur in both directions. Open-source licensing is one route to inspectable software, but plenty of open-source AI tooling is consumed as SaaS you do not control, and a licence type alone says nothing about your data path or audit trail. What sovereignty requires is inspectability plus ownership of the running system.

EpicStaff is a platform for governed, self-hosted automation and AI agents — built for the Level-4 posture this post describes. You own and govern the whole stack: your infrastructure, your LLM, your data, your audit trail.

A regulated mid-market operator, MoveYourMachine, already runs EpicStaff in production — across sales follow-up, onboarding, and CFO reporting. Level 4, live.

• Self-hosted, source-available. Runs entirely on your own infrastructure, with support for local and self-hosted LLMs, and the source published under PolyForm Perimeter 1.0.0. For defence-grade deployment requirements, see the defence page.
• Governance in the free tier. RBAC ships in the free source-available tier, and every session and interaction is persisted and exportable as JSON or CSV — governance is not paywalled.
• Single sign-on. Integrates with your identity provider (LDAP/OIDC/SAML).

• Model choice, including local inference. You decide which model runs and where — including models that never have to leave your network.
• Compliance support, honestly framed. We do not claim certifications we do not hold. We support your compliance work with what sovereignty actually produces: exportable audit logs, access control, and a stack your auditors can inspect.

If you're working out what the stricter cloud rules mean for your automation and AI, talk to us about your environment — or read the platform and defence pages for the deployment models.