Back to Article List

Add Google Gemini to Your Site the GDPR-Safe Way

Google Gemini DSGVO-konform in Ihre Website einbinden - Add Google Gemini to Your Site the GDPR-Safe Way

You can add Google Gemini to your website without shipping your visitors' personal data across the Atlantic — but only if you build it deliberately. The safe pattern is simple: call Gemini from your own server, never from the browser, strip anything identifying before the request leaves your machine, and turn off the settings that let Google keep your prompts. Do that and you get useful AI search, summaries or a support helper while staying on the right side of GDPR.

Most tutorials skip the privacy part entirely. They hand you a client-side API key and a copy-paste widget, which means every question your visitors type flies straight from their browser to Google, tagged with their IP address, and — with the wrong settings — potentially gets used to improve Google's models. That is a data transfer you cannot document, cannot control, and probably cannot lawfully justify.

This guide walks the setup that keeps you in charge. It assumes you already run a site and can deploy a small backend or serverless function.

Where does your visitor data actually go with Gemini?

Every prompt sent to the standard Gemini API travels to Google's infrastructure, and unless you pin a region, you have no guarantee it stays inside the EU. That is the whole problem in one sentence.

There are two very different products here, and the difference matters for compliance. The free consumer-grade Gemini API via Google AI Studio is fast to start with but gives you weak data-residency guarantees and, on free tiers, may use your inputs to improve the service. The Vertex AI Gemini models on Google Cloud let you pin processing to a European region (for example europe-west4 in the Netherlands or europe-west1 in Belgium) and come with a Data Processing Addendum you can actually sign.

For anything touching real visitor data, use Vertex AI with a European region. The AI Studio key is fine for a prototype on dummy data, but it is not a foundation for a public feature on an EU business site. Google Cloud is a US company, so a transfer mechanism still applies even with EU regions — the Standard Contractual Clauses in Google's DPA cover this, and pinning the region keeps processing physically in Europe.

Why every call must go through your server, not the browser

The single most important decision in this whole setup is where the call originates: your backend, never client-side JavaScript. A browser call exposes your API key to anyone who opens dev tools, and it sends the visitor's raw IP address directly to Google with no chance for you to filter or log it responsibly.

The architecture is a thin proxy. Your visitor's browser talks to your endpoint. Your server validates the request, removes what it does not need, calls Gemini, and returns only the answer. Google sees your server's IP, not your visitor's, and your key never leaves your infrastructure.

Here is the core of a Node proxy hitting Vertex AI in an EU region. The region is baked into the hostname, so there is no global default to accidentally fall back to:

  • Endpoint: https://europe-west4-aiplatform.googleapis.com/v1/projects/YOUR_PROJECT/locations/europe-west4/publishers/google/models/gemini-1.5-flash:generateContent

And the handler itself:

  • app.post('/api/ask', ...) — validate the payload length, rate-limit by session, reject anything odd.
  • const clean = stripPII(req.body.question) — remove emails, phones and names before the call.
  • const token = await auth.getAccessToken() — from a service-account credential in an env var, never in the repo.
  • await fetch(ENDPOINT, { method:'POST', headers:{ Authorization: `Bearer ${token}` }, body: JSON.stringify({ contents:[{ role:'user', parts:[{ text: clean }] }], generationConfig:{ maxOutputTokens: 512 } }) })
  • Return only the model's text to the browser, and log timestamp and status — not the transcript.

If you host with us, this proxy runs happily as a small Node or PHP service on your plan, right next to your site, in an EU data centre. Keeping the proxy and your site in the same European location means the only cross-border hop is the one you have documented and controlled.

The safer configuration defaults to set on day one

Set these before you go live, not after your first data request. Retention off, input capped, logs minimal — none of it costs you a working feature.

Here is the checklist worth pinning above your desk:

  • Disable prompt logging for training. On Vertex AI, your prompts are not used to train Google's models by default — confirm this in your project settings. On the AI Studio API, assume the opposite and do not use it for real data.
  • Pin the region explicitly in the endpoint (europe-west4 or another EU location). Do not rely on a global default.
  • Strip PII server-side before the call. A quick regex pass for emails, phone numbers and obvious names catches most of it; a library like presidio does a thorough job.
  • Set a low max token limit on both input and output. It cuts cost and reduces how much text you ever transmit.
  • Keep safety filters on at Google's default or stricter, so a hostile prompt does not return something ugly on your page.
  • Log without the payload. Store timestamp, latency and status — not the visitor's question and answer verbatim. If you must keep transcripts for quality, anonymise and set a short retention window.

These defaults cost you nothing in usefulness. A support helper does not need to know a visitor's name to answer a shipping question, and a search summariser only needs the query text.

