Sovereign AI

Sovereign AI Cloud Architecture and Control Requirements for Nations and Enterprises

One of the largest procurement risks in sovereign AI is remote control access to an in-country system, which doesn't show who operates or owns it.

The CNAS Sovereign AI Index counts at least one foreign partner in more than 60% of its tracked infrastructure and model projects. A foreign partner can run operations or supply the hardware behind an in-country facility.

Here, we take a sovereignty claim and break it down into four layers of control to check each separately.

The Four-Layer Sovereign AI Control Test

McKinsey's Luca Bennici splits sovereign AI into four control dimensions:

  1. Territorial: the location of data and compute
  2. Operational: control of day-to-day operation and of the on/off switch
  3. Technological and IP ownership: who owns the technology and the intellectual property
  4. Legal: the jurisdiction whose law governs the system

We build our four-layer audit from those dimensions and from Red Hat's component framing of sovereign AI infrastructure. Each layer carries its own detailed checks:

LayerChecks
Territorial• Name the jurisdiction for the facility, primary storage, backups and disaster-recovery copies.
• Check the storage and processing location of logs, telemetry and support tickets.
• Confirm residency terms appear in the contract as well as the architecture diagram.
Hardware and network• Name the suppliers of GPUs, servers and network equipment, and the export-control regime covering each one.
• Check who signs firmware and driver updates, and the operator's right to delay or refuse each update.
• Confirm how spare parts and replacement hardware reach the site over the contract term.
Orchestration and software• Identify who holds administrator credentials and their working jurisdiction.
• Check whether a vendor or provider can suspend, throttle or remotely disable the system.
• Review which software licenses depend on license servers or support access outside the country.
• Confirm the location of support and incident-response staff.
Financing and governance• Identify who holds title to the facility, hardware and licenses at each stage of the contract.
• Confirm the governing law and the venue for disputes.
• Check the lender's jurisdiction, its security over the assets and its step-in rights.
• Review the exit terms: data return, migration support and termination triggers.

Which Sovereign AI Layers Are Hardest to Verify?

Territorial checks take the least effort: a site visit confirms the facility's location, and architecture documents show the location of compute, storage and backups.

We find orchestration and financing the hardest layers to verify from a sales conversation. Their answers sit in contracts, operational runbooks and cap tables.

A deployment can sit in-country, on domestically sited hardware, under remote administration from another jurisdiction. That deployment fails the orchestration layer. Red Hat counts protection against remote disabling by a foreign entity as part of operational sovereignty.

The financing layer can fail the same way. A foreign entity can hold title to an in-country facility, carry its debt and contract under foreign law.

Sovereignty as a Spectrum Across Layers

Red Hat frames sovereignty as a spectrum with three stages:

  1. Zero sovereignty: the organization uses a hosted model service and sends data across borders, so the provider can cut off access.
  2. Partial sovereignty: the organization hosts open-weight models on regional infrastructure and relies on external hardware, such as NVIDIA chips or cloud providers in other countries.
  3. Full sovereignty: the system runs on domestic land and owned hardware, trains on local data and uses domestic power.

We apply that spectrum to each layer separately. A single aggregate score would hide the weakest layer. The same deployment can rate full at the territorial layer, partial at hardware and zero at financing.

How Nations and Enterprises Weight the Sovereign AI Layers

We see nations and enterprises weighting the same four layers differently.

A national program weights the territorial and orchestration layers most. NVIDIA lists five ingredients of a national AI strategy in a July 2026 blog post:

  1. AI imperative: domestic AI capability tied to economic growth, national security, cultural preservation and innovation
  2. AI-ready workforce: local AI skills and talent, plus basic AI literacy across the population
  3. AI models and data: models trained and fine-tuned on local data, hosted on local infrastructure and subject only to local laws
  4. AI ecosystem: local investors, developers, scientists, entrepreneurs, enterprise customers and government organizations
  5. AI factories: locally owned, operated and governed AI clouds for training and inference

NVIDIA leaves the list unranked. We rank domestic operating capability high for national programs, and operating capability sits in the orchestration layer. McKinsey's Melanie Krawina estimates that sovereign AI could add roughly €480 billion a year to Europe's GDP by the end of the decade, a stake that sits with national programs.

An enterprise program weights the financing and governance layer most, because its exposure concentrates in contractual exit terms and custody of its technology and IP. Bennici describes the enterprise benefit as reduced vendor lock-in in the same March 2026 McKinsey explainer, noting that lock-in can raise costs and limit interoperability. We read that as the reason exit terms carry the most weight for an enterprise.

Sovereign AI Projects in the CNAS Index

The CNAS Sovereign AI Index tracks 184 sovereign AI projects, with data current to June 2026, across three categories:

  1. Infrastructure (59%): AI data centers, supercomputers, GPU clusters and compute access programs
  2. Model (32%): government-backed efforts to develop or adapt foundation models
  3. Data (9%): national training datasets and data-sharing platforms

Investment concentrates in the Middle East and East Asia, which hold more than 80% of tracked, publicly disclosed investment. The 10 largest national spenders account for roughly 90% of it. Those totals include announced roadmaps as well as deployed spending, so they do not measure deployed capital.

CNAS counts more sovereign AI infrastructure announcements in the first quarter of 2026 than in 2024, so the sovereign AI label is spreading quickly.

How Dependent Are Sovereign AI Projects on Foreign Technology?

The CNAS index measures that dependency at three points:

  1. 45% of infrastructure projects use NVIDIA GPUs, so a single supplier sits behind the hardware layer of nearly half the tracked projects.
  2. Meta's Llama underpins 14 of the 25 model projects that disclose their base model, so foreign dependency reaches the model layer too.
  3. 37% of tracked projects now disclose no foreign partner, up from 31% at the index's April 2026 release.

CNAS finds that even the United States cannot fully control the inputs that power frontier AI systems. CNAS concludes that most economies will manage their dependencies, choosing which layers matter most and accepting foreign providers for the rest.

Few projects would pass a four-layer test that demands zero dependency. We use the test to map each layer's dependence on foreign suppliers and the reach of each dependency. That disclosure profile gives a national program or an enterprise a concrete basis for negotiation.

Testing a Sovereign AI Claim, Including Our Own

A generic pitch reads: "a fully sovereign AI cloud, operated in-country." We put it through the four layers:

  1. Territorial: "In-country" covers the facility only. Storage, backups and recovery copies need their own jurisdiction, set out in a data residency architecture.
  2. Hardware and network: The pitch leaves out the supplier and the export-control regime.
  3. Orchestration: "Operated in-country" places the operators. It leaves out who holds administrator access and who can suspend the system. We compare provider-operated and customer-owned systems separately.
  4. Financing: The pitch leaves out title and governing law.

Two further diligence items sit outside this test:

  1. Model-weight custody: who holds the trained model weights
  2. Training-data lineage: the origin of the training data

Zettabyte delivers through BOTT (Build, Operate, Train, Transfer), which runs in four phases:

  1. Strategic planning and design: requirement analysis, architecture blueprints for GPUs and liquid cooling, and capacity planning
  2. Construction and deployment: site buildout, hardware integration and software stack deployment through final handover
  3. Operations and optimization: Zettabyte monitors performance, maintains the systems and tunes them
  4. Customer handover: knowledge transfer, documentation and onboarding of the local team to take over the assets and operations

Under BOTT, Zettabyte runs operations until handover, and the local team runs them from that point. Each contract sets the title holder at each stage, the governing law for the handover and the handover's completion date.

We put sovereignty claims, ours included, through the four layers before accepting the sovereign label.