Sovereign AI is not where your data sits. It is what keeps working when the connection is cut

Compare two ways of buying “sovereign AI”.

In the first, the model runs in a cloud region in your country, your data is stored there, and the contract says so. In the second, the model runs on hardware you control, disconnected from the internet, and keeps answering if the vendor’s network, the vendor’s staff or the vendor’s government become unavailable for a month.

Both are sold under the same word. They are different products, and on October 20 the two largest enterprise clouds made the difference concrete.

What the two announcements show

Google made Gemini 3.5 Flash generally available in Google Distributed Cloud air-gapped, its disconnected deployment, along with NVIDIA HGX B300 systems. Enterprise search with multimodal retrieval on GDC is in preview, and open models such as Gemma and Mistral are supported. Google calls itself one of the first hyperscalers to bring a frontier model of this kind to air-gapped environments.

Microsoft described a broader program across public, private and partner clouds. Some of it is available now: confidential VMs on Azure Local, external key management in which the root key sits in customer-owned hardware, SQL Server on Azure Local for connected and disconnected use, and a public preview for moving workloads between connected and disconnected operation. For EU and EFTA customers, Data Guardian (oversight of qualifying Microsoft engineer access by an EU partner) is rolling out and the Production Touch Ledger (a tamper-evident record of that access) is in phased rollout. The AI pieces come later: Foundry Local for connected and disconnected AI on Azure Local and GitHub Enterprise Local, with Copilot running on locally hosted models, are both due to become generally available at Ignite, in November. A Sovereign Control Panel, which reports on sovereignty posture and continuity readiness, enters public preview then too.

The facts matter less than the vocabulary. Neither company leads with data residency. Both lead with operations: what runs disconnected, who can reach the systems, who holds the keys, what keeps working.

Our view: location is the least informative question

This is our position, and it is a view rather than a fact: for most regulated enterprises, “where is the data stored” has become the least informative sovereignty question, because every large vendor can answer it the same way. The useful questions are about control in operation. They extend the argument we made when we said custody is the first question: it is not enough to know where each copy lives; you need to know what happens to it when something goes wrong.

Sovereign AI has also grown down the stack, as Palantir and Armada showed, and into the power supply, as Microsoft’s exit from an Essex data center reminded everyone. A model that runs locally on hardware that cannot be powered, updated or repaired is not sovereign either.

Seven questions to test any offer

What to ask before calling an AI deployment sovereign

Question	A strong answer	A weak answer
1. Where does inference run?	On infrastructure we control, near the data	In-country region, operated by the vendor
2. Who holds the model weights?	Deployed locally, versioned by us	Called over an API we cannot inspect
3. Where do indexes and embeddings live?	Built and stored locally	Built by a cloud service, even if source data stays
4. Who holds the root key?	Our hardware or a trusted third party	The vendor's key service
5. Who can reach production, and what is recorded?	Approved per session, logged where we can read it	Vendor policy, summarized in a report
6. How do updates arrive when disconnected?	Signed bundles we load and test	Assumes a connection
7. What still works after 30 days offline?	Tested in a drill, with the list written down	Not tested

A few notes on applying it.

Question 3 is where most “local” AI leaks. Retrieval quality depends on embeddings and indexes. If they are built by a cloud service, the content has left even when the source records have not. Google’s air-gapped enterprise search is still in preview; check where its embedding models run before relying on it.

Question 6 is the hidden cost. A disconnected model is a frozen model. Security patches, model versions and evaluation sets all have to cross the gap through a controlled process, and every crossing is a change that needs testing. Teams that have not run open weights themselves tend to underestimate this.

Question 7 should be a drill, not a slide. Microsoft’s Control Panel promises a continuity readiness view; useful, but the evidence that counts is a test in which the connection was actually cut and someone wrote down what stopped.

Not every workload needs every answer. A coding assistant for internal tools, an agent that reads clinical trial data and a system that serves a defense ministry need different scores. The framework is for deciding which questions matter per workload, then paying only for those. Disconnected AI costs real money in hardware, operations and slower updates, and it does not by itself make anything compliant.

What would change our mind

If vendors start offering contractual, audited guarantees on operator access and continuity for their regular cloud regions, guarantees that regulators accept as equivalent to local control, the case for disconnected deployment would shrink to the most sensitive workloads. Microsoft’s EU access controls are a step in that direction. Until they are tested in practice, the question to ask of any sovereign AI offer is the one in the title: what keeps working when the line is cut?