GDPR-compliant AI is not a product you buy. It is a setup where you have a lawful basis for the data, a signed processor contract, a known data location, short retention, and no training on your inputs. Five setups meet that bar. An EU-hosted inference API with zero data retention suits developers shipping products. Managed AI from a big cloud suits companies already under a cloud contract. Self-hosting suits regulated teams with steady volume. Business-tier assistants suit everyday staff use. A redaction layer suits anyone sending free text to any model.
The problem is familiar. Someone pastes a customer email, a CV, or a support ticket into an AI tool, and legal asks whether that was allowed. The answer depends on the vendor's terms, the region where the data is processed, and what you wrote down beforehand. Fines for serious breaches reach €20 million or 4% of global annual turnover.
This article explains what to check in any vendor, then walks through five setups in order, from the most turnkey for developers to the most general. Geodd runs inference infrastructure with regions in the US and Norway, so we list ourselves first and say plainly where another option fits better.
What makes an AI tool GDPR-compliant
An AI tool is GDPR-compliant when you can use it with personal data and still meet your duties as the data controller. That takes a lawful basis, a processor contract, controlled data location, limited retention, and a way to honor deletion and access requests. The vendor supplies the controls. You supply the legal basis.
Compliance is shared work
GDPR stands for General Data Protection Regulation. It applies to any organization, including US ones, that offers goods or services to people in the EU or monitors their behavior. A US company with EU customers is in scope. The top fine tier is €20 million or 4% of global annual turnover, whichever is higher.
Before you pick a tool, write down your purpose and lawful basis. If the processing is high risk, such as profiling or large-scale use of sensitive data, run a Data Protection Impact Assessment under Article 35.
A vendor can make compliance possible, but only you can make it lawful.
Seven checks for any vendor
Run every candidate through the same filter. If a vendor cannot answer a row in writing, treat that row as a no.

| Check | What to ask for | Why it matters |
|---|---|---|
| Processor contract | Signed data processing agreement (Article 28) | Required when a vendor handles personal data for you |
| Training use | Written confirmation that your inputs do not train models | Keeps your data out of other users' outputs |
| Data location | Named processing region with an EU option | Limits cross-border transfer risk |
| Transfer mechanism | Adequacy decision or standard contractual clauses | Needed whenever data leaves the EU |
| Retention | Zero or short, documented retention of prompts and outputs | Storage limitation principle |
| Sub-processors | Published list with change notice | You answer for the whole chain |
| Rights handling | Process for erasure and access requests | Data subject rights |
1. Geodd, an EU-hosted inference API
How it handles personal data
Geodd runs serverless and dedicated inference for open-weight models behind an OpenAI-compatible API. Active regions are US-EAST and EU-NORTH in Norway, and a Zero Data Retention policy means prompts and outputs are not kept after a request. To migrate from another provider, you change the provider settings in the OpenAI SDK.

Zero retention removes the biggest GDPR risk of an API: your prompts sitting in someone else's logs.
Details differ per model. The GPT-OSS-120B page lists regional endpoints and data handling for that model, and DeepSeek V4.1 Flash and GLM 5.3 Flash have their own pages. Do not assume every model is in every region. Confirm the EU-NORTH endpoint for the one you pick, so GDPR-compliant AI holds in production and not only on paper.
Who it suits and the catch
This fits developers building products on text models, especially EU companies that want the OpenAI SDK workflow without routing customer data through a US region. It also suits teams that may move from serverless to dedicated later, since the inference service covers both.
The catch is certification. Geodd describes its data handling as GDPR-ready, but SOC 2 is still pending. If procurement requires a finished report, ask for the current status. You also still need a signed data processing agreement and your own documented lawful basis.
2. Managed AI from a major cloud provider
How it handles personal data
The large cloud providers sell managed model access, with Azure OpenAI Service as the common example. You deploy in a chosen EU region under the cloud's standard data processing terms, and your existing enterprise agreement usually already carries a DPA. Some deployment types route requests across regions, so pick a regional deployment and read the data location terms for that exact model.
Choose the deployment type before you choose the model, because the deployment type decides where your data goes.
Check the transfer basis too. Most of these providers are US companies, so data access from outside the EU is a legitimate question. The EU-US Data Privacy Framework adequacy decision from July 2023 covers certified companies, and standard contractual clauses are the usual fallback. Ask which one your contract relies on.
Who it suits and the catch
This suits companies already committed to one cloud, with legal and security teams that have vetted it. Procurement is fast because the paperwork exists. It is a sound route to GDPR-compliant AI for mid-size and large organizations.
The catch is choice. You get the models the provider lists, in the regions it supports, with its quota rules. If you need a specific open-weight model in an EU region, the catalog may not have it.
3. Self-hosted or dedicated open-weight models
How it handles personal data