Three jobs Gemini does well on a small business site

Gemini earns its place in three concrete spots: smarter on-site search, page summaries, and a first-line support answer — pick one and ship it before adding more.

Smarter search is the highest-value, lowest-risk starting point. Instead of matching keywords, you send the visitor's query plus your own page snippets to Gemini and ask it to answer from that context. This is retrieval-augmented generation, and the trick is grounding: you supply the source text, so the model summarises your content rather than inventing answers. Store your page content as embeddings, retrieve the top few chunks per query, and pass those in.

Summaries work well for long product descriptions, documentation or blog archives. Generate them at publish time, not per visitor — a batch job that summarises once and caches the result means zero per-visitor data leaves your site, since the input is your own content.

Support answers carry the most risk because visitors type personal details into chat boxes. If you go here, be strict: a clear notice that AI handles the message, PII stripping before the call, and an easy handoff to a human. Speaking of which — our own support is real engineers, not a bot, 24/7, and we think that is the right model. Let AI handle the repetitive lookups and keep a person for anything that matters.

FeatureData riskGood default
On-site search (grounded)LowSend query + your snippets only
Content summariesVery lowGenerate at publish time, cache
Support chatHigherStrip PII, notice, human handoff

Getting your paperwork right without a legal team

Two documents cover most of your GDPR obligations, and neither needs a lawyer: an updated privacy policy entry and a signed Data Processing Addendum with Google. You can handle both in an afternoon.

In your privacy policy, name Google as a processor, state that AI features may process the text visitors submit, and note that processing happens in the EU with SCCs covering any transfer. Add Gemini to your record of processing activities and, if the feature is central to your service, run a short Data Protection Impact Assessment.

That DPIA does not need to be a formal document. A one-page data-flow note that answers these six lines is far better than nothing, and you can copy the headings straight into a text file:

  • Data collected: e.g. the visitor's typed query text only; no account or contact fields.
  • Purpose: e.g. answer on-site search from our own content.
  • Region: e.g. Vertex AI, europe-west4.
  • Transfer mechanism: e.g. Google Cloud DPA with Standard Contractual Clauses.
  • Retention: e.g. request metadata for 30 days; no transcripts stored.
  • Access: e.g. two named admins; service-account key in an env var, rotated quarterly.

Accept Google Cloud's DPA in the console; it is a checkbox during setup, not a lawyer's negotiation. If a visitor ever files a data request, that one page is your answer.

A realistic path to launch

Resist wiring everything at once. Grounded search on a staging site is the right first move — run it for a week, then decide whether support chat is worth the extra care.

The order that works: get the server proxy running with a Vertex AI key in an EU region, prove it on your own content with no visitor data, add PII stripping and rate limiting, then point one small feature at it. Watch your logs, watch your bill, and only expand once you trust it.

The hosting side is deliberately boring, and that is the point. Your proxy, your site and your data sit together in an EU data centre, we are GDPR-friendly by default, and if the whole experiment does not pan out you have 30 days to back out. Free migration means you can move an existing site over to try this without a weekend of downtime.

If you want to build it on hosting that keeps everything in the EU, you can start at tpc-hosting.com.

FAQ

Can I use the free Gemini API for a public feature on my EU website?

For a public feature handling real visitor data, no — use Vertex AI in an EU region instead. The free AI Studio API gives weak data-residency guarantees and may use your inputs to improve Google's service, which makes it hard to justify under GDPR. It is fine only for prototyping on dummy data.

Does adding Gemini mean visitor data leaves the EU?

Not if you pin processing to a European region like europe-west4 and call the API from your own server. The data stays physically in Europe, and Google's Standard Contractual Clauses in its Data Processing Addendum cover the fact that Google is a US company. Client-side calls, by contrast, send visitor IPs straight to Google with no control.

Do I need a Data Protection Impact Assessment?

You need one if the AI feature is central to your service or processes sensitive data, and it is good practice either way. For a simple grounded-search feature a short one-page note on data flows and mitigations is usually enough. For a support chatbot handling personal details, do a proper DPIA.

How do I stop Gemini seeing my visitors' personal details?

Strip personal data server-side before the request ever reaches Google. Run a regex or a tool like presidio to remove emails, phone numbers and names from the text, and design features so they never need identifying data in the first place. Grounded search and summaries usually need only the query and your own content.

Where should I run the server proxy that calls Gemini?

Run it in an EU data centre, ideally alongside your website. Keeping the proxy and site in the same European location means the only cross-border hop is the controlled, documented one to Google's EU region. A small Node or PHP service on a standard TPC Hosting plan handles this comfortably.