What This Template Covers
The GDPR DPA template for AI products covers eight core sections that together constitute a legally compliant controller-processor agreement adapted for the specific obligations that arise when the processing involves AI systems. The definitions section establishes the key terms used throughout the agreement, including the definitions required by GDPR Article 4 (personal data, processing, controller, processor, sub-processor) and additional AI-specific definitions (training data, model inputs, model outputs, inference processing). The scope of processing section defines precisely what personal data is processed, for what purpose, by what means, and for what duration. This section is the foundation of the DPA. Vague scope definitions create legal and operational problems when scope disputes arise. The controller obligations section records what the controller commits to: providing lawful instructions, ensuring the data subject rights framework is in place, and informing the processor of any relevant regulatory constraints. The processor obligations section records the processor's GDPR Article 28 commitments: processing only on documented instructions, ensuring confidentiality, implementing appropriate security measures, managing sub-processors, assisting with data subject rights, supporting security obligations, enabling audits, and deleting or returning data on termination. The sub-processor management section is particularly important for AI products. Every AI model API (OpenAI, Anthropic, Google, Azure OpenAI) that receives personal data is a sub-processor. The DPA must name them or establish a process for managing them, and must flow down the data protection obligations. The security measures section specifies the technical and organisational measures applied to the personal data processing. For AI products, this includes measures specific to model input and output handling. The international transfer section covers the mechanisms for any transfers of personal data outside the UK or EU, including transfers to AI model providers whose infrastructure is located in the United States. The AI-specific clauses section covers the data protection considerations specific to AI processing: training data use, output retention, model improvement use, and bias monitoring obligations.
How to Use This Template Step by Step
Step one: complete the parties section. Identify the controller (your customer, who determines the purpose and means of processing) and the processor (you, the AI product company, who processes personal data on behalf of the controller). In some AI product architectures, there may be a chain: your customer is a controller, you are a processor, and an AI model provider is your sub-processor. Step two: complete the scope of processing annex. This is the most important section to complete carefully. For each category of personal data processed, document: the data category (names, contact details, financial data, health data, employment data), the subjects whose data is processed (the controller's customers, employees, or other individuals), the processing activities performed (data ingestion, model inference, output generation, storage), the purpose of processing, and the duration of processing or the criteria for determining it. Step three: review the processor obligations and confirm your organisation meets each one. The critical obligations for AI products: you process only on the controller's instructions (this means you cannot use the controller's data to train your models unless the controller has explicitly instructed this); you ensure confidentiality through appropriate staffing measures (staff processing agreements, access controls); you implement appropriate technical and organisational security measures (see Article 32 and the template's security annex); you obtain controller authorisation before engaging sub-processors; you assist the controller with data subject rights requests, including deletion requests that may affect data used in AI training; and you delete or return all personal data on termination. Step four: complete the sub-processor schedule. List every third-party service that will receive personal data as part of your processing. For an AI product, this commonly includes: the AI model provider (OpenAI, Anthropic, Google, Amazon Bedrock), the cloud hosting provider (AWS, GCP, Azure, Vercel), the database provider (Supabase, Neon, PlanetScale), the authentication provider (Clerk, Auth0), and any monitoring or logging service that receives personal data. For each sub-processor, record: the name, the country where processing occurs, the data categories shared, and the legal mechanism for any international transfer. Step five: complete the security measures annex. Required measures include: encryption of personal data at rest and in transit, access controls and authentication, audit logging of access to personal data, vulnerability management process, incident response procedure, and staff training on data protection. For AI-specific processing, add: controls on what data can be submitted as model inputs, controls on model output retention, and the process for responding to ICO or regulator requests for information about AI processing. Step six: address international transfers. If any sub-processor is based outside the UK or EU (which is very common for US-based AI model providers), the DPA must include a transfer mechanism. For UK GDPR, the relevant mechanisms are: adequacy regulations (for countries the UK Secretary of State has designated as adequate), International Data Transfer Agreements (the UK equivalent of Standard Contractual Clauses), or the UK Addendum to EU Standard Contractual Clauses. For EU GDPR, the mechanisms are adequacy decisions or Standard Contractual Clauses (EU SCCs, 2021 version).
Section-by-Section Walkthrough
The scope of processing annex is the most commonly poorly completed section of GDPR DPAs. Vague descriptions like "customer data as provided" or "data necessary for the service" do not meet the Article 28(3)(a) requirement to specify the subject matter and duration, the nature and purpose of processing, the type of personal data, and the categories of data subjects. Complete each field specifically. If the scope is genuinely unknown at contract signing (for example, because the controller may send different types of personal data over time), establish a process for scope updates rather than leaving it blank. The processor obligations section should be reviewed against your actual processing activities. The obligation to process only on controller instructions has a specific implication for AI products: if you want to use customer data to improve your AI model (for fine-tuning or evaluation), this constitutes a processing activity beyond the original purpose. You need the controller's explicit instruction to do so. Many AI product terms of service claim the right to use customer data for model improvement without the DPA reflecting this as an instruction. This creates a legal gap. The sub-processor section needs to address the notification mechanism for new sub-processors. Article 28(2) requires that processors inform controllers of intended changes to sub-processors and give them the opportunity to object. In practice, AI products frequently add or change model providers. Establish a clear notification mechanism (email notification with a 30-day objection window is standard) and implement it consistently. The security measures annex for AI products should specifically address: the technical controls applied when personal data is submitted as model input (is it encrypted in the API call? is it logged? is it retained by the model provider?), the controls on model output that may contain personal data (outputs that reproduce personal data from inputs), and the controls on any fine-tuning or evaluation use of personal data (if applicable). The AI-specific clauses section should include a clause that explicitly prohibits use of personal data for model training outside the scope of the agreed DPA unless separate controller instruction is obtained. It should also include clauses addressing the right to erasure obligation: if a data subject requests erasure, how will you identify and delete personal data that may have been processed as model input? This is a technically complex obligation that many AI products have not fully addressed.
Common Mistakes This Template Prevents
The most common GDPR DPA mistake for AI products is not having one at all. Many AI SaaS products process customer personal data without a DPA in place because the founders are not aware that one is required. Under GDPR Article 28, the absence of a DPA means the controller is in breach, and if the ICO investigates, the absence is an aggravating factor in any enforcement action. This template removes the barrier to having the right agreement in place. The second mistake is using a generic DPA template that does not address AI-specific processing. Standard DPA templates were written for conventional software processing. They do not address model input handling, output retention, training data use, or the sub-processor chain that is specific to AI products. This template includes AI-specific clauses that standard templates omit. The third mistake is listing sub-processors incorrectly or incompletely. Teams often list the primary cloud provider but omit the AI model provider, the database provider, or the analytics provider. A sub-processor is any third party that processes personal data on the processor's behalf. If OpenAI receives personal data as part of API calls made by your product, OpenAI is a sub-processor and must be listed. The fourth mistake is not including international transfer mechanisms. Many AI products process data in EU or UK based infrastructure but route model API calls to US-based model providers. The transfer of personal data in those API calls is an international transfer that requires a legal mechanism. This template's transfer section specifically addresses AI model provider transfers.
Customisation Tips for Different Project Types
For fintech products subject to FCA oversight, add a section covering FCA-specific data governance obligations. The FCA expects regulated firms to maintain appropriate records of data processing, to be able to demonstrate control over data processors, and to conduct due diligence on processors' security posture. The DPA should be supplemented by a formal supplier due diligence process. FCA SYSC rules on data and systems management are the relevant reference. For healthcare products that process special category health data (Article 9 GDPR), the DPA needs additional provisions. Processing special category data requires a lawful basis under Article 9 as well as Article 6. The common bases for health data processing in a B2B AI context are Article 9(2)(h) (healthcare and social care) or Article 9(2)(j) (scientific research). The DPA should record the Article 9 basis explicitly and the additional safeguards applied to special category data. For products processing children's data (under 18 in the UK, under 16 in most EU member states), the DPA should include enhanced safeguards for children's data and a prohibition on using children's data for model training or improvement without specific legal basis. For multi-jurisdictional enterprise products sold to both UK and EU customers, consider whether to use separate UK GDPR and EU GDPR DPA templates or a combined template with country-specific addenda. The ICO and the European Data Protection Board have published compatible but not identical guidance on DPA requirements. A combined template is more efficient but requires careful review to ensure both sets of requirements are met.