GDPR DPA template for AI: the seven clauses that matter
May 2, 2026
A starting point, not a final document
Three regulators, three contractual frames, one Data Processing Agreement that has to satisfy all of them. The General Data Protection Regulation Article 28 governs the controller-to-processor relationship. The EU AI Act Article 26 governs the deployer's obligations to the AI system's provider. The Digital Operational Resilience Act Article 30 governs financial-services customers' contracts with their critical ICT third parties (with Article 28 setting the third-party risk-management principles and Article 39 the competent authority oversight powers). Most Data Processing Agreement templates available online are written for one of those frames only, usually General Data Protection Regulation Article 28, applied to software-as-a-service vendors that process customer data inside their own infrastructure. They assume the vendor is a processor, the vendor controls the data path, audit rights flow from the customer to the vendor's infrastructure. Those templates fit hosted-API deployments well. They fit customer-environment AI deployments badly.
Customer-environment deployment inverts the assumption. The vendor never sees the data in production. The data path is entirely inside the customer's environment. The vendor's role is shipping the deployment software and the operational tooling, not handling personal data. A Data Processing Agreement scoped to this pattern has to capture an unusual structure: the vendor is "neither a controller nor a processor" in steady state, with explicit conditions under which processor status would apply (incident response, support sessions with re-granted read access).
Seven clauses decide whether a Data Processing Agreement fits AI infrastructure deployments in the customer's environment. This post walks through each, naming what the clause should say and where generic templates trip up. It is for the founder, the chief technology officer, or the compliance lead at an early-stage startup who is about to negotiate a Data Processing Agreement with a regulated end-customer and wants to start from the right shape.
A note on legal status. This post is a starting point for negotiation, not a final document. Your own legal counsel should review any draft you build from this structure before you sign anything based on it. The structural specification is designed to be Dutch-jurisdiction-aware, with the General Data Protection Regulation, the EU AI Act Article 26 deployer obligations, and (for financial-services customers) the Digital Operational Resilience Act as the substrate, adaptable to other European Union member states with local-law adjustments. The seven clauses below operationalize the contractual side of where your AI vendor responsibility ends.
A Data Processing Agreement that names the audit boundary is stronger than one that hides it.
The seven clauses that matter
Clause 1: Roles and definitions (controller, processor, or neither)
What the clause should say: name the deployment shape (customer-environment deployment with vendor-shipped infrastructure software), state the vendor's role in steady state (neither controller nor processor under General Data Protection Regulation Article 4), name the conditions under which the vendor would become a processor (incident response with re-granted read access, support sessions involving access to personal data), and define the "incident response" and "support session" terms precisely. Acknowledge separately that the customer maintains its own deployer-obligations register under EU AI Act Article 26. The vendor's role under Article 4 of the General Data Protection Regulation does not directly change that register, but the audit boundary documented in Clause 3 below directly informs what the customer can show its competent authority.
Why most templates trip up: most templates assume processor status by default and lack the "neither in steady state" framing. Inserting that framing into a template-driven Data Processing Agreement late in negotiation is harder than starting with it as the default.
Clause 2: Sub-processor disclosure
What the clause should say: list the vendor's sub-processors in scope of the deployment (typically: the open-weight model authors and distributors, the source registry for software dependencies, any third-party libraries with telemetry). State that the customer's hyperscaler and the customer's own sub-processors are out of scope of the vendor's sub-processor list because they are the customer's relationships, not the vendor's. Define the notification cadence for sub-processor changes (typically 30 days advance notice with a right of objection).
Why most templates trip up: most templates assume the vendor's sub-processor list includes the hyperscaler the vendor runs on. In customer-environment deployment the vendor does not run on a hyperscaler at all; the customer's hyperscaler is the customer's relationship and belongs in the customer's own register, not the vendor's.
Clause 3: Data flow and audit boundary
What the clause should say: describe the data path (originating in the customer's environment, processed inside the customer's environment, never leaving the customer's environment for inference purposes), describe the audit boundary (at the customer's perimeter), document any narrow exceptions (the licensing webhook payload contains only license token, software version, and heartbeat timestamp, with no inference data, document text, or user identifiers). Reference an architectural diagram as an exhibit.
Why most templates trip up: most templates do not have a data-flow clause at all, leaving the audit boundary undocumented. When the audit boundary is implicit, the customer's compliance team has to take it on faith. When it is explicit and diagrammed, the auditor can verify it.
Clause 4: Audit rights
What the clause should say: name three audit channels separately. (1) Audit rights over the vendor's organization, with annual audit, on-site or remote, and reasonable notice. (2) Audit rights over the deployment in the customer's environment, effectively unlimited because the deployment is in the customer's perimeter and does not require any vendor cooperation. (3) Regulator's direct audit access, which splits into two channels: Digital Operational Resilience Act Article 30 plus Article 39 for financial-services customers (Article 30 gives financial entities the contractual right of inspection that extends to their competent authorities, and Article 39 gives competent authorities direct access to designated critical ICT third-party providers' premises, systems, and personnel), and EU AI Act Article 26(10) plus Article 26(12) for any customer deploying a high-risk AI system (Article 26(10) requires the deployer to maintain logs and documentation, and Article 26(12) requires the deployer to cooperate with competent authorities, which includes producing that documentation on request). The DORA channel is the heaviest; the Article 26 channel reaches further across industries. See Financial services AI compliance for the DORA-specific contractual implications.
Why most templates trip up: most templates conflate "audit rights over the vendor" with "audit rights over the deployment." In customer-environment deployment these are separate. The audit rights over the deployment do not require any vendor cooperation because the deployment is inside the customer's perimeter.
Clause 5: Incident response and notification
What the clause should say: define an "incident" precisely (what triggers notification), name the maximum notification timing (typically 24 to 48 hours from vendor awareness, tighter than the customer's two outbound clocks), name the access pattern during incident response (re-granted read access, time-bounded, logged in the customer's identity and access management audit trail), and name the deliverables (post-incident report within 30 days, root cause analysis, remediation plan). The customer's two outbound clocks are: General Data Protection Regulation Article 33's 72-hour notification to the supervisory authority for personal-data breaches, and EU AI Act Article 26(5)'s requirement that deployers inform the AI system's provider of any serious incident. The vendor's notification has to be fast enough to give the customer time to act on both.
Why most templates trip up: most templates have generic 72-hour notification, which is too slow for the customer to meet either of its own outbound deadlines. The vendor's notification has to be tighter than the customer's regulatory deadlines.
Clause 6: Data residency and minimization
What the clause should say: name the data residency requirement (data stays in the customer's chosen jurisdiction, typically the European Economic Area; the vendor has no role in residency because the vendor does not have the data), name the data minimization commitment (the deployment defaults to logging only what is operationally necessary, with the customer choosing the verbosity), and name the data return and deletion obligations on contract termination.
Why most templates trip up: most templates assume data residency is a vendor commitment, which requires the vendor to control the data location. In customer-environment deployment the customer controls the data location. The clause flips: the customer commits to its own residency choice, the vendor commits to not undermining it (no exfiltration, no cross-region replication initiated by the vendor).
Clause 7: Termination and exit assistance
What the clause should say: name the termination triggers (material breach, non-payment, change of control, regulatory change), name the exit assistance period (typically 90 to 180 days during which the deployment continues to function while the customer transitions), name the data return and deletion obligations (in customer-environment deployment, data return is trivial because the data never left the customer's environment), name the source-code escrow arrangement if applicable.
Why most templates trip up: most templates assume the vendor has to "return" customer data on termination. In customer-environment deployment the data was never with the vendor; the question is whether the deployment continues to function after the vendor relationship ends. The clause needs to address that explicitly.
When the vendor is "neither", and how to write that into a Data Processing Agreement
Most generic Data Processing Agreement templates assume the vendor is a processor under General Data Protection Regulation Article 4. The "neither" framing is unusual enough that it benefits from explicit drafting rather than relying on the absence of processor language to imply non-processor status.
The right structure: a primary clause stating the vendor is neither a controller nor a processor in steady state, followed by an enumerated list of conditions under which the vendor becomes a processor (incident response, support sessions involving personal data access, configuration changes that require vendor staff to view personal data). Each condition is bounded in time (the access is time-limited), bounded in scope (read-only or to specific resources), and logged in the customer's identity and access management audit trail.
This structure gives the customer's auditor a defensible artifact. They can show the auditor the contractual statement that the vendor is neither in steady state, the enumerated conditions under which processor status applies, the time and scope bounds, and the audit-trail evidence that the conditions have or have not been triggered. A Data Processing Agreement that says "vendor is not a processor in steady state" plus the enumerated conditions is a stronger compliance posture than the absence of a Data Processing Agreement, and a stronger posture than a generic template that defaults to processor status.
For the full conceptual analysis of when this framing applies, see the audit boundary. The template here is the operational artifact that captures the analysis in contract form.
If you are about to negotiate a Data Processing Agreement with a regulated end-customer and want a starting point, the next step is a deployment call with deeplit®. The seven-clause structure above is the working document; we will walk through how each clause maps onto your deployment shape and what your end-customer is most likely to push back on. Book a deployment call when the conversation is the priority.
If your end-customer's compliance lead is the one asking for a Data Processing Agreement template scoped to AI infrastructure, this post is written to be forwarded to them. The seven-clause structure is theirs to negotiate from.
A Data Processing Agreement that names the audit boundary is stronger than one that hides it.
The cheapest legal review you can buy is a template that already has the right structure.
Frequently asked questions
Does our end-customer accept a Data Processing Agreement that says "vendor is not a processor"?
Most do, when the framing is explicit and the audit-boundary is documented. The customer's compliance team is looking for a defensible answer to give their own auditor. "Vendor is not in the data path; here is the architectural diagram and the contractual clause that confirms it" is a defensible answer. "Vendor is a processor with these scope limitations" is the fallback if the customer's compliance posture requires processor status by default.
Do we still need standard contractual clauses if data stays in the European Union?
If the data stays in the European Union and the vendor is not in the data path, standard contractual clauses for international data transfers are not applicable to the deployment itself. They may still be applicable to ancillary flows (the vendor's customer support emails, the licensing webhook destination if it is outside the European Union). Document each flow separately.
What about the European Union–United States Data Privacy Framework?
The European Union–United States Data Privacy Framework applies to transfers of personal data from the European Union to the United States. In customer-environment deployment with data staying inside the European Union, the framework is not relevant to the deployment. It becomes relevant if the vendor's licensing webhook or support tooling involves transfers to the United States. Document those flows separately.
How often does the sub-processor list need updating?
The Data Processing Agreement should commit to advance notice (typically 30 days) on any change to the sub-processor list, with a right of objection. In customer-environment deployment the sub-processor list is short and changes infrequently. The notification mechanism is what matters, not the cadence.
Does the EU AI Act Article 26 change what we need in the Data Processing Agreement?
For the GDPR sub-processor and processor-vs-controller questions, no. EU AI Act Article 26 sits alongside General Data Protection Regulation Article 28 rather than replacing any clause in it; the sub-processor disclosure (Clause 2) and the roles framing (Clause 1) are unchanged whether or not the deployed system is high-risk under the EU AI Act. For audit rights and incident response, yes. Article 26(10) requires the deployer to maintain logs and documentation, and Article 26(12) requires the deployer to cooperate with competent authorities (which includes producing that documentation on request), which means Clause 4 needs an explicit channel for that access (separate from the Digital Operational Resilience Act Article 30 plus Article 39 channel that financial-services customers already require). Article 26(5) gives the deployer an outbound notification obligation to the AI system's provider when a serious incident occurs, which means Clause 5's vendor notification timing has to be tight enough to let the customer meet that obligation alongside the General Data Protection Regulation Article 33 72-hour clock.
