Sovereign AI is a placement problem

Governments are investing in sovereign AI at scale. The European Commission's AI Continent Action Plan, adopted in April 2025, set out a network of AI factories and planned AI gigafactories with around 100,000 advanced chips each. On 30 July 2026 the EuroHPC Joint Undertaking opened the call for up to seven gigafactories in at least seven Member States, alongside 19 AI factories already under way. Similar programmes are running in the Gulf, India, Japan and elsewhere.

Building capacity is necessary, but it does not make AI sovereign on its own. A national GPU cluster still serves foreign workloads if routing sends them there. An operator in your jurisdiction can still be compelled by another state. Weights hosted locally still answer to whoever holds the keys. Sovereignty is decided one request at a time, by three properties of the infrastructure: placement, key control and proof.

Placement: where each request actually runs

The first question is literal. When a citizen, a hospital or a ministry sends a prompt, which machine processes it? Modern inference stacks make that hard to answer. Requests pass through gateways, routers, load balancers, caches and fallback providers, and each layer has its own idea of a good destination. A sovereign deployment that falls back to a foreign region under load is only sovereign when it is quiet.

Placement has to be a hard constraint that the routing layer enforces before it scores price or latency. It should fail closed: if no permitted machine can serve the request, the caller gets an explicit refusal, not a quiet reroute. The same rule must apply to everything that carries request data later, including standby replicas, KV-cache checkpoints and streaming failover.

This changes the policy conversation. Instead of asking "is there a sovereign cloud?", a buyer can ask "can this platform prove that it refuses to serve my request anywhere else?" The second question can be tested.

Keys: who can act as the machine

The second question is about control. Data in a jurisdiction is only as sovereign as the keys that decrypt it, sign for it and authorise access to it. Two kinds of keys matter most.

Identity keys. These let a machine sign receipts, join a network or receive payment. If such a key sits in a file, anyone who copies the file, whether through a backup, a stolen disk or a container escape, becomes that machine. Sovereign infrastructure should keep identity keys in hardware: a TPM, a Secure Enclave, a passkey or an equivalent element, sealed so they never exist as plaintext on disk.

Operator keys. These are the credentials that let someone administer a node, change its configuration or move its funds. When those keys sit with a foreign provider's control plane, the deployment's sovereignty depends on that provider's legal exposure. The US CLOUD Act, passed in 2018, is the example European buyers raise most often. It concerns electronic evidence held by US-based providers wherever the data is located. The EU-US Data Privacy Framework addresses transfers of personal data. It does not change who holds an operator's keys.

The practical test: list every key that can make a node act, and name the jurisdiction and the person or organisation that holds it.

Proof: what can be shown afterwards

The third question is evidence. A regulator, an auditor or a court will eventually ask where a specific output came from. "Our provider says so" is a weak answer. A strong answer has four parts:

• A signed record per request, naming the model and weights hash, the serving machine and a hash of the input and output.
• A declared jurisdiction bound to that machine and signed in advance, so it cannot be chosen after the fact.
• A measured environment where the workload is sensitive. Confidential-computing hardware such as Intel TDX, AMD SEV-SNP or NVIDIA GPU confidential computing can attest that a known software image ran.
• Reproducible builds, so anyone can rebuild the measured image and compare its digest with the published one.

One point needs saying plainly: no cryptographic primitive proves physical location. What infrastructure can prove is that a specific, attested machine served the request under a signed jurisdiction declaration, made by an operator with something to lose if it is false. That is a stronger standard than most contracts reach, and it is honest about its limits.

Sovereignty without isolation

A common response to all of this is to build a closed national stack. That has costs. Closed stacks concentrate risk in a single operator, struggle to fill their capacity and cut users off from the pace of open models.

Placement constraints offer another route. When jurisdiction is a property of the request rather than of the platform, sovereign and general workloads can share an open market. A request pinned to "EU" goes only to machines in the EU. An unpinned request can go anywhere. Operators inside a jurisdiction can serve both kinds of demand, which helps keep sovereign capacity busy rather than idle. Open-weight models, served on hardware the operator owns, remove a further dependency: the model itself does not have to be accessed through a foreign API.

What this means for policy makers, CTOs and telcos

For EU policy makers, procurement for AI factories and gigafactories can ask for request-level evidence: fail-closed jurisdiction routing, hardware-held identity keys, signed per-request records and reproducible measured images. These are concrete, testable requirements, and they work whatever the ownership structure.

For CTOs, a sovereignty review should cover all three layers. Where does each request run, including on failover? Who holds every key that can make a node act? Can you verify the evidence yourself? Under the AI Act, which has applied in stages since 2025 according to the Commission's timeline, the same records also support your transparency obligations.

For telcos, sovereignty is a commercial opening. Operators already hold national licences, sites in every region and trusted relationships with governments. Edge and core sites that can enforce jurisdiction pins and produce signed records can sell sovereign inference as a service, not only as a project.

Where Tenzro fits

Tenzro is an open network where machines sell AI compute and inference. It is live in preview, and governance decides the steps to testnet and mainnet. What is built:

• Placement. Requests can carry a jurisdiction pin, such as "DE,EU". Only providers whose operators declared a matching country or bloc are candidates. Matching fails closed, and session successors and KV-cache checkpoints follow the same pin.
• Keys. Machine and validator identity keys are derived and held in a TPM 2.0, a Secure Enclave or a passkey and are never written to disk. Wallet keys live only in passkeys, TPMs or Secure Enclaves.
• Proof. Responses carry receipts signed by a key certified by the serving machine's hardware identity key, covering the model hash, the machine, the input commitment and the output hash. Pinned requests can carry a signed jurisdiction receipt, bound to an attestation report on confidential-computing nodes. Measured confidential-VM images for Intel TDX, AMD SEV-SNP and AWS Nitro are built reproducibly.
• Control. Operators can make a node private, gated or public, and can bootstrap a separate network of their own with its own genesis and validator set.

The network does not ship its own models. It serves third-party open-weight models on operators' own hardware.