The short answer
Under GDPR Article 28, any organization processing personal data using a third-party AI service must execute a legally binding Data Processing Addendum (DPA) with the provider.
To obtain a DPA, you must subscribe to a business, team, or enterprise plan; consumer accounts do not offer executable DPAs. When reviewing an AI vendor’s DPA, you must specifically audit five AI-unique clauses: model training prohibitions, sub-processor notification rights, prompt retention schedules, cross-border transfer mechanisms, and breach notification windows.
How to Obtain a DPA from Major AI Vendors
AI vendors handle DPAs through three primary mechanisms:
- Self-Serve Online DPAs (Team/Business Plans): Vendors provide pre-signed online DPAs within the admin portal of business plans. The DPA becomes legally binding upon account registration or online countersignature.
- Custom Executed DPAs (Enterprise Plans): For enterprise tier customers, vendors negotiate and sign custom DPAs containing tailored SLA, audit, and indemnification terms.
- API Terms of Service: API access for developers is often governed by standard business terms that incorporate an automatic DPA by reference upon API key creation.
Consumer Plan Warning: Individual paid accounts ($20/month Plus/Pro plans) are governed by standard consumer terms of service. You cannot obtain an Article 28 DPA on consumer accounts. See our guide on free vs paid AI tools terms.
The 5 Essential AI Clauses to Check in a DPA
When auditing an AI vendor’s DPA, standard boilerplate clauses are insufficient. Look for these specific provisions:
1. Explicit Model Training Prohibition
The DPA must contain explicit language stating that the vendor (and its sub-processors) shall not use customer personal data, prompts, or completions to train, retrain, or fine-tune public foundation models.
2. Sub-processor Inventory & Right to Object
GDPR Article 28(2) requires data processors to obtain written authorization before engaging sub-processors.
- Verify that the DPA includes a link to an active sub-processor list (covering GPU cloud hosts like AWS, GCP, or Azure).
- Check that the vendor commits to providing advance notice (typically 14–30 days) before adding new sub-processors, allowing your organization the right to object.
3. Prompt Log Retention & Deletion Schedules
The DPA must define maximum retention periods for prompt logs and confirm that data is securely deleted or anonymized upon contract termination or upon request.
4. Cross-Border Data Transfer Mechanisms
If the vendor processes data outside the EEA (such as US-based GPU inference), the DPA must incorporate valid transfer mechanisms:
- Standard Contractual Clauses (SCCs) updated to post-Schrems II standards.
- Verification under the EU-U.S. Data Privacy Framework (DPF) where applicable.
- Review our analysis on EU data residency for AI: inference vs storage.
5. Personal Data Breach Notification Windows
GDPR Article 33 requires data controllers to notify DPAs of data breaches within 72 hours. The vendor’s DPA must commit to notifying you of a security incident or data breach “without undue delay” (ideally within 24 to 48 hours) to allow you to meet your statutory obligation.
DPA Review Checklist for Security & Legal Teams
| Clause to Audit | Compliant DPA Language | Red Flag / Non-Compliant Language |
|---|---|---|
| Model Training | “Vendor shall not use Customer Data to train any public model.” | “Vendor may use aggregated or anonymized data for service improvement.” |
| Sub-processors | 30-day advance notice + Right to Object | “Vendor may update sub-processors without notice.” |
| Data Retention | Purged within 30 days or immediately upon API call completion | “Vendor retains logs indefinitely for safety and system monitoring.” |
| Data Transfers | EU-U.S. DPF certification or SCCs included | No international transfer mechanisms specified |
| Breach Notice | Written notification within 48 hours | “Notification as required by applicable law” (no timeframe) |
The Article 28 clauses that must be there regardless
The five above are the AI-specific ones. They sit on top of a mandatory set that Article 28(3) requires in every processor contract, and a DPA missing any of them is defective no matter how good its training language is.
The processor must process only on documented instructions from you, including for international transfers. It must ensure persons authorised to process are bound by confidentiality. It must implement Article 32 security measures. It must not engage sub-processors without authorisation, and must impose the same obligations on them. It must assist you with data subject requests, and with your obligations under Articles 32 to 36 — security, breach notification, and DPIAs. At the end of the service it must delete or return all personal data, at your choice. And it must make available the information needed to demonstrate compliance and allow for audits or inspections.
Two of these are worth extra attention with AI vendors.
The assistance obligation is what makes access requests answerable when the data sits in the vendor’s logs rather than yours. “Vendor will provide reasonable assistance” with no mechanism behind it is very different from a documented export capability. Ask what the assistance actually consists of — see prompt logs and data subject access requests for why the deadline makes this operational rather than theoretical.
The audit right is almost always narrowed in practice to “vendor will provide its current third-party audit report”, which is a reasonable commercial position for a provider with thousands of customers. What matters is that something concrete is promised: a named report type, on a stated cadence, that you can actually obtain.
The retention carve-out to read carefully
The single most common gap between what a DPA appears to say and what happens is abuse and safety monitoring.
Many providers commit not to train on your data and commit to a short retention period for standard logs — then retain inputs separately, for a defined window, for abuse detection, trust and safety, or legal compliance. This is usually disclosed, frequently in a different document from the one you are reading, and it is not necessarily unreasonable. It is simply not what “we do not retain your data” sounds like.
The questions to ask, in writing:
- Does a retention period apply for abuse monitoring or safety review, and how long is it?
- Does it apply on our tier, or only on consumer tiers?
- Is a zero-retention configuration available, and what does it exclude?
- Who can access data held under that carve-out, and is that access logged?
- Is data in that store searchable in response to a data subject request?
A provider that answers all five precisely is one you can document. A provider that cannot is telling you something useful about its internal clarity.
Who you are actually contracting with
Check the entity name on the DPA against the entity on the invoice and the one named in the terms of service. For providers with European operations these are frequently different companies, and the identity of the contracting entity determines which law governs, which supervisory authority is competent, and whether an international transfer is even occurring.
A US-headquartered provider contracting through an Irish subsidiary presents a different transfer analysis from the same provider contracting directly from the United States. Both may be fine; they are not the same, and your Article 30 records need to say which.
Where the provider is not established in the EU, check whether an Article 27 representative is designated, and record the contact.
What is actually negotiable
Setting expectations here saves weeks. With a large provider on a standard business plan, the DPA is a take-it-or-leave-it document and no amount of redlining will change it. Your leverage is the choice of provider and tier, not the wording.
Negotiation becomes realistic at genuine enterprise scale, or with smaller vendors who want the logo. Even then, the terms that move are usually notification periods, audit rights, liability caps and support commitments — rarely the core data handling, because that is determined by how the platform is actually built. A vendor cannot contractually promise a retention period its architecture does not implement.
The practical consequence: assess the terms before you commit to the vendor, not after. Once your organisation has standardised on a tool, the security function’s remaining options are to accept the terms or to fight a battle it will lose. This is the argument for running the assessment at procurement, using something like the AI vendor security questionnaire.
Getting it done, in order
- Confirm you are on a tier that offers one. Consumer plans do not, as above.
- Find the self-serve DPA in the admin console first. Most providers have one, and accepting it there is faster than any email thread.
- Read the sub-processor list and subscribe to change notifications. This is a live document and your Article 30 record depends on it.
- Record the transfer mechanism, and check that any DPF certification actually covers the entity you are contracting with.
- Send the five retention questions above and keep the written answers with the DPA. They are the part not in the document.
- File the executed DPA where your auditor can find it, with the date and the version. A DPA nobody can locate during fieldwork is a finding — see AI tools in a SOC 2 audit.
- Diarise a re-read. Providers update these documents, usually with notice you will not read. Annually is enough.
One clarification on terminology, since the abbreviation collides: Article 33 requires you, the controller, to notify the supervisory authority within 72 hours of becoming aware of a personal data breach. Article 33(2) requires the processor to notify you without undue delay. Your vendor’s contractual notification window is what determines whether your own 72 hours is achievable, which is why an unspecified window is a genuine problem rather than a drafting nicety.
To evaluate vendor profiles before signing, consult our provider directory and read our framework on how to judge an AI provider.