Written by Jakub Rusinowski · Last updated 2026-07-12 · Hardware figures computed by our VRAM engine
Sovereign AI means keeping the four layers of an AI system — data, models, compute, and operational control — inside infrastructure and jurisdictions you choose, rather than depending on a foreign vendor's cloud. It moved from government rhetoric to procurement reality in 2025–2026: in Deloitte's State of AI in the Enterprise survey of 3,235 business and IT leaders across 24 countries, 77% of organizations said they now factor an AI vendor's country of origin into selection decisions, and nearly three in five build their AI stacks primarily with local vendors.
"Sovereign AI" gets used loosely, so it helps to split it into the four layers where control can actually sit. An organization can be sovereign at all four, some, or none — and most sensible strategies are deliberately mixed.
| Layer | The question | Sovereign answer | Dependent answer |
|---|---|---|---|
| Data | Where are prompts, documents, and outputs processed and stored? | Your infrastructure or a domestic processor you contract directly | A foreign provider's cloud, under its retention terms |
| Model | Who controls the weights you run? | Open-weight models you host (Qwen, Llama, Mistral, GPT-oss) | A proprietary API that can change, reprice, or be restricted |
| Compute | Whose hardware executes inference? | Owned servers or domestic/EU-hosted capacity | Hyperscaler regions governed by a foreign parent |
| Operations | Who can update, throttle, or switch it off? | Your team | The vendor's release schedule and terms of service |
The layers interact. Running an open-weight model (model sovereignty) on a US hyperscaler (no compute sovereignty) still leaves the data-and-jurisdiction question open; running a proprietary model on-premises — some vendors offer this — closes the data path but keeps you operationally dependent. The strongest position, and the one this hub's other guides cost out, is open weights on infrastructure you control: at that point all four layers answer to you.
Three pressures converged.
Procurement caught up with geopolitics. The headline number: 77% of organizations now factor an AI vendor's country of origin into selection decisions, per Deloitte's *State of AI in the Enterprise* (a survey of 3,235 business and IT leaders across 24 countries and six industries, fielded August–September 2025). The same survey found nearly three in five organizations building their AI stacks primarily with local vendors. Country of origin was a niche defense-sector concern five years ago; it is now a standard column in vendor scorecards, driven by tariff volatility, export-control whiplash, and the plain observation that AI terms of service change faster than contracts do.
Regulation attached obligations to data location. GDPR's Chapter V transfer rules already made "where does inference happen?" a legal question for EU personal data — see our GDPR deep-dive for the mechanics. The EU AI Act layers obligations on top for high-risk systems, with its main high-risk provisions applying from August 2026. And sector rules (banking secrecy, health data, legal privilege) were never comfortable with third-country processors in the first place. None of this *requires* on-premise AI — but each rule is simpler to satisfy when the data path ends inside your own rack.
The infrastructure math flipped. Sovereignty would remain a lawyer's topic if running serious models yourself were impractical. It isn't anymore: open-weight models reached business-grade quality on single-server hardware, and enterprises noticed. In Broadcom's *Private Cloud Outlook 2026* (survey of 1,800 senior IT decision-makers at enterprises across eight countries), the share using public cloud as the primary environment for production AI inference fell from 56% to 41% in one year, while 56% now run or plan production inference on private cloud. Sovereignty stopped costing a premium — at sustained volume it often saves money.
Concretely, a vendor's home jurisdiction shows up in four places:
Note what this list does *not* say: that foreign vendors are unsafe, or that domestic ones are automatically compliant. Origin is a risk dimension to weigh, not a verdict — which is exactly how the Deloitte respondents treat it: a factor in selection, alongside capability and cost.
Sovereignty is a dial, not a switch. From least to most control:
1. Frontier cloud API, default terms — maximum capability, minimum control. Fine for non-sensitive workloads. 2. Cloud API with enterprise terms — DPAs, no-training commitments, regional processing. Control by contract; the ongoing legal-review workstream is the cost. 3. Domestic/EU-hosted provider — removes the third-country transfer problem (Mistral's EU hosting is the common example); an external processor relationship remains. 4. Private cloud / hosted dedicated GPUs — your models and data on rented but dedicated hardware. Where much of the Broadcom-survey shift is landing. 5. On-premise open-weight deployment — all four layers in-house. The subject of the rest of this hub. 6. Air-gapped deployment — position 5 with the network cable pulled; for regulated verticals and genuinely sensitive corpora.
The pattern that works in practice is workload tiering: public marketing copy can use position 1; the internal assistant that reads HR documents and customer contracts sits at 4–5; the M&A data room or patient-record pipeline gets 6. Tiering also answers the capability objection — you keep frontier-API access for the rare tasks that need it, while the steady-state volume (which is where the cost lives) runs on infrastructure you control.
If those figures and the tiering logic describe your situation, the next reads are the vendor evaluation checklist if you're buying, and the hardware and TCO guides on the hub if you're building.