Sovereign AI has become a label that vendors put on a slide and buyers nod at, and both sides walk away meaning different things. For a bank, a ministry or a hospital group, the difference is not academic. It is the difference between a system you can put through an audit and one you have to explain to a regulator later.
Here is what the promise actually contains. Five parts. If a vendor cannot answer all five, they are not selling you sovereignty, they are selling you a region setting.
1. Where the weights live
The model is a file. A large one, but a file. Sovereign means that file sits on hardware you control, or a provider you have contracted under your own jurisdiction, and that you can copy it, back it up and delete it. If the model is only ever reachable through someone else's API, you do not have the weights, whatever the contract says about data.
Ask: can we take a copy of the model and run it ourselves if you disappear?
2. Where inference runs
Inference is the moment your data meets the model. Every prompt, every document, every second of a phone call passes through the machine doing the inference. That machine has to be inside your boundary: your servers, your private cloud, or a segment you control.
The trap here is hybrid setups where "the easy calls" run locally and "the hard ones" are quietly routed to a hosted frontier model. Sometimes that is fine. It is never fine if nobody told you.
Ask: draw me the path of one request, and show me every machine it touches.
3. Where the logs go
Models are usually the part people worry about. Logs are the part that leaks. Prompts, transcripts, extracted fields and error traces are the richest description of your business that exists, and they are written by default to wherever the vendor's tooling sends them. Sovereign means logs stay inside, are retained on your schedule, and can be deleted on request.
Ask: where does a transcript go after the call ends, and who can read it?
4. Who can change the model
A model that updates itself from the internet is not sovereign, however locally it runs. Updates should arrive as signed packages, reviewed and rolled out on a schedule you agree, with the previous version kept so you can go back. Our engineering team wrote up how that works inside an air-gapped network, including the parts that go wrong.
Ask: how does a new version get in, and how do we roll one back?
5. Who holds the keys
Encryption at rest is a checkbox. The question is who holds the keys, who can rotate them, and whether the vendor can be compelled to hand them over under a law that is not yours. Sovereign means the keys are yours, in your key management system, and the vendor operates without them where possible.
Ask: if a court in another country asked you for our data, what could you physically give them?
The three deployment shapes
Sovereign does not have to mean a rack in the basement. It has to mean the five answers above hold. These are the shapes we deploy, and where each one fits.
| Shape | Where it runs | Fits when |
|---|---|---|
| On-premise | Your data centre, your hardware | Regulation names the building, or the data cannot cross a network boundary |
| Air-gapped | On-premise, with no outbound connection at all | Defence, critical infrastructure, certain government and financial workloads |
| Private cloud | A tenancy in your name, in a region you choose | Residency rules are about the country, not the building |
Air-gapped is the strictest and the most work. It is also entirely doable: models do not need the internet to run, only to be downloaded, and downloading is a one-time, reviewable event.
Sovereign is not a feature you switch on. It is five questions with five answers you can show an auditor.
What regulators tend to ask
The exact rules vary by country and sector, and this is not legal advice. But the questions that come up, from data protection regimes in the Gulf to healthcare rules in the United States, tend to be the same shape: where is the data, who can access it, how long is it kept, how do you prove it, and what happens when something goes wrong.
If your AI system can answer those from its own logs and configuration, an audit is a document exercise. If it cannot, it is an argument.
The telemetry trap
One last thing to check, because it catches careful teams. Many AI tools send usage telemetry home by default: model names, error rates, sometimes prompt fragments for "quality improvement". It is often harmless. It is also, by definition, data leaving the building. Ask for the list of every outbound connection the system makes, and turn off the ones you did not ask for. An air-gapped deployment makes this moot, which is one of its quieter advantages.
If you are weighing this up for your own organisation, bring the five questions to a call. We will answer them for our own stack first, in writing.