AI Vendor DPA: 8 Clauses Whose Absence Breaks Your Audit
AI Vendor DPA: 8 Clauses Whose Absence Breaks Your Audit
Reading time: about 8 minutes. Cluster: compliance. Author: Fryderyk.
Answer first
A data processing agreement (DPA) with an AI vendor is not a formality you sign at the end. It is the document an NIS2 or GDPR auditor leans on to ask: who processes your data in this AI system, where, and on what terms. A vendor's standard DPA usually does not answer the AI-specific questions: whether your prompts and documents feed model training, who the sub-processor behind the model API really is, and how you get your data back and deleted at the end. Below are eight clauses whose absence most often breaks an audit or leaves a gap in the supply chain. For each: what it must contain and what breaks when it is missing. This is not legal advice.
Table of contents
- Why an AI vendor DPA differs from an ordinary one
- The eight clauses, one by one
- Table: clause and risk when missing
- How to use this list in practice
- FAQ
- Disclosure and biases
- What I do not cover here
- Related notes
Why an AI vendor DPA differs from an ordinary one
Two things set it apart from a classic processing agreement. First, the sub-processor chain is deeper and less obvious: behind a single model API there is often a cloud provider, sometimes a separate model provider, sometimes both. Second, a question appears that a classic DPA does not know: what happens to your data, prompts and outputs on the model side. Do they only serve the request, or also improvement and training. A copied vendor template usually stays silent on both, and an auditor will not miss it.
The eight clauses, one by one
1. Subject, purpose and documented instructions
What it must contain: a defined subject, duration, nature and purpose of processing, plus a statement that the vendor processes data only on your documented instructions. What breaks without it: a blanket „for the provision of the service" does not let you show you control the scope, and an auditor reads it as the controller losing control over the processor.
2. Sub-processor register and change notice
What it must contain: a current list of sub-processors, including the infrastructure provider and the model provider, an obligation to give prior notice of changes, and a right to object. What breaks without it: you do not know who actually touches the data, so you cannot assess either the NIS2 supply chain or transfers. This is the most common quiet gap with public model APIs.
3. Processing location and transfers outside the EEA
What it must contain: where data is processed and stored, plus the basis and safeguards for transfers outside the European Economic Area. What breaks without it: a transfer to a third country with no basis is a classic GDPR audit finding, and with AI it is easy to trigger when the model or its backend sits outside the EEA.
4. Use of data for model training
What it must contain: a clear exclusion of using your data, prompts and outputs to train or improve models, or, if you deliberately allow it, an explicit and limited consent. What breaks without it: silence works against you, because you cannot guarantee that sensitive content will not settle into the model. This is the clause a standard DPA simply does not have, and for an AI system it is the decisive one.
5. Concrete technical and organisational measures
What it must contain: measures named explicitly, meaning encryption at rest and in transit, access control, environment separation and logging, not just a reference to „the vendor's security policy". What breaks without it: a pointer to an internal document you neither see nor control is not evidence that survives an auditor.
6. Event logging, log access and audit rights
What it must contain: the scope of logged events, your access to logs or reports, and a real right to audit or inspect, not just the sight of a certificate. What breaks without it: without access to the event trail you cannot reconstruct what the system did and on what data, which is exactly what the NIS2 regime expects.
7. Breach notification within a defined window
What it must contain: an obligation to report a breach without undue delay, within a window that fits inside your own clock toward the regulator. What breaks without it: if the vendor reports „within a reasonable time", you may miss your own notification duty, and the processor's delay becomes your problem.
8. Retention, return and permanent deletion
What it must contain: what happens to data at the end of the contract, the term and method of return or deletion, and confirmation of deletion, including from backups and logs. What breaks without it: data stays with the vendor after the relationship ends, which is both a GDPR finding and a real piece of vendor lock-in.
Table: clause and risk when missing
| Clause | What it must contain | What breaks without it |
|---|---|---|
| Purpose and instructions | Processing only on documented instructions | Controller loses control over the processor |
| Sub-processors | List plus change notice and right to object | Unknown supply chain, NIS2 blind spot |
| Location and transfers | Processing location and basis for transfer outside EEA | Unlawful transfer, GDPR audit finding |
| Model training | Exclusion of data use for training | Sensitive content settles into the model |
| Security measures | Concrete measures named explicitly | A pointer with no evidence, not verifiable |
| Logs and audit | Log scope, access, inspection right | No reconstruction of events under NIS2 |
| Breach notice | Window that fits your own clock | Late notification to the regulator |
| Retention and deletion | Return, deletion and confirmation | Data stays with the vendor, lock-in |
How to use this list in practice
Do not negotiate the eight clauses separately at the end of the process. Folding them into the request for proposal and the vendor assessment before you choose saves a full round of renegotiation. A practical order: settle sub-processors and location first (2 and 3), because they decide whether you enter a transfer and a deeper chain at all. Then model training (4), because many vendors have no ready answer, so it is better asked early. The rest are clauses that any mature processing agreement should already carry, but with AI you have to read them for what is specific. That whole trail, the vendor assessment, the DPA and the data flow map, usually serves several regimes at once, so it pays to produce it once rather than separately for GDPR and for NIS2.
FAQ
Is the vendor's DPA template enough?
Rarely. A vendor template is written for the vendor and usually stays silent in the two places that matter most for AI: the full list of sub-processors behind the model API, and the use of data for training. Those two points have to be added or negotiated.
How does this differ from an ordinary processing agreement?
The core is the same, because a DPA is a GDPR construct. The difference lies in the deeper sub-processor chain and in the model-training clause that a classic DPA does not contain.
Does on-prem remove the need for a DPA?
It depends on the deployment model. If data never leaves your environment and there is no external processor, the role of a DPA shrinks, because there is no one to entrust data to. When an external vendor or its infrastructure is involved, a DPA is needed, and on-prem mainly shortens the sub-processor list.
What if the vendor refuses an audit right?
Common with large vendors. An acceptable compromise is often access to independent assurance reports and to logs instead of physical inspection, as long as the report scope really covers what you have to demonstrate.
// disclosure & biasesDisclosure and biases
I write from the perspective of someone working on AI that runs outside the public cloud, so I naturally emphasise control over data flow and a shorter sub-processor chain. I have tried to describe the clauses independently of the deployment model, because the same list has to be worked through for cloud and for on-prem alike, only the split of evidentiary work differs. This text is not legal advice. Confirm clause wording with a lawyer and a data protection officer, because it depends on the specific facts.
What I do not cover here
I do not give ready wording for the clauses or a contract template, because that is a job for a lawyer, not a note. I do not go into the numbering of specific provisions, referring to them functionally. I skip a full analysis of transfer mechanisms outside the EEA, because that is a separate, larger topic. I also do not cover the arrangement where the vendor is a joint controller rather than a processor, because it follows a different logic than entrustment.
Related notes
Building CortexMine, an on-prem AI platform for European manufacturers under NIS2. Where this bias could affect conclusions, it is flagged inline.
Want to apply this to your case: architecture, compliance, and cost?
→ Book 30 minAI Act in manufacturing: high-risk classification and what it means for deployment
When a manufacturing AI system is high-risk under the AI Act and when it is not. Two routes to high-risk, step-by-step classification, and what the July 2026 Digital Omnibus changed. Plus the effect on the on-prem versus cloud choice.
NIS2 and AI: mapping Article 21 to concrete controls, one cheat sheet
The ten Article 21 NIS2 areas mapped to an AI system. For each area, the question an auditor will ask and the single artefact you need to show.
NIS2 audit readiness for AI: the 7 documents an auditor asks for
NIS2 does not ask for a standalone AI policy. It asks that your AI system sits inside seven documents you already produce. Here is the list, with a mapping table.