The sovereign cloud market did not exist five years ago. Today, every major US hyperscaler has one — or at least a product carrying that name.

• Microsoft has its Sovereign Landing Zone and EU Data Boundary,
• AWS has its European Sovereign Cloud,
• Google has its Sovereign Controls for Google Workspace.

All of them appeared in roughly the same time window, and in direct response to the same pressures: GDPR enforcement tightening, geopolitical unease sharpening after 2022, and government customers asking increasingly pointed questions about where their data actually goes and who can reach it.

The products themselves are real, and the investments behind them are substantial; but what they represent is not really sovereignty. It's a series of increasingly elaborate attempts to simulate sovereignty within architectures that were designed from the ground up for global connectivity, centralised control, and provider-managed operations.

Understanding the difference — and understanding specifically what each technique can and cannot deliver — is the most important thing any organisation with genuine sovereignty requirements can do before they have their next risk review meeting or make their next procurement decision.

There are three techniques in the hyperscaler toolkit.
They’re neither equivalent, nor cumulative. Each one addresses a subset of the sovereignty problem as the hyperscalers believe they understand it, whilst leaving many other tougher issues structurally unresolved.

Technique 1: ‘The data boundary’

The first and most widely deployed technique is the creation of a defined “data boundary”: a contractual and technical commitment that customer data will remain within a defined geographic perimeter, typically defined as a country or region.
The underlying platform continues to be operated, updated, and managed by the provider and the customer’s data, by agreement, stays within the boundary; at least mostly.

Careful reading of their Terms of Service will nearly always include provisions that allow the Cloud Service Provider (CSP), to transfer data anywhere in their infrastructure 'to deliver the service' (or similar wording). That's a red flag you should see waving.

This does however notionally address what is for many organisations the simplest regulatory compliance question — where is my data stored? — and for many commercial use cases, it addresses it adequately.
GDPR compliance, at its most basic level, requires knowing where personal data is processed and by whom. Although data boundaries may only address storage (sometimes referred to as 'data at rest'), and not 100% of the data processing, many organisations seem happy to rely on this partial commitment.

If you do not look too deeply a well-presented data boundary can appear to provide enough assurance (especially for those who want to be assured). What it does not however address is who controls the system.

The provider’s engineers, wherever they may be located in the world, will retain operational access. The provider’s update mechanisms, normally driven from HQ remain live.
The provider’s corporate legal obligations — including those owed to their home jurisdiction — remain fully intact.

In a French Senate hearing in June 2025, Microsoft France’s president acknowledged that his company could not guarantee customer data would never be transferred to US authorities under the CLOUD Act, regardless of where it was stored. This is a truth shared by all US based "Communication Service Providers", which includes Cloud companies but also many more US HQ'ed companies.

That acknowledgement was not a unique admission, but rather an accurate description of what a data boundary actually is: a constraint on data location, but not a transfer of operational or legal control to your legal jurisdiction.

Technique 2: ‘The sovereign operating partner’

The second technique goes further than just drawing a digital line on the map. Rather than simply constraining where data is held, it restructures who takes ownership of the operation of the infrastructure.

A local entity — a national partner or sometimes a dedicated subsidiary — will contractually take on ‘operational management’. In this model engineering access, support, and day-to-day operations will be delivered by staff inside the national jurisdiction.
The underlying technology still originates from the global provider, but the operating layer is mostly locally controlled.
In theory such a model is close to the minimum viable model; but in practice it has problems.

1. It is quite rare for hyperscale services to operate under in-country control; that wasn’t part of their design, and core control plane or identity services may remain centralised offshore.
2. In some cases the local partner is little more than a reseller function, or a call handling layer with little real control over the infrastructure.
3. Local operational control does not mean there is no support from overseas - there often is, in particular for 2nd/3rd line support, and sometimes for specific functions that the CSP has simply not sought to resource in-country, and
4. Where the operator is a subsidiary of the hyperscale US parent, they shall remain subject to CLOUD Act rules, breaking the mirage of sovereignty.

For most commercial deployments, this may be considered a theoretical rather than operational risk. For the most sensitive government, defence, and critical infrastructure workloads however, the risk isn't theoretical at all — it’s the precise gap that sovereign cloud exists to fill, and which adversaries and foreign governments would directly seek to exploit if the circumstances ever arose where your sovereignty is challenged.

