Sovereign AI Cloud: Provider-Operated Neocloud vs Customer-Owned Build
Each sovereign AI cloud starts with a mandate, the law, charter or policy that requires national control of the AI system. The mandate tells the buyer whether to rent GPU capacity from a provider or build and own the facility.
A sovereign neocloud is a GPU cloud for AI training and inference that a provider runs inside the mandated country. It fits a government agency facing a fixed go-live date without a GPU operations team.
A customer-owned build means a delivery partner builds and runs the facility, then hands it to the buyer. This path fits a telecom or sovereign operator that already runs data centers, or a mandate that requires the buyer to own the facility and hardware.
Three questions separate the two paths:
- Operator: who runs the GPU environment day to day.
- Access: who can reach the AI model's weights and the buyer's data before the owner takes control.
- Demand: how far ahead the buyer can forecast its GPU needs.
Both paths also raise a legal question: U.S. export rules on the weights of advanced AI models.
Which Mandate Conditions Favor a Sovereign Neocloud or an Owned Build
Read the mandate for these conditions before evaluating vendors.
| Mandate condition | Better fit |
|---|---|
| Fixed start date, without in-house GPU operations staff | Provider-operated neocloud |
| Explicit ownership mandate over the facility and hardware | Customer-owned build |
| Telecom or sovereign operator with existing data center staff | Customer-owned build, with a Build, Operate, Train, Transfer handover |
| Demand the buyer can't forecast yet, such as a pilot or a first deployment of a new workload | Provider-operated neocloud |
| Ownership required by a set date later in the program | Rented capacity first, with the handover date written into the first contract |
Some laws and operator charters require the buyer to own the facility and hardware. The buyer then picks the date it takes ownership.
Provider-operated neoclouds can meet data residency rules, which require data to stay inside the country.
Sovereign Neocloud vs Owned AI Infrastructure: Key Differences
| Criterion | Provider-operated sovereign neocloud | Customer-owned infrastructure |
|---|---|---|
| Who operates the environment | The provider | The delivery partner until handover, then the owner's staff |
| Protecting weights and data from the operator | Hardware encryption can hide them from the provider's operators | The same encryption can apply until handover |
| Adding capacity | On-demand or reserved capacity from the provider | Expansion and upgrades as a later stage of the build engagement |
| Effort to switch paths later | Moving workloads and weights to another environment | A build, operate and train cycle before the owner takes control |
What Does a Sovereign Neocloud Give the Buyer?
A provider-operated neocloud gives the buyer GPU capacity inside the mandated country without building or staffing a facility. The provider's engineers run that hardware, so they can reach the systems holding the buyer's data.
Cisco calls this the **sovereignty gap**. Confidential computing narrows that gap.
Cisco explains that trusted execution environments (TEEs), hardware-isolated areas of a processor, can keep a model's weights and training data encrypted even from the infrastructure provider.
AI models run on GPUs during training and inference, so the GPUs need confidential computing support alongside the CPUs. NVIDIA added that support with its Hopper GPUs, such as the H100.
Write the protection into the contract and the architecture. Then ask for attestation, a signed report from the hardware showing the cluster runs in protected mode.
On-demand capacity suits pilots, evaluation runs and inference that rises and falls with traffic. Reserved capacity suits steady training and inference at a known size.
Ask the provider to name, by role, who holds the encryption keys for each protected environment. Then check the contract's limits on the provider's own operators.
What a Sovereign Owner Gets From a Customer-Owned AI Data Center
A customer-owned build gives the owner's staff control of the facility after Transfer, the final handover phase. In exchange, the owner commits capital, waits through construction and trains local staff.
BOTT (Build, Operate, Train, Transfer) is the delivery model that takes a facility from construction to sovereign operation in four phases:
- Build: The delivery partner constructs the facility and integrates the GPU environment.
- Operate: The delivery partner runs the environment at production load until it's stable.
- Train: The delivery partner trains local technicians and engineers to run the facility.
- Transfer: The sovereign operator, telecom or enterprise takes over the assets and operations.
Auditors should watch the Operate phase most closely. The delivery partner's engineers hold the same access as a neocloud provider's engineers until Transfer.
Write the same encryption and key-holder terms into the contract for that period.
Do U.S. Export Rules Cover AI Model Weights?
CSIS, a Washington think tank, reports that U.S. license requirements for exporting the weights of AI models aren't in effect in 2026.
The Commerce Department runs U.S. export licensing through its Bureau of Industry and Security (BIS). BIS created ECCN 4E091, an export classification for unpublished weights of AI models trained with more than 10^26 computing operations, in its January 2025 AI Diffusion Rule.
In May 2025, BIS told its enforcement officials to stop enforcing the rule. BIS also said it would issue a replacement rule.
Check the rule's status before weights cross a border, because a replacement could restore the license requirements.
The provider holds the hardware and weights on the neocloud path. The delivery partner holds them on the build path until Transfer, then passes them to the owner.
Which Sovereign AI Cloud Path Fits Each Type of Buyer
We recommend these paths by type of buyer:
- Government agency under a deadline: Contract the neocloud path. The agency has a fixed go-live date and lacks a GPU operations team. The agency skips the build, operate and train cycle, since the provider runs the GPU capacity. On-demand capacity lets the agency start small and add GPUs as demand becomes clear. Focus diligence on the export status of the weights and the contract's limits on the provider's operators.
- Telecom or sovereign operator with existing staff: Build, with a transfer model. The operator's existing staff take over operations at Transfer.
- Enterprise with uncertain demand: Rent capacity first and consider a build after demand is clear. On-demand GPU access lets the enterprise learn its real usage before paying for a build.
- Ownership-mandated buyer: Build. A neocloud contract leaves ownership of the hardware with the provider. Read the contract for the date ownership passes, the date the delivery partner's access ends and the handover terms.
- Phased buyer: Rent capacity first and set the handover date in the first contract. The BOTT model works the same way, with Transfer as a named final phase.
Zettabyte runs both paths. zCLOUD sells on-demand, reserved and private GPU capacity in the buyer's required region.
Zettabyte runs build-and-transfer engagements through its sovereign AI data center service. TITAN designs AI data halls, including floorplans, power distribution and cooling layouts.