What is a DPIA and when do you need one for AI?
You need a DPIA for an AI system when its processing of personal data is likely to result in a high risk to individuals. AI itself is not the legal trigger; the combination of personal data, purpose, scale, technology and possible consequences is what determines the risk.
A DPIA — Data Protection Impact Assessment — is a structured assessment of the privacy risks associated with a processing activity. Under the GDPR, it is mandatory when a planned processing operation is likely to result in a high risk to the rights and freedoms of individuals. With AI, that threshold can be reached relatively quickly because AI systems often combine large amounts of data, profile people, process sensitive information or rely on new technologies.
That does not mean every AI project automatically requires a DPIA. An internal text-generation tool that only works with non-personal business information may fall outside the DPIA requirement. But as soon as personal data appears in prompts, training data, logs, embeddings, decision models or automatically generated assessments, you need to seriously consider whether Article 35 GDPR requires a DPIA.
A DPIA is more than a privacy checklist
A DPIA is not a form you complete after the project is finished. Its purpose is to assess, before deployment, what personal data you plan to process, why that processing is necessary, what risks it creates and what measures can reduce those risks.
Article 35 GDPR requires a DPIA to include at least a systematic description of the processing operations and their purposes, together with an assessment of necessity and proportionality. It must also evaluate the risks to data subjects and document the technical and organisational measures used to manage those risks.
This makes a DPIA relevant to both the technical architecture and the business process. The question is not only whether the data is encrypted, but also whether the AI system genuinely needs particular personal data, how long prompts and outputs are retained and what the consequences of an incorrect model output could be for an individual.
Why AI can lead to high-risk processing more quickly
The GDPR explicitly mentions the use of new technologies as a factor when determining whether processing is likely to create a high risk. AI is therefore not automatically "high risk", but many AI applications combine several risk factors at once.
Consider a recruitment model that ranks applicants, software that analyses employees, a fraud-detection system that assigns customers a risk score or a healthcare application that summarises patient records. In these cases, an error can influence a decision or assessment with real consequences for an individual.
Generative AI can also process personal data in ways that are less obvious. An employee may paste customer information into a prompt, a RAG system may retrieve passages from personnel files, and an embedding database may contain mathematical representations of text that can still relate to identifiable individuals. Saying "we only store vectors" therefore does not automatically mean the GDPR no longer applies.
When is a DPIA mandatory?
Article 35 GDPR identifies three situations in particular in which a DPIA is required: systematic and extensive evaluation of personal aspects based on automated processing where decisions produce legal or similarly significant effects; large-scale processing of special-category personal data or criminal-conviction data; and systematic monitoring of publicly accessible areas on a large scale.
In addition, the Dutch Data Protection Authority publishes a list of processing operations for which a DPIA is mandatory. The underlying European guidance looks at factors including evaluation or scoring of individuals, automated decision-making, systematic monitoring, sensitive data, large-scale processing, combining datasets, data relating to vulnerable people, innovative use of new technologies and processing that may prevent a person from exercising a right, using a service or entering into a contract.
The relevant question is therefore not simply: "Are we using AI?" A better question is: "What is this AI system doing with personal data, and what effect could that have on people?" European guidance uses the presence of multiple risk criteria as a practical indication that a DPIA is more likely to be required, although in some circumstances a single criterion may already be sufficient.
Examples of AI projects where you should consider a DPIA
For some applications, the need for a DPIA is relatively obvious. An AI system that automatically assesses job applicants may combine profiling, evaluation of individuals and automated decision-making. A system analysing medical records processes special-category personal data. Software that continuously monitors employee productivity, behaviour or communication may amount to systematic monitoring.
Less obvious applications deserve attention as well. Suppose a customer-service assistant is given access to CRM data and uses complete customer records when generating responses. Or an organisation builds a RAG system over thousands of emails, HR documents and contracts. The AI interface does not change the nature of the underlying personal data: the organisation is still processing that information and may introduce new risks by making it easier to retrieve, combine and expose.
By contrast, a basic AI summarisation tool that runs locally on public, non-personal documents will generally not trigger a DPIA obligation under the GDPR. Limited processing of ordinary personal data also does not automatically require a DPIA where the expected risk remains low.
What should you investigate technically in an AI DPIA?
A useful DPIA should reflect the actual data flow. Document where information enters the system, which AI components process it and where the data subsequently goes. That may include the application itself, an external API provider, a vector database, logging systems, analytics tools, backups and any human reviewers.
For AI systems, relevant questions include: what personal data appears in prompts, documents, embeddings and generated outputs; are special-category or criminal-conviction data being processed; is data sent to an external AI provider, and if so, where is it processed and how long is it retained; are prompts or outputs used for model training or evaluation; can the system create profiles, scores, predictions or decisions about individuals; which employees or systems can access the source data and generated responses; could incorrect outputs, bias or faulty retrieval negatively affect someone; and can the amount of data be reduced, pseudonymised or processed locally instead?
The next step is to define safeguards. These may range from data minimisation and access controls to encryption, shorter retention periods, human review, logging, source attribution in a RAG system and disabling provider-side training on submitted data. When algorithmic systems are involved, the risks to individuals must form part of the DPIA and should be mitigated where possible.
A DPIA should be completed before production
Timing matters. The DPIA is supposed to take place before the high-risk processing begins. Privacy considerations therefore need to be part of the design process rather than something added after the technical architecture has already been finalised.
A DPIA is also not a one-off document. Article 35 requires organisations, where necessary, to review whether processing is still being carried out in accordance with the DPIA, especially when the level of risk changes. With AI systems, that can happen easily: a new model, an additional dataset, a different provider, longer log retention or a move from advisory output to automated decision-making can materially change the risk profile.
If your organisation has a Data Protection Officer, their advice must be sought when carrying out the DPIA. If a high residual risk remains even after the planned safeguards have been implemented, Article 36 GDPR may require prior consultation with the supervisory authority before processing begins.
How does a DPIA relate to a FRIA under the AI Act?
Certain high-risk AI systems may require a fundamental rights impact assessment (FRIA) in addition to a DPIA. This obligation is set out in Article 27 of the EU AI Act. It does not apply to every deployer of a high-risk AI system, but includes bodies governed by public law and private entities providing public services when they deploy certain high-risk systems under Article 6(2). Deployers of systems for creditworthiness assessment and credit scoring, and for risk assessment and pricing in life and health insurance, are also covered.
A DPIA and a FRIA are not the same assessment. A DPIA derives from the GDPR and focuses on high privacy risks from personal-data processing; a FRIA looks more broadly at potential impacts on fundamental rights caused by using an AI system. Therefore, only a DPIA, only a FRIA, or both may be required. Article 27(4) expressly states that where relevant elements have already been assessed through a DPIA, the FRIA should complement that assessment rather than duplicate the same work.
A DPIA does not make unlawful AI processing lawful
Completing a DPIA does not give an organisation permission to process personal data. You still need a valid legal basis under the GDPR and must comply with requirements such as purpose limitation and data minimisation. Separate rules may also apply to special-category data and automated decision-making.
The real value of a DPIA is that it forces these choices to become explicit. In some cases, stronger security controls may be sufficient. In others, you may need to reduce the amount of personal data, add human oversight or redesign the architecture. And sometimes the conclusion may be that a particular processing activity cannot responsibly be carried out in its proposed form.
Conclusion
You need a DPIA for an AI system when its processing of personal data is likely to result in a high risk to individuals. AI itself is not the legal trigger; the combination of personal data, purpose, scale, technology and possible consequences is what determines the risk.
A DPIA should therefore be treated as part of the design of an AI system, not as a compliance document added afterwards. Profiling, automated decisions, sensitive data, monitoring, large datasets and combined data sources are all strong reasons to raise the DPIA question early. Neuralex does not provide legal advice; if there is uncertainty about whether a DPIA is required, which GDPR legal basis applies, or whether a FRIA obligation applies as well, have the specific use case reviewed by a qualified legal professional.