Why AI sovereignty matters for European enterprises

"Sovereign AI" has become a procurement checkbox, which is a shame, because underneath the marketing there are three genuinely different questions and most vendors only answer one of them.

Question one: where does the data sit?

This is residency, and it is the easy one. A region selector in a cloud console answers it. Most serious vendors can tell you customer data is stored in an EU region, and many now default to it.

Residency is necessary and it is not sufficient. Data at rest in Frankfurt can still be processed elsewhere, backed up elsewhere, accessed for support from elsewhere, and read by a subprocessor you have never heard of. The question worth asking is not "where is it stored" but "list every party that can read it, and tell me where they are".

Question two: who can compel access?

This is jurisdiction, and it is the question residency marketing quietly skips.

The US CLOUD Act of 2018 allows US authorities, through legal process, to compel a US-based provider to produce data in its possession, custody or control, regardless of where in the world that data is physically stored. Choosing an EU region does not change the nationality of the company operating it.

The transfer rules sit on top of that. Chapter V of the GDPR governs transfers of personal data outside the EEA. The Court of Justice's Schrems II judgment in 2020 invalidated the Privacy Shield framework, and the EU-US Data Privacy Framework adopted in July 2023 restored an adequacy route: one that has been challenged, and that any competent DPO treats as a mechanism carrying political risk rather than as a settled fact. The EU Data Act, applicable from September 2025, pushes in the same direction from the commercial side by requiring cloud providers to make switching genuinely possible.

The practical consequence is simple. If the answer to "who operates this service" is a US entity, you are relying on an adequacy decision plus contractual safeguards. That may well be an acceptable risk. It should be a decision someone made, not something nobody noticed.

Question three: where did the model come from?

Provenance. Whose weights, trained by whom, running on whose infrastructure, in which country, under which terms? A sovereign deployment that routes every inference call to a US model API is sovereign in roughly the way a locked front door is secure when the window is open.

Europe now has credible answers here. Mistral's models are built in France and can be run on European infrastructure, and the gap between frontier models and European open-weight models has narrowed far enough that model choice is no longer a capability sacrifice for most enterprise workloads. Independence at the model layer protects you commercially too: a governance platform that can only run on one provider's models has handed that provider a veto over its own roadmap, and over your pricing.

Why the governance layer is the hardest place to get this wrong

Here is the part that usually gets missed. An AI governance platform sees more than the AI systems it governs.

It holds the map: every AI system running in the enterprise, which of them touch regulated data, which have no owner, which failed their last assessment, which hold access nobody remembers approving, and the dated record of everything you have found and not yet fixed. That is a description of your weakest points, assembled by you, kept in one place, in a format designed to be read quickly, and unlike a breach, it does not need to be exfiltrated to be damaging. It only needs to be produced.

Putting that outside your jurisdiction in order to satisfy a compliance requirement is self-defeating. If you are adopting a governance tool because data was going somewhere you could not account for, the tool must not become the next place it goes.

Independence is architectural, not contractual

There is a structural point alongside the legal one. A governance product owned by the same company as the AI it inspects has a conflict of interest that no contract clause resolves. That vendor's incentive is to keep you consuming its models. Your incentive is to be able to say no to any of them, including theirs, and to move.

The concern is not that a vendor would lie to you. Serious companies do not. It is that the vendor sets the terms of the question: what counts as a violation, what gets recorded, and what the console is built to show you. Each of those is a defensible commercial decision taken in good faith. Together they mean the evidence you would rely on in an audit or a dispute has been scoped by your counterparty in it.

Independent tooling is the only version of this that survives contact with a real negotiation.

Where we stand

We built Qastel in Europe and we host it in Europe. A single EU-based provider covers the whole processing chain, so no customer data is transferred outside the EU and no third-country transfer mechanism sits between you and the service. The models Qastel uses for its own assessment work are European (Mistral) running on that same European infrastructure, so the layer you rely on to reason about a foreign dependency does not quietly create a second one. And we do not sell the AI we grade, so when an assessment is unflattering, nothing in our business model argues the other way.

Our subprocessor list, data residency statement and certification roadmap are published in the Trust Center, and a DPA is available on request. Sovereignty claims should be checkable. Those are ours: check them.

This post describes a well-documented tension between two legal regimes. It is context for a governance decision and not legal advice.

Sources

• US Department of Justice, CLOUD Act resources.
• Court of Justice of the European Union, case C-311/18 (Schrems II), 16 July 2020.
• European Commission, Implementing Decision (EU) 2023/1795 on the EU-US Data Privacy Framework, 10 July 2023.
• Regulation (EU) 2023/2854, the Data Act.
• Regulation (EU) 2016/679, the GDPR, Chapter V.