Data residency, localisation and sovereignty are three different things

These three appear in the same sentence in most requirements documents and impose materially different obligations.

Data residency

Data is stored in a specified geography.

The weakest of the three. It constrains storage location and typically says nothing about processing, about who can access it, or about who controls the system.

Data can be resident in a country and readable by an operations team on another continent, under another jurisdiction's legal compulsion. That is compatible with most residency clauses as written.

Data localisation

*Data is stored and processed in a specified geography, and generally may not leave it.*

Stronger, and where most regulated enterprise requirements actually sit. It constrains the processing path, which for AI systems means inference and training must happen in-region — a much more demanding constraint than storage.

Common gaps to check: does it cover backups, does it cover logs and telemetry, does it cover the vector index, and does it cover the model's context window during inference.

Digital sovereignty

The capability remains under the jurisdiction's control, including when external parties withdraw.

This is a control question, not a geography one. The test: does this keep working, and can it keep improving, if every foreign party becomes unavailable?

That implicates model availability, control-plane licensing, update supply, training capability, evaluation ownership, operational staffing and exit. Geography is a small part of it.

Questions that establish which you need

Ask the risk owner:

1. Where must the data be stored? — residency.
2. Where must it be processed? — localisation.
3. Who may access it, and under whose legal compulsion? — this usually reveals that the requirement is stronger than the document says.
4. What happens if the vendor withdraws the model? — sovereignty. If the answer is "we would have a problem", it is a sovereignty requirement regardless of what the heading says.
5. Who decides what is safe to deploy? — evaluation ownership, and almost never asked.
6. Could you run this without us in ninety days? — the honest sovereignty test.

What each costs

Residency is close to free in any multi-region platform.

Localisation costs the elasticity of a global estate: you cannot burst into another region during a spike, and you may need a dedicated deployment per jurisdiction.

Sovereignty costs the most — a capability gap against hosted frontier models, compute priced at peak rather than rented, and an operating model with local staffing and capability transfer. Model the premium against your own utilisation rather than against a published multiple.

Buying sovereignty when you needed localisation is one of the more expensive mistakes available in this market. Buying residency when you needed sovereignty is the cheaper mistake that surfaces at the worst possible moment.

A note on multi-jurisdiction estates

Organisations operating across jurisdictions need routing that enforces this per request, from attributes on the request, with a hard failure when no compliant route exists.

The design decision to make deliberately, in advance: if the compliant endpoint is unavailable, does the request fail or fall back? For localisation and sovereignty requirements the answer is almost always that it fails — and that has to be built, because the convenient default is the other one.