DPA for AI vendors: what to actually check before you sign

TL;DR. A DPA for an AI vendor has to cover the same Article 28 ground as any other processor contract, plus four AI-specific concerns: training defaults, retention defaults, subprocessor depth, and EU/UK transfer mechanism. The vendor name on the front page tells you nothing on its own — the answer always lives in which product you bought (API, enterprise tier, consumer plan) and which retention setting is in force.

Why an AI vendor DPA is different

A Data Processing Addendum is the contract Article 28 GDPR requires whenever a controller hands personal data to a processor. The structure is the same for any SaaS vendor: scope, instructions, security, subprocessors, transfers, deletion, audit, breach.

What changes with AI vendors is the surface area the DPA has to cover. Three additions force themselves into every serious review:

1. Training position. Does the vendor use your inputs and outputs to train models? Commercial defaults at the major providers say no. Consumer defaults at the same providers often say yes — and the default at the consumer tier has flipped at least once for both OpenAI and Anthropic in the last 18 months.
2. Retention default. How long does the vendor keep prompts and outputs after the API call returns? Defaults sit at 7-30 days on commercial tiers, with Zero Data Retention (ZDR) available on request from OpenAI and Anthropic. Some enterprise products on Microsoft and Google sit on customer-controlled storage and answer the question differently.
3. Subprocessor depth and EU Data Boundary scope. Most AI products now run on at least two clouds plus the model provider, and the subprocessor list has been growing. Anthropic became a Microsoft 365 Copilot subprocessor on 2026-01-07 and is explicitly out of EU Data Boundary scope for that route. Buyers who assumed Copilot meant EU-only processing got a surprise.

The DPA is the artifact that pins all three down in writing. Reading it once is not optional for any AI deployment that touches personal data, and a re-read on every major product change is the realistic minimum.

The eight clauses that actually decide the risk

A serious DPA review looks at all standard Article 28 clauses, but the eight below carry most of the AI-specific weight.

1. Scope of processing and instructions

The DPA has to state what the vendor processes on your behalf and that they only process on your documented instructions. With AI products this clause has to expressly cover prompts, outputs, embeddings, attached files, retrieval-augmented context, and tool-call results. Vendors who quietly leave embeddings or tool-call payloads out of scope create a gap you cannot rely on for an Article 28 claim.

2. Training position (commercial tier)

The default at every commercial AI provider this review covers is contractually no training on customer data through the API or enterprise product. The contract clause is what gives that default legal weight — the help-centre page does not. Check that the DPA itself, not the marketing site, contains the no-training commitment.

3. Training position (consumer or free tiers)

The same vendor will often run a different default at the consumer tier. OpenAI flipped its consumer training default to opt-out by setting in late 2025; Anthropic flipped its consumer claude.ai default to opt-in for training on 2025-10-08, with up to five-year retention on inputs of users who opted in. Staff who use the free consumer product without an enterprise contract are inside the consumer default, not the commercial one. The DPA does not protect them because no DPA applies.

4. Retention defaults and Zero Data Retention

API retention defaults at OpenAI sit at 30 days. Anthropic dropped its API default from 30 days to 7 days on 2025-09-14 — the strongest default in the LLM market at time of writing. Both vendors offer ZDR through their commercial sales channel, but ZDR is approval-gated, not on by default. A buyer who needs ZDR has to apply, document the use case, and accept that certain abuse-monitoring exceptions remain.

5. Subprocessor list and change-notice cadence

AI vendors are stacking subprocessors faster than legacy SaaS. The list now routinely includes the model provider, the cloud the model runs on, a content-moderation provider, an analytics provider, and a security tooling provider. The DPA should commit to publishing the list, giving notice on additions, and providing an objection mechanism. The realistic notice window has shortened to 14-30 days at most AI vendors, which compresses the buyer's diligence window.

6. EU/UK transfer mechanism

The post-Schrems II structure stands: Standard Contractual Clauses for EU controller-to-processor transfers, the UK Addendum on top for UK controller exports, and a Transfer Impact Assessment to back both up. AI vendors should name the SCCs in use (the 2021 set, not the legacy 2010 set), the UK Addendum version, and any EU Data Boundary commitment they make on top. Anthropic's 2026-01 inclusion as a Copilot subprocessor with an explicit EU Data Boundary carve-out shows why the "EU-only" claim from any enterprise vendor needs the carve-outs read line by line.

