When must you carry out a DPIA before switching on AI?

A DPIA sounds like something for large organisations with an in-house legal team. It isn't. It is an obligation under the GDPR that can apply to you the moment you put an AI assistant on your inbox, your WhatsApp or your phone line. And the awkward part is that it applies before you start, not after something goes wrong. This page explains what a DPIA is, when Article 35 GDPR makes one mandatory, what the Dutch supervisory authority has published about it, what belongs in the document, and what you do if a high risk still remains after you have taken every measure you can.

What is a DPIA, exactly?

DPIA stands for data protection impact assessment. The name is clumsy; the idea is simple. You write down in advance what you intend to do with personal data, what risk that creates for the people involved, and what you will do to reduce that risk.

Note that last part: for the people involved. A DPIA is not a risk analysis for your business. You are not assessing whether you might be fined or whether your system might go down. You are assessing what happens to your customer, your patient or your employee if things go wrong. That is a different perspective from the one most business owners are used to, and it is why a DPIA that only talks about uptime and backups is not a DPIA at all.

A DPIA is also not a form you fill in once and file away. It is an assessment tied to a specific processing operation. If you put an AI assistant on incoming email today and an AI phone agent that books appointments next quarter, those are two different operations with two different risk profiles. The second does not automatically inherit the conclusion of the first.

When does Article 35 GDPR require a DPIA?

The core rule sits in Article 35(1) GDPR. The law says you must carry out an assessment where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of individuals. Two things about that sentence matter to anyone considering AI.

First, new technologies are named explicitly. The legislator flagged them back in 2016. A language model that reads, summarises and answers customer messages falls within that description without much argument. That does not mean a DPIA is automatic — new technology is a reason to look, not a standalone obligation. But you cannot credibly claim that AI falls outside the frame.

Second, the text says "prior to the processing". The assessment belongs in the phase where you can still make choices: which data goes in and which does not, where the model runs, how long conversation history is kept, when the system hands over to a human. If you do the DPIA once the assistant has been running for three months, it is no longer an assessment but a retrospective justification. That is precisely what the provision is not for.

Article 35(3) then names three cases where a DPIA is "in particular" required: systematic and extensive evaluation of personal aspects on which decisions are based, large-scale processing of the special categories of data in Article 9 GDPR, and systematic large-scale monitoring of publicly accessible areas. If you recognise your plan in any of those three, the question of whether to do a DPIA no longer arises.

The supervisory authority has a list — and that list is not the end of it

Article 35(4) GDPR instructs every national supervisory authority to publish a list of processing operations for which a DPIA is mandatory in any case. The Dutch Data Protection Authority has done so. Its list includes, among other things, covert investigation of individuals, blacklists, processing of health data, biometrics, location data, communications data, profiling, and systematic monitoring of employees.

Several of those are immediately recognisable for AI in customer contact. Communications data: an AI assistant handling email or WhatsApp does nothing other than read and store communications. Employee monitoring: if the same system measures how fast your staff reply or how their conversations score, you are in that category too. Health data: at a clinic, a dental practice or a physiotherapy practice it arrives on its own, whether you ask for it or not.

Where it goes wrong in practice is the reverse reasoning. Business owners read the list, fail to recognise themselves in it, and conclude they are done. That is not how it works. The authority states itself that the list is not exhaustive and that if your processing is not on it, you must assess for yourself whether it creates a high privacy risk for the people whose data you want to process. The list is a floor, not a ceiling. If you are not on it, all that changes is where the burden lies: you have to be able to show that you made the assessment and why you landed on "no high risk".

Which criteria together add up to a high risk?

To make that assessment yourself, there is a fixed set of criteria. They come from European guidance and are used by the Dutch authority as well. The rule of thumb is this: if your processing meets two or more of these criteria, assume there is a high risk and carry out a DPIA. If it meets one, a DPIA may still be needed — and if you decide otherwise, you have to explain why.

The high-risk criteria, set against whether they typically apply to AI in customer contact

