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

OpenAI, Claude, and Gemini can be used in Europe in a GDPR-compliant manner, just not in the standard setup. Those who simply connect the APIs often unknowingly send personal data to the US. This article shows what the three providers actually do with your data, why direct use is legally risky, and the three ways you can 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. DPA, legal basis, and the handling of logs, embeddings, and caches are also part of it.

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

"The models run 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 daily use. None of the major providers have EU processing set as the default. It is an option that you must actively set.

What OpenAI, Claude, and Gemini Really Do with Your Data

Before thinking about compliance, take a sober look at where queries 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 for each project. It is not included in ChatGPT Plus. The most common mistake here: confusing the billing 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 that can be selected by the customer. Commercial data is processed across multiple regions. Anyone who wants to use Claude with EU data residency cannot avoid deploying it via AWS Bedrock (Frankfurt, Ireland, Paris) or Google Vertex AI. This then involves your own cloud contracts, IAM, and billing.

Google Gemini

Gemini's Developer API runs on global infrastructure without reliable region pinning. An EU region can only be locked down via Vertex AI. 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.

With all three, the same dangerous assumption lurks: that the enterprise promises from the marketing material also apply to the exact plan you use in production.

Why Direct API Use in Europe Becomes a Legal Risk

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

1. Third-country transfer without configuration.
Without an explicitly set EU region, personal data leaves the EU. This constitutes a transfer to a third country within the meaning of Articles 44 to 46 GDPR. Since the ECJ ruling "Schrems II" (July 16, 2020, C-311/18), this is only permissible with an additional case-by-case assessment, and 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 disclose it under the CLOUD Act. Data residency alone does not protect against access if the provider is subject to US law. Jurisdiction therefore matters alongside the server location.

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

The Three Most Common Misconceptions

Before looking at the solutions: Three assumptions come up in almost every discussion, and none of them hold up under scrutiny.

"We anonymize the data beforehand."
In practice, this is rarely done consistently enough. Free-text fields, support tickets, and open chat histories make true anonymization complex—and under time pressure, it gets skipped. The European Data Protection Board also clarified in its opinion 28/2024 that even a model trained with personal data is not automatically considered anonymous; this is always a case-by-case assessment. We describe what robust redaction must look like technically in Redacting personal data.

"But the provider has standard contractual clauses."
SCCs are necessary, but not sufficient. Since the Schrems II ruling (ECJ, July 16, 2020, C-311/18), data controllers must additionally check in each individual case whether there is actually an adequate level of protection in the destination country—an effort that falls back on each individual company when using a direct connection.

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

And what about the EU-US Data Privacy Framework?

Since July 2023, the adequacy decision on the EU-US Data Privacy Framework allows transfers to certified US companies without additional SCC assessments. This eases the situation, but does not resolve it: The decision only applies to certified recipients, does not cover every scenario, and remains under legal scrutiny. Although the General Court of the EU dismissed the lawsuit brought by MP Philippe Latombe on September 3, 2025, the appeal is still pending before the ECJ (Case C-703/25 P). Anyone who bases their architecture on the continuation of an adequacy decision is building on a foundation that has already fallen away twice—Safe Harbor in 2015, Privacy Shield in 2020.

Comparison of Direct Connection and EU Gateway

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 queries via the EU endpoint. Then, check whether the desired model and endpoint are actually released for the EU region. Not every model is.

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

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

The price of this path: three separate DPAs, three audit trails, three billing relationships. On top of that, there 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

• Query processing exclusively on EU infrastructure

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

• DPA according to Art. 28 GDPR included without a negotiation marathon

• 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 advantage is huge: one API key, one endpoint, model changes via parameter. Routing, logging, and compliance are centrally located in one place. This shrinks the GDPR attack surface from "per provider" to "once, centrally regulated."

This is how kontinent.ai works: You retain 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 for each 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 a single model, vLLM for production-ready, OpenAI-compatible operation, Open WebUI as a self-hosted 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 take a hybrid approach: self-hosting sensitive workloads, and routing 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 under Art. 28 GDPR. That remains mandatory.

International Transfers. A server in Frankfurt does not rule out sub-processors accessing it from outside the EEA. If they do, standard contractual clauses apply once 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 your exact productive plan, model, and endpoint

• DPA signed under Art. 28 GDPR, 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 toward users

• Human oversight documented for significant 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 come with 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 a GDPR-compliant manner?

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 that allow a person to be identified. This can easily end up in a support ticket or chat history.

Is a 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 regulates processing by a service provider in accordance with Art. 28 GDPR and is always required. Standard contractual clauses are additionally required as soon as data is transferred to a third country without an adequacy decision. A checklist for this is available in DPA for AI Tools.

What does the Schrems II ruling state?

On July 16, 2020 (C-311/18), the ECJ declared the EU-US Privacy Shield invalid. Since then, simply referring to standard contractual clauses is no longer enough—companies must also check in each individual case 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 such as 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. Both count for resilient protection.

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)

• ECJ, 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

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