7. Security commitments and certifications

The DPA should reference the vendor's security documentation, and the buyer should pull the documents named. SOC 2 Type II and ISO 27001 are the realistic floor; ISO 27701 and ISO 42001 (AI management system) are appearing on the better vendors. A DPA that names a certification the vendor has not actually maintained is a flag worth raising in writing before signature.

8. Deletion and return at end of contract

Article 28(3)(g) requires deletion or return at the controller's choice. With AI vendors the practical question is whether deletion applies to model artifacts that may have been built from the customer's data on enterprise tiers with fine-tuning or retrieval augmentation. A buyer who fine-tuned should ask for written confirmation that the fine-tuned model is deleted, not just the underlying training data.

How the six vendors line up on the DPA basics

The full review for each vendor lives in the dedicated profile. The table below is the at-a-glance read for buyers triaging multiple products in one procurement window.

| Vendor | Commercial training default | API retention default | ZDR available | Profile | |---|---|---|---|---| | OpenAI | No (API/Enterprise) | 30 days | Yes, approval-gated | OpenAI | | Anthropic | No (API/Team/Enterprise) | 7 days | Yes, approval-gated | Anthropic | | Microsoft 365 Copilot | No (tenant-bound) | Tenant-controlled | N/A (tenant model) | Microsoft 365 Copilot | | Google Gemini (Workspace) | No (workspace-bound) | Workspace-controlled | N/A (workspace model) | Google Gemini | | Perplexity (Enterprise) | No (Enterprise tier) | Enterprise-tier defaults | Enterprise-tier dependent | Perplexity | | ElevenLabs | No (Enterprise / API) | Tier-dependent | Enterprise-tier dependent | ElevenLabs |

The pattern across the six: commercial defaults are protective, consumer defaults often are not, and the enterprise tenant-bound products (Copilot, Workspace Gemini) push retention into the buyer's own Microsoft or Google environment rather than holding it at the AI vendor.

The DPA review steps for a procurement gate

The version below assumes the buyer has a procurement gate to clear and a DPO or compliance owner who has to sign off.

1. Confirm which product the staff or app will actually use. Commercial API, enterprise SaaS tenant, or consumer free / Pro / Max plan. The DPA only covers what the buyer actually contracted for.
2. Pull the live DPA from the vendor's portal. Do not rely on the marketing version of the page. Note the version number and date.
3. Read clauses 1-8 above against the buyer's deployment. Flag any clause whose scope does not match what the staff will actually do with the product.
4. Cross-check the subprocessor list against EU Data Boundary expectations. If the buyer needs EU-only processing, every subprocessor has to be inside that scope or have a documented carve-out the buyer can accept.
5. Decide on ZDR or extended retention. ZDR is the cleaner default for any deployment touching special-category data. The application step takes 1-3 weeks at OpenAI and Anthropic in our experience.
6. Document the transfer mechanism. SCC version, UK Addendum status, Transfer Impact Assessment on file. The procurement gate needs the three artifacts; the DPA itself usually only names the first.
7. Record the consumer-tier exposure. If staff might use the free consumer product alongside the contracted enterprise tool, the DPO needs a written policy on which is permitted. The default at the consumer tier is what governs, and that default is not always protective.

When the DPA is not enough

A DPA covers processor obligations. It does not cover the AI-specific risks that sit upstream:

• The DPIA the buyer owes under Article 35 for the deployment itself
• The AI Act role assessment (provider, deployer, distributor) for any system that touches the EU market
• The buyer's own data-mapping for what categories of personal data the deployment ingests
• The retention policy the buyer applies on its own side, regardless of the vendor's retention default

The DPA pins the vendor down. The DPIA and the AI Act role assessment pin the buyer down. Both have to land before the procurement gate closes.

Related reading

• The buyer-side AI Act read for the same six vendors: EU AI Act for AI buyers
• The US healthcare-adjacent read for the same vendors: HIPAA for AI tools
• Head-to-head on the two most-asked-about API vendors: OpenAI vs Anthropic DPA
• Enterprise tenant comparison: Copilot 365 vs Google Workspace AI

For ongoing AI compliance support, work with Janus DPO-as-a-Service. Browse the vendor index or other topic guides.