Part 2 of the “European AI Stack” series.

9 min readJust now

–

Press enter or click to view image in full size

*Image generated with *BFL Flux

A GDPR-compliant AI setup, running entirely in the EU, with $300 in free credits — and I set it up in 30 minutes. I stared at my screen afterward, waiting for the catch.

***Disclaimer: ***I am a Data Scientist and AI Engineer, not a lawyer. This guide represents my personal research and technical implementation of Google Cloud’s data residency features. It does not constitute legal advice. GDPR compliance is complex and depends on your specific data, processes, and legal context. Always consult with a qualified data protection officer or legal counsel for your specific requirements.

(Want to skip the story? Scroll down to the 30-minute setup)

The Problem I Was Trying to Solve

As someone building AI tools from Germany, I’ve developed a healthy paranoia about data residency. Every time I use an AI API, there’s this nagging question: where is my data actually going? Is it being processed in the US? Stored somewhere I can’t control? The GDPR isn’t optional for me — it’s the law.

Most AI providers make this frustratingly vague. “We comply with GDPR” usually means they’ve got some legal boilerplate about Standard Contractual Clauses, not that your data actually stays in Europe.

So when I heard Google’s Vertex AI offered genuine EU data residency — with processing guaranteed to stay in European data centers — I was skeptical but curious.

What I Expected vs. What I Found

I expected the usual enterprise cloud experience: buried documentation, confusing pricing tiers, and at least three different IAM roles to configure before anything works.

What I found was simpler than expected.

Here’s the actual setup I ended up with:

Table 1: Configuration summary for the 30-minute GDPR-compliant setup.

The key decision was choosing europe-west4 (Netherlands) over europe-west3 (Frankfurt). Both are EU regions, but Frankfurt has limited model availability. When I tested it, gemini-2.5-pro returned a 404 error there. (Model availability varies by region - check the current EU regional availability for updates.) The Netherlands region has full model support and is equally GDPR-compliant.

The $300 Free Credits — With a Catch

Google gives new accounts $300 in credits valid for about 90 days. Sounds generous, and it is. But there’s a catch I didn’t find mentioned clearly anywhere: the Free Trial tier has restricted model access.

On Free Trial, I could only use gemini-2.5-flash. Every attempt to use gemini-2.5-pro or newer models failed with opaque permission errors (usually 403s) that didn’t explicitly say "upgrade required". The Google documentation says these models are "available in EU regions" - technically true, but only after you upgrade.

The fix was simple: upgrade to Pay-as-you-go billing. Your $300 credits stay intact, but now you get access to the full model catalog. No immediate charges unless you burn through those credits.

The Part Where I Got Paranoid About Costs

Cloud billing horror stories are everywhere. I’ve read too many Reddit and Medium posts about developers waking up to $10,000 bills because of a misconfigured loop or a forgotten service. A recent article by Teja Kusireddy on Toward AI detailed a $47,000 bill from two agents stuck in an infinite conversation loop — a scenario that shows how quickly costs can spiral without safeguards.

So before I ran a single production request, I built a three-layer cost protection system:

Table 2: The three layers of defense against accidental cloud bills.

The quota limit is your real protection. It’s enforced immediately at the API level. Even if something goes catastrophically wrong, the absolute worst case with my limits is about $60/day for Flash or $840/day for Pro. And those numbers assume you’re hitting the rate limit continuously for 24 hours — unlikely in practice.

The budget alert and Cloud Function are backup layers. They have a delay because billing data isn’t real-time, but they add a safety net. The Cloud Function literally disables billing for the project when triggered — a nuclear option, but one I’m glad exists.

I tested the entire pipeline on 2026–01–02. Sent a fake “budget exceeded” message through Pub/Sub, watched the Cloud Function trigger, and verified billing got disabled. It works.

The GDPR Fine Print That Actually Matters

Here’s the important caveat: not everything in Vertex AI gets EU data residency.

Google’s own Gemini models (2.5 Pro, 2.5 Flash, Imagen) — those stay in your specified region. Your prompts and responses are processed in the Netherlands, stored there, and never touch US servers.

