Processor or controller: who is which when you buy AI?
With an AI handling your customer contact you are almost always the controller and the vendor is the processor. That is not a choice you settle in a contract: the Dutch DPA looks at who in fact determines why and how the data is processed. If the processing agreement says something other than what actually happens, reality wins.
Published on
Why this is more than a label
The division of roles determines who is held to account. The controller reports a data breach to the regulator, answers data subject requests, and is the party that accounts for things when they go wrong. The processor carries out instructions and answers to the controller, not to the data subject.
When buying AI that division is often dismissed in a single sentence — "we are the processor" — and left there. That is too quick, because the test is not what the contract says.
What the regulator looks at
The Dutch Data Protection Authority frames it as a factual question: whether an organisation is a processor or a controller depends on where actual influence over the purpose and means of the processing sits. In other words: who determines for what purpose the personal data is processed, and how that happens.
That is a test of behaviour, not of paperwork. A vendor who decides on their own which data to retain, for how long, or who uses it to improve their own model, is behaving as a controller — regardless of what the agreement says.
| Question | Points to you as controller | Points to the vendor as controller |
|---|---|---|
| Who decides which messages are processed? | You, per mailbox or channel | The vendor sets the scope |
| Who sets the retention period? | You, recorded in the agreement | The vendor, as "standard policy" |
| Is your data used to train the model? | No, or only on your explicit instruction | Yes, for product improvement generally |
| Who selects sub-processors? | The vendor proposes, you authorise | The vendor swaps them without asking |
| Who answers a customer's access request? | You, with the vendor's help | The vendor, directly |
What to take into a vendor conversation
Three questions separate a genuine processor from someone behaving as a controller. One: is our data used to improve your model, and if so, can we switch that off? Two: who decides how long messages are retained, and where is that written down? Three: which sub-processors exist today, and what happens when you add one?
A vendor with a concrete answer to all three does not need to be a lawyer. A vendor who points at the contract for all three has not understood the question.
And the limit on what the AI may decide
Separately from the division of roles, article 22 GDPR applies: decisions based solely on automated processing that significantly affect someone are prohibited as a rule. The Dutch implementation act carves out an exception in article 40, but only in narrowly described cases and not on the basis of profiling. That boundary should be established before the system is switched on, not after.
This article is not legal advice and does not replace an assessment of your own situation. What it does do: sharpen the questions you should be asking a vendor.