Criterion	What it means	Does it apply to AI in customer contact?
Evaluation or scoring	You assess people's characteristics, behaviour or value, including profiling.	Sometimes. As soon as the AI classifies, prioritises or estimates the sales potential of customers, this counts.
Automated decisions with an effect	The system decides something the customer notices, without a human looking at it.	Only if you genuinely let the AI decide. Drafting a reply is not the same as rejecting a request. See also Article 22 GDPR.
Systematic monitoring	You observe people structurally and they cannot easily avoid it.	Often. Reading and storing every incoming message is structural, not incidental.
Sensitive or highly personal data	The special categories in Article 9 GDPR, or data that sits deep in someone's private life.	Yes in healthcare and legal services. Elsewhere too, because customers volunteer information about illness, debt or divorce.
Large-scale processing	Many people, a lot of data, over a long period or a wide area.	Depends on your volume. A single practice with a limited client base scores differently from a webshop with thousands of conversations a month.
Matched or combined datasets	You bring together data from different sources that the customer did not expect to be combined.	Yes as soon as the assistant queries inbox, calendar, CRM and order history at once in order to answer.
Vulnerable data subjects	People who find it hard to object: children, patients, people in financial difficulty, and your own staff.	Yes in healthcare and in debt-sensitive sectors. Employees count here too, because genuinely free choice is difficult inside an employment relationship.
New technology or innovative use	You deploy technology whose consequences are not yet settled.	Almost always. This is the criterion Article 35 itself names, and AI meets it by definition.
Blocking a service or a right	Anyone who does not go along with the processing is denied access or denied the service.	Yes if the AI becomes the only point of entry and there is no human route left for those who want one.

Count them honestly for your own situation once. An AI assistant on the inbox of a physiotherapy practice hits sensitive data, vulnerable data subjects, new technology and systematic processing of communications in one go. That is four. You do not need a long meeting about that one: it is a DPIA.

What belongs in a DPIA?

Article 35(7) GDPR names four elements. They are written briefly, but they determine whether your document is worth anything.

1. A systematic description of the processing and its purposes. What data goes in, from which sources, who can access it, where it is stored, what happens to it, how long it is kept. For AI that also includes: do conversations go to a supplier's model, and what happens to them there.
2. An assessment of necessity and proportionality. Could the purpose be achieved with less data? Does the assistant really need access to the full customer file, or is the most recent order enough? This is where data minimisation under Article 5 GDPR becomes concrete.
3. An assessment of the risks to the rights and freedoms of data subjects. What happens to the customer if the model answers something wrong, if a conversation reaches the wrong person, or if the conversation history leaks.
4. The measures you will take. Safeguards, security measures and mechanisms that let you demonstrate compliance with the GDPR.

That fourth point is where most of the work sits, and the supervisory authority does not hand you a ready-made checklist for it. The Dutch Data Protection Authority states that every organisation processing personal data must determine for itself which security measures are needed, and must look at the risks the processing brings with it in order to do so. There is no approved set you can simply copy. What you can do is write down, per risk, the measure you put against it: restricting access rights on the inbox, a short retention period for conversation history, human review before the AI answers on its own, logging of what the system did, and arrangements with the supplier in the processor agreement required by Article 28 GDPR.

Two things are frequently forgotten. If you have a data protection officer, you must seek their advice; that is Article 35(2). And Article 35(9) says that where appropriate you seek the views of data subjects or their representatives. For a system that also measures your staff, the works council is the obvious address for that.

Does the AI touch special category data? Then you start from a stricter position

For healthcare providers, and for anyone who receives health data, the bar sits differently. Article 9(1) GDPR prohibits the processing of special categories of personal data in principle. Health data falls within that. So you do not start from "may I do this with a good reason", but from "this is prohibited unless I can point to an exception".

In practice that means two things for your DPIA. You must write down explicitly which exception you rely on and why it applies to this specific processing. And you have to account for the fact that health data arrives even when you do not ask for it: someone rescheduling an appointment over WhatsApp because they have had surgery has just handed you a special category of personal data. If your AI assistant reads and stores all that traffic, it processes that data too. The question is not whether it happens, but whether you have described and secured it.

