DPAs and Sub-Processors for AI Vendors

5 min read · updated August 3, 2026

A data processing agreement is a boring document that answers exactly the questions an AI integration makes interesting: what the vendor may do with content, who else sees it, where it goes, how long it lives and what happens at the end. Most DPAs were written for software that stores records, not for software that reads free text and forwards it.

What follows is a review checklist from an engineering standpoint — the things that determine system behaviour — and not legal advice. Have the agreement reviewed properly; this is how to arrive at that review with the right questions already marked up.

Why a generic DPA is not enough here

A standard processing agreement assumes you know what data you are sending, because in a normal integration you do: these fields, this schema, this table. An inference call sends free text. The schema is “whatever the user typed”, which means the categories of personal data are effectively unbounded and the special-category risk is permanent rather than occasional.

It also assumes the processor is the party doing the processing. In brokered inference — a gateway, a reseller, an aggregator, or a provider that itself buys capacity — the party you signed with may be forwarding your text to a party you have never heard of, chosen at request time. That is not necessarily wrong, but a DPA that does not contemplate it will not describe your system.

The review checklist

Article 28 sets out what a processor contract must contain. Work through the list below against the document in front of you; the starred items are the ones a generic template usually handles badly for AI.

Clause	Description
Subject matter & duration	Named, and tied to the term. If it says 'as described in the Order Form' make sure the Order Form actually describes it.
Nature & purpose *	Should say inference on customer-supplied content and nothing broader. Watch for 'and to improve the Services', which is a different purpose wearing a conjunction.
Categories of data *	Free text cannot be enumerated. Say so honestly — 'any personal data the customer chooses to include in a prompt' — rather than pretending to a field list.
Documented instructions	Processing only on your instructions, with the API call being the instruction. Look for anything permitting processing on the processor's own initiative.
Confidentiality	Personnel bound to confidentiality. Cross-reference this with whatever the human-review clause says.
Security measures	Should be an annex with actual measures, not the word 'appropriate'. Encryption in transit is table stakes; ask what applies to content in memory and to crash artefacts.
Sub-processors *	Authorisation model, a published list, notice period for changes, and a right to object. See below — this is the clause that matters most in this market.
Assistance with rights	How they help you answer access and erasure requests, and in what timeframe relative to your own one-month clock.
Breach notification	Without undue delay, with enough detail to meet your own reporting duty. A vendor SLA measured in business days does not fit inside a 72-hour obligation.
Deletion or return *	At termination, covering derived artefacts — caches, evaluation copies, logs — and not only the primary store. Ask what 'delete' means for backups.
Audit & information	A right to information sufficient to demonstrate compliance. For most buyers a report plus written answers is the realistic form; make sure something exists.
Transfers *	Mechanism named, destinations named, and the mechanism flowing down the whole chain rather than stopping at the counterparty.

The sub-processor chain

Draw it before you sign it. In a brokered setup the chain has more links than the invoice suggests, and each link is a party whose terms govern a copy of your customer’s text:

you (controller)
  └─ vendor you signed with            processor
       ├─ cloud hosting                sub-processor
       ├─ observability / logging      sub-processor  ← often forgotten
       ├─ model provider A             sub-processor
       │    └─ their compute partner   sub-sub-processor
       └─ model provider B             sub-processor
            └─ another broker          sub-sub-processor ← the surprise

The last line is the one to hunt for. Where a provider is itself an aggregator, your text can reach a fourth party under terms neither you nor your counterparty negotiated. The question to ask is blunt and fits in one sentence: for each model we use, is the party running the model the party we contracted with, and if not, who is it?

Flow-down, and where it breaks

Flow-down means the obligations you agreed with your processor bind everyone they engage. It is standard in the contract and imperfect in practice, and the failure points are predictable:

The list is published but not versioned. If you cannot tell what changed and when, the notice period is decorative. Ask for a dated list, or diff it yourself on a schedule.
Notice is a page you must visit. A change notified only by updating a webpage is a change you will find out about afterwards. Ask for email notice, or automate the check.
Objection has no remedy. A right to object that leads only to termination is a right to leave, which may be worth very little mid-contract. Find out what the actual remedy is.
Model-level granularity is missing. A list of company names does not tell you which model routes to which of them. For residency and for retention, the mapping is the thing you need.

What to actually ask for

Five requests, in descending order of how often you will get them: the current sub-processor list with regions; the retention and deletion behaviour in writing, including for flagged content; the security annex rather than the summary; the mapping from models to the parties that serve them; and a commitment on notice period with a named channel. None of these require a vendor to reveal anything commercially sensitive, and a vendor that treats all five as exceptional is telling you something useful about what the answers are.

Then re-ask annually. A DPA is a snapshot of an arrangement that changes underneath it, and the list you filed at signature is the one that will be wrong when somebody audits you.