You run an open-weight model on servers you control, in an EU data center. Prompts never reach a shared inference service, so there is no model vendor in the data path. If you rent the hardware, the host is still a processor and needs a DPA. With dedicated GPU servers, you get single-tenant hardware and server-level control of the software stack.
Self-hosting shrinks the vendor chain, but it moves every security duty onto your team.
Logs are the hidden trap. Request logs that capture prompts are personal data, so set a retention schedule and a deletion job on day one. Do the same for caches, vector stores, and fine-tuning datasets.
Who it suits and the catch
This suits regulated teams in health, legal, finance, or HR with steady, high volume and ML operations staff. At that volume, a fixed-capacity server can also be cheaper than per-token billing, which the pricing page helps you estimate.
The catch is ownership. You handle patching, access control, uptime, and capacity planning. Low or spiky volume rarely justifies it. Start serverless and move to dedicated hardware only when utilization and compliance needs justify the operational load.
4. Business-tier AI assistants
How it handles personal data
Business and enterprise plans of the major assistants, including ChatGPT, Claude, Copilot, and Gemini, typically add a data processing addendum, admin controls, and no training on your data by default. Free consumer accounts do not give you that. So the honest answer to "is ChatGPT GDPR compliant?" or "is Claude GDPR compliant?" is that it depends on the plan and settings you use.
The same assistant can be unsafe on a free account and defensible on a managed business plan.
Regulators do act on consumer products. Italy's data protection authority fined OpenAI €15 million in December 2024. Read the current terms of your plan before you rely on any default.
Who it suits and the catch
This suits non-technical staff who need drafting, summarizing, and research help without any engineering work. IT assigns seats, enforces single sign-on, and turns off optional features that widen data flows, such as memory, connectors, or web search.
The catch is shadow use. Staff who paste client data into personal accounts defeat the whole setup. Publish a short acceptable-use policy, block consumer sign-ins on work devices where you can, and train people on what never goes into a prompt.
5. A redaction and pseudonymization layer
How it handles personal data
You strip identifiers before the prompt leaves your system. Names, emails, phone numbers, and IDs become placeholders, the model works on the placeholders, and your code maps them back in the response. Open-source detectors such as Microsoft Presidio do the detection. This layer sits in front of any of the four setups above.
| Raw input | Sent to the model |
|---|---|
| Anna Weber ([email protected]) reports a billing error | PERSON_1 (EMAIL_1) reports a billing error |
Pseudonymized data is still personal data, because you hold the key to reverse it.
That nuance matters. Under GDPR, only truly anonymized data falls outside the rules. Pseudonymization lowers risk and supports data minimization, but your lawful basis and DPA still apply.
Who it suits and the catch
This suits teams processing free text at volume, such as support tickets, emails, call transcripts, and notes. It pairs well with any API, including a GDPR-compliant AI endpoint chosen from the options above.
The catch is detection quality. Automated tools miss unusual name formats and indirect identifiers, like a rare job title in a small town. Test on real samples, measure the miss rate, and treat the layer as risk reduction, not a free pass.
Pick one setup and document it
Start from your data, not from the tool. Developers shipping products usually want an EU-hosted API with zero retention. Companies on a major cloud can stay there with a regional deployment. Regulated, high-volume teams should price self-hosting. Staff who just need an assistant need a business plan and a clear policy. Add redaction whenever the input is free text.
Whichever you choose, run the seven checks, sign the processor contract, and record your purpose, lawful basis, and region choice. That record is what regulators ask to see.
If you want to test the first option, review GPT-OSS-120B regional endpoints and data handling on Geodd and confirm the EU-NORTH endpoint fits your requirements.



