The question lands with the legal or data-protection team almost every week now — "do we need a separate DPA for this AI tool, or does the master vendor DPA already cover it?" The answer depends on a small number of triggers, and on whether your standard SaaS DPA template still works when the processor is calling a large language model under the hood. This piece walks through the decision logic, the AI-specific clauses a generic DPA misses, and the negotiation moves that hold up across the next twelve months of regulatory drift.
A data-processing agreement (DPA) for an AI tool is the GDPR Article 28(3) contract that binds an AI vendor to process your personal data only on your documented instructions, with named sub-processors, defined retention, and security controls. Free consumer AI tools rarely sign one; enterprise tiers (ChatGPT Business/Enterprise, Claude Teams, Gemini Workspace) do. Responsible AI Studio (RAIS) generates a schedule-based DPA via the AI DPA Generator tool tailored to AI vendors specifically — clauses, schedules, annexes, and the AI-specific use limitations regulators now expect.
Qualified review still required. Outputs are AI-generated starting-point documents — not a substitute for qualified legal or compliance advice.
When you need a separate DPA
Three triggers move an AI tool from "covered by an existing DPA" to "needs its own DPA". The first is the no existing DPA at all case — the tool is a standalone vendor, often a new procurement, and the GDPR Article 28(3) contract has never been signed. The second is the master DPA does not cover AI case — the existing vendor signed a SaaS-era DPA in 2021 that says nothing about model training, prompt retention, or sub-processor model providers. The third is the material change case — the same vendor has added an AI feature (Slack AI summaries, Notion AI, Salesforce Einstein) that introduces new processing the original DPA did not contemplate.
Each trigger has a different practical response. The standalone tool needs a fresh DPA, full stop. The 2021 SaaS DPA needs an AI-specific schedule layered on top — re-papering the whole agreement is usually not necessary if the schedule is properly drafted. The material-change case needs a vendor notification request, an updated processor-activity record, and — depending on what changed — a schedule amendment. The decision logic is mechanical once the three triggers are named; what slows teams down is treating every case as the first one. The upstream policy context for these decisions is the employee AI guidelines rollout guide.
What an AI-specific DPA must add to the standard template
The standard SCC-aligned DPA template handles processor obligations as they existed for cloud SaaS in 2018. It does not handle the four AI-specific concerns regulators now expect to see in writing.
Training-data use is the headline. The DPA needs an explicit clause stating whether — and on what basis — the vendor uses customer-supplied prompts, outputs, or fine-tuning data to train its own models. The conservative default is no training without separate written consent, with the consent mechanism named.
Prompt and output retention is the second. Standard DPAs name retention in months for data at rest; AI DPAs need separate retention rules for prompts (input to the model) and outputs (model-generated content), each with the data-subject-rights mechanism for both. Outputs in particular are often treated as the customer's own data, but the DPA needs to say so.
Sub-processor model providers is the third. The AI vendor is rarely operating the model itself — most enterprise AI products call OpenAI, Anthropic, Google, or another provider underneath. The DPA's sub-processor schedule needs to name the model providers, the EU AI Act Article 25 classification (provider vs deployer) for each, and the notification window before a sub-processor model provider changes. The contract layer here is the operational counterpart of the DPA is the contract layer of the vendor assessment.
AI-specific incident definition is the fourth. A standard DPA incident clause covers data breaches and security incidents. An AI DPA also needs to cover model misbehaviour — material hallucination affecting a customer-facing output, prompt-injection compromise, or model behaviour drift after a vendor model update. The clause names which incident types require notification and on what timeline. For the parallel supervisory-side expectations on AI data handling, see supervisory expectations on AI data handling.
These four sit on top of, not instead of, the standard Article 28(3) processor obligations. Together they make a generic SaaS DPA into one that holds up under an AI-specific regulator inquiry.
Cross-border transfer provisions
If the AI vendor processes personal data outside the EU or UK, the cross-border transfer regime applies on top of the DPA. The EU Standard Contractual Clauses for controller-to-processor transfers are the default for transfers from EU controllers to non-adequate-country processors. The UK International Data Transfer Agreement (IDTA), or the UK Addendum to the EU SCCs, is the equivalent for UK controllers. The Swiss-equivalent provisions apply where data is sourced from a Swiss controller or the FADP otherwise applies.
The practical complication with AI vendors is the sub-processor chain. The named model provider underneath your direct vendor may itself be in a non-adequate country — and the transfer regime applies to that onward leg as well. The DPA needs to confirm that the cross-border instruments flow down the chain, not just at the top layer. The EDPB Guidelines 07/2020 on controller and processor concepts sit underneath this analysis.
Negotiation checklist
Six asks come up in nearly every AI-vendor DPA negotiation. Vendors push back on most of them initially.
- Explicit no-training clause for customer prompts and outputs unless separately consented.
- Sub-processor model provider list with EU AI Act Article 25 classification disclosed.
- Material change notification — including underlying model version changes — with a defined window.
- AI-specific incident definition with notification timeline.
- Data subject rights mechanism that works for prompts and outputs as separate categories.
- Exit terms that include destruction or return of all prompts, outputs, and any fine-tuning data.
Concede on the deadline durations before you concede on the structural asks. A 72-hour notification window negotiated to 96 hours is acceptable; a vague "as soon as reasonably practicable" is not. The structural asks are what make the DPA usable two years from now; the deadline durations are negotiable inside that frame.
FAQ
Q1. Do I need a DPA for an AI tool? Yes, if the AI tool processes personal data on your behalf and you are subject to GDPR or a comparable regime (UK GDPR, Singapore PDPA, Australia Privacy Act). The DPA is a GDPR Article 28(3) contractual requirement.
Q2. What's different about a DPA for an AI vendor? An AI-specific DPA must address training-data use (will your data train the vendor's models?), prompt and output retention, sub-processor model providers (Anthropic, OpenAI, etc.), and the AI-specific incident definition (model misbehaviour, not just a data breach). A generic SaaS DPA misses these.
Q3. Does OpenAI sign a DPA for ChatGPT? OpenAI signs a DPA for ChatGPT Business, ChatGPT Enterprise, and API; not for the free or personal Plus tiers. The DPA is requested through OpenAI's enterprise privacy portal.
Q4. Can I use a template DPA for AI vendors? A standard SCC-aligned DPA template is the starting point, not the finished agreement — the AI-specific schedules need to be added on top. Responsible AI Studio (RAIS) generates a DPA with the AI-specific schedules pre-built, aligned to GDPR Article 28(3).
A DPA for an AI tool is not a different species of contract from the SaaS DPA your legal team already runs — it is the same instrument with four additional concerns regulators now expect to see written down. RAIS tools amplify your in-house expertise — the AI-specific schedule library, the cross-border instrument selection, and the negotiation move-set — so legal and DPO teams move from clause-by-clause re-drafting to qualified review on the parts that need their judgement.
Generate an AI-specific DPA → /tools/dpa-generator
Qualified review still required. Outputs are AI-generated starting-point documents — not a substitute for qualified legal or compliance advice.