Sovereign AI: where your agents actually run

The short answer: sovereignty is about jurisdiction and control — whose law governs your data, who can compel access to it, and whether you could keep operating if a supplier relationship changed. Data residency (where bytes are stored) is one component and the easiest to satisfy. For AI agents you have to answer it in four places, not one: where the data sits, where the model call goes, where the credentials live, and where the agent's memory and logs accumulate.

Third-party figures on this page were checked on 26 September 2026 against the publishing organisation's own release or report. Research in this field ages quickly and definitions vary between surveys — treat any undated statistic with suspicion, including on our own pages.

Why this became urgent in 2026 specifically

Three things converged. Regulation gave it a deadline: the EU AI Act's obligations arrived on a schedule, which turned an architectural preference into a compliance date. Geopolitics gave it a reason: enterprises started asking what happens if a supplier's home jurisdiction changes what that supplier may do. And the hyperscalers gave it a product line — AWS, Microsoft, Google and Oracle all shipped sovereign or boundary offerings for Europe, which made "where does this run" a question with a purchasable answer rather than an awkward one.

The market numbers follow from that. Sovereign cloud spending was reported at around $80bn in 2026, growing about a third year on year, and sovereign AI investment globally is projected above $100bn — from a base close to zero four years earlier.

Four places an agent touches, and the question for each

Most vendor sovereignty claims answer the first of these and go quiet on the rest.

1. Data at rest. Where do documents, transcripts and records physically live? This is the question everyone asks, and the one with the easiest answer.
2. The model call. When your agent reasons, whose infrastructure processes the prompt, and what is the contractual position on retention and training? An agent whose files never leave a region but whose every thought crosses an ocean has solved the easy half.
3. Credentials. An agent holds tokens to your mail, your CRM, your files. Where those are stored and who can decrypt them is a sovereignty question with an incident-response dimension attached.
4. Memory and logs. The agent's accumulated context — what it learned, what it did, who approved it — is often the most sensitive artefact of the lot, because it is a distillation of everything else. It is also the one most likely to be sitting in a vendor's shared database without anyone having asked.

Six questions worth putting to a vendor in writing

1. In which jurisdiction does the compute run, and can I choose it? A region list is not a commitment unless your tenancy is pinned to one.
2. Where does the model inference happen, and under what retention terms? Ask separately for the default model and for anything the platform calls internally — summarisation, embedding, classification.
3. Where do you store the credentials my agents use, and who can read them? The answer should involve encryption at rest and a scope limited to the agent, not the account.
4. Where does the agent's memory live, and can I export and delete it? Export is the test of whether you own it. Deletion is the test of whether they meant it.
5. What happens to all of the above if I stop paying? A clean answer here is the difference between a supplier and a dependency. We wrote about the general case in platform lock-in and what it costs.
6. Can I run this on infrastructure I control, and what do I lose if I do? Even if you never exercise it, the shape of the answer tells you how the product is built.

Self-hosting is a means, not the goal

A common move is to jump straight to "we will self-host everything". Sometimes that is right. Often it substitutes one risk for another: an agent stack running on a server nobody patches, with backups nobody tested, is less resilient than a managed deployment in the correct jurisdiction. The honest comparison includes the operational load, which is the part most plans underestimate — what self-hosting an agent really costs works through it.

The useful middle is a deployment you control, in a region you chose, that you could move. Control over configuration, credentials and data, without owning the pager. That is also what makes the answer defensible to an auditor: not "we run it ourselves" but "here is where each of the four things lives, and here is how we would change it".

The sovereignty question agents raise that models do not

A model that answers a question and forgets it poses a data question. An agent that holds credentials, takes actions in your systems and accumulates a record of what it did poses an operational one: if access to the platform ended tomorrow, what would you have lost, and what would still be running with your keys?

That is worth answering before it is urgent. The agents whose answer is comfortable tend to be the ones where state and credentials were kept in one place the customer controls from the beginning — not the ones that got migrated there later.

For the regulatory backdrop this sits inside, see the EU AI Act and AI agents and the US state AI law patchwork.