Controller vs Processor: Getting the Roles Right
GDPR draws a fundamental distinction between the data controller and the data processor. The controller is the entity that determines the purposes and means of processing personal data - in most cases, this is your company. You decide why you collect user data, what it is used for, and how long it is kept. The processor is an entity that processes personal data on behalf of the controller, following the controller's instructions. When you call the OpenAI API with your user's data, OpenAI is acting as your data processor. When you store user records in AWS RDS, Amazon is your processor. The DPA formalises this relationship and sets out the obligations of the processor. Without a DPA in place, the controller is in breach of GDPR Article 28 regardless of how well the processor actually handles the data.
What a GDPR-Compliant DPA Must Contain
GDPR Article 28 specifies the mandatory content for DPAs. The agreement must state the subject matter, duration, nature, and purpose of the processing. It must identify the type of personal data involved and the categories of data subjects. It must set out the obligations and rights of the controller. The processor must be bound to process data only on documented instructions from the controller. The processor must ensure that all persons authorised to process the data are under confidentiality obligations. The processor must implement appropriate technical and organisational security measures. The processor must not engage sub-processors without prior written authorisation from the controller, and must flow down equivalent obligations to sub-processors. The processor must assist the controller in fulfilling data subject rights requests and in conducting DPIAs. On termination, the processor must delete or return all personal data. In practice, most major cloud and SaaS vendors provide standard DPAs that cover these requirements. Your obligation is to review and accept them, not draft them from scratch.
DPAs and LLM API Providers
The three major LLM API providers - OpenAI, Anthropic, and Google (Vertex AI) - all offer DPAs for their API customers, typically covering the API product separately from consumer-facing products. OpenAI's API DPA includes Standard Contractual Clauses for transfers of EU personal data to the US. Anthropic's commercial API terms include equivalent provisions. Google Cloud and AWS Bedrock operate under their standard Cloud DPAs which have extensive regulatory compliance coverage. The critical point is that you must actively accept or execute the DPA, not just use the service. For most providers, this means ticking a box in account settings or signing the DPA addendum. Review the sub-processor list in your LLM provider's DPA, as personal data you send may be processed by multiple downstream infrastructure providers. You must disclose material sub-processors to your customers if you are acting as a processor for them.
When You Are Both Controller and Processor
If your AI product processes data on behalf of your B2B customers, you occupy the processor role in relation to your customers' data, while your customers are the controllers. This means your customers need a DPA with you. If you are a B2B SaaS providing an AI tool that processes your customers' employee data or end-user data, you must offer a DPA to your B2B customers and your DPA must flow down obligations to your own sub-processors including LLM API providers. Enterprise procurement teams will request your DPA before signing contracts. Not having one ready is a common reason early-stage B2B AI products fail procurement reviews. At SpeedMVPs, we recommend including a standard DPA template in the product delivery package for any B2B AI MVP, so founders can respond to enterprise procurement requests immediately after launch.
International Data Transfers and SCCs
When personal data moves from the EU or UK to a country without an adequate level of data protection, a transfer mechanism is required. For transfers from the EU to the US, the most common mechanism is Standard Contractual Clauses. For UK data transfers, the UK equivalent is the International Data Transfer Agreement or the UK Addendum to EU SCCs. Most US-based LLM API providers include SCCs in their DPAs. For UK data specifically, check whether the provider's DPA covers UK transfers explicitly. The UK and EU maintain separate but broadly aligned transfer frameworks. If you are operating in both markets, your legal documentation needs to address both. The ICO publishes guidance on transfers of personal data from the UK, which is the authoritative source for UK teams.
Practical DPA Checklist for AI Startups
Work through this checklist as you build your compliance documentation. First, map all third-party services that receive personal data and classify each as processor or independent controller. For processors, confirm DPAs are in place and executed, not just available on their website. For independent controllers, ensure your privacy notice discloses the data sharing. Second, if you offer a B2B product, prepare your own DPA for customers. It should cover the mandatory Article 28 elements, include your sub-processor list, and include appropriate SCCs or UK transfer mechanisms for any US-based sub-processors. Third, establish a process for handling sub-processor changes. GDPR requires you to notify customers of material sub-processor additions, and customers have the right to object. Fourth, ensure your DPAs have termination provisions that require processors to delete or return data, and that you can actually comply with these provisions from your own infrastructure when a customer ends their contract.