Running Gemini Enterprise in the EU

Why “EU region” is only the first step to compliance

An EU-located Gemini Enterprise app gives you two guarantees: customer data at rest stays in the EU, and ML processing for supported features happens in the EU. That is necessary for European data protection, but it is not compliance. Compliance also depends on who can access the data, what the contract says, which features are switched on, and how you govern AI use under the EU AI Act.

The honest claim for a DPO sign-off is therefore: “EU at-rest residency plus EU ML processing, with global-only features disabled.” This article explains how that guarantee works, where it stops, and what the platform, security and governance teams must add on top.

Why “100% EU compliant” is the wrong question

No cloud product is “compliant” on its own. Compliance is a property of a processing activity, and your organisation owns that activity as the GDPR controller and the EU AI Act deployer. A provider can only give you capabilities, contractual commitments and evidence. You turn those into compliance through configuration, process and documentation.

Five questions get blurred together in most EU AI discussions. Data residency answers only the first one fully.

A residency setting closes the first row. Every other row needs work from your side.

How data residency works in Gemini Enterprise

Google makes two separate commitments, and they cover different things. At-rest DRZ means stored customer data stays in the chosen location. ML processing (MLP) means inference, tuning and similar model work run inside that location. For the eu multi-region, ML processing stays in the EU when requests go to regionally available APIs, subject to listed limitations.

The location is chosen once, when the app and its data stores are created. API callers must then use the matching regional endpoint: eu-discoveryengine.googleapis.com with location eu, never global-discoveryengine or the unprefixed endpoint. A UK in-country region (europe-west2) also exists, but it is allowlist-only and more constrained than eu.

The guarantee is feature by feature, not app-wide. As of the 29 September 2026 version of Google’s locations page, the EU multi-region looks like this:

Two patterns matter more than any single row. First, the newest models and features usually land in global first, so the table shifts with every release. Second, some global-only features sit behind a confirmation dialog that reroutes traffic to the global endpoint. One click by an admin quietly breaks the guarantee. Source: Google Cloud: Data residency for Gemini Enterprise.

Global or EU: choose by requirement, not by instinct

Google’s own guidance is to pick global unless you have security or regulatory reasons to use us, eu or an in-country region. The stated reasons are better response times, the latest model versions and the newest features. That is a fair recommendation, and "we are a European company" alone is not a reason to accept the trade-offs.

The choice is not only about where data sits, though. Two controls exist only outside global: customer-managed encryption keys (CMEK) and Access Transparency are not supported in the global region. Choosing global therefore also gives up key control and visibility into provider access.

The location cannot be changed after creation. Moving from global to eu means a new app, re-created data stores and re-ingested connectors, so decide before rollout, not after.

What residency does not cover

Residency tells you where the bytes are. Regulators and works councils ask three further questions: who can reach them, on what legal terms, and under whose jurisdiction.

Access: who can read the data

Access Transparency logs actions that Google personnel take on your content, in the same way audit logs record your own staff. For Gemini Enterprise it has three gaps you should document:

• It only works with multi-region (us or eu) apps and data stores, not global.
• Data in preview features is not covered.
• Google staff access to search analytics data is not logged.

The project must also sit inside an organisation (Gemini Enterprise: Access Transparency).

Access Approval goes one step further: Google must ask before accessing, and you approve or deny. It is not listed among Gemini Enterprise’s supported security controls, which name only data residency, CMEK, VPC Service Controls and Access Transparency (Gemini Enterprise: compliance and security controls). Treat it as unavailable for this product until Google says otherwise.

Key control is the strongest technical lever. CMEK lets you hold the keys in Cloud KMS in an EU location and revoke them. Using an external key manager (EKM) or HSM with CMEK is GA with allowlist. With EKM, keys live outside Google, which is the usual answer to “what if Google is compelled to hand over data?”.

One footnote on that controls page matters a lot: residency, CMEK and Access Transparency do not apply when Grounding with Google Search is enabled. That single toggle disables most of the controls in this section.

Contract: what Google has promised

