Sovereign AI without the slogans

Every cloud and AI vendor now has a sovereignty page, and almost none of them will tell you which of the four constraints they actually satisfy, because sovereignty sells better as a feeling than as a specification. It is not a feeling. It is the answer to four questions, and a yes to one of them does not imply a yes to any of the others, which is the fact that most of the slogans are written to obscure.

The four questions

The first is about data: where does it rest, where does it move, and who can be compelled to hand it over? The second is about the model: can you run it where you choose, inspect its weights, and keep using it if the vendor changes its terms? The third is about compute: whose hardware is it, in whose jurisdiction, operated under whose law? And the fourth is about operations: who holds the keys, who can push a change, and who do you call at three in the morning?

Each of those has a failure case that makes it real rather than theoretical. Data fails when a UK region turns out to be a location rather than a jurisdiction, with the bytes sitting in London while the operator is headquartered somewhere whose courts can compel access. The model fails when the provider changes its terms, deprecates the version you validated or withdraws the model from your region, and a regulated process now depends on something you can neither run nor inspect. Compute fails when the hardware your workload runs on is operated under another country's law however local the data centre's postcode, and operations fails on the night a change goes wrong and the only people who can roll it back are asleep in another time zone, bound by a support contract nobody read closely enough. A vendor's sovereignty page tends to answer the first question well, the second vaguely and the last two not at all.

The shapes the options take

There are four broad shapes, and most regulated organisations end up combining them rather than choosing one. Hyperscaler UK regions give you data at rest in the UK, excellent capability and the widest choice of models, and their limit is the operator, because a provider headquartered abroad is subject to that jurisdiction's law and no region setting changes that; for many workloads this is an acceptable and documented risk, and for some it is not, and the sovereignty page will not tell you which is which. UK-operated cloud, where infrastructure, operations and legal entity all sit in the UK, is stronger on the compute and operations questions and usually narrower on capability and model choice, and its operational maturity is something to test rather than take from the brochure. Open-weight models on compute you own or lease are the only shape that fully answers the model question, since you hold the weights, you choose where they run and no vendor can withdraw them, and the price is that you now operate a model with everything that implies for skills, evaluation and patching. And then there is hybrid, the pattern most regulated firms actually land on, with sensitive data and the decisions that touch it on the tighter shapes and everything else on the hyperscaler where capability is richest, the boundary between them written down and enforced; the design work lives in that boundary, and it is where most sovereignty programmes either succeed or quietly fail.

A ladder instead of a switch

I find it useful to grade an estate on a ladder of five levels, numbered zero to four, because it stops the conversation being binary. Level zero is a UK region setting and nothing else, so data at rest is local and every other question is unexamined. Level one adds contractual commitments on data movement and access requests and an understanding of which foreign laws apply to the operator. Level two puts sensitive workloads on UK-operated infrastructure with the operational chain of custody documented, so that you can say who can change what, from where and under whose law. Level three adds model independence for the processes that need it, meaning open-weight models you can run and inspect, validated by you and deployable on more than one provider. Level four is an owned stack: your hardware or a UK-operated lease, open weights, and UK operations end to end.

Most organisations do not need level four, and pretending otherwise is how sovereignty programmes stall. A retailer probably needs level one and good hygiene; a regulated firm handling customer decisions needs level two for those decisions and level three for any model they depend on; Defence and parts of the public sector need level four for specific systems and level two for the rest. The point of the ladder is to decide per workload, and to be able to say why.

What to demand from a vendor

One page, four headings, and a single rule: every answer must point to a contractual clause rather than a diagram. Under data, ask where it rests, where it moves including for support and telemetry, under which laws it can be compelled, and what the vendor will do and tell you if it is. Under model, ask which versions you are on, how much notice of deprecation or withdrawal is contractual, whether you can export what you need to reproduce your validation, and whether you can run the model elsewhere if the terms change. Under compute, ask who owns and operates the hardware, in which jurisdiction the operating entity sits, and who else can be compelled by whom. Under operations, ask who holds administrative access, from where and under what law, who can push a change to your environment, and what the contractual response is when something breaks at three in the morning. A vendor that answers in clauses is selling sovereignty, and a vendor that answers in architecture diagrams is selling a region.

Why this belongs to leadership, not procurement

Every step up the ladder costs something, in capability because the best models arrive on the hyperscalers first, in money because operating your own stack is not cheap, and in speed because sovereign options take longer to stand up, while every step down accepts a risk that someone will one day have to explain to a regulator or a customer. That is a trade-off between capability, cost and control, and trade-offs of that kind are not procurement decisions. Procurement can run the questionnaire, but it cannot decide that a customer-facing decision process is worth level three while a marketing workload is not, and someone senior has to own that trade, write it down per workload and stand behind it when it is questioned.

In my experience that is where sovereignty programmes actually go wrong, not in the technology, which is increasingly available, but in the absence of anyone with the authority to say how much control is enough. Give the decision an owner and the slogans stop mattering.