Can You Use Google Vertex AI or Gemini Enterprise on Sensitive Government Data?

You can run Google Vertex AI and Gemini Enterprise on some government workloads, and both offer data residency, VPC Service Controls, customer-managed encryption keys and governance tooling. For the most sensitive government data the honest answer is more limited: you can use them, but you cannot hold sovereignty over them. Both services remain operated by a hyperscaler, so the provider still holds the hardware, the root keys and the network perimeter. Sovereignty is therefore asserted by contract, not held by the buyer, and under the US CLOUD Act a US-headquartered provider can be lawfully compelled to produce data it controls, wherever it sits.

This question matters more in 2026 because the regulatory floor has risen. DORA has been in force since January 2025, NIS2 now reaches essential and important entities across critical sectors, and GDPR still governs any personal data in the set. Public-sector buyers are no longer asking only whether a service is secure. They are asking a sharper question: if the data is sensitive enough that a foreign court order would be a national-security event, who actually holds the keys? That is the test this article answers.

What is the honest sovereignty test?

Sovereignty is a set of physical facts you can check. We use a three-part test. First, who holds the hardware the model runs on. Second, who holds the encryption keys and the root of trust. Third, who controls the network perimeter and can see or move the data. If the answer to any of these is a third party, sovereignty over that data is delegated, not retained. A residency guarantee tells you where the bytes sit. It does not tell you who can compel access to them.

What do Vertex AI and Gemini Enterprise actually give you?

Both are capable enterprise services. Vertex AI offers regional data residency, VPC Service Controls to fence a perimeter, customer-managed encryption keys, access transparency logs and assured-workload configurations for regulated sectors. Gemini Enterprise adds governed access to frontier models with admin controls and audit logging. These are real controls that satisfy many commercial and some public-sector requirements. What they do not change is the operating model: the infrastructure is owned and run by the provider, and the strongest key controls still sit inside an environment the provider administers.

Why does data residency not equal operational sovereignty?

Data residency is a location promise. Operational sovereignty is a control fact. Residency keeps data in a named region. Operational sovereignty means the operator, and only the operator, can run the workload, hold the keys and deny access to everyone else, including the vendor. A hyperscaler can honour residency perfectly and still retain the technical ability to access, patch, update or, under legal compulsion, disclose. Customer-managed keys narrow this, but if the key management, the hardware security modules and the control plane all live in the provider's cloud, the provider remains inside the trust boundary.

“Residency tells you where your data lives; sovereignty tells you who can be compelled to hand it over, and only one of those survives a foreign court order.”

Which law makes this the deciding factor?

The US CLOUD Act. It allows US authorities to compel a US-based provider to disclose data in its possession, custody or control, regardless of where the data is stored. A European data centre does not place data beyond that reach if the operating company is US-headquartered. This is not an accusation against any vendor; it is the plain design of the law, and it is why residency alone cannot answer a sovereignty question. For data whose exposure would be a national or public-safety concern, the controlling question is jurisdiction over the operator, not the postcode of the server.

What can an auditor actually check?

An auditor should verify facts, not review policy documents. The checkable questions are simple. Can you produce a tamper-evident log of every inference and data access, and verify it offline without trusting the vendor? Is the audit ledger signed with a post-quantum signature standard, FIPS 204, so the record survives a future cryptographic break? Is identity hardware-attested and bound to that ledger? Is the inbound perimeter zero-egress, so data cannot leave the boundary by design? On a hyperscaler service, several of these depend on the provider's own attestations. On operator-owned infrastructure, they can be proven independently.

How does a sovereign architecture answer the question differently?

A Sovereign Intelligence Operating System, a SIOS, moves the three physical facts back to the operator. Mickai runs offline on operator-owned hardware inside the perimeter, so no sensitive prompt or record leaves the estate. Every action is cryptographically sealed to a post-quantum signed audit ledger, using FIPS 204, so the log is verifiable offline and after the fact. Identity is hardware-attested and bound to that chain. The perimeter is zero-egress inbound by design, and cross-model consensus lets multiple sovereign models check each other before an answer is trusted. The architecture and design of this approach is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; these remain filed applications, never granted or patented. On sovereign infrastructure the operator answers the who-holds-the-keys question directly, rather than by contract.

What does the 2026 regulatory timeline mean for this choice?

Treat the current window as time to build, not to wait. The EU AI Act high-risk obligations under Annex III, once due on 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk obligations moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve. DORA already binds financial entities, NIS2 covers essential and important entities, and ISO/IEC 42001 sets the AI management-system baseline auditors will expect. A buyer who chooses architecture now will not be re-procuring under deadline pressure in 2027.

Frequently asked questions

Is Vertex AI sovereign when customer-managed encryption keys are used?

Customer-managed keys strengthen control but do not make the service sovereign. If the key management service, the hardware security modules and the control plane run inside the provider's cloud, the provider stays inside the trust boundary and can be compelled under the CLOUD Act. Sovereignty means the operator holds the hardware, the keys and the perimeter, not just the key material.

Does storing data in an EU region protect it from the US CLOUD Act?

No. The CLOUD Act reaches data in the possession, custody or control of a US-based provider regardless of storage location. An EU data centre operated by a US-headquartered company does not place the data beyond a US court order. Jurisdiction over the operator, not the location of the server, is the deciding factor.

Can Gemini Enterprise be used for classified or highly sensitive material?

For most classified or highly sensitive material the safer answer is no, unless the deployment sits on infrastructure your organisation controls end to end. Standard Gemini Enterprise is hyperscaler-operated, so access ultimately depends on the provider's controls and legal exposure. Where sovereignty is the requirement, sensitive inference should run offline on operator-owned hardware.

What is the difference between data residency and operational sovereignty?

Data residency guarantees where data is stored. Operational sovereignty guarantees who can run the workload, hold the keys and deny access to everyone else, including the vendor. A service can offer perfect residency and still lack sovereignty, which is why residency alone cannot satisfy a sovereignty requirement.

How can we prove sovereignty to an auditor rather than assert it?

Replace policy attestations with verifiable facts. Provide a tamper-evident audit ledger signed with a post-quantum standard, FIPS 204 as the primary, that an auditor can verify offline without trusting the vendor. Bind identity to that ledger with hardware attestation, and show a zero-egress perimeter. These properties are checkable on operator-owned infrastructure.