IT emails the privacy officer: Copilot goes live across the organisation next month, so does that need a DPIA? The privacy officer knows the answer is not in the licence agreement, nor in the name of the tool.
The answer: not automatically, but in most organisations, yes. The obligation follows the risk of the processing, and for generative AI used by dozens of people with customer or staff data in their prompts, that risk is rarely low.
When does Article 35 GDPR require a DPIA?
Article 35 GDPR requires a data protection impact assessment where processing, taking into account its nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of individuals. The article itself names three situations, including large-scale processing of special categories of data and systematic evaluation of personal aspects.
The EDPB guidelines (WP248 rev.01) make this workable with nine criteria: evaluation or scoring, automated decisions with legal effect, systematic monitoring, sensitive data, large-scale processing, matching or combining datasets, vulnerable data subjects, innovative use of new technology and processing that can prevent people from exercising a right or using a service. The rule of thumb: if processing meets two criteria, a DPIA is generally required.
The Dutch Data Protection Authority (Autoriteit Persoonsgegevens, AP) also keeps a list of processing operations that always require a DPIA. It has seventeen categories, including employee monitoring and large-scale processing of health data. If your processing is on that list, there is nothing left to weigh.
Why does AI at work often meet several criteria?
Generative AI almost always meets one criterion: innovative use of new technology. In practice, others soon follow.
| What the assessment looks at | How it plays out with AI tools at work |
|---|---|
| Innovative use of new technology (criterion) | Generative AI, especially with memory or a connection to your own documents |
| Large-scale processing (criterion) | Dozens to hundreds of employees, every day, with different data each time |
| Sensitive data (criterion) | Sickness absence, health, finances and appraisals in prompts from HR, care and finance teams |
| Vulnerable data subjects (criterion) | Employees, whose data and behaviour end up in the tool |
| Transfers outside the EU (context) | Most well-known tools process data in the US, unless a business contract provides otherwise |
Transfers are not one of the nine criteria, but they are part of the context Article 35 asks you to weigh, and with AI tools they are rarely neutral. What the table shows is that the use decides the outcome, not the tool. A single employee rewriting job adverts meets at most the first criterion. An organisation where customer service, HR and finance all use the same tool meets four. Which data is at stake in each case is covered in our article on GDPR and AI tools at work.
What goes into a DPIA for AI use?
The GDPR sets out the contents in broad terms: a description of the processing and its purpose, an assessment of necessity and proportionality, the risks to individuals and the measures taken. For AI use, that means:
- Which tools. The approved ones, but also the tools people are already using, because the DPIA describes the processing as it actually happens, not as intended.
- Which data. By type of work: customer contact, personnel files, contracts and client records, and which of these involve special categories of data.
- Which legal basis. Often legitimate interest, with the balancing test that goes with it; for public bodies, the public task. The measures the GDPR expects for AI use belong here.
- Which measures. An approved alternative for each type of use, a data processing agreement (DPA) with the vendor, guidance for staff and highlighting of sensitive data before a prompt is sent.
- Who maintains it and when. A DPIA is a dated document. It needs a set moment when the description is checked against practice again.
How this relates to the AI Act, in two sentences: the FRIA in Article 27 assesses how deploying a high-risk system affects fundamental rights, and is mandatory from 2 December 2027 for public bodies and a limited group of private organisations. For everyday use of AI tools the DPIA remains the instrument, and Article 26 of the AI Act itself refers to it.
What does this look like in an organisation?
In the spring, a housing association writes a DPIA for Copilot covering the data, the legal basis, the settings and guidance for staff. It is a solid document. Six months later, an inventory shows that ChatGPT, Perplexity and a meeting transcription tool are in use alongside Copilot. The transcription tool processes tenants' voices and names, and does not appear in any document.
That is not an incident; it is the usual gap between a description and a working day. The DPIA described one tool, while in practice there were four. The association adds the tools to its overview, decides on each one and sets a fixed date in the DPIA for comparing the description with what is actually in use.
How do you show the measures are actually working?
A DPIA describes. It says that sensitive data is highlighted before it disappears into a prompt, and that employees see an approved alternative when they open a tool the organisation has decided on. Whether that actually happens is not in the document. It shows in the figures afterwards: how many highlights there were, what happened to them and what share of AI use went through approved tools. What those figures are worth to a regulator is covered in our article on what AI metrics are good for.