Is sovereign cloud actually sovereign? Hyperscaler regions examined for regulated buyers

A vendor-run sovereign region is only as sovereign as its control plane, and by that measure most are not. If a hyperscaler holds the encryption keys, runs the control plane and employs the administrators, that region remains reachable by the operator's home-country law, including the US CLOUD Act, wherever the servers physically sit. True sovereignty means a single party holds the hardware, the keys and the network perimeter, and can prove it offline without calling home to a vendor.

The question matters in 2026 because sovereign-cloud marketing has outrun sovereign-cloud architecture. Microsoft, AWS and Google now publish sovereign-region pages, and regulated buyers in banking, healthcare, defence and government are asking a sharper question: not where does the data live, but who can be compelled to produce it. The honest answer turns on control, not geography.

What does a sovereign cloud actually promise?

Sovereign-cloud offerings usually promise three things: data residency in a named country, local support staff, and contractual commitments about access. These are real improvements. They are not the same as sovereignty. Residency governs where bytes rest. Sovereignty governs who can lawfully compel their disclosure. A region can satisfy every residency clause and still sit inside a foreign legal perimeter, because the operating company, not the postcode, determines jurisdiction.

Which law makes vendor-run sovereignty fragile?

The US CLOUD Act, passed in 2018, is the load-bearing fact. It allows United States authorities to compel a US-headquartered provider to produce data within that provider's possession, custody or control, regardless of where the data is stored. A European sovereign region operated by a US company is still operated by a US company. Local incorporation, local staff and local data centres do not remove the parent from CLOUD Act reach. This is not an accusation against any vendor; it is how the statute is written and how corporate control is read. The consequence is simple: if a foreign entity can be served an order and technically comply, residency alone does not deliver sovereignty.

What does real sovereignty require in architecture?

Real sovereignty is an architecture, not a certificate. Three conditions have to hold at once:

• The operator holds the hardware. Compute runs on machines the regulated entity owns or fully controls, not leased slices of a vendor estate.
• The operator holds the keys. Encryption keys are generated and held by the operator, with no vendor-held root and no lawful-access path to plaintext.
• The operator holds the perimeter. The network boundary is closed to outbound calls, so nothing can egress to a vendor control plane.

If any one of the three sits with an outside party, that party is a point of compulsion, and the claim of sovereignty is partial.

How do you test whether a region is truly sovereign?

We use a single question as the test, and buyers can put it to any vendor: if the operator's home government served a lawful production order tomorrow, could the vendor technically comply without the regulated entity's consent? If the answer is yes, the workload is not sovereign, whatever the region is called. For procurement: name every party that holds a key, runs the control plane or can push a software update, then count the jurisdictions those parties answer to. Sovereignty is the case where that count is one, and it is yours.

“Sovereignty is not a data-centre postcode; it is the answer to one question about who can be compelled to hand over the keys.”

How does a Sovereign Intelligence Operating System meet the test?

Mickai is a Sovereign Intelligence Operating System, a SIOS, built to pass that test by construction. It runs offline on operator-owned hardware. Sovereign models run in place, so teams gain machine intelligence without sending prompts to ChatGPT, Claude or Gemini, none of which regulated buyers can lawfully feed with controlled data. Identity is hardware-attested and bound to the audit chain. The perimeter is a zero-egress inbound design: work comes in, nothing phones home. Every action is cryptographically sealed into a post-quantum signed audit ledger, and sensitive decisions can be put to cross-model consensus rather than a single opaque model. The architecture is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending, never granted or patented.

Which rules make this necessary now?

Several regimes converge on the same requirement, to know and control who can reach regulated data:

• DORA has applied to EU financial entities since January 2025 and holds firms responsible for concentration risk and oversight of critical technology providers.
• NIS2 raises security and accountability duties across essential and important sectors.
• GDPR still governs international transfer and lawful-access exposure.
• ISO/IEC 42001 sets a management-system standard for AI governance that auditors increasingly expect.
• FIPS 204 and FIPS 203 define the post-quantum signature and key-encapsulation standards that a durable audit trail should already use.

On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moved to 2 August 2028 and Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve.

What can an auditor actually check?

An auditor needs checkable evidence, not a brochure. The audit ledger verifies offline, because the signatures validate without contacting any vendor service. Network capture shows no outbound traffic. Key-custody records show no vendor-held root. Device attestation binds each action to a known machine. The test is falsifiable: if an assessor can force a call home, verify a signature only against a remote service, or find a key the operator does not hold, the claim fails on the spot.

Frequently asked questions

Is a hyperscaler sovereign region subject to the US CLOUD Act?

If the region is operated by a US-headquartered company, then yes, in principle. The CLOUD Act reaches data within a US provider's possession, custody or control, regardless of storage location. Local incorporation and EU data centres do not by themselves remove the parent company from that reach. Sovereignty from CLOUD Act exposure requires an operator that is not compellable under US law and cannot technically comply.

Does data residency in the EU make a cloud sovereign?

No, not on its own. Residency guarantees where data is stored, not who can be compelled to disclose it or who technically holds the keys. A workload can meet every EU residency clause and still sit inside a foreign legal perimeter if the operating company is foreign-controlled. Residency is useful and necessary for some rules, but it is not sufficient for sovereignty.

Can regulated firms use ChatGPT, Claude or Gemini for controlled data?

Generally not for controlled or regulated data. These public cloud AI services process prompts on vendor infrastructure outside the customer's perimeter and legal control, which conflicts with data-protection, sector and sovereignty requirements. The sovereign alternative is to run models offline on operator-owned hardware so that no prompt leaves the perimeter. That is the design a SIOS is built around.

What is the difference between sovereign cloud and a sovereign operating system?

Sovereign cloud typically means a vendor-operated region with local residency and support, while the vendor keeps the control plane, keys and staff. A Sovereign Intelligence Operating System runs on hardware the operator owns, with keys, perimeter and audit trail held by the operator. The difference is where control sits, and control is what a production order tests.

How do you prove sovereignty to an auditor?

Show offline evidence rather than assurances. Verify the audit ledger's post-quantum signatures without any vendor service, capture network traffic to demonstrate zero egress, produce key-custody records showing no vendor-held root, and show device attestation binding each action to a known machine. If every check passes without a call home, the claim holds. If any check needs a vendor, it does not.