Data Processing Agreement Clauses Specific to AI Sub-Processing

Most AI vendor DPAs are a generic Article 28 template with the word “AI” substituted into the recitals. The template was written for a hosting relationship, and it is silent on the four things that actually differ: whether your data trains the model, how long the provider keeps prompts for abuse review, which upstream providers see them, and what deletion means once content has been embedded or learned.

The Article 28(3) baseline

Article 28(3) of the GDPR requires the contract to stipulate, in substance, that the processor: (a) processes only on documented instructions from the controller, including as regards third-country transfers; (b) ensures persons authorised to process have committed to confidentiality or are under a statutory duty of it; (c) takes all measures required by Article 32; (d) respects the Article 28(2) and 28(4) conditions for engaging another processor; (e) assists the controller by appropriate technical and organisational measures in responding to data subject rights requests; (f) assists in ensuring compliance with Articles 32 to 36; (g) at the controller’s choice deletes or returns all personal data at the end of the services and deletes existing copies unless Union or Member State law requires storage; and (h) makes available all information necessary to demonstrate compliance and allows for and contributes to audits, including inspections. The final sub-paragraph adds that the processor must immediately inform the controller if an instruction infringes the Regulation. The text is at EUR-Lex, Regulation (EU) 2016/679.

Two structural points before the AI-specific part. First, if you are also executing standard contractual clauses Module Two or Module Three, those clauses are drafted to satisfy Article 28(3) themselves, so you may not need a separate DPA at all — and where both exist they must not contradict each other, which they frequently do on retention. Second, Article 28(4) makes the first processor fully liable to the controller for the performance of any sub-processor’s obligations. That single sentence is why an unnamed upstream model provider is your vendor’s problem contractually and your problem practically.

The clauses only an AI DPA needs

• Training and improvement exclusion. The most important clause in the document. It should prohibit use of customer content — prompts, attachments, outputs, and embeddings derived from any of them — to train, fine-tune, evaluate or otherwise improve any model, whether the vendor’s own or a third party’s. Draft it as a prohibition rather than as a default setting, and make it apply to the vendor’s sub-processors expressly. Without it the vendor is pursuing its own purpose, which puts you into the analysis in joint controllership between an AI vendor and its customer.
• Retention window per store, with a maximum. Not “in accordance with our retention policy”. A number, per category: inference request logs, abuse-monitoring copies, support case attachments, telemetry. State whether zero retention is available and on what terms, since it is commonly conditional on forgoing some feature.
• Human review disclosure. If flagged content is read by a person, say so, say under what trigger, say who those people are — employees or a third-party moderation vendor — and say where they are located. A human review path is a separate recipient and frequently a separate third-country transfer, and it is almost never in the template.
• Upstream model provider identification. The sub-processor list must name the model providers, not just the cloud regions. “Third-party AI service providers” as a category entry is not a name, and it makes your own Article 30 record and your transfer assessment impossible to complete. See sub-processor disclosure obligations for AI vendors.
• Processing location and region commitment. Which region serves inference, whether failover can move it, and whether you are notified when it does. A region commitment that silently fails over is not a commitment.
• Output handling. Generated responses are personal data when they concern an identifiable person, including when they are wrong. State that outputs are subject to the same retention, confidentiality and training-exclusion terms as inputs, because many templates define “Customer Data” in a way that covers only what the customer sent.
• Breach notification with a workable number. Article 33(2) says the processor notifies the controller without undue delay, with no fixed period. Your own clock under Article 33(1) is 72 hours, so a contractual vendor window of 72 hours makes your own obligation unachievable. Negotiate 24 hours or less, and require enough detail to file. See breach notification timelines when an AI system leaks personal data.
• Rights assistance that reaches the model. Article 28(3)(e) assistance is usually drafted as “we will forward your request”. For an AI vendor, specify what happens to an erasure request in respect of data already in an index, an embedding store, or a fine-tuned artefact.

The deletion clause that cannot be performed

Article 28(3)(g) requires deletion or return at the end of the services. For stored records this is straightforward. For anything that has influenced model weights it is not, and pretending otherwise in a contract creates a promise nobody can keep.

Three distinct artefacts need separate treatment. Stored content — prompts, files, conversation history — is deletable in the ordinary way, and the clause should say within how many days including from backups. Embeddings are derived data and are deletable if the store is designed for it, but only if the contract treats them as customer data rather than as vendor-generated metadata, which is a definitional point worth checking. Model weights that have been fine-tuned on the content are the hard case: deleting the training corpus does not remove its influence from the parameters, and the only reliable remedy is deleting the fine-tuned model itself and retraining without the data.

So the clause to draft is not “delete all personal data”. It is a clause that says what happens to each artefact class, and commits the vendor to deleting any model artefact trained on your content on termination. Whether a base model that saw your data during pre-training must be retrained is a question the law has not answered, and it is entangled with the separate question of whether the model contains personal data at all — see anonymised or just pseudonymised. Do not draft a clause that assumes an answer.

The drafting checklist

1. Confirm the role. Controller to processor, or processor to sub-processor. The whole document changes, and so does which SCC module attaches.
2. Define customer data to include outputs and derivatives. Check the definition covers prompts, files, responses, embeddings and logs. This one definition determines the reach of every other clause.
3. Insert the training exclusion and extend it to sub-processors expressly.
4. Fix the retention numbers per store, with a stated maximum and a stated route to zero retention.
5. Set the sub-processor mechanism. Prior specific authorisation, or general authorisation with a named notice period and a real objection right — including what happens commercially if you object.
6. Set the breach notice window below 72 hours, with a content requirement matching Article 33(3).
7. Attach the audit mechanism. Article 28(3)(h) allows for audits and inspections; most vendors substitute a third-party report. Whether that substitution is acceptable is the subject of the right-to-audit clause in an AI vendor contract.
8. Attach transfer paperwork and check for contradiction between the DPA’s retention and security terms and Annex II of the clauses.
9. Record the artefact-by-artefact deletion terms and the termination consequences for fine-tuned models.

What is negotiable

Realistically, a small customer of a large model provider is signing a standard form, and the useful skill is knowing which terms are worth raising and which are fixed. In practice the training exclusion and the zero-retention option are the two most likely to be available already, often as enterprise-tier settings rather than as negotiated language — in which case the drafting work is getting the setting reflected in the contract so that it cannot be changed by an administrator later. The breach notice window and the sub-processor notice period are sometimes movable. The audit right almost never is.

Where a term cannot be moved, the answer is not to sign and hope. It is to record the gap as a residual risk in the assessment that sits behind the processing, with a mitigation that lives on your side of the line — redacting before the call, limiting which workloads use that vendor, or keeping a second provider available so that a term you cannot accept is a routing decision rather than a re-platforming. A gap recorded with a named mitigation is a defensible position; a gap nobody wrote down is the one that looks like an oversight two years later.