Sovereign AI vs Data Sovereignty: What Actually Differs

The shortest honest version of sovereign AI vs data sovereignty is one line, and it comes from Michael Feldbauer writing for an Australian audience: data sovereignty governs information, AI sovereignty governs decisions.

Melanie Krawina at McKinsey draws the same line with more precision. Data sovereignty, she says, focuses on the data sets: where the data is stored, where it is processed, and which legal jurisdiction it sits in. Sovereign AI is about who controls the intelligence built on top of them.

Her colleague Ali Ustun then supplies the consequence, which is really the whole article compressed into a sentence. You can have data sovereignty and still not have sovereign AI, because if you rely on a foreign model to process your data, it is not sovereign AI at all.

Read that slowly if you are about to sign something. The data never left the country. The decision did.

Three terms that get used as one

Most people arriving at this comparison are confused one level further down, because the vocabulary underneath data sovereignty is also a mess. Sales decks treat residency, sovereignty and localisation as synonyms. They are three different things, and only one of them is a law.

Data residency: where the bytes are

Residency is the physical location of the data, the place where the servers and data centres that store or handle it actually sit. It is a geographical category, and it is the most operationally concrete of the three. Because data moves, a single organisation's data can have several residencies at once: collected in one country, stored in a second, processed by a SaaS application whose servers are in a third.

Residency requirements often come from an organisation's own internal policy or a contract, with no regulator involved at all.

Data sovereignty: whose law reaches them

Sovereignty is the legal concept layered on top. It is the principle that data is subject to the laws of the country where it is generated or processed, including for national security purposes.

Residency usually determines sovereignty. Store data in Ireland and Ireland has legal authority over it. But residency is not the only input. Where the data was collected and who it relates to also decide which law applies, which is why GDPR can reach data about EU residents held and processed outside the EU entirely. Data can carry several sovereignties at the same time, just as it can carry several residencies.

Data localisation: what the data is allowed to do

Localisation is the most restrictive of the three and the only one that is always a government mandate: a requirement that specified data not merely reside locally but be processed locally, with cross-border transfer restricted or banned outright. China's Personal Information Protection Law and its Cybersecurity Law are the furthest-reaching regime currently in force, requiring regulatory approval before specified categories of data go abroad. Russia has comparable rules.

The compression worth keeping: residency is where the data lives, sovereignty is whose rules apply to it, localisation is what it is permitted to do.

Why a residency map stopped answering the question

Here is where the tidy hierarchy breaks, and it breaks before you get anywhere near AI.

The US CLOUD Act, passed in 2018, allows American authorities to compel US-based companies to produce data stored on servers in other countries. So data can be physically resident in a Frankfurt data centre and legally reachable by US authorities anyway, because the vendor is incorporated in the United States. Jurisdiction does not always follow geography.

Amine Raji turns that observation into the better question. A residency map answers where the bytes sit. What a regulator, a board or a serious auditor is actually asking is narrower: who can legally force someone to hand this over, under whose law, with what notice to you. He calls the answer a compulsion boundary, and it is drawn by corporate parentage and legal reach rather than by geography. Both diagrams can describe the same deployment. Only one of them answers the question you will be asked.

Two things have sharpened this recently. The EU Data Act began applying in September 2025, and its Chapter VII requires cloud and data processing providers operating in the EU to put technical, legal and organisational measures in place to prevent non-EU governments obtaining non-personal data held in the EU where that access would be unlawful under EU or member state law. That is the compulsion question written directly into European law, in open collision with the CLOUD Act. And it covers non-personal data, which is most of what an AI pipeline actually moves, after five years in which the whole argument was about personal data.

One caution from the same source, and it is worth repeating because it is the difference between an argument that survives scrutiny and one that does not. The sovereignty conversation is full of confidently stated rules that turn out to be somebody's summary of their own risk committee's decision. If you are building a business case, cite the instrument. "Our regulator told us no" is a real constraint, but it is a different claim from "the law forbids it", and the second one collapses in front of anyone who checks.

What sovereign AI adds on top

Everything so far concerns data. Sovereign AI is a larger question, and the cleanest way to see how much larger is to break it into dimensions.

The four dimensions

Luca Bennici at McKinsey defines sovereign AI as the ability of a country or organisation to build, run and govern AI in line with its own rules, security needs and values, across four dimensions: territorial, meaning where the data and compute sit; operational, meaning who can operate these systems and switch them off; technological and IP, meaning who owns the stack and the rights to the models and code; and legal, meaning whose jurisdiction applies.

Set data sovereignty against that list and the gap is immediately visible. Data sovereignty covers the territorial dimension and part of the legal one. The operational and the technological dimensions are untouched by it. You can keep every byte inside the country and hand the models, the agents and the orchestration to external providers, which is precisely the arrangement that produces data sovereignty with no sovereign AI whatsoever.

The decision layer is the new thing

The reason the old vocabulary does not stretch is that traditional systems store and retrieve, while AI systems interpret, infer and generate new information. They do it in ways that are hard to predict, based on models that are opaque or proprietary, and they can change without the customer seeing it happen.

