You need a DPIA for AI when an AI feature or tool is likely to result in a high risk to the people whose data it processes. The EU guidelines treat meeting two of their nine criteria as the usual signal, and an AI feature often meets one from the start, because innovative use of new technology is itself a criterion. To run the assessment, map the data flow, test whether each data use is necessary, rate the risks from the data subject's side and record the controls, all before launch.
A Data Protection Impact Assessment (DPIA) is the record GDPR Article 35 requires for high-risk processing of personal data. This is general information, not legal advice. Your data protection officer (DPO) or counsel should confirm the final position.
When is a DPIA for AI required?
Article 35 requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons" and names new technologies as a particular concern. The DPIA guidelines (WP248) endorsed by the European Data Protection Board turn that into nine criteria:
- Evaluation or scoring, including profiling and prediction.
- Automated decisions with legal or similarly significant effects.
- Systematic monitoring.
- Sensitive or highly personal data, which can include emails, documents and notes.
- Large-scale processing.
- Matching or combining datasets in ways people wouldn't expect.
- Data about vulnerable people, which explicitly includes employees and children.
- Innovative use of new technology.
- Processing that stops people from exercising a right, using a service or entering a contract.
Processing that meets two criteria will need a DPIA in most cases, according to the guidelines, and one can be enough. If your AI use counts under criterion 8, adding one more, such as summarizing support tickets at scale or reading employee mailboxes, puts you at two.
If you decide a DPIA isn't needed, record why and the DPO's view. Also check the list of processing that requires one, published by the supervisory authority in each country where you operate.
Which AI use cases usually need a DPIA
These are illustrations; the answer depends on your data and context.
| Use case | Criteria likely met | DPIA likely? |
|---|---|---|
| Staff draft text in an approved assistant, no customer or colleague data | Innovative technology | Usually not; document the decision |
| Support chatbot that handles account questions | Innovative technology, large scale | Often |
| LLM summarizing support tickets or sales calls | Innovative technology, large scale, highly personal content | Yes |
| AI screening or ranking job applicants | Scoring, significant effects, access to a contract | Yes |
| Meeting notetaker recording internal calls | Monitoring, employees, highly personal content | Yes |
| Retrieval assistant over HR or medical documents | Sensitive data, employees or patients, innovative technology | Yes |
Work from your AI inventory so nothing is skipped. Our guide on finding the AI tools your team already uses covers how to build one.
Who does the DPIA: you or the vendor?
The controller, the company that decides why and how data is processed, is responsible. If you build on a model API or deploy a vendor's AI tool, that's usually you. Seek the DPO's advice where one is designated; a processor must help with the information it holds (Article 28(3)(f)). A vendor's own DPIA can inform yours, but WP248 is clear that the deploying company still assesses its own implementation.
For high-risk AI systems under the EU AI Act, Article 26(9) tells deployers to use the information the provider supplies under Article 13 for their DPIA. Ask for that documentation during procurement.
How to run a DPIA for an AI feature
Article 35(7) sets the minimum content: a description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to the people concerned, and the measures to address them. For an AI feature, work in this order:
- Map the data flow. Trace personal data from where it enters to every place it rests: user input, system prompts, retrieved documents, tool calls, model output, logs, evaluation datasets and the vendor's side. Note each subprocessor and region.
- State the purpose and lawful basis. One purpose per processing activity. "Improve the product" is too broad to assess.
- Test necessity field by field. A ticket summary rarely needs the customer's name when an account ID does the same job.
- Rate the risks to people. Score likelihood and severity from the data subject's perspective, not the company's.
- Choose measures and re-score. Link each measure to the risk it reduces, then rate what's left.
- Sign off and set review triggers. Record the DPO's advice, the decision and a named owner. If high residual risk remains, Article 36 requires you to consult the supervisory authority before processing starts.
AI-specific risks and the controls that address them
Generic DPIA templates miss the places AI features keep and expose data. Cover these explicitly:
| Risk | What to check | Typical measures |
|---|---|---|
| Vendor training on inputs | Contract and API terms on training | Terms that exclude training, in writing |
| Retention in prompts and logs | Retention at the vendor and in your logs, traces and eval sets | Short retention, redaction before logging |
| Inaccurate output about a person | Whether outputs are stored or used in decisions | Human review, source citations, a correction route |
| Automated decisions | Whether a person meaningfully reviews the result | A reviewer with authority to overrule, an appeal route |
| Exposure across permissions | Whether retrieval respects each user's access rights | Permission filtering at retrieval time |
| Prompt injection leaking data | Whether untrusted content can make the model reveal or send data | Least-privilege tools, approval for outbound actions |
| Data subject rights | Whether you can find and delete one person's data in logs and vector indexes | Records keyed by subject ID, a tested erasure process |
| International transfers | Where the provider and subprocessors process data | Regional endpoints, a transfer mechanism in the processing agreement |
Prompt injection belongs in a DPIA because text inside a document or email can instruct the model to disclose whatever it can read. Our explainer on prompt injection for product teams covers how to limit it.
How a DPIA relates to the EU AI Act FRIA
The EU AI Act adds a fundamental rights impact assessment (FRIA) under Article 27. It applies to public bodies, private entities providing public services, and deployers of high-risk systems for credit scoring or for life and health insurance pricing. Where the DPIA already covers an element, the deployer can cross-reference it.
The DPIA comes first, and a FRIA, if needed, builds on it. Our EU AI Act guide for SMBs explains how to tell whether a system is high-risk. The Act has been amended since adoption, so check the current consolidated text before relying on specific obligations.
Common DPIA mistakes with AI features
- Assessing the model instead of the use. The same model can be low risk in a drafting tool and high risk in hiring.
- Writing the DPIA after launch, when it can only document choices already made.
- Copying the vendor's assessment, which can't cover your data or your decisions.
- Minimizing the prompt but keeping full transcripts in a tracing tool with no retention limit.
- Listing "human in the loop" as a control without checking that reviewers have the time and authority to disagree.
Keeping the DPIA current
Article 35(11) requires a review at least when the risk changes. For AI features, define the triggers in advance: a new model or provider, a new retrieval source or tool, a new purpose or user group, changed vendor terms on retention or training, and any incident involving the feature. Tie them to your change process so a matching pull request or vendor change gets a DPIA review before release.
If you want help mapping where personal data flows through your AI tools, our AI Readiness & Governance Assessment covers data protection and GDPR touchpoints, the security of AI tools and vendors, and a risk register. Your legal counsel confirms final legal positions.
Frequently asked questions
Do we need a DPIA to use an AI assistant at work?
Not automatically. If staff use an approved business account without personal data about customers or colleagues, the processing may not be high risk, but record that decision. Once the assistant handles customer records, employee data or anything sensitive, assess it against the nine criteria.
Is a DPIA the same as a privacy impact assessment?
WP248 notes that "privacy impact assessment" (PIA) is often used elsewhere for the same concept. Under GDPR, the minimum content is fixed by Article 35(7), so a PIA built on another framework may need extra sections.
Do we have to publish our DPIA?
No. Publication isn't a GDPR requirement, though WP248 suggests publishing a summary to build trust. You must give the full DPIA to the supervisory authority if you consult it under Article 36 or if it asks.