A reference architecture for sovereign AI

Summary

Most procurement documents that ask for "sovereign AI" are asking for data residency. Residency is necessary and nowhere near sufficient. An estate whose data never leaves the country but whose models can be withdrawn, whose control plane phones home for licences, and whose operators are all foreign nationals is not sovereign in any sense that survives a bad week.

This paper defines sovereignty operationally: an estate is sovereign if it continues to function, and can continue to be improved, when every external party is unavailable. It then works through the seven dependencies that break that property, and what each one costs to eliminate.

Why residency is the wrong test

Residency answers "where does the data sit". It says nothing about:

• who can stop the system working,
• who can change what it does,
• who can rebuild it if it breaks,
• and who owns what it has learned.

A capability can pass every residency test and still be a rental. If the model is served through an API you do not control, the answer to all four questions is "somebody else".

The seven dependencies

1. Model availability

If the estate depends on a hosted frontier model, the vendor's commercial, legal or political decisions are your availability. Model deprecation is normal product management for the vendor and an outage for you.

Elimination: open-weight foundation models held in-country, with weights on media you control. This is a real capability trade — the best open-weight models trail the best hosted ones — and it is a trade sovereign programmes should make consciously rather than discover later.

2. Control plane licensing

Many enterprise platforms validate licences over the network. In an air-gapped estate that is a hard failure, and in a partially-connected one it is a lever somebody else holds.

Elimination: offline licence material with a validity window long enough to survive any plausible disruption, and a documented degraded mode when it expires.

3. Model updates and supply

If new model versions arrive only over the network, an air gap freezes the estate at its deployment-day capability.

Elimination: a physical import path with the receiving country's own inspection and evaluation process in front of promotion. The point is not that media crosses the gap — it is that the decision to promote is made in-country.

4. Training capability

An estate that can serve models but not train them is a museum. The first time a domain shifts, it is stuck.

Elimination: in-country compute sized for the retraining cadence, not just the serving load. This is the single largest cost line in a sovereign programme and the one most often cut first.

5. Evaluation

Whoever owns the evaluation suite decides what "good enough to deploy" means. If that is the vendor, the vendor is setting your safety bar.

Elimination: evaluation suites authored and owned in-country, versioned as national assets, with promotion gated on them.

6. Operations

A system that only a foreign team can run is available only as long as that team is. This is where most "sovereign" deployments quietly fail — the architecture is sound and the rota is not.

Elimination: a named local counterpart for every operating role, a written transfer plan with dates, and periodic exercises where the local team runs the estate unaided.

7. Exit

The last dependency is the one nobody writes down: what happens when the relationship ends. If the answer is "start over", every other guarantee was decoration.

Elimination: a written exit position, agreed before the first deployment, specifying exactly which artefacts transfer — weights, corpora, evaluation suites, pipeline definitions, runbooks — and in what format.

The architecture

The estate divides into four planes, and the sovereignty question is asked separately of each.

Compute plane. In-country accelerators, sized for serve plus retrain. Physical access controlled by the host. No remote management path that the host cannot sever.

Data plane. The governed corpus, entity resolution, quarantine and lineage. This is the plane that accumulates value, and it must never have an egress path. Everything downstream is reproducible from it; nothing else is.

Model plane. Open-weight base models, domain models trained in-country, versioned weights, and the evaluation suites that gate promotion. Weights are held by the host, not by the vendor.

Control plane. Orchestration, policy, routing, observability, audit. Offline-licensed, with an explicit degraded mode and no telemetry egress.

Around all four sits the operating model — runbooks, rotas, clearances and the transfer plan — which is not an architectural diagram but is the thing that most often determines whether the diagram is true.

What it costs

Sovereignty is not free and the honest numbers matter more than the architecture.

Expect a capability gap against hosted frontier models at deployment, narrowing over time as domain training compounds. Expect compute costs materially above an elastic public-cloud equivalent, because you are buying peak rather than renting it — model it against your own utilisation before committing to a figure. Expect the operating model to be the longest lead item — clearances and capability transfer take longer than hardware.

Against that: the estate keeps working, it improves on your own data, and nobody else decides when it stops.

What we recommend

Start with the data plane. It is the plane that accumulates irreplaceable value, it is the least glamorous, and it is the one that determines whether everything above it can be rebuilt. A sovereign programme that begins with GPUs and gets to entity resolution in year two has spent a year producing decisions it cannot defend.

Then write the exit plan. Before the first deployment, while nobody is under pressure, and with the specificity of a contract rather than the vagueness of a principle.