OpenAI's Data Processing Agreement for EU customers: what it covers and what it doesn't

When a DPO or legal counsel asks “can we use OpenAI for data that includes personal information of EU data subjects,” the answer involves more than confirming OpenAI has a DPA. The DPA’s actual contents, its enforceability, and the gaps it leaves open all matter for a complete compliance assessment.

This is a plain-language walkthrough of what OpenAI’s DPA for API customers actually says — and what it doesn’t.

What the DPA covers

OpenAI makes its Data Processing Agreement available to API customers. The core provisions align with Art. 28 GDPR requirements for processor agreements:

Processing purpose limitation: The DPA restricts OpenAI’s use of your data to the services you’re contracting for. OpenAI cannot use your API prompts and completions to train or improve models (with the abuse monitoring exception discussed below). This is a meaningful restriction.

Standard Contractual Clauses: OpenAI’s DPA includes the EU Standard Contractual Clauses (Module 2: controller-to-processor) approved by the European Commission under Art. 46(2)(c). SCCs provide a legal transfer mechanism for data flows from the EU to the US, which is where OpenAI’s primary infrastructure operates.

Subprocessor disclosure: OpenAI publishes its subprocessor list and commits to notifying customers of changes (typically with 30 days notice). The DPA requires OpenAI to impose equivalent obligations on subprocessors. Customers who object to a new subprocessor can terminate the relevant services.

Data subject rights assistance: OpenAI commits to assist you in responding to Art. 15-22 requests (access, rectification, erasure, portability, objection) from EU data subjects whose data you’ve processed via the API.

Breach notification: OpenAI commits to notify you of security incidents affecting your data within 72 hours of becoming aware — matching the Art. 33 requirement for you to notify your supervisory authority.

Security measures: The DPA incorporates technical and organizational measures (TOMs), though these are described at a high level rather than specifying exact controls.

These are real commitments. The DPA is properly structured under Art. 28 and the SCCs meet the formal requirements for international transfer.

What the DPA does not provide

Zero data retention is not the default

Under OpenAI’s standard API terms (including those covered by the DPA), prompts and completions are retained for 30 days for abuse monitoring. This is the default.

Zero Data Retention (ZDR) — where no prompts or completions are stored — is available but requires separate application, is not granted automatically, and is subject to OpenAI’s approval. Most customers operating under the standard DPA are under the 30-day retention default, meaning their data (including any personal data it contains) is stored in OpenAI’s systems for at least a month.

This matters for data minimization under Art. 5(1)(e) (storage limitation) and for erasure requests under Art. 17. If a data subject requests deletion and their personal data appears in stored prompt logs, the deletion chain is more complex than if data was never stored.

SCCs are a transfer mechanism, not a technical safeguard

The SCCs provide a legal basis for the EU-to-US transfer. They do not technically prevent OpenAI, or personnel within OpenAI’s infrastructure, from accessing your data. They create a contractual obligation not to access data improperly — enforceable, in principle, through contract law.

The Court of Justice of the EU’s Schrems II judgment (C-311/18) established that SCCs must be assessed case by case: if the law of the destination country (the US) requires disclosure to public authorities in ways incompatible with EU standards, SCCs may not be sufficient without supplementary measures. OpenAI’s DPA does not include supplementary technical measures that address Schrems II concerns. Your DPA review should assess whether the risk profile of your specific processing warrants additional measures.

Subprocessor chains mean extended trust

OpenAI’s subprocessor list is published. At the time of writing, it includes Microsoft Azure (compute infrastructure), Stripe (billing), and several others. The DPA requires OpenAI to impose equivalent obligations on each subprocessor.

In practice, this means you’re trusting a chain: your contractual relationship with OpenAI, OpenAI’s agreements with Microsoft Azure, Azure’s security controls over the actual compute. Each link in this chain is a potential failure point — and you have no direct contractual relationship with OpenAI’s subprocessors. You cannot audit Microsoft Azure directly as a result of your OpenAI DPA.

No audit rights over OpenAI’s actual systems

The DPA provides for audits — but in practice, this typically means access to OpenAI’s audit reports (SOC 2 Type II, ISO 27001) rather than a right to conduct your own technical audit of OpenAI’s infrastructure. If your DPA review requires direct audit rights over the systems processing your data, the DPA’s audit provision may not satisfy that requirement.

Abuse monitoring is an exception to processing restrictions

The DPA restricts OpenAI’s use of your data, but abuse monitoring is a standard exception. OpenAI reviews a portion of API traffic for safety and compliance with its usage policies. This is human review of your prompts and completions. For many use cases, this is acceptable; for healthcare applications handling PHI, legal applications handling privileged communications, or any application processing sensitive personal data, it deserves explicit consideration.

The three options for transfer compliance

DPOs typically evaluate three approaches to international transfer risk:

Option 1 — SCCs only: Sign the DPA, rely on SCCs. This is the minimum legal basis for transfer. It doesn’t reduce Schrems II risk without supplementary measures and doesn’t address retention or subprocessor chain concerns.

Option 2 — EU data residency: Use a provider with EU-only infrastructure. Azure OpenAI with EU region selection, or providers with EU-resident data centers. Eliminates Art. 44 transfer concerns but still involves third-party processing of personal data — your compliance posture depends on the vendor’s controls.

Option 3 — Pseudonymization before transmission: Personal data is pseudonymized before the API call. The processor (OpenAI, Azure, whoever) never receives identifiable data. SCCs become less critical because there’s no personal data in the transfer. Data subject rights are easier to manage because personal data isn’t in the provider’s logs. This satisfies Art. 25 privacy-by-design requirements directly.

Option 3 provides the strongest GDPR position, but it requires an implementation layer between your application and the AI provider. Option 2 is the next strongest, with Option 1 as the legal baseline.

What a complete DPO recommendation looks like

The technically and legally sound approach:

1. Execute the OpenAI DPA — it’s a genuine Art. 28 agreement and the SCCs are properly structured. This is table stakes.

2. Apply for ZDR if your processing warrants it — if you’re processing sensitive categories of data under Art. 9 (health data, political opinions, biometric data), the default 30-day retention creates ongoing risk that the DPA’s purpose limitation doesn’t fully address.

3. Document your Schrems II assessment — your Art. 30 record should include your transfer impact assessment showing why SCCs are sufficient for your specific processing context.

4. Add technical pseudonymization — particularly for any sensitive personal data. If the data flowing to OpenAI contains no identifiable information, the DPA, SCCs, and retention provisions all become less critical because there’s less personal data in scope.

---

The combination of a properly executed DPA and pre-transmission pseudonymization provides defense in depth: the legal framework covers the organizational relationship, and the technical measures ensure minimal personal data exposure regardless of what happens within that relationship.

For the technical implementation of pseudonymization before API calls, the GDPR compliance guide covers the architecture in detail.