What has to be in a data processing agreement with an AI supplier?
Article 28 GDPR requires a written contract setting out the subject matter, duration, nature and purpose of the processing, the type of personal data, the categories of data subjects and your rights and obligations as controller. It must also cover processing on your documented instructions, confidentiality, security (Article 32 GDPR), sub-processors, assistance with customer requests and data breaches, and deletion or return at the end. Sub-processors need your authorisation and the chain must carry the same duties. In the end the factual situation counts, not the wording.
Published on
Why does the law require a contract here at all?
The moment you let an AI supplier process customer data, someone else is handling your customers' information. The GDPR allows this, but not on the basis of trust alone. Article 28 GDPR states that processing by a processor shall be governed by a contract that binds the processor with regard to you, the controller. That is not a recommendation or a best practice: it is written as a requirement. Article 28(9) adds the form. The contract must be in writing, and electronic form counts. So an agreement confirmed by email or a document signed online qualifies; a verbal arrangement with the account manager does not.
What surprises many business owners: the duty does not sit with the supplier alone. The Dutch Data Protection Authority writes that the GDPR requires a processing agreement from both controllers and processors, and that both parties are liable if there is none. So you cannot say the supplier should have provided it. If the document is missing, that is your problem too.
The practical meaning is simple. Before the AI assistant goes live on your inbox, your WhatsApp or your phone line, a signed document has to exist. Not afterwards, not at the first renewal, and not only once something goes wrong.
What subjects have to be in it as a minimum?
Article 28(3) first lists a number of things the contract must set out about the processing itself. There are six of them:
- the subject matter of the processing: what the supplier does for you;
- the duration of the processing: how long, and what happens when it stops;
- the nature and purpose of the processing: which operations, and what for;
- the type of personal data being processed;
- the categories of data subjects: whose data this is;
- the rights and obligations of you as the controller.
In most standard contracts those six sit in an annex at the back. That is exactly the annex that is most often left blank or filled with generalities such as "data supplied by the customer" and "for the duration of the service". An annex like that does not meet what Article 28 asks, because there is nothing in it you can check later. Fill that annex in carefully together with the supplier and you immediately have the most important part of your own record of processing activities in order.
What should you look at per item with an AI supplier?
With AI for customer contact, the difficulty is not in the list but in how it is filled in. A chat or phone channel is free text. Your customer types or says whatever they want, and all of it ends up in the system. The table below walks through the mandatory items and states, for each one, what to watch for.
| Component | What the law asks | What to watch with AI |
|---|---|---|
| Subject matter | What the processing covers | Name the channels separately: email, WhatsApp, telephony. A voice agent makes recordings and transcripts; that is something other than answering text. |
| Duration | How long processing lasts | Not just the contract term, but also how long conversations, transcripts and log files stay in the supplier's system. |
| Nature and purpose | Which operations, and what for | Record that your customer data is not used to train models or improve the service unless you expressly instruct it. |
| Type of personal data | What data is involved | Free text means anything the customer puts in. Describe that honestly and agree what happens when sensitive data comes through. |
| Categories of data subjects | Whose data this is | Often more groups than expected: customers, prospects, job applicants, suppliers, and your own staff working in the system. |
| Rights and obligations of the controller | What you may and must do | Your right to give instructions, retrieve data and stop the service has to be spelled out concretely, not as a polite formula. |
| Instructions | Processing only on your documented instructions | Make clear what the instruction is: the configuration, the system prompt and the integrations are part of it. |
| Confidentiality | Staff are bound to confidentiality | Ask whether the supplier's support staff can read along in conversations, and under what conditions. |
| Security | Measures under Article 32 GDPR | Ask for concrete measures: encryption, access control, logging. "We take security seriously" is not a measure. |
| Sub-processors | Conditions for engaging others | An AI service almost never runs on its own. Ask for the current list and agree how you hear about changes. |
| Assistance with customer rights | Helping with access, correction and erasure | Can you find and delete one customer's conversation without damaging the rest? If not, that is a problem today. |
| Assistance with security and notifications | Helping with Articles 32 to 36 GDPR | Agree how fast and with what information the supplier notifies you, so that you are on time yourself. |
| End of processing | Deletion or return, at your choice | Record in what format you get the conversations back and within what period copies and backups disappear. |
| Information and audits | Providing information and allowing audits | If your own audit is unrealistic, agree which reports you receive and how often. |
What duties does the law place on the supplier?
After those six subjects, Article 28(3) sets out under (a) to (h) what the contract must "in particular" stipulate about the processor. In short: it processes only on your documented instructions, it ensures its people are bound to confidentiality, it takes the security measures of Article 32, it respects the conditions for engaging other processors, it assists you with requests from customers exercising their rights, it assists you with your obligations around security and data breaches, it deletes or returns the data when the service ends, and it makes available the information you need to demonstrate that all of this is being complied with.
There is one further provision that is easy to miss: the processor must immediately inform you if, in its opinion, an instruction from you infringes the GDPR. That is a useful clause to leave in. It forces the supplier to speak up rather than quietly carry out what you asked.
Watch for softening language as you read. "As far as reasonably possible", "at additional cost" and "within a reasonable period" are not forbidden words, but they take the edge off precisely those points where you will need the supplier later. Especially for assistance with data breaches and customer requests, a specific deadline beats a reasonable one.
May the supplier bring in other parties itself?
Only if you allow it. Article 28(2) states that a processor shall not engage another processor without prior written authorisation from the controller. That authorisation can be specific, per party, or general. If you go for general authorisation, there is a counterweight: the processor must inform you of intended changes to the list of sub-processors and give you the opportunity to object.
With AI services this is not a formality. An assistant for customer contact almost always leans on a chain: a language model running through another party, hosting capacity, a telephony provider, speech recognition, perhaps a monitoring service. Every link in that chain that sees customer data is a sub-processor. So ask for the current list with name, function and country of establishment, and for the agreement that you hear about changes in advance rather than through an updated page on their website.
Article 28(4) governs what applies then. The same data protection obligations as set out in your own contract must be imposed on that other processor, and the first processor remains fully liable to you for the performance of those obligations. So your supplier cannot hide behind its own supplier. What does that mean in practice? If you agree a clause about model training, it has to carry through the chain. Ask about that explicitly.
What if those sub-processors sit outside Europe?
With AI that is the rule rather than the exception, and it changes the question. The Dutch Data Protection Authority states that personal data may only be sent from the Netherlands to another country if that country offers sufficient protection, and that separate rules apply to transfers to the United States. So transfer is not an annex detail but a test of its own.
For the contract this means three things. First: have it recorded in which countries the processing and storage take place, including those of the sub-processors. Second: have it recorded on what basis the transfer rests, and ask for the accompanying documents. Third: if the supplier promises everything stays inside the EU, get that in writing, together with the agreement that any relocation is announced in advance. A verbal reassurance about "European servers" that appears nowhere in the contract is worth nothing at the moment you need it.
What do you agree about security?
Article 32 GDPR requires appropriate technical and organisational measures, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, plus the risks to the people involved. An important detail: that article addresses the controller and the processor. The duty scales with the risk, not with the size of your company.
The Dutch Data Protection Authority adds that every organisation must determine for itself which security measures are needed, based on the risks the processing brings. There is no checklist to tick off. That makes the annex to your processing agreement important: it sets out what the supplier actually does, and that is the material with which you support your own assessment. Ask for measures you can verify, such as encryption of storage and transport, two-factor authentication, roles and permissions, and logging of who viewed which conversation.
How do you handle data breaches in the contract?
Article 33 GDPR states that the controller shall notify a breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it. That clock runs at your end, not at your supplier's. And in most cases you depend on the supplier even to know that something has happened.
So make sure the contract does not stop at "the processor informs the controller". Agree within how many hours it reports, to whom it reports (a name or a role mailbox, not a general contact form), and what information comes with it straight away: what happened, which data and how many people are affected, and what has already been done. Also agree that the supplier cooperates with your notification and with informing customers, and that it does not go public on its own about an incident that affects your customers.
What has to happen when the contract ends?
Article 28(3)(g) gives you the choice: after the end of the provision of services, the processor deletes all personal data or returns it, and deletes existing copies, unless storage is legally required. The word that counts is "choice". It is yours, not the supplier's. Many standard contracts reverse this and simply state that everything is deleted after thirty days. That can be a problem if you still need the conversation history yourself.
So record what you choose and what that looks like in practice. In what format do you get the conversations back, and is that format usable outside their system? Within what period after termination? Does the return cover transcripts, audio files, log files and analyses, or only the visible messages? How long does the data stay in backups and when do those expire? And if you choose deletion: do you get confirmation of it, and what exactly does that confirmation state?
You make these arrangements at the start, because at the end you are in the weakest position. A supplier you are just parting ways with is rarely the party that quickly helps you with an export.
Why practice weighs more heavily than the text
There is a misunderstanding in many contracts that is worth considering. A supplier can call itself a "processor" on paper, but that does not make it one. The Dutch Data Protection Authority puts it sharply: the organisation that actually determines the purposes and means of the processing is the controller under the GDPR, regardless of what the processing agreement says. When assessing a processing operation, the authority looks at the factual situation.
For you that means two things. If the supplier also uses your customer conversations for its own purposes, for example to improve its model or to do product research, then for that part it determines the purpose itself. A processing agreement is then not the right instrument for that part, and you have gained a problem rather than a solution. And the other way round: a tidy contract with an annex that does not match how the system really works does not protect you. If the contract says no data leaves the EU while it does, reality is what counts.
So go through the contract once with the question: does this match what the system does? Who sees conversations in practice? Where are they stored? What happens to the text after the customer has had an answer? If you cannot answer those questions, that is not a contract problem but an information problem, and you solve it with the supplier before you sign.
What do you do now, concretely?
A workable order for a business owner with little time:
- Ask for the processing agreement before the trial period, not after it. If you do not get one, or only after insisting, that in itself is information.
- Skip the general terms and read the annexes first: the description of the processing, the security measures and the list of sub-processors.
- Check whether the six subjects from Article 28(3) are genuinely in there and whether they describe your situation.
- Find the provision about using your data for training and improving the service. If there is nothing there, ask about it in writing.
- Request the list of sub-processors and their countries of establishment, and agree how you hear about changes.
- Make the breach notification arrangement concrete: deadline, recipient, contents.
- Decide now what happens at the end, and in what format you get your data back.
- Store the signed document somewhere you can find it within a minute, together with the annexes that applied at that moment.
This article is general explanation of what the law asks, not legal advice about your situation. If you have doubts about a specific contract or about processing that involves special categories of data, put it to a lawyer who knows your circumstances.