Sovereign AI Infrastructure: Ownership, Local Operations, Data Location and Vendor Independence
A country can buy thousands of GPUs and still lack sovereign AI infrastructure. The buyer also has to own the system, keep its data in the country, run it with local staff and keep the option to switch hardware vendors.
Before buying, governments and companies compare written proposals from vendors. We check each proposal against four control points, the things a buyer has to verify in a vendor's answers.
A proposal can pass three control points and fail the fourth, so each one needs its own evidence.
What Are the Four Control Points of Sovereign AI Infrastructure?
The four control points are ownership, local operations, data location and vendor independence:
- Ownership: who owns the hardware, the software licenses and the data after delivery, and who controls the supply of spare parts and upgrades.
- Local operations: who runs the system after handover to the buyer.
- Data location: where workloads such as model training run, and who holds the admin accounts on the system.
- Vendor independence: whether the network and software run on more than one GPU vendor's hardware.
Oracle's guide to sovereign AI also covers regulations, infrastructure choice, data residency, data privacy, legal controls and AI security. Residency and privacy both come down to where data runs and who can reach the data, so we treat them as one control point.
Regulations and legal controls belong in the buyer's legal review, so we leave them out of the infrastructure test.
| Control point | Answer that passes | Answer that fails |
|---|---|---|
| Ownership | The contract transfers the servers, software licenses and data to the buyer on a named date | The vendor keeps ownership and sells the buyer capacity |
| Local operations | A handover plan names the local staff to be trained and the date they take over | The vendor's engineers keep running the system after go-live |
| Data location | The proposal names the facility and lists who holds admin accounts | The proposal names an in-country region and leaves admin access unstated |
| Vendor independence | A named open protocol and a supported-hardware list with two or more GPU vendors | A brochure line about openness, without a protocol or hardware list |
Who Owns the AI Infrastructure After Handover?
The buyer owns the AI infrastructure when the contract transfers the servers, the software licenses and the data to it on a named date. If the vendor keeps ownership of the servers or the licenses, the buyer is renting capacity.
Start with ownership, because a buyer can't hand operations to its own staff or switch hardware vendors on servers that belong to someone else. The contract should also say who buys spare parts and upgrades after handover.
Who Operates the AI Infrastructure in Year Three?
The buyer's own staff should run the system after a named handover date, with their training written into the contract. A buyer without trained staff depends on the vendor's engineers.
Nils Muthmann leads sustainability programs at T-Systems, Deutsche Telekom's IT services company. He argues in a T-Systems post on sovereign AI that sovereignty rests with "those who can operate and advance the underlying infrastructure."
Zettabyte builds handover training into its build, operate, train and transfer (BOTT) model. The final phase trains the local team to take over the assets and operations.
Ask the vendor for the handover date, the roles to be trained, the number of staff in each role and a copy of the written operating procedures.
Where Do Sovereign AI Workloads Run, and Who Holds the Admin Accounts?
The proposal should name the facility where workloads run and list who holds admin accounts on the system. Oracle offers two setups that keep workloads in a known place:
- Dedicated region: an Oracle cloud region installed inside the customer's own data center.
- Isolated cloud region: a cloud setup that runs disconnected from the internet.
The buyer still needs to know who can log in to those regions. Oracle's guide suggests customer-provided encryption keys or support staff with security clearance to limit that access.
Ask for the list of accounts with admin rights, with each holder's employer and country.
Can the AI Infrastructure Run on More Than One GPU Vendor?
A proposal shows vendor independence when it names an open protocol or lists supported hardware from more than one GPU vendor. AMD describes its AI offering for Europe as "designed for interoperability, transparency, and freedom from vendor lock-in" on its sovereign AI page.
The page doesn't back that line with a named protocol or a supported-hardware list, so a buyer can't check the claim.
Zettabyte's zFABRIC network uses RoCEv2, an open standard that carries GPU-to-GPU traffic over ordinary Ethernet. The zFABRIC page lists support for NVIDIA, AMD and other accelerators.
That covers the network layer. Ask which GPU programming toolkit the cluster software needs, such as NVIDIA's CUDA or AMD's ROCm, and whether the software supports both toolkits.
Testing a Sovereign AI Infrastructure Proposal
Put the four questions to each vendor in writing, and compare the answers with the table above.
Zettabyte's Sovereign AI Data Centers service gives government customers ownership of the hardware, software, data and supply chain through the BOTT model. zPLATFORM is our GPU management software.
zPLATFORM adds identity management, usage tracking and tenant controls, which separate teams that share the same GPUs. Buyers should test our proposal against the same four questions.
Sovereign AI FAQ
Is Sovereign AI the Same as Data Sovereignty?
Sovereign AI includes data sovereignty. Data sovereignty covers where data is stored and which country's laws apply to the data.
Oracle's FAQ describes sovereign AI as control of the AI systems themselves, including the data they use, inside one jurisdiction. For infrastructure buyers, sovereign AI also means owning the compute, staffing its operation and limiting dependence on one hardware vendor.