Privacy & Compliance
What Is a DPIA for AI Tools?
- GDPR Art. 35
- WP248 criteria
- Residual risk
Short answer
A DPIA, or data protection impact assessment, is the written risk assessment GDPR Article 35 requires before processing that is likely to result in a high risk to people's rights and freedoms. Using an AI tool with personal data often meets that bar, but the GDPR doesn't say every AI tool needs one. You decide case by case and document why. This is not legal advice.
Maskflare Engineering Updated
A bank's HR team wants to paste interview notes into an LLM to draft candidate feedback. Another team wants a support assistant that reads customer tickets, including complaints about health insurance. Before either goes live, someone has to answer a question the GDPR puts in writing: is this processing likely to result in a high risk to the people in the data, and if so, what have we done about it? The written answer is a DPIA.
What does Article 35 require?
Article 35(1) of the GDPR says that where a type of processing, in particular using new technologies and taking into account its nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of natural persons, the controller must assess the impact of the envisaged processing before it starts. One assessment can cover a set of similar operations that present similar high risks, so you don't need a new DPIA for every prompt or every team. If you have a data protection officer, you must seek their advice (Article 35(2)).
Article 35(7) sets the minimum contents. Keep the document current as the tool, the data or the provider changes.
| Article 35(7) element | What to write for an AI tool |
|---|---|
| Description of the processing and its purposes | Which tool and model, who uses it, which data categories reach it, where it runs, whether the provider keeps or trains on inputs |
| Necessity and proportionality | Why the task needs personal data at all, and whether masked or synthetic data would do |
| Risks to people | Disclosure to the provider, re-identification, wrong output about a person, transfers outside the EEA, staff pasting more than intended |
| Measures to address the risks | Processor terms, masking before the prompt leaves, access controls, retention settings, training, monitoring |
When does an AI tool trigger a DPIA?
Article 35(3) names three cases where a DPIA is required: a systematic and extensive evaluation of people based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based; large-scale processing of special categories of data or of criminal convictions data; and systematic monitoring of a publicly accessible area on a large scale. The list opens with the words "in particular", so it isn't exhaustive. Supervisory authorities also publish their own lists under Article 35(4). Check the one for your country.
The Article 29 Working Party's guidelines on DPIAs (WP248 rev.01, last revised and adopted on 4 October 2017) set out nine criteria that point to high risk. Several fit AI use: evaluation or scoring, sensitive or highly personal data, data processed on a large scale, data about vulnerable people (which includes employees), and innovative use of new technological solutions. The guidelines say that in most cases processing meeting two criteria requires a DPIA, while in some cases a controller can conclude that one criterion is enough.
The EDPB's Opinion 28/2024, adopted on 17 December 2024, is about AI models, not about every use of an AI tool. It does say that DPIAs are an important element of accountability where processing in the context of AI models is likely to result in a high risk. It doesn't say that every AI use needs one.
What does a DPIA for an AI tool look like in practice?
A support team in Lyon uses an LLM to draft replies. Tickets contain names, email addresses, IBANs and sometimes health details. The description records API access under a processor agreement and an EU region. The necessity section notes that a draft needs the content of the complaint, not the IBAN or the email address. The risks are identifiers reaching the provider, a health detail in free text slipping through, and an invented fact about a customer in a draft. The measures are masking identifiers before the call, blocking health-category content, human review of every draft and a monthly sample check. The residual risk is free-text details that identify someone without a detectable value, such as "the only cardiologist in the village".
Where does masking fit in a DPIA?
Masking is a measure for the Article 35(7)(d) section, and it is a form of pseudonymisation, which the GDPR names as a safeguard. It lowers the risk. It doesn't take the processing outside the GDPR: tokens you can reverse remain personal data for you, and whether they are personal data for the provider depends on the facts, as explained in are pseudonymised prompts still personal data. Write the DPIA to show the residual risk after masking, not to claim the risk is gone.
Maskflare doesn't perform DPIAs or legal assessments. It can supply evidence for one. The GDPR profile and coverage report show which personal-data categories your live policy covers and export as CSV or PDF. The Detection Engine keeps the originals behind tokens encrypted for 30 days so answers can be restored, and prompts and responses aren't logged or stored. Use these as inputs and verify them on your own documents.
When do you have to consult the authority?
Article 36(1) says the controller must consult the supervisory authority before processing where a DPIA under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate it. Ask your data protection officer how that applies once your measures are in place.
A short checklist
- List the AI tools and APIs in use, including the ones staff use without asking (see shadow AI).
- Screen each use case against Article 35(3), your authority's list and the WP248 criteria. Record the answer even when it is no.
- List the measures, and test each one on your own documents before you rely on it.
- Record the residual risk and who accepted it, then review the DPIA when the provider, the model or the data changes.
Frequently asked questions
Is a DPIA mandatory for ChatGPT or other LLM use?
Not automatically. Article 35 requires one when processing is likely to result in a high risk. Large volumes of customer data, health details or decisions about people usually reach that bar, while occasional drafting without personal data may not. Document your reasoning either way.
Who writes the DPIA, you or the AI vendor?
The controller, which is usually you. The vendor can supply security documentation and terms that you use as inputs, but the assessment of your processing and its risks is your responsibility.
Does masking personal data remove the need for a DPIA?
Not by itself. Masking reduces risk and belongs in the measures section, but reversible tokens are still personal data for you, and the assessment still has to cover purposes, necessity and residual risk.
When should the DPIA be done?
Before the processing starts, according to Article 35(1), and again when something material changes, such as a new provider, a new model or a new kind of data in the prompts.
Can one DPIA cover several AI tools?
Article 35(1) says a single assessment may address a set of similar processing operations that present similar high risks. Tools with different data, purposes or providers usually need their own sections.