What is the difference between a data controller and a data processor?

The GDPR distinguishes two roles with different legal responsibilities over any processing of personal data. The data controller is whoever determines the purpose and means of processing: why the data is collected, what it is used for, with which tools. The controller is ultimately accountable for GDPR compliance, and it is the controller who is sanctioned in case of a breach, even when the actual processing happens elsewhere. The data processor is instead whoever processes data on the controller's behalf, following the controller's documented instructions: typically a vendor, a cloud provider, a SaaS platform. The processor does not decide why the data is processed, it carries out a task on someone else's mandate. That is why a DPA (Data Processing Agreement, required under Article 28 of the GDPR) must exist between controller and processor: it defines the subject matter, duration, nature and purpose of processing, security obligations, sub-processor management, and the conditions for any transfer of data outside the European Union.

Why it matters even more with AI

When a company uses a third-party AI service, a cloud LLM or an analytics platform, the question "who is the controller and who is the processor for this data" stops being a legal-department exercise and determines who is accountable when something goes wrong. The point often overlooked in SaaS and AI contracts is this: a vendor that also uses customer data to train its own models, on top of providing the contracted service, may be acting as an independent controller for that specific purpose, not merely as a processor for the main service. In that case the vendor no longer just follows the customer's instructions, it decides on its own the purpose and means of an additional processing activity, and is accountable for it directly. Blurring the two roles, or missing the point where one slides into the other through model training, leaves exposed exactly the area where an incident costs the most.

How to check it in practice

The first step is reading the vendor's DPA, not just the general terms of service: they are two different documents, and the latter often does not cover the obligations the former is meant to formalize. Inside the DPA, three clauses deserve particular attention: the list and regime of sub-processors (who else processes your data downstream of the direct vendor), the conditions for transferring data outside the European Union, and above all whether and how the vendor uses the data for its own purposes such as model training. If that last point is not explicitly excluded or regulated, it needs clarifying before signing, not after an incident.

Why it matters for anyone adopting third-party AI tools

The topic connects to two other glossary entries: the jurisdictional risk of the CLOUD Act for vendors subject to US law, and the data classification that makes it possible to establish what can be shared with an AI vendor and what cannot, namely data governance. Anyone adopting third-party AI tools without clarifying roles and responsibilities is, in effect, delegating a legal decision to their procurement department.

This entry is informational and does not constitute legal advice: for decisions on regulated data, involve your DPO or legal counsel.