Data Residency and Sovereignty in Government AI Tenders

Data residency and data sovereignty are not the same thing, and a tender that asks only for residency does not deliver sovereignty. Residency controls where data physically sits; sovereignty controls who holds legal and technical authority over it. Because extraterritorial law such as the United States CLOUD Act can compel a provider under United States control to disclose data it holds anywhere in the world, in-country hosting alone does not remove foreign legal reach. A tender that wants sovereignty must require three things beyond residency: jurisdictional control of the operator, operator-held keys, and provable offline operation.

The 2026 procurement market is full of residency language that reads as a sovereignty guarantee and is not one, yet the controlling company and its keys often remain under a foreign jurisdiction.

What is the difference between data residency and data sovereignty?

Data residency is a location control: data is stored and processed inside a named country or region. Data sovereignty is a control-and-jurisdiction question: who can lawfully access the data, who holds the encryption keys, and which legal system can compel disclosure. A dataset can be fully resident in London and still be reachable by a foreign court if the operator answers to that court. Residency is necessary. It is not sufficient.

Which rule makes foreign reach possible even with local hosting?

The clearest example is the United States CLOUD Act of 2018. It lets United States authorities compel a provider subject to United States jurisdiction to produce data in its possession, custody or control, wherever it is stored. Jurisdiction follows the company, not the server, so a European subsidiary of a United States parent can sit inside such an order while its data centre stands in Frankfurt or Dublin. This does not mean every foreign-hosted workload will be disclosed. It means the exposure exists, and a residency clause does not close it.

Why do residency clauses and contractual promises fall short?

A residency clause fixes geography, not who owns the operating company or who holds the keys. A promise not to move data, or to resist a foreign order, is a commitment, not a technical barrier: if the provider holds the keys, it can be compelled to use them, and if it can reach the system over a network, that path can be turned against the buyer. Ask whether any entity outside your jurisdiction can be lawfully compelled to hand over this data or its keys; if yes, residency has not delivered sovereignty.

“Residency answers where data lives; sovereignty answers who can be compelled to surrender it, and only the second protects government information.”

What should a government AI tender require instead?

A tender that wants sovereignty, not just residency, should require the following, with evidence of each:

• Jurisdictional control: the operating entity and its key custodians sit within the buyer's legal system, with no foreign parent able to compel disclosure.
• Operator-held keys: the buyer, not the supplier, holds the encryption keys, so no third party can decrypt the data on demand.
• Provable offline operation: the system can run air-gapped, with no outbound connection needed for normal use, so there is no network path for external access.
• A zero-egress inbound perimeter that accepts requests inward but sends nothing out, demonstrable on the buyer's own network.
• A tamper-evident audit trail the buyer can verify without trusting the supplier.

What can an auditor actually check?

Sovereignty claims should be checkable. An auditor can verify concrete facts:

• Pull the network cable or block egress and confirm the system keeps working. Provable offline operation is a yes or no test.
• Inspect key custody and confirm the buyer holds the keys and the supplier cannot decrypt without them.
• Read the audit ledger and verify each entry's signature. A post-quantum signed ledger under the ML-DSA standard (FIPS 204) lets an auditor confirm no record was altered or back-dated.
• Trace the ownership of the operating entity and its key custodians to confirm no foreign compulsion path exists.

How does a sovereign architecture deliver this in practice?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs on operator-owned hardware inside the buyer's own perimeter, not on a shared cloud region. It runs offline: normal operation needs no outbound connection, removing the network path a foreign order or remote operator would need. The buyer holds the keys. Every action is sealed to a post-quantum signed audit ledger using the ML-DSA signature standard (FIPS 204), and each entry is bound to a hardware-attested identity, so the record is tamper-evident and independently verifiable. The architecture behind this is covered by 104 filed UK patent applications and approximately 2,340 claims, owned by Mickai LTD. This design supports a buyer's residency, sovereignty and audit duties, but does not, on its own, certify compliance with any regulation; that remains the buyer's own assessment.

Which rules make this necessary in 2026?

Several regimes push the same way, toward provable control rather than a location label:

• GDPR governs personal data and cross-border transfer, and a foreign compulsion path is a transfer risk a residency label does not answer.
• The EU AI Act sets obligations for high-risk systems, and the Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I obligations moving to 2 August 2028 and Article 50 transparency duties largely unchanged. We read this as a build window, not a reprieve.
• DORA, in force since January 2025, holds financial entities and their critical third parties to operational-resilience and control duties.
• NIS2 raises security and supply-chain requirements for essential and important entities.
• ISO/IEC 42001 provides a management-system standard for AI governance that buyers increasingly cite in tenders.

Frequently asked questions

Does data residency mean your data is sovereign?

No. Residency only fixes where data is stored and processed. Sovereignty depends on who owns the operating company, who holds the encryption keys, and which legal system can compel disclosure. Data can be fully resident in your country and still be reachable by a foreign court if the provider answers to that court.

Can the US CLOUD Act reach data stored in the UK or EU?

Yes, it can create that exposure. The CLOUD Act lets United States authorities compel a provider under United States jurisdiction to produce data in its control, wherever it is stored. A local data centre owned or controlled by a United States entity does not remove that reach. Whether any specific data is ever disclosed is separate; the exposure exists, and a residency clause does not close it.

What should a government AI tender ask for to protect sovereignty?

Ask for three things beyond residency, with evidence of each: jurisdictional control of the operating entity and its key custodians, operator-held encryption keys, and provable offline operation. Add a tamper-evident audit trail the buyer can verify independently. Each requirement is checkable rather than a promise.

Is a European cloud region enough for GDPR and sensitive government data?

Not on its own. A European region answers where the data sits, but GDPR also concerns who can access it and under which jurisdiction. If the provider or its parent sits under a foreign legal system that can compel disclosure, that transfer risk remains. The safer position is operator-held keys and a system that can run offline inside your own perimeter.

Can we use public cloud AI assistants for classified or sensitive government work?

Public cloud AI services send data to infrastructure the buyer does not control, and the operating companies typically sit under a foreign jurisdiction, which creates the residency and sovereignty exposure a procurement gate is meant to prevent. For classified or sensitive work, the safer pattern runs on operator-owned hardware, offline, with buyer-held keys and a verifiable audit trail. That is the design principle behind a Sovereign Intelligence Operating System.