But Vertex AI also offers third-party models through what Google calls “MaaS” (Model-as-a-Service). DeepSeek, Llama, Qwen, and other open-source models are available through the platform. These are in a different category than Google’s own models when it comes to data residency.

Table 3: Data residency guarantees by model type on Vertex AI.

Important: Google has been expanding EU regional support for open models. As of early 2026, DeepSeek, Llama, and Qwen show availability in europe-west1 (Belgium) and europe-west4 (Netherlands). However, these models are managed differently than Google’s own models - always check the current data residency documentation before relying on them for GDPR-sensitive workloads.

For my use case — using Gemini models via API — the built-in guarantees are sufficient.

For Stricter Compliance: Zero Data Retention

Here’s something I discovered while digging deeper into Google’s documentation: even with EU data residency, Vertex AI has some default behaviors that privacy-conscious users should know about.

**In-memory caching: **By default, Google keeps your prompts in memory for up to 24 hours to speed up similar requests. This isn’t storage — it’s a performance optimization — but for some compliance scenarios, even transient caching matters.

Abuse monitoring: Google may log prompts for safety and abuse detection. This is standard practice across AI providers, but it means your data could be reviewed by humans in edge cases.

If your use case requires stricter controls, Google offers “Zero Data Retention” mode. You enable it per-request by adding a header:

curl -X POST \  -H "Authorization: Bearer $(gcloud auth print-access-token)" \  -H "Content-Type: application/json" \  -H "X-Vertex-AI-LLM-Request-Type: zero-data-retention" \  "https://europe-west4-aiplatform.googleapis.com/v1/projects/${GOOGLE_CLOUD_PROJECT}/locations/europe-west4/publishers/google/models/gemini-2.5-flash:generateContent" \  -d '{"contents":[{"role":"user","parts":[{"text":"Your prompt here"}]}]}'

With this header, Google commits to not retaining your prompts or responses beyond the immediate request processing.

**Features to avoid for zero retention: **If you need strict zero data retention, stay away from Grounding with Google Search (sends data to Search infrastructure), Session Resumption (requires storing conversation state), and Cached Context (explicitly stores prompts for reuse).

For enterprise deployments handling sensitive data — medical records, legal documents, financial information — the extra friction of zero retention mode might be worth it. For my daily coding assistance, the standard EU data residency is sufficient.

For the full technical details, see Google’s Zero Data Retention documentation.

One More Gotcha: Express Mode

Google offers an “Express Mode” that lets you use the API with just an API key instead of a full service account. It’s simpler, but there’s a problem: Express Mode doesn’t let you specify a region.

Your requests go to a global endpoint, and you lose control over where processing happens. For GDPR purposes, this is a non-starter. Always use service account authentication with an explicit region parameter.

What I Actually Use This For

My setup integrates with the opencode CLI (which I covered in Part 1: Why I Switched to OpenCode). The configuration looks like this:

{  "provider": {    "google-vertex": {      "options": {        "project": "agentic-ai-forge",        "location": "europe-west4"      },      "models": {        "gemini-2.5-pro": {          "name": "Gemini 2.5 Pro (EU-NL)"        }      }    }  }}

Daily coding sessions with Gemini 2.5 Flash cost me roughly $0.05–0.15. Pro is more expensive — maybe $0.50–1.00 for an intense session — but I use that selectively for harder problems.

At this rate, those $300 credits should last me several months of actual work.

Network Security: Is HTTPS Enough?

Does standard HTTPS satisfy GDPR requirements, or do you need VPNs and private gateways? I dug through official sources — GDPR text, BSI (Germany’s federal cybersecurity authority), and ENISA — to find out.

Get Björn Büdenbender @ agentic.ai.forge’s stories in your inbox

Join Medium for free to get updates from this writer.

Short answer: HTTPS is sufficient for most use cases.

GDPR Article 32 requires “appropriate technical and organisational measures” including encryption. The key word is appropriate — the regulation deliberately avoids prescribing specific technologies. Instead, it uses a risk-based framework considering state of the art, risk level, and implementation cost. Recital 83 clarifies that encryption is an example measure, not a mandate for any specific implementation.

