Illustration: Sovereign AI infrastructure, minus the press release “Sovereign AI” appears in a great many government and enterprise strategies and means different things in almost all of them. Before designing anything, it is worth separating the requirements it bundles, because they have different costs and some of them are much easier than others.

Four distinct requirements

Data residency. The data must be physically stored within a jurisdiction. The most common requirement and the most tractable: it is a location decision about storage, satisfied by a data centre in the right country.

Operational sovereignty. Not only is the data here, but it cannot be accessed by people or entities subject to another jurisdiction’s legal compulsion. This is stricter and it constrains who can operate the platform, not only where it sits. A local region of a foreign-owned provider satisfies residency and does not necessarily satisfy this.

Technological independence. The capability continues to function if a foreign supplier withdraws. This reaches into hardware supply, software licensing, model weights, and support contracts, and it is the hardest of the four.

Capability ownership. The ability to build and adapt models locally rather than only consume them. This is an economic and skills objective more than an infrastructure one, though infrastructure follows from it.

Most organisations saying “sovereign” mean the first, occasionally the second, and are surprised by what the third and fourth cost.

What each one implies

Residency is a site selection and a contractual commitment. Verifiable, achievable, often available from existing providers.

Operational sovereignty pushes you toward infrastructure you operate, or a provider incorporated locally, with encryption keys held by you and a clear answer to who can compel disclosure. Legal review is part of the architecture here.

Technological independence means owning hardware rather than renting it, preferring open model weights you hold locally over API access to a service, and having a support arrangement that survives a supplier relationship ending. It is expensive and it is the correct requirement for genuinely critical national functions.

Capability ownership is a people question. Infrastructure without the team to use it is a building.

The practical architecture

For most organisations with a real residency or operational requirement, the shape that works is: accelerators you own, in a facility in-country, running open-weight models you hold locally, with your own key management, operated by staff employed locally.

That is achievable at modest scale, and the falling cost of capable open models has made it far more achievable than it was two years ago. You do not need a frontier training cluster to run useful inference on your own data in your own country.

The trap

Building a large training capability because the strategy document says sovereign, when the actual requirement is that data does not leave the country during inference.

Those are wildly different investments. The first is a national-scale programme. The second is a rack of servers and a team.

Read the requirement carefully, name which of the four it is, and size to that. The gap between the sovereignty most organisations need and the sovereignty they describe in slides is usually one or two orders of magnitude in capital.

The question I would ask first

What specifically are you trying to prevent? A foreign government compelling access? A supplier withdrawing service? Data crossing a border in transit? Reliance on a capability you cannot reproduce?

Each has a different answer, and the answer is cheaper when the question is specific.