How to evaluate an AI provider's DPA: a framework for EU customers

Note: this article explains a general framework for evaluating an AI provider’s DPA under GDPR. It is not legal advice and does not assess whether a specific provider’s DPA is adequate for your processing. Any determination about the sufficiency of a particular agreement is for the data controller to make with qualified legal counsel.

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

This is a framework for reading any AI provider’s DPA — illustrated with what OpenAI’s documentation states about its own, which should be independently verified before being relied upon.

What a DPA typically covers

According to OpenAI’s published documentation, it makes a Data Processing Agreement available to API customers. The core provisions it describes align with the kind of requirements GDPR sets for processor agreements generally:

Processing purpose limitation: The DPA is stated to restrict the provider’s use of your data to the services you’re contracting for, with an abuse-monitoring exception discussed below. This kind of restriction, if accurately described and currently in force, is a meaningful one — confirm it directly in the agreement you sign.

Standard Contractual Clauses: OpenAI’s documentation states its DPA includes EU Standard Contractual Clauses approved by the European Commission. SCCs, where actually incorporated and kept current, provide a legal transfer mechanism for data flows leaving the EEA.

Subprocessor disclosure: According to OpenAI, it publishes its subprocessor list and commits to notifying customers of changes. A DPA should require the provider to impose equivalent obligations on subprocessors, and typically gives customers who object to a new subprocessor a path to terminate the relevant services — confirm the specific notice period and mechanism in the current agreement.

Data subject rights assistance: A DPA should commit the provider to assist you in responding to access, rectification, erasure, portability, and objection requests from EU data subjects whose data you’ve processed via the API.

Breach notification: A DPA should commit the provider to notify you of security incidents affecting your data within a defined window — fast enough for you to meet your own notification obligations to your supervisory authority.

Security measures: DPAs typically incorporate technical and organizational measures (TOMs), though these are often described at a high level rather than specifying exact controls.

If OpenAI’s DPA delivers what its documentation states, these are meaningful commitments. Confirming that it does, on the version you’re actually signing, is the point of this exercise — not something to take as given from a blog post.

What a DPA typically does not provide

Zero data retention is rarely the default

According to OpenAI’s documentation, under its standard API terms, prompts and completions are retained for abuse monitoring for up to 30 days by default — a figure worth reverifying against current terms rather than assuming stable. That same documentation states API data is not used to train models unless the customer explicitly opts in. Zero data retention is available but gated: it requires prior approval, additional contractual commitments, and — outside the US — a Modified Retention amendment. This shape of arrangement is common across providers, not specific to one.

A Zero Data Retention (ZDR) option — where no prompts or completions are stored — is offered by some providers, including reportedly OpenAI, but typically requires separate application, is not granted automatically, and is subject to the provider’s approval and eligibility criteria. Most customers operating under a standard DPA remain under whatever the default retention window is, meaning their data (including any personal data it contains) is stored in the provider’s systems for some period.

This matters for data minimization (specifically, the storage limitation principle) and for erasure requests. 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

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

A landmark Court of Justice of the EU ruling established that SCCs must be assessed case by case: if the law of the destination country requires disclosure to public authorities in ways incompatible with EU standards, SCCs may not be sufficient without supplementary measures. Whether a specific provider’s DPA includes supplementary technical measures addressing this concern should be confirmed directly rather than assumed either way. Your DPA review should assess whether the risk profile of your specific processing warrants additional measures.

Subprocessor chains mean extended trust

Any AI provider’s subprocessor list will typically name infrastructure, billing, and other service providers it relies on. The DPA should require the provider to impose equivalent obligations on each subprocessor.

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

Audit rights over the provider’s actual systems are usually limited

DPAs commonly provide for audits — but in practice, this typically means access to the provider’s third-party audit reports (such as SOC 2 or ISO 27001 certifications, where held) rather than a right to conduct your own technical audit of their infrastructure. If your DPA review requires direct audit rights over the systems processing your data, a standard DPA’s audit provision may not satisfy that requirement — check the specific clause.

Abuse monitoring is a common exception to processing restrictions

Most DPAs restrict the provider’s use of your data, but abuse monitoring is a standard carve-out. According to OpenAI’s documentation, some portion of API traffic may be reviewed for safety and policy compliance, which can include human review of prompts and completions depending on the provider and configuration. 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 and should be confirmed directly with the provider.

The three options for transfer risk

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 transfer 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, whether that’s an EU region option from a major provider or a vendor with EU-resident data centers. Reduces cross-border transfer concerns but still involves third-party processing of personal data — your compliance posture depends on the vendor’s controls, so verify what “EU region” actually covers before relying on it.

Option 3 — Pseudonymization before transmission: Personal data is pseudonymized before the API call. The processor 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 aligns directly with privacy-by-design principles.

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 provider’s DPA — confirm it’s a genuine processor agreement with properly structured SCCs. This is table stakes, but “the provider says so” is not the same as having read the current version yourself.

2. Apply for ZDR if your processing warrants it — if you’re processing special categories of data (health data, political opinions, biometric data), the default retention window creates ongoing risk that a DPA’s purpose limitation doesn’t fully address.

3. Document your transfer risk assessment — your record of processing activities should include a transfer impact assessment showing why your chosen mechanism is sufficient for your specific processing context.

4. Add technical pseudonymization — particularly for any sensitive personal data. If the data flowing to the provider 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.