For German businesses specifically, the BSI C5 criteria catalogue is the relevant cloud security benchmark. Google Cloud holds C5:2020 attestation, meaning their infrastructure has been independently verified against German federal security standards. C5 requires encryption in transit — and TLS satisfies this requirement. No VPN mandate exists.

Google’s implementation covers all bases: TLS 1.2+ for all API traffic (you can’t make unencrypted requests), TLS between regions, and AES-256 encryption at rest by default.

**When you might need more: **If you’re processing healthcare records, financial transactions, or data under sector-specific regulations (BaFin, KRITIS), your risk assessment may justify additional measures like VPC Service Controls or Private Service Connect. These create security perimeters or private network paths to Google APIs. But they add cost and complexity — for typical AI API usage, they’re overkill.

The data residency guarantee is about where your data goes. The encryption guarantee is about how it gets there. Both are handled automatically.

The 30-Minute Setup (Step by Step)

Here’s the actual sequence I followed. Times are approximate — your mileage may vary depending on how fast you click.

Minutes 0–5: Create GCP Project

1. Go to console.cloud.google.com
2. Click the project dropdown → “New Project”
3. Name it something memorable (I used agentic-ai-forge)
4. Wait for creation (~30 seconds)

Minutes 5–10: Enable Billing & Upgrade

1. Navigation menu → Billing → Link a billing account
2. Add payment method (credit card required, but you won’t be charged yet)
3. Critical: Click “Upgrade” to switch from Free Trial to Pay-as-you-go
4. Your $300 credits transfer automatically

Minutes 10–15: Enable Vertex AI API

1. Navigation menu → APIs & Services → Enable APIs
2. Search “Vertex AI API” → Enable
3. Wait for propagation (~1 minute)

Minutes 15–20: Create Service Account

1. Navigation menu → IAM & Admin → Service Accounts
2. “Create Service Account” → Name it (e.g., vertex-ai-client)
3. Grant role: “Vertex AI User”
4. Click into the new account → Keys → Add Key → Create new key → JSON
5. Download and store securely (this is your GOOGLE_APPLICATION_CREDENTIALS file)

Minutes 20–25: Set Quota Limits

1. Navigation menu → IAM & Admin → Quotas
2. Filter: metric:aiplatform.googleapis.com/generate_content_requests region:europe-west4 (note paste these in separetly)
3. Select the quota → Edit Quotas → Set to 5 (or your preferred limit)
4. Submit and wait for approval (usually instant)

Minutes 25–30: Configure Budget Alert

1. Navigation menu → Billing → Budgets & alerts
2. Create budget → Set amount (I use $50/month)
3. Set thresholds: 50%, 90%, 100%
4. Enable email notifications

That’s the core setup. The Cloud Function for auto-disabling billing adds another 45 minutes but provides real peace of mind.

Optional: Deploy Budget Guard Cloud Function

For the ultimate peace of mind, you can deploy a Cloud Function that automatically disables billing when your budget is exceeded. This is a more advanced setup, so I’ve moved it to a separate, dedicated guide.

➡️ **Full Guide: **How to Build a GCP Budget Guard Cloud Function (Coming Soon)

Test the API

export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your-key.json"export GOOGLE_CLOUD_PROJECT="your-project-id"export GOOGLE_CLOUD_LOCATION="europe-west4"

curl -X POST \  -H "Authorization: Bearer $(gcloud auth print-access-token)" \  -H "Content-Type: application/json" \  "https://europe-west4-aiplatform.googleapis.com/v1/projects/${GOOGLE_CLOUD_PROJECT}/locations/europe-west4/publishers/google/models/gemini-2.5-flash:generateContent" \  -d '{"contents":[{"role":"user","parts":[{"text":"Say hello"}]}]}'

If you get a response with generated text, you’re done. Your data never left the EU.

Final Thoughts

Setting up a GDPR-compliant AI workflow on Google Cloud is not only possible but surprisingly straightforward. The secret sauce is selecting an EU region like europe-west4, upgrade to a pay-as-you-go plan to unlock all models with your free credits, and always use service account authentication.

While basic setup takes 30 minutes, building a robust cost-protection system is a more involved, but highly recommended, next step. With this configuration, you can confidently build AI applications for the EU market, knowing your data stays where it belongs.