What do you do if a high residual risk remains?

Sometimes you cannot get there. You have listed the measures, you have cut what could be cut, and a high risk still stands. That is the residual risk. Article 36 GDPR covers it: where a high residual risk cannot be mitigated, you consult the supervisory authority before you begin the processing. This is called prior consultation.

In practice this is rarely the end of the road for a smaller business, for a simple reason: with AI in customer contact, almost every high residual risk can be brought down by changing the design. That is the payoff of doing a DPIA genuinely in advance. The levers used most often:

• Less data into the model. Give the assistant access to what it needs for the answer, not to the whole archive.
• A human in the loop. Let the AI draft, and have someone approve, rather than sending autonomously. That often removes the "automated decisions" criterion entirely.
• Shorter retention. Conversation history you no longer hold cannot leak.
• A narrower scope. Start with one channel and one type of question instead of everything at once.
• A human route alongside. Anyone who does not want AI should be able to reach a person. That removes the blocking criterion.

Change the design and you change the outcome of the DPIA. Write that down. A DPIA showing that you first considered a heavier variant and scaled it back for good reasons is stronger than one that lands on the light variant straight away.

How do you handle this in practice before switching the AI on?

A workable order of play for a business without a legal department:

1. Write down in plain language what the AI will do, on which channel, and which data it sees to do it. One page is enough to start.
2. Walk through the criteria in the table above and note yes, no or maybe for each, with one sentence saying why.
3. Check whether your processing appears on the supervisory authority's list. If it does, the DPIA is mandatory and there is nothing left to debate.
4. If you land on two or more criteria, do the DPIA. If you land on nought or one, record in writing why you see no high risk. The recording is the work; the conclusion is one line.
5. Work out the four elements of Article 35(7) and attach a measure to each risk.
6. Put the measures the supplier has to implement into the processor agreement, so that they do not live only in your own document.
7. Put a date and an owner on it, and diary the review.

That last step is not a formality. Article 35(11) GDPR says you review the assessment when the risk changes. With AI, things change fairly often: your supplier swaps the model under the bonnet, you give the assistant access to an extra system, you put it on a second channel, or you suddenly let it send replies itself. Each of those changes is a reason to pick the DPIA back up rather than treat it as finished.

How does this relate to the AI Act?

The DPIA comes from the GDPR and is about personal data. The AI Act is a different law with its own logic. It is built around risk: the higher the risk to people or to society as a whole, the stricter the rules your organisation has to deal with, and the law distinguishes between risk groups to do that. For ordinary customer contact you usually sit in the category where transparency obligations are the main issue — people have to know they are talking to a machine.

What matters is that the two laws apply independently. If your application is not in the high-risk category under the AI Act, that says nothing about your DPIA obligation. And the other way round. An AI assistant that only answers standard questions can be light under the AI Act and still require a DPIA under the GDPR, simply because the communications data of a lot of people passes through it. Treat them as two separate boxes to tick on the same piece of preparation.

What happens if you skip it?

The practical risk is not an inspector on your doorstep. It is the moment something goes wrong: a data breach, an angry customer requesting access, an employee who feels watched, or a complaint to the supervisory authority. At that moment the first question is always the same: what had you assessed in advance, and what had you decided? Without a DPIA you are empty-handed, even if your system is technically sound.

Conversely, a DPIA on file is no guarantee, but it is evidence that you took the assessment seriously. That is exactly what the accountability principle in Article 5(2) GDPR asks of you: not only acting properly, but being able to show that you acted properly. And along the way it gives you something you needed anyway — a clear picture of which data flows through your AI channel and why.

This page is general information about legislation and not legal advice. Whether a DPIA is mandatory in your specific situation depends on facts that do not all fit here. If you are in doubt, or if special categories of personal data are involved, having a lawyer or privacy adviser look at your own set-up is the safe route.