Is it GDPR-compliant to send customer data to OpenAI?

When does GDPR apply to an LLM prompt?

GDPR applies when you process personal data of people in the EU (or you are established there). Personal data is any information relating to an identifiable person: a name, an email address, an order number tied to an account, a phone number in a support ticket.

There is no prompt exception. If your support bot forwards "Hi, I'm Sarah Chen, sarah@acme.com, my card was charged twice" to the OpenAI API, you just processed personal data and disclosed it to a third party. The same is true for background jobs, evals, and fine-tuning datasets, not just live chat.

If your prompts genuinely contain no personal data (say, you only send product descriptions you wrote yourself), most of this post does not apply to you. The honest first step is knowing which case you are in, and that means actually reading what your app sends.

What is OpenAI, legally, in this relationship?

In GDPR terms, you are the controller (you decide why and how customer data is processed) and OpenAI is a processor: it processes personal data on your behalf, on your instructions, to deliver the API service. If you are yourself a processor for your customers, OpenAI becomes a sub-processor, and your own contracts likely require you to disclose it.

Article 28 says a controller-processor relationship must be governed by a written contract with specific required terms. This is the Data Processing Agreement, or DPA. It is not optional paperwork; without it, the disclosure itself is the compliance gap, regardless of how well OpenAI behaves.

What paperwork do you actually need?

1. Sign the DPA. OpenAI offers one for API customers. If you have never seen it, nobody at your company has signed it.
2. Update your sub-processor list. If your privacy policy or customer contracts list sub-processors, OpenAI belongs on that list, and many contracts require notifying customers before adding one.
3. Update your records of processing (Article 30). The AI feature is a processing activity: what data, what purpose, what recipient, what retention.
4. Check your lawful basis. Whatever basis covers the underlying activity (contract, legitimate interests) needs to plausibly extend to the AI processing. A legitimate-interests assessment is worth writing down.
5. Consider a DPIA. If the AI feature processes data at scale or touches sensitive categories, a Data Protection Impact Assessment (Article 35) may be required, and is a good exercise either way.

On the training question: per OpenAI's published terms, API and enterprise data is not used to train models by default. That is a real and useful commitment. It is also a separate question from whether the disclosure itself was lawful, so it does not replace the DPA or the transfer analysis.

Does sending data to a US company break the transfer rules?

Chapter V of GDPR (Article 44 onward) restricts transfers of personal data outside the EU unless a valid mechanism covers them. For US companies there are two common ones today.

The first is the EU-US Data Privacy Framework: if the US company is certified under it, transfers to that company are covered by an adequacy decision. The second is Standard Contractual Clauses (SCCs), contract terms approved by the European Commission, usually bundled into the DPA.

Practically: check whether your provider is DPF-certified, and check what transfer mechanism its DPA relies on. Also note where processing actually happens; some providers offer EU data residency options, which simplifies but does not remove the analysis.

What technical measures does GDPR expect?

Article 32 requires "appropriate technical and organisational measures" proportionate to the risk. Article 5(1)(c) adds data minimisation: process only the personal data you actually need for the purpose. Both point at the same practical question. Does the model need the real email address to answer the ticket?

Usually it does not. Redacting or pseudonymising personal data before the prompt leaves your infrastructure is the strongest technical measure available for this path, because data that never reaches the processor needs no safeguards at the processor. GDPR itself recognizes pseudonymisation as a risk-reducing measure (Recital 28 and Article 32 both mention it).

To be precise about what redaction does and does not do: it reduces risk and demonstrates minimisation, but it does not "make you compliant" by itself, and reversible pseudonymised data is still personal data in your own hands. It shrinks what the provider sees; your obligations as controller remain. The mechanics of doing this without breaking your UX are covered in our complete guide to PII redaction for LLM apps.

What have regulators signaled, and where does the EU AI Act fit?

European regulators have made clear that GDPR applies fully to AI systems; there is no AI grace period. Italy's Garante temporarily restricted ChatGPT in 2023 over transparency and lawful-basis concerns, and the EDPB has since run a coordinated look at how data protection law applies to LLM services. The direction of travel is scrutiny, not exemption.

The EU AI Act is a separate law layered on top of GDPR, with its own obligations based on how risky the AI use is. Key obligations apply from August 2, 2026, and the most serious violations carry fines of up to 7% of global annual turnover. For most teams calling an LLM API the practical takeaway is not panic; it is that "we never looked at what our AI feature sends" is aging badly as a posture.

What do you need for each type of data?

So, is it compliant or not?

It can be. A team that signed the DPA, listed OpenAI as a sub-processor, confirmed the transfer mechanism, minimised what the prompts contain, and wrote it all down has a defensible position. None of those steps is exotic or expensive.

The uncomfortable truth is simpler: most teams have done none of them, because the AI feature shipped in a sprint and the data-handling review never happened. If that is you, the fix is a checklist, not a crisis. Start by reading one real request your app sends, then work down the table above.

This post is not legal advice. It is an engineer's map of the terrain, written to help you ask your lawyer better questions. For decisions about your specific data and contracts, consult a qualified data protection professional.