The Cloud Data Processing Addendum (CDPA) is the Article 28 GDPR contract. The points a DPO will check:

Two items are not in the CDPA and need separate checks. First, the Service Specific Terms for AI services, which cover whether customer data trains models. Second, the terms of any third-party connector or MCP server, which sit outside Google’s DPA entirely.

Sovereignty: under whose jurisdiction

Google is a US company, and residency does not change that. Independent analysts note that US laws such as the CLOUD Act can still create legal obligations despite technical controls (KuppingerCole). Google answers this with three tiers of sovereign offering (Google Cloud blog):

1. Google Cloud Data Boundary, delivered through Assured Workloads: residency, access and personnel controls inside the public cloud.
2. Google Cloud Dedicated: a regional, independent operator runs the cloud.
3. Google Distributed Cloud: on-premises, for requirements that rule out public cloud.

For most enterprises the realistic step is tier 1. Assured Workloads applies a control package to a folder. Gemini Enterprise (discoveryengine.googleapis.com) is a supported product in the EU Data Boundary package, including Web Grounding for Enterprise (Assured Workloads: EU Data Boundary). That package is free, and it enforces EU-only resource locations and blocks TLS 1.0 and 1.1.

The base package has two limits you must know. Support cases are routed to global support staff, so pick EU Data Boundary and Support if EU-only support personnel matter. And Google Cloud MCP servers are not covered: the package gives no residency for their in-use or in-transit data. A third package, EU Data Boundary with Access Justifications (formerly Sovereign Controls for EU), adds key access justifications. Check its supported-products list for Gemini Enterprise before committing to it.

The regulatory map

At least five legal regimes touch an enterprise Gemini rollout in Germany. Residency is evidence for the first one; the others need their own artefacts.

The last row is often the slowest. A works agreement that fixes what is logged, who may read logs and for what purpose also makes the GDPR documentation much easier.

The EU AI Act for organisations deploying Gemini Enterprise

The AI Act regulates the use of AI, so it applies regardless of where data is stored. An EU-resident app can still be a prohibited or high-risk AI system. The Digital Omnibus on AI (Regulation (EU) 2026/1744) amended the timeline; it entered into force on 27 July 2026 (Cooley).

Who is who

• Google is the provider of the general-purpose AI models. The GPAI obligations in Articles 51 to 56 have applied to Google since August 2025. You do not inherit them.
• Your organisation is a deployer when staff use the Gemini Enterprise assistant, search and Google-made agents.
• Your organisation can become a provider when it builds its own agents and puts them into service under its own name. That matters only if the agent falls into a high-risk use case. Using an agent for a purpose the provider did not intend can also shift you into the provider role (Formalize).

What applies now and what is coming

The Omnibus deferred the high-risk rules because harmonised standards were not ready, not because the requirements were dropped. The Commission published draft classification guidelines on 19 May 2026 (Praxikon), so classification work can start now.

The practical consequence

A general-purpose assistant used for drafting, search and summarisation is not high-risk. The trap is the custom agent built six months later for HR or for a business decision about individuals. Govern the use case, not the platform: every new agent gets a risk classification before it is shared beyond its builders.

Advice for the platform team

The platform team’s job is to make the EU guarantee hold by default, so it does not depend on an admin making the right click. Work from the outside in: organisation, project, app, then agents and connectors.

The EU guarantee holds only when every layer enforces it

Each layer catches what the one inside it misses: an org policy still blocks a non-EU resource when an admin enables something in the app.

Get Ahmed Mohamed’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

1. Organisation and folder

• Place the production Gemini Enterprise project in an Assured Workloads folder with the EU Data Boundary package, or EU Data Boundary and Support if EU-only support personnel are required.
• Enforce gcp.resourceLocations limited to in:eu-locations, plus gcp.restrictServiceUsage to supported services. Assured Workloads sets both; add them yourself if you skip Assured Workloads.
• Keep a separate global sandbox project in a different folder for evaluating new models, with no production connectors and no personal data.
• Regionalise logs: set Cloud Logging default buckets to an EU location, so prompt metadata and audit records stay in the EU too.

