Processing on behalf
What an Article 28 contract must contain, which five points matter most with AI providers, and how to spot a bad contract.
The mandatory content
| Point | What to watch |
|---|---|
| Subject matter and duration | Concrete, not "IT services" |
| Nature and purpose | What exactly is processed and for what |
| Data categories and data subjects | Complete, including free-text fields |
| Instructions | Only on documented instruction, with legal exceptions |
| Confidentiality | Obligation of the people involved |
| Technical measures | Concrete, not a link to a website |
| Sub-processors | List, approval, notice of change, right to object |
| Assistance | With data subject rights and impact assessments |
| Deletion or return | After the contract ends, with evidence |
| Evidence and audits | Inspection rights, not only certificates |
The five points that matter most with AI providers
- Training use. Exclusion of any use of inputs and outputs for training, contractually and technically evidenced.
- Retention of inputs. Whether and how long prompts are stored, and who looks at them.
- Human review. Whether provider staff read inputs for quality assurance, and on what conditions.
- Sub-processors. With AI services often several layers, including data centre providers.
- Model changes. Whether the provider may switch the underlying model without notice.
The last point is unremarkable in data protection terms and the most consequential operationally: a silent model change can invalidate reviewed prompts and touch an AI Act classification.
When there is no processor
Anyone deciding on purposes and means themselves is a controller in their own right, not a processor. With AI providers that arises regularly:
- The provider uses inputs to improve its own models. That is a purpose of its own.
- The provider analyses usage data for its own purposes.
- The provider decides independently which data is retained and for how long.
Where one of those applies, a processing agreement is the wrong construction and a legal basis is needed for transmission to a further controller. Anyone not settling that question has a contract that does not fit.
How to spot a bad contract
- Technical measures only as a link to a website the provider can change at will.
- Sub-processors only as a category, with no names and locations.
- A blanket right to use inputs to improve the service.
- Inspection rights limited to producing a certificate.
- No rules on remote access from third countries.
- Deletion "within a reasonable period" with no figure and no evidence.
The interplay with the AI Act
A processing agreement covers data protection, not the AI Act duties. For high-risk systems you additionally need the provider's instructions for use, statements on accuracy and limits, and a rule on how the provider notifies changes. Those belong in the same contract but in a separate section. See Duties by role.
Checklist for the agreement
FREE ACCOUNT
Data processing agreement checklist
The points where an agreement with an AI provider is usually incomplete, with the wording that is missing.
Checklist3 items
Related courses and sources
Guidelines of the European Data Protection Board
The GDPR as interpreted by the body of supervisory authorities. In a dispute about a legal basis, the most solid source after the text of the law itself.
For legal teams and data protection officers when an interpretation has to hold up.