Sovereign AI in the United States: what sovereignty means when the hyperscalers are domestic
When the hyperscalers are domestic, US sovereignty stops being about foreign subpoena and becomes a question of concentration, agency isolation and export control.
For US buyers sovereignty is about control, not jurisdiction: the CLOUD Act reach is domestic, so concern shifts to concentration, agency isolation and export control.
This matters in 2026 because US agencies and regulated enterprises are pushing generative AI from pilots into production, and the sovereignty conversation imported from Europe does not translate cleanly. The public cloud AI services most teams reach for first are excellent for open work but cannot lawfully hold the most sensitive classified or export-controlled data. Getting the framing right is now a procurement decision, not a debate.
What does sovereign AI mean for a US buyer?
For a US buyer sovereign AI means running sensitive workloads in an isolated, operator-controlled enclave that meets export and classification rules without concentrated single-vendor dependency.
The overseas sovereignty debate leans on a single fact: the US CLOUD Act can compel a US-based provider to disclose data regardless of where the servers physically sit. For a buyer in London or Frankfurt that is foreign reach. For a buyer in Washington or Austin the same provider answers to the same government, so the exposure is ordinary domestic legal process. The question therefore relocates. It is no longer who can subpoena the data but whether the most sensitive workloads can run isolated, export-compliant and free of a single concentrated dependency. That is a matter of architecture, not nationality.
If the CLOUD Act reach is domestic, why still worry about jurisdiction?
Jurisdiction still matters when a US firm serves foreign customers, but for domestic sensitive data the CLOUD Act is ordinary legal process, not foreign reach.
Jurisdiction has not vanished, it has narrowed. A US company that serves European customers or runs European operations still sits under GDPR, the transfer regime shaped by the Schrems rulings, DORA, which has been in force since January 2025, and NIS2 for essential and important entities. For those flows the CLOUD Act is exactly the friction a European counterparty worries about. But for domestic classified or export-controlled data held on home soil, the CLOUD Act is not a foreign-reach problem at all. Reading it as the core US argument imports a concern that does not apply and misses the ones that do.
How does the US framing differ from the UK and EU?
In the UK and EU the argument is jurisdiction and residency; in the US it is concentration, classification, export control and procurement, not foreign subpoena.
The frameworks rhyme but the pressure points differ. In Europe the argument is residency, transfer and timetable: the high-risk Annex III obligations of the EU AI Act, once due 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. In the United States the levers are concentration, classification, export control and procurement accreditation. The table below maps the same four concerns across both framings.
| Concern | UK/EU framing | US framing |
|---|---|---|
| Jurisdiction | CLOUD Act lets a foreign government compel a US provider, even for local data | Same reach is domestic legal process, so worry is isolation not subpoena |
| Concentration risk | Reliance on a few US hyperscalers is a sovereignty and trade concern | A few domestic providers concentrate compute, so single-vendor failure dominates |
| Classification and export control | GDPR, residency and transfer rules drive the argument | ITAR, EAR and classification bar sensitive data from commercial cloud AI |
| Procurement | Public-sector rules favour local hosting and auditable supply chains | FedRAMP, impact levels and air-gap accreditation set the bar, not residency |
Is concentration among domestic hyperscalers a real risk?
Yes: a small number of domestic providers concentrate compute, so a single vendor outage, dependency or control-plane change becomes systemic risk for agencies and enterprises.
The domestic hyperscalers, AWS GovCloud, Azure Government and Google Distributed Cloud, are the right choice for elastic, accredited workloads at national scale, and they carry real accreditations that took years to earn. The sovereignty concern is narrower and sits alongside them. When a handful of providers concentrate the nation's compute, a single control-plane change, dependency or outage can propagate as correlated, systemic risk. Agencies and regulated enterprises want the sensitive tier of their estate to survive that, running on infrastructure they own and can verify without asking anyone's permission.
How do export controls and classification change the picture?
Export regimes such as ITAR and EAR, plus classification handling, keep certain data and model weights out of commercial cloud AI, forcing isolated on-premises processing.
Export-control regimes govern more than hardware. Technical data, source code and, increasingly, model weights can fall under ITAR or the EAR, and classified material must stay within accredited, isolated systems. Routing any of that through a commercial cloud AI service risks spillage and a control violation. ChatGPT, Copilot and Gemini are outstanding for drafting, research and everyday productivity, and most teams should keep using them for open work. They are simply the wrong destination for classified or export-controlled inputs, which need processing that never leaves a boundary the operator controls.
How does a Sovereign Intelligence Operating System address this?
A Sovereign Intelligence Operating System runs offline on operator-owned hardware behind a zero-egress perimeter, with hardware-attested identity and post-quantum signed audit for every action.
Mickai is a Sovereign Intelligence Operating System, a SIOS, built and live, running offline on operator-owned hardware with every action cryptographically sealed. A zero-egress inbound perimeter means data enters and is answered without a path out. Identity is hardware-attested and bound to the audit chain, so every actor is provably who they claim to be. The audit ledger is signed with FIPS 204 ML-DSA and FIPS 205 SLH-DSA, while FIPS 203 ML-KEM handles key encapsulation and never signs, giving a tamper-evident record that survives the arrival of quantum computing. Fifty brains, twenty-five domain and twenty-five operational, run under cross-model consensus so no single output is trusted unchecked. The substrate design is covered by 104 filed UK patent applications and 2,340 claims, owned by Mickai LTD (Companies House 17166618), filed and patent pending.
“In the United States the sovereignty question is not whose government can reach the data but whether the workload can run isolated, export-compliant and free of any single concentrated dependency.”
Frequently asked questions
Is the CLOUD Act really irrelevant for a US company?
Not irrelevant, but relocated. For domestic sensitive data held on US soil the CLOUD Act is ordinary legal process rather than foreign reach. It matters most for US firms that serve European customers or run European operations, where a counterparty treats it as an exposure. The practical answer for the sensitive tier is isolation, not choice of jurisdiction.
Can I put ITAR or classified data into ChatGPT or Copilot?
No. Those cloud AI services are built for open, unclassified work and are excellent at it. Export-control regimes such as ITAR and the EAR, together with classification handling rules, keep technical data, controlled source code and classified material out of commercial cloud processing. That data needs an isolated environment the operator owns and can attest.
Does sovereign AI mean giving up the public cloud entirely?
No. The sensible pattern is hybrid. Public cloud and public cloud AI stay in place for elastic, open work where they are the right pick. Only the classified, export-controlled and mission-critical tier moves to an isolated, operator-owned substrate. Sovereignty is applied where it is required, not everywhere.
How is a signed audit ledger different from ordinary cloud logs?
Cloud logs record events inside a provider's trust boundary and can be altered by whoever controls that boundary. A post-quantum signed ledger is tamper-evident and offline verifiable: each entry is signed with FIPS 204 and FIPS 205, so the record can be checked independently, without trusting the operator or any provider. That is evidence, not just telemetry.
How does an isolated substrate stay current if it never connects out?
Through a controlled, verified update channel rather than an open link. New model weights and corpus material are validated, checksummed and admitted by the operator, so the substrate keeps improving without ever opening an outbound path or trusting an external service. Currency and zero-egress are not in conflict.