That is why the liability argument lands harder than the privacy one. Regulations increasingly require a deployer to reproduce, explain and correct the decisions their systems make, and that capacity is structurally absent when the intelligence layer sits outside their control. What opens up is a gap between legal liability and actual influence over the system: you answer for the output, and someone else decides it.

A supply chain that changes under you

There is also a category of risk that no residency guarantee can see. Unlike traditional vendors, AI providers may change models without notice, retrain on new data and introduce behavioural changes without customer approval. Your data stayed exactly where the contract said. The thing interpreting it quietly became a different thing.

What actually leaves the boundary when you call a model

This is the concrete failure of the residency map, and it is worth doing as an exercise rather than an argument.

Ask a team what data leaves their control when they call a hosted model. They will say the prompt. Then the thread starts pulling, and Raji's inventory of what else goes is uncomfortably long: the retrieved context, arbitrary chunks of your documents chosen at runtime; the embeddings derived from those documents; the arguments passed to tool calls, and the results those tools return; the traces and logs, frequently shipped to a third SaaS vendor nobody put on the architecture diagram; and the system prompt, which is usually where the business logic lives.

Teams name the first item. The other five are the ones that were never classified, never mapped, and never covered by the residency clause, because the clause was written about storage and this is all movement.

If you want a single diagnostic to take away from this article, it is that one. Not "where is our data", but "list everything that crosses the line on one production request, and name who can compel each item".

The test that replaces the residency map

The buyer's posture has to change with the vocabulary. Stop asking a vendor whether they are compliant, which is a question with only one available answer, and ask the four that have content:

• Where does our data live?
• Who can access it, and under what legal jurisdiction?
• What cross-border flows are occurring, including for AI processing, telemetry and support functions?
• What happens to our data if we need to exit the platform?

The AI layer then adds two more, which the sources above make unavoidable. Who can change the model, and on what notice? And can a decision the system makes be explained, challenged and audited by us rather than by the vendor?

One architectural warning belongs here too. Organisations routinely try to retrofit this: build a global platform, scale it, then scramble to geo-duplicate the infrastructure when a new market demands it. That is consistently more expensive and more fragile than designing for residency, sovereignty and localisation from the start. The same is true one layer up, and more so, because an intelligence layer is far harder to repatriate than a database.

Where a small jurisdiction actually lands

Most readers of this comparison will never own the model layer. That is not a failure of ambition, it is arithmetic, and it is worth stating plainly because the consultancy version of this topic tends to assume a reader with a national budget.

What the distinction gives a smaller jurisdiction is a way to be specific about what it is buying. A residency clause is not a sovereignty clause, and neither of them is a statement about the model. Write all three separately and you get a rule that means something. Write one and call it sovereignty and you have bought a data centre location and a sense of security that does not match it. It is worth reading what sovereign AI means and what a country can realistically control alongside this, because the layers you can hold are fewer and more useful than the ones usually announced.

Two working examples, neither of them finished, both from jurisdictions doing this deliberately rather than rhetorically. A group of small island governments has been finalising a sovereign data framework for climate adaptation built so the data stays under public ownership even where the sovereign compute underneath it is leased, which is exactly the separation this article argues for, written into a design requirement. In Indonesia, Bali Province's digital residency sandbox grants a ninety day residency, a policy pilot lane and access to municipal data, so the rule meets its consequence in months instead of years. There are structural reasons islands make unusually good regulatory sandboxes, and most of them come down to that short distance.

The EX Future Summit runs a Government track over exactly this ground, sovereign compute, digital residency and the island as policy sandbox, alongside tracks on research, finance, health technology and AI ethics. It runs from 18 to 20 November 2026 as a single continuous thirty hour broadcast moving between Las Palmas in the Canary Islands and Bali, twelve hours apart, so you can join from any timezone. Online attendance is free for verified researchers, students and the EX community. If your next deliverable is a procurement rule rather than a data centre, the neighbouring question is usually what AI regulatory compliance actually demands.

FAQ

Can you have data sovereignty without sovereign AI?

Yes, and it is the normal case rather than the exception. Ustun's formulation settles it: relying on a foreign model to process your data is not sovereign AI, even though the data never left. The data layer is sovereign and the intelligence layer, where models, agents and orchestration actually sit, belongs to somebody else.

Is data residency the same as data sovereignty?

No. Residency is a geographical category and sovereignty is a legal one. Residency usually determines sovereignty, but it does not exhaust it, because where the data was originally collected and who it relates to can also decide which law applies.

Does the CLOUD Act override EU data residency?

It is not an override, it is a competing claim, and the two now collide in writing. The CLOUD Act lets US authorities compel a US-incorporated provider to produce data held anywhere, while EU Data Act Chapter VII requires providers operating in the EU to resist non-EU government access that would be unlawful under EU or member state law. Which one bites depends on your provider's corporate parentage, not on the address of the data centre.

Which one should a procurement rule specify?

Both, in separate clauses, because a residency clause is silent on the model. Specify where data may reside, which jurisdiction governs it, what may cross a border including for AI processing and telemetry, and what happens on exit. Then add the model questions: who may change it, and who can audit a decision it makes.