Using OpenAI, Claude, and Gemini in Europe – without GDPR risk

OpenAI, Claude, and Gemini can be used in compliance with the GDPR in Europe, but just not in the default setup. Anyone who simply integrates the APIs often unknowingly sends personal data to the US. This article shows what the three providers actually do with your data, why direct use is legally risky, and which three ways you can use to deploy the models cleanly.

Key Takeaways

• EU data residency is not the default for OpenAI, Claude, and Gemini, but an option that depends on the plan, model, and endpoint.

• Three paths lead to compliant use: the providers' native EU options, an EU gateway, or self-hosting open models.

• Data residency alone is not enough. DPAs, legal basis, and the handling of logs, embeddings, and caches are also part of it.

• In addition to server location, jurisdiction matters (US CLOUD Act), and the EU AI Act comes as a second set of regulations.

„The models are running in Europe, we selected an EU region.“ We hear this sentence often, and most of the time it is not true. Where it is true, data residency depends on a specific plan, a specific model, and a specific endpoint that is easily overlooked in everyday life. For none of the major providers is EU processing preconfigured. It is an option that you must actively set.

What OpenAI, Claude, and Gemini actually do with your data

Before you think about compliance, look soberly at where requests are processed by the three providers and under what conditions.

OpenAI

OpenAI offers EU data residency, but not for everyone. It is reserved for eligible API, Enterprise, and Edu customers and must be actively selected per project. It is not included in ChatGPT Plus. The most common mistake here: confusing the billing entity's address with the location of data processing. Where your invoice is issued says nothing about which region your prompts run in.

Anthropic / Claude

Through the direct Anthropic API, there is no EU-only residency selectable by the customer. Commercial data is processed across multiple regions. Anyone wanting to use Claude with EU data residency cannot avoid deployment via AWS Bedrock (Frankfurt, Ireland, Paris) or Google Vertex AI. This then includes your own cloud contracts, IAM, and billing.

Google Gemini

Gemini's Developer API runs on global infrastructure without reliable region pinning. Only through Vertex AI can an EU region be locked down. The classic misconception here: confusing the commitments of the Enterprise platform (Vertex AI) with the freely accessible Developer API. These are two different products with very different guarantees.

For all three, the same dangerous assumption lurks: that the Enterprise commitments from the marketing material also apply to exactly the plan you use in production.

Why direct API use in Europe becomes a legal risk

Three developments turn a convenient standard integration into a tangible risk.

1. Third-country transfer without configuration.
Without an explicitly set EU region, personal data leaves the EU. This is a transfer to a third country within the meaning of Articles 44 to 46 GDPR. Since the CJEU ruling „Schrems II“ (July 16, 2020, C-311/18), it is only permissible with an additional case-by-case assessment, not solely on the basis of Standard Contractual Clauses.

2. US CLOUD Act despite EU hosting.
Even if data is physically located in the EU, a US parent company can be forced to hand over data via the CLOUD Act. Data residency alone does not protect against access if the provider is subject to US law. In addition to the server location, jurisdiction therefore also counts.

3. EU AI Act with stricter fines.
The EU AI Act is applicable law with phased deadlines. Transparency obligations under Art. 50 have applied since August 2, 2026; high-risk obligations were postponed by the Digital Omnibus to December 2, 2027 (Annex III). Violations of prohibited practices cost up to 7% of worldwide annual turnover. That is more than the 4% of the GDPR. Anyone who uses AI without a clean legal basis and transparency gets a second set of rules added to the existing data protection risk.

The three most common misconceptions

Before moving on to the solutions: Three assumptions turn up in almost every discussion, and none of them hold up well enough.

„We anonymize the data beforehand."
In practice, this rarely happens consistently enough. Free text fields, support tickets, and open chat histories make real anonymization complex – and under time pressure, it is skipped. The European Data Protection Board has also clarified in its Opinion 28/2024 that even a model trained on personal data is not automatically considered anonymous; this is always a case-by-case assessment. What robust redaction looks like technically is described in Redacting personal data.