Technique 3: ‘Fully disconnected deployment’

The third technique — and the one most recently entering the hyperscaler portfolio, as well as the one being most actively marketed as the answer to the problems the first two leave unresolved — is the disconnected or air-gapped deployment.

Here, the infrastructure is physically isolated from the provider’s cloud platform and updates and patches arrive through controlled, audited out-of-band channels rather than live connections.

Microsoft’s Foundry Local, announced in February 2026, theoretically represents this approach: large AI models running on customer hardware inside sovereign boundaries, with no persistent cloud connectivity required would be a significant step toward the disconnected operation that genuinely sensitive sovereign deployments require.

Unfortunately it’s also currently yet to represent reality. Although announced in January 2026 as having reached General Availability, it remains impossible to purchase and appears to represent Microsoft’s aspiration rather than reality.

The gap between the marketing hype and the production reality is the question that customer procurement due diligence needs to resolve; but might be poorly equipped to do in sufficient depth.
Those seeking to do so should remember that disconnected operation of hyperscale grade cloud and AI is architecturally demanding: every update cycle, every model version change, every patch must be delivered and validated through offline mechanisms. Without the infinite autoscaling of global public cloud,  resource management becomes critical, and testing and operational overheads are substantial.

The capability claims of providers who have entered this space recently — and whose core infrastructure was built for always-on global connectivity — absolutely deserve diligent scrutiny rather than acceptance at face value.

Any architecture that was cloudified for global deployment does not become a sovereign air-gapped system simply by adding a disconnected mode to the product catalogue, it requires remodelling of all connections to an internal register and the first question a customer should ask is how has this been achieved?

Quite likely the answer will mirror the responses given to Computer Weekly in May 2026 - deflection, marketing and plain denial. 

Disconnected operations can however work; in particular if presented into a hybrid of Technique Two and Three.

The Thales and Google Cloud joint venture S3NS in France is a SecNumCloud assured implementation, and a serious attempt to address the hyperscaler-into-sovereign-cloud question rather than merely rebrand around it.

It is meaningfully stronger, closes most of the support access gaps that the data boundary leaves open, and creates a local accountability structure that can engage with national regulators on their own terms.

Unfortunately the solutions in this space remain clunky, do not have all key features of the public cloud variants and consume prodigious amounts of power to run.

The wider residual problem is still grounded in corporate jurisdiction however; the technology platform itself remains at least part-owned by a US-headquartered entity.
Whether in whole or in part, that entity’s obligations to the US government cannot be extinguished by any joint-venture operating model placed on top of it.

The CLOUD Act reaches into all US-owned technology regardless of the division of operational labour, so this is close but still not fully sovereign.

What genuine sovereignty capability looks like

Genuine sovereignty is not a feature added to any globally or internationally connected platform. It's an architectural property that has to be designed in from the start:

• no persistent external dependencies; 
• update mechanisms designed for offline delivery;
• operational control that does not require the provider’s involvement;
• robust, protected and fully auditable supply chains;
• software provenance and escrow so you can be assured of access regardless of external pressures; and
• the ability to take the system completely dark — including dark from the provider — without any loss of function.

These distinctions matter most at the institutional and regulated end of the market: government, defence, law enforcement, regulated critical infrastructure, as well as any organisation whose AI systems handle data that a foreign government might find attractive, or whose operational continuity cannot depend on a provider’s willingness to maintain services under their own domestic political pressure.

For those organisations, the right question to ask of any sovereign AI provider is not ‘which techniques do you use?’ but ‘where does the service's dependency on your own infrastructure and cloud engineering end?’

The answer to that question is the sovereignty test that the marketing materials rarely address directly.

Axiom Edge’s inference infrastructure has been  built for air-gapped national deployment by default.

The question of where our dependency on our own infrastructure ends has a clear answer: it ends at the point of a customer deployment.

When the customer takes control, they assume full control and that’s what we mean when we say its sovereign.

Axiom Edge is a sovereign AI inference and cloud provider. Our infrastructure is built for national deployment, air-gapped operation and assured supply chain provenance. Learn more at axiom-edge.ai