2. Project security controls

• Turn on CMEK with Cloud KMS keys in an EU location. Request the EKM or HSM allowlist if the sovereignty assessment requires keys outside Google.
• Enable Access Transparency at organisation level and route its logs to your SIEM.
• Put discoveryengine, aiplatform, Cloud Storage and BigQuery inside one VPC Service Controls perimeter.
• Create Model Armor templates in the EU and attach them to the app for prompt-injection and sensitive-data screening.

3. App configuration

• Create the app and data stores in eu. Every API caller uses eu-discoveryengine.googleapis.com with location eu.
• Turn off the global-only and out-of-region features: Gemini 3.1 Pro, Grounding with Google Search, Gemini 3 Pro image, video generation, Notebook Content Studio and Discover Sources.
• Use Gemini Enterprise’s managed organisation policy constraints to allow-list data sources and egress domains, so a new connector cannot be added silently.
• Restrict the app-admin role to a small named group, and brief them never to confirm a “route to global” dialog.

4. Agents and connectors

• Deploy custom agents in an EU region and grep their code for global, us-central1 and hard-coded US endpoints.
• Do not give agents the Agent Runtime code-execution tool; it has no EU at-rest residency.
• Review every MCP server and third-party tool an agent calls. Google Cloud MCP servers are outside the EU Data Boundary, and third-party ones are outside Google’s DPA.
• For each third-party connector, record where the source system is hosted. A federated connector queries the source live, so its region matters as much as yours.

5. Operations

• Manage the app, data stores and org policies as code (Terraform), with drift detection on the feature toggles.
• Alert on admin-activity audit log entries that change models, grounding or app location settings.
• Watch the Assured Workloads violations dashboard.
• Re-check Google’s locations page at every Gemini Enterprise release. A new model goes to the sandbox first and reaches EU production only once it shows EU residency and processing.

Advice for the DPO, security, legal and AI governance

The platform team can make the system capable of compliance. Each of these roles turns that capability into evidence an auditor will accept.

One finding for the security review: Antigravity in Gemini Enterprise does not support Access Transparency or the ISO and SOC certifications (Gemini Enterprise: compliance and security controls). Either keep the AI developer tools off, or scope them out of your certification claims explicitly.

A simple operating rhythm keeps this current: a monthly review of Google’s release notes and locations page, a quarterly review of the agent inventory, and a yearly re-run of the DPIA.

Wording the sign-off

Claim exactly what the configuration delivers, and name what it does not. An overclaim in a sign-off is a liability the moment a toggle changes.

A sign-off paragraph the DPO can adapt:

The Gemini Enterprise production app runs in the eu multi-region inside an Assured Workloads EU Data Boundary folder. Stored data and ML processing for all enabled features remain in the EU. Features without EU residency (Gemini 3.1 Pro, Grounding with Google Search, Gemini 3 Pro image, video generation, Notebook Content Studio and Discover Sources) are disabled and monitored for change. Data is encrypted with customer-managed keys held in the EU, and Google personnel access is logged via Access Transparency. Processing is governed by the Cloud Data Processing Addendum and the DPIA of [date]. This statement reflects the configuration on [date] and is reviewed at each product release.

Sources

• Google Cloud: Data residency for Gemini Enterprise and Gemini Notebook Enterprise (updated 29 Sep 2026)
• Google Cloud: Gemini Enterprise compliance certifications and security controls (updated 30 Sep 2026)
• Google Cloud: Enable Access Transparency for Gemini Enterprise
• Google Cloud: Assured Workloads EU Data Boundary control package (updated 24 Sep 2026)
• Google Cloud: Cloud Data Processing Addendum
• Google Cloud blog: Sovereign cloud platforms
• KuppingerCole: Google Cloud’s sovereign solutions, a European perspective
• Cooley: Digital AI Omnibus delays key deadlines
• Praxikon: Digital Omnibus and the high-risk postponement
• Formalize: What the Digital Omnibus changed
• Reed Smith: Germany implements NIS2

This article is technical guidance, not legal advice. Confirm conclusions with your DPO and legal counsel.