„But the provider has Standard Contractual Clauses."
SCCs are necessary, but not sufficient. Since the Schrems II ruling (CJEU, July 16, 2020, C-311/18), controllers must additionally assess in each individual case whether there actually is an adequate level of protection in the target country – an effort that, with a direct connection, remains the responsibility of each individual.

„We are small, nobody audits us."
Complaints rarely come from supervisory authorities first. They come from data subjects, from competitors, and increasingly from customers who want to see your sub-processor list in their own audits.

And the EU-US Data Privacy Framework?

Since July 2023, the adequacy decision on the EU-US Data Privacy Framework has allowed transfers to certified US companies without additional SCC assessment. This defuses the situation but does not solve it: the decision only applies to certified recipients, does not cover every constellation, and remains under legal scrutiny. Although the General Court of the EU dismissed the lawsuit by MEP Philippe Latombe on September 3, 2025, the appeal against this is still pending before the CJEU (Case C-703/25 P). Anyone who bases their architecture on the continued existence of an adequacy decision is building on a foundation that has already vanished twice – Safe Harbor in 2015, Privacy Shield in 2020.

Direct Integration and EU Gateway in Comparison

Path 1: Configure the providers' native EU options

The most direct way is to set up EU processing yourself with each provider.

OpenAI: Create a new project in the organization settings, select the Europe region, and route requests via the EU endpoint. Then check whether the desired model and the endpoint are actually approved for the EU region. Not every model is.

Claude: Deploy via AWS Bedrock (Frankfurt, Ireland, Paris) or Vertex AI. You then manage IAM, billing, and logging of the cloud separately. This is additional operational effort and at the same time the only clean way to EU residency.

Gemini: Via Vertex AI with a supported EU endpoint. In the SDK initialization, you set the location parameter, and for direct REST calls, you address the request to an EU region like europe-west4-aiplatform.googleapis.com.

The price of this path: three separate DPAs, three audit trails, three billing relationships. Added to this is a real risk of misconfiguration as soon as multiple teams deploy in parallel.

Path 2: Route all three through an EU gateway

Instead of securing each provider individually, you bundle access behind an EU gateway. You can recognize a resilient EU gateway by these criteria:

• Company headquarters and jurisdiction in the EU

• Request processing exclusively on EU infrastructure

• Zero Data Retention as standard, not as an add-on option

• DPA according to Art. 28 GDPR included without negotiation marathons

• Certifications such as SOC 2 and ISO 27001

A more detailed selection checklist is available in the article on what companies need to consider regarding the EU AI Act when choosing an AI gateway. The operational benefit is major: one API key, one endpoint, model change via parameter. Routing, logging, and compliance are centrally located in one place. This shrinks the GDPR attack surface from „per provider“ to „once, centrally managed“.

This is how kontinent.ai works: You keep access to OpenAI, Claude, Gemini, and Mistral, but via a deployment hosted in the EU with a single contract partner. The data does not leave the EU. This path is best suited for multi-model products, fast-working teams, and anyone who does not want to allocate a separate compliance or platform department per provider.

Path 3: Self-host open-source models in the EU

If you want maximum control, host open models yourself on European infrastructure.

Models: Mistral Large (Apache 2.0, French company), the Mixtral family, or Meta Llama under the community license are serious candidates.

Infrastructure: OVHcloud and Scaleway in France, Hetzner and IONOS in Germany, all with EU headquarters and EU data centers.

Tools: Ollama for an easy start with one model, vLLM for production-ready, OpenAI-compatible operation, Open WebUI as a self-hosted user interface.

The price of control is operations. Updates, scaling, security, and monitoring are entirely up to you, there is no SLA, and for demanding tasks there is often a quality gap compared to frontier models. Many therefore run a hybrid model: sensitive workloads self-hosted, the rest via a gateway.

What data residency alone does not solve

An EU server location is necessary, but not sufficient. Four points remain unaffected by it.

