Is OpenAI GDPR-compliant? What EU firms need to know

“Compliant” means two different things

Before anyone can answer whether OpenAI is GDPR-compliant, the question has to be split, because “compliant” is doing two jobs at once. One is procedural: are the contracts, the terms, the data-processing agreement and the technical safeguards such that you, the customer, can satisfy the GDPR’s accountability requirements? The other is jurisdictional: can a non-EU state force the provider to hand over the data, no matter what the contract says?

These are not the same axis, and conflating them is how most of the confusion happens. A provider can be procedurally airtight and still jurisdictionally exposed. Conversely, a provider can be jurisdictionally clean and procedurally sloppy. When an EU company asks “is OpenAI GDPR-compliant?”, it is usually really asking the second question — can US law reach my data — even when it uses the word “compliant”.

What the GDPR actually requires

The GDPR regulates the processing of personal data of people in the EU. For a tool like an LLM API, the relevant provisions are the ones about lawful basis, data minimization, purpose limitation, transparency and, critically, international transfers. If you send a user’s prompt containing personal data to an API, you are a data controller transferring personal data, and you need a legal basis that holds up.

None of this is unique to OpenAI. Any LLM provider — US or EU — is a data processor in this picture, and the obligations fall mostly on you, the data controller. So the procedural part of “is OpenAI GDPR-compliant” is largely a question of whether OpenAI’s Data Processing Addendum and terms give you what a controller needs. For a wide range of EU companies, they do; that is not a controversial claim. But if you have a data protection officer (DPO) on staff, they will likely ask a follow-up: have you run a data transfer impact assessment for the personal data processing that this API represents, and what happens when a US court order reaches the processor?

The transfer problem: SCCs and adequacy

The friction enters with international transfers. If you are an EU company sending personal data to a US provider, that is a transfer outside the EEA, and it needs Chapter V of the GDPR to be satisfied. In the absence of an adequacy decision, the standard mechanism is a set of Standard Contractual Clauses (SCCs) — a signed contract that obliges the receiver to protect the data to EU standards.

SCCs are real and statutory; they are not a workaround. But after Schrems II (CJEU, 2020), relying on SCCs to a country like the US carries an obligation to assess whether the recipient can actually honour them — against the backdrop of US surveillance law, including the CLOUD Act. That is why the “is it compliant” answer depends on your risk posture: for many companies the SCC route is adequate; for others — regulated sectors, certain contractual obligations, a hard requirement that no US court can reach the data — it is not enough.

The CLOUD Act is a jurisdictional lever, not a bug

The US CLOUD Act (2018) lets US law-enforcement and intelligence agencies compel a US company to disclose data it controls, regardless of where that data is stored. It does not matter whether the servers sit in Virginia or Frankfurt: the obligation attaches to the company, not the machine.

This is the part that no contractual clause can fully neutralise. A US provider can be perfectly cooperative with the GDPR, sign every SCC, encrypt everything in transit and at rest — and still be subject to a legal order, backed by the threat of contempt, that a court in Paris or Berlin cannot veto. For most companies this never comes up. For the ones whose whole reason to exist is “no US company can be ordered to hand over our data”, it is decisive.

Provider by provider: OpenAI, Microsoft, Anthropic

It helps to be specific, because these three are often lumped together and they are not identical.

• OpenAI. A US company, subject to the CLOUD Act. Can be used GDPR-compliantly in the procedural sense; jurisdictionally, it is a US company.
• Microsoft (Azure OpenAI). Microsoft is a US company too. Its EU regions are real, but “EU region” is not the same as “not subject to US law” — a US company remains a US company wherever the region sits.
• Anthropic. Likewise a US company, subject to US law, even though its API is enormously popular with European developers.

The pattern is the shared one: these are all US-controlled entities. None of them is “EU sovereign”, and no contractual arrangement changes who owns and controls the company.

Your obligations as controller

“Is OpenAI GDPR-compliant” risks reframing the question in a way that hides your own role. Under the GDPR, when you send personal data to an LLM API, you are the controller and the provider is a processor. A large part of compliance lives on your side of the relationship, whatever provider you pick:

• Lawful basis. You need a valid basis for processing — consent, contract, legitimate interest, legal obligation — and it has to be documented.
• Data minimization. Send only the personal data the task actually needs. A surprising amount of “GDPR problem” with LLM APIs is really “we sent far more personal data than we needed to”.
• Purpose limitation. Data collected for one purpose cannot silently be reused for an unrelated one — including model training, unless that is disclosed and separately justified.
• Records (Article 30). You should be able to show a record of processing, which for an API includes knowing what went to which provider and why.
• Rights and retention. Subject-access requests and retention limits apply to what you hold, which includes the logs and transcripts you keep of your calls.

The jurisdictional question (CLOUD Act) sits on top of all of this and is orthogonal to it. A sovereign provider helps with the transfer side; it does not discharge your controller obligations. Conversely, being scrupulous about minimization makes whichever provider you choose easier to defend. Both layers matter, and neither is optional if the task genuinely calls for personal data.

When this matters for your workload

Getting the risk framing right matters more than a wishy-washy verdict, so here is the practical line we would draw.

• If you are a startup or a small company building a consumer product, and your data-processing agreement plus SCCs satisfy your counsel, OpenAI being a US company is very often an acceptable trade-off. That is a legitimate choice.
• If you serve a regulated sector — health, public procurement, legal, some financial services — or a customer whose contract says “no data processed under non-EU jurisdiction”, then the US personality of the provider is the problem, not the paperwork. No SCC vaults over it.
• If you are building for a government or a public body with explicit sovereignty requirements, only a provider that is genuinely outside non-EU control closes the loop.

None of this is OpenAI-specific moralising. It is the same test we apply to ourselves in reverse: we label every model sovereign or fast access based on who controls the operator, not where the region is — and we never call a US-run model sovereign.

The EU-sovereign alternative

The alternative is not “no AI” — it is running open-source models on infrastructure operated by companies with no non-EU capital or jurisdictional control. When the operator is, say, OVHcloud or Scaleway, the CLOUD Act has no hook on the company itself, and the GDPR discussion is no longer dominated by the transfer question. That is the whole position Frontière AI is built on: the same open-source weights you could call from OpenAI, served through EU-controlled infrastructure, behind one OpenAI-compatible API you already know how to call.

It is not about pretending OpenAI is bad — it is about giving the buyer who has a hard jurisdictional requirement the option that a US-run API, however well run, structurally cannot be.

FAQ