Four Tests for Sovereign AI Infrastructure Software

We test a vendor's claim to sell sovereign AI infrastructure software with four written questions. Staff in another country can run the software that handles logins, customer settings, usage records and administration for an in-country GPU cluster, called the control plane.

Cisco defines a **sovereignty gap** as legal control of the data without control of the hardware or software processing that data.

Send the vendor these four questions and ask for written answers:

1. Logins: the country where the system checks logins and stores administrator credentials, including the backup login path.
2. Customer isolation: whether the running software stops one customer sharing the cluster, which vendors call a tenant, from reading another customer's data.
3. Usage records: how long the vendor keeps usage and event logs, and the law behind that period.
4. Operations: who administers the control plane, from which country, and on what contract terms.

Three passing answers can't make up for one failed answer.

These questions cover the software layer. Check physical access to the building, staff clearances and facility ownership separately, using our guide to the hardware and facility layer of sovereign AI infrastructure.

Where Does Sovereign AI Software Check Logins?

A passing answer puts the identity provider, the service that verifies each user, inside the buyer's country. Administrator credentials stay in-country too, and so does the backup path for logins during an outage.

Ask the vendor to name three things in writing:

1. Login service location: the country where the login service runs, for the main path and each standby server.
2. Credential storage: the country holding administrator passwords and certificates, and the role-based access control (RBAC) rules that set which staff roles can use those credentials.
3. Backup login path: the endpoints the system switches to during an outage, and the country of each endpoint.

Don't accept encryption, certifications or a data residency promise as an answer, because they don't name the login path.

How Do You Prove Customer Isolation in a Sovereign AI Platform?

Run a controlled breach attempt during a trial, and ask for the log entry showing the software blocked the attempt. A console setting doesn't prove the running system enforces the policy.

For example, have one customer account try to read a named file in another customer's storage area. Then ask for the audit log entry that records the block, with its time and the account that made the attempt.

That log entry counts as a pass. These answers don't count as proof: a console screenshot, a compliance badge, or a line saying the platform "was designed with isolation in mind."

How Long Should Sovereign AI Software Keep Usage Records?

EU law sets a six-month minimum for keeping logs from high-risk AI systems, such as AI used in hiring, credit scoring or critical infrastructure. That duty belongs to the AI system's supplier, under Article 19 of the EU AI Act.

Article 12 requires high-risk AI systems to record events automatically over their lifetime. A different retention period can apply under other EU or national law, data protection law in particular.

The start dates moved in 2026 under the Digital Omnibus on AI, an amendment to the Act. The duties apply to hiring, credit scoring and similar uses from 2 December 2027, and to AI built into regulated products, such as medical devices, from 2 August 2028.

Ask whether the platform will keep a hosted high-risk system's logs for six months or longer. Deployments outside the EU follow other retention laws, so ask the vendor to name the law alongside the contract term.

Who Runs a Sovereign AI Control Plane, and From Which Country?

Local staff should run a sovereign control plane. Red Hat's sovereign AI architecture guidance calls for a local control plane that handles user access and resource scheduling inside the country.

Get a written operations statement that names:

1. Administrators: the team that runs the control plane, its employer and the work location of its staff.
2. Remote access: how the vendor reaches the control plane for support, and who approves each session.
3. Handover: the date and contract terms for the buyer's team taking over administration, and the vendor access left afterward.

The US CLOUD Act lets US authorities demand data held abroad by a provider under US jurisdiction. The law reaches data in the provider's possession, custody or control, regardless of the server location.

Ask what access the vendor keeps to the buyer's data after the handover date. Retained access can keep that data within the vendor's control, and within the law's reach.

Zettabyte's Sovereign AI Software and the Four Tests

Zettabyte sells software in this category and holds it to the same four questions. zPLATFORM builds in observability: identity management, usage tracking and system monitoring in one console.

zPLATFORM also meters and bills usage, applies per-customer controls and usage policies, and supports on-premises and in-country deployment. zWARE is our GPU cluster management software for deployments that require data isolation, audit trails and reliable operations.

We answer the fourth test with the Build, Operate, Train, Transfer (BOTT) model, which runs in four phases:

1. Build: Zettabyte plans and builds the data center and GPU cluster, including the software stack.
2. Operate: Zettabyte runs, monitors and tunes the system.
3. Train: Zettabyte trains the buyer's local team and documents the operating procedures and program governance.
4. Transfer: the buyer's team takes over the assets and operations.

For the facility itself, see our Sovereign AI Data Centers service.