Legal basis. Residency does not replace a legal basis. You still need performance of a contract, legitimate interest, or consent before personal data is processed.

DPA. An EU server does not replace a Data Processing Agreement according to Art. 28 GDPR. That remains mandatory.

International transfers. A server in Frankfurt does not exclude sub-processors outside the EEA from accessing it. Then Standard Contractual Clauses apply again.

Prompts are not the only data. Personal data is also contained in uploaded files, outputs, logs, embeddings, and caches. The same retention and deletion rules apply to all of this.

Checklist before Go-Live

• EU residency verified for exactly your productive plan, your model, and your endpoint

• DPA according to Art. 28 GDPR signed, not just relying on the T&Cs

• Transfer mechanisms (SCCs) documented for any access outside the EEA

• Legal basis checked before personal data is sent

• Logs, traces, and caches audited for stored personal data

• Transparency obligation under Art. 50 EU AI Act fulfilled towards users

• Human oversight documented for material decisions

• Record of processing activities (Art. 30 GDPR) updated

For high-risk cases such as health, recruiting, creditworthiness, or biometrics, this checklist does not replace a full legal assessment.

Frequently Asked Questions

Is OpenAI GDPR-compliant?

That depends on the plan and configuration. With the EU data residency option for eligible API and Enterprise customers and a signed DPA, OpenAI can be operated compliantly. ChatGPT Plus does not include a DPA or selectable EU residency and is therefore not suitable for processing personal business data.

Does Claude store data in Europe?

Not reliably via the direct Anthropic API. You can only achieve EU data residency via AWS Bedrock (Frankfurt, Ireland, Paris) or Google Vertex AI in an EU region.

Can Gemini be used in compliance with GDPR?

Only via Vertex AI with an EU endpoint. The freely accessible Developer API does not offer reliable region pinning and is therefore critical for personal data.

What actually counts as personal data in a prompt?

Names, email addresses, IP addresses, account and customer numbers, free text with personal references, and indirect identifiers through which a person can be identified. This is easily contained in a support ticket or chat history.

Is reference to the provider's T&Cs enough?

No. A DPA according to Art. 28 GDPR is required and, in the case of third-country relations, documented Standard Contractual Clauses. The statement in the fine print is not sufficient.

What is the difference between a DPA and Standard Contractual Clauses?

A Data Processing Agreement (DPA) regulates processing by a service provider according to Art. 28 GDPR and is always required. Standard Contractual Clauses are additionally added as soon as data is transferred to a third country without an adequacy decision. A checklist for this can be found in DPA for AI Tools.

What does the Schrems II ruling state?

On July 16, 2020 (C-311/18), the CJEU declared the EU-US Privacy Shield invalid. Since then, mere reference to Standard Contractual Clauses is no longer sufficient – companies must additionally assess in individual cases whether the third country offers an adequate level of protection and, if necessary, take additional measures.

Are there European alternatives to GPT and Claude?

Yes. Mistral from France is a serious alternative for many use cases, along with open models like Mixtral or Llama on European infrastructure. Which EU routers bundle these is shown in our Comparison of GDPR-compliant LLM Routers.

Data residency or data sovereignty: what matters?

Residency describes the location of processing, sovereignty the legal control over it. A US provider can host in the EU and still be subject to US law. For resilient protection, both matter.

Sources

• Regulation (EU) 2016/679 (GDPR) – Art. 28, Art. 44–49

• Regulation (EU) 2024/1689 (AI Act) and Regulation (EU) 2026/1744 (Digital Omnibus on AI)

• EDPB, Opinion 28/2024 on AI models (18.12.2024)

• CJEU, Judgment of 16.07.2020, C-311/18 („Schrems II") · General Court, Judgment of 03.09.2025 (Latombe), appeal C-703/25 P pending

• OpenAI, Data residency for the OpenAI API

• Google Cloud, Vertex AI data residency

Status: August 27, 2026 · kontinent.ai. Legal status checked against EUR-Lex and provider documentation; no legal advice.