How to do a DPIA for AI

GDPR Article 35(1) says that where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out an assessment before the processing. Article 35(3) names three cases where one is always required: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions with legal or similar effects are based; large-scale processing of special categories of data or criminal-conviction data; and systematic monitoring of a publicly accessible area on a large scale.

For everything else, use the criteria. The Article 29 Working Party guidelines (WP248) list nine: evaluation or scoring; automated decision-making with legal or similar significant effect; systematic monitoring; sensitive or highly personal data; large-scale processing; matching or combining datasets; vulnerable data subjects; innovative use of new technological or organisational solutions; and processing that prevents people exercising a right or using a service. The guidance says processing that meets at least two should be presumed to need a DPIA, although one can be enough.

Many AI uses meet two. An LLM that summarises customer complaints can combine innovative technology with large-scale processing. A recruitment screening model combines scoring with an effect on access to opportunities. Check your national data protection authority's published list too, because lists differ by country. If you decide a DPIA is not needed, write down why. That decision is itself a record.

Article 35(7)(a) calls for a systematic description of the envisaged processing operations and their purposes. The UK Information Commissioner's guidance, which follows the same structure, says the description should cover the nature, scope, context and purposes of the processing. Nature includes how data is collected, stored, used and shared, who has access, which processors are involved, retention periods, security measures and whether new technologies are used. Scope covers the type, volume, sensitivity and number of people. Purpose covers the intended outcome for individuals and the expected benefits.

For an AI system, make the description concrete. What goes into the prompt, and where does it come from? What does the model return, and what happens to that output? Which model and which vendor? Is data sent to a third party, and does the vendor keep or train on it? What is logged and for how long? Where are embeddings and indexes stored? A diagram that shows these flows, with a column for the lawful basis, saves pages of prose.

Include what the system must not do. If an agent has restricted actions, say what they are. That clarifies the risk and shows you have thought about the limits.

Article 35(7)(b) asks for an assessment of the necessity and proportionality of the processing in relation to its purposes. The ICO guidance puts it as questions: does the plan help to achieve the purpose, and is there another reasonable way to reach the same result? For AI, the second question is a useful one. Could a rules-based system, a smaller model or less data do the job?

Work through the lawful basis, data minimisation, how you will prevent function creep, how you will keep data accurate, what you will tell people, how you will support their rights, how processors are held to account, and safeguards for international transfers. Record the answers in plain sentences.

Pay attention to minimisation in prompts. Many assistants are given more personal data than the task needs, because it was easier. Strip, mask or avoid fields the model does not need, and say what you did.

The assessment is of risks to people, not risks to your company. The ICO guidance suggests considering physical, emotional or material harm, and lists examples such as inability to exercise rights, inability to access services or opportunities, loss of control over personal data, discrimination, financial loss, reputational damage, loss of confidentiality and re-identification of pseudonymised data. To decide whether a risk is high, look at likelihood and severity together.

AI adds particular risks. A model can produce inaccurate statements about a real person. It can reflect bias in its training data and treat groups differently. It can reveal personal data from its training or from retrieved documents to someone who should not see it. A prompt can leak data to a vendor. An agent can take an action on the wrong account. A scoring system can be opaque, so people cannot understand or challenge a decision. Logs and evaluation sets can create new copies of sensitive data.

Write each risk in a sentence a non-specialist could follow: who is harmed, how, and how likely it is. Rate it, and keep the unrated list short and honest.

Article 35(7)(d) requires the measures envisaged to address the risks, including safeguards, security measures and mechanisms to demonstrate compliance. Pair each risk with a specific control. For AI these often look like: limit the data sent to the model; use an EU-scoped or self-hosted deployment where residency matters (see how to deploy an LLM in the EU); filter retrieval by the requesting person's permissions; require human approval for actions with significant effect (see how to set up human approval for AI agents); keep logs for a stated period; and test for accuracy and bias before launch (see how to validate your AI).

Then rate the residual risk. If a high risk remains that you cannot reduce, GDPR Article 36 requires you to consult the supervisory authority before you start. That is not a failure. It is the route the law provides for hard cases.

Where appropriate, seek the views of data subjects or their representatives. Article 35(9) provides for this, and for workplace systems that may mean employee representatives.

This example uses Swfte's illustrative Trust Profile for "Customer Service Agent 017". It is not a real customer deployment. The profile reads: owner Customer Operations; risk level Medium; approved models Model A and Model B; data classification Confidential; data residency EU; permitted systems CRM, knowledge base and ticketing; allowed actions read, recommend and draft; restricted actions account modification and refund; human approval required for refunds above a threshold; retention defined by organisational policy; audit with a full action trace; policy set Corporate AI Policy and Customer Data Policy.

Screen: the agent reads customer records at scale and uses a new technology, so two WP248 criteria (large scale, innovative technology) are met. A DPIA is presumed. Describe: it reads CRM and ticket data, drafts replies and recommendations, and does not change accounts or issue refunds. Necessity: drafting saves staff time, and reading only the fields needed for the ticket limits exposure. Risks: a draft could state something wrong about a customer, expose another customer's data through retrieval, or send personal data to a vendor.

Measures: restricted actions mean it cannot change accounts or refund; approval is needed above a refund threshold; EU residency applies; the audit trail records every action; a person reviews drafts before they are sent; retrieval follows the ticket owner's permissions. Residual risk: low to medium, because a person reviews each draft. The assessment is then signed off, with a review date.

Article 35(2) says the controller must seek the advice of the data protection officer, where one is designated, when carrying out a DPIA. Record that advice, and what you did with it. If you disagree with the DPO, record why.

Have a named person with authority sign off the measures and accept the residual risk. Write the review trigger into the document. Article 35(11) says the controller should review at least when there is a change in the risk of the processing. For AI, treat any change of model, vendor, data source or allowed action as a trigger, and add a calendar review as well.

Link the DPIA to your wider records. It can feed your register of AI systems under the EU AI Act (see how to prepare for the EU AI Act). Where the AI Act requires a fundamental rights impact assessment under Article 27, the two assessments can share material. Our DPIA for AI page summarises the link.