DPIA for AI Systems: A Practical Guide

When does an AI system need a DPIA

Article 35(1) GDPR requires a DPIA whenever processing – particularly where new technologies are involved – is likely to result in a high risk to the rights and freedoms of individuals, taking into account its nature, scope, context and purposes.

Article 35(3) lists, among other scenarios, three in particular: a systematic and extensive evaluation of personal aspects based on automated processing – including profiling – on which decisions producing legal or similarly significant effects are based; large-scale processing of special categories of data or criminal-offence data; and systematic large-scale monitoring of a publicly accessible area.

AI systems tend to accumulate several risk criteria at once: profiling, prediction, combining data sources, vulnerable individuals, sensitive data, monitoring, innovative use, large scale, or decisions affecting employment, credit, education, health or access to services. You don't need to wait for the system to be classified as "high-risk" under the AI Act: if the data processing can generate high risk under the GDPR, the DPIA is mandatory.

Conversely, not every system falling under the AI Act's high-risk categories automatically requires a DPIA. If it doesn't process personal data, the GDPR may not even apply. If it does, the controller must still carry out its own analysis under Article 35 and against the lists and criteria published by the supervisory authority.

A decision not to carry out a DPIA must also be documented. It should explain the processing analysed, the criteria considered, the safeguards already in place, the date, and who approved the conclusion.

DPIA, conformity assessment and fundamental rights impact assessment

These are related instruments, but they are not interchangeable:

Article 27 of the AI Act provides that, where the obligations of the fundamental rights impact assessment are already covered by a DPIA, the FRIA should complement it. The efficient approach is a coordinated file built on a shared inventory of system, data, people, decisions, risks and measures, keeping clear traceability of which requirement each document satisfies.

Step 1. Define the actual processing

The unit of analysis is not just the model. The entire processing operation must be described:

• the business purpose and the decisions it supports or makes;
• the people affected, including those who are not users;
• input, inferred, generated and logged data;
• sources, lawfulness, quality and retention periods;
• training, validation, inference, monitoring and retraining;
• recipients, processors, sub-processors and transfers;
• integration with other systems and downstream action taken;
• human intervention and channels for complaint.

The same model can be embedded in very different processing operations. A classifier used to prioritise administrative documents does not carry the same risks as the same component applied to job applications.

It helps to map a flow from collection through to deletion. Each step should show the data, purpose, system, actor, location, access, output and supporting evidence. Grey areas – provider telemetry, prompt retention or use for model improvement – are findings to be resolved, not boxes you can leave blank.

Step 2. Confirm purpose, legal basis and transparency

The purpose must be specific and understandable. "Improving the service with AI" doesn't let you assess necessity or properly inform people. A better formulation is: "prioritising incoming requests to reduce assignment time, without deciding whether they are accepted."

Every operation needs a legal basis under Article 6 GDPR. Where special categories of data are involved, an exception under Article 9(2) is also required. Legitimate interest requires identifying the interest, proving necessity and balancing it against people's rights; contractual necessity covers only what is objectively required; and consent must be freely given, specific, informed and unambiguous.

The DPIA must check the information required under Articles 13 and 14 and, where relevant, the requirements on automated decision-making. The explanation doesn't need to reveal trade secrets, but it must let people understand which data influences the outcome, what the output is used for, what consequences it can have, and how to challenge it.

Step 3. Assess necessity and proportionality

Before calculating risk, you have to show that the processing is justified. For every data point, inference and function, ask:

1. Does it demonstrably contribute to the purpose?
2. Is there a less intrusive alternative?
3. Does the improvement it delivers outweigh the impact on people?
4. Can accuracy, frequency, population or retention be reduced?
5. Can the decision be kept in the hands of a person?

A technically accurate system can still be disproportionate. Continuously capturing location data to verify a one-off action, for example, can go beyond what's necessary even if the data itself is precise.

Minimisation also applies to derived variables, logs, embeddings and explanations. Proxies that reconstruct sensitive categories must be avoided. Retention is set per purpose and per component – you don't apply the longest period to the whole system.

Step 4. Identify impacts on people

A DPIA protects rights and freedoms, not just databases. The inventory should cover:

• unjustified exclusion from an opportunity or service;
• direct, indirect or proxy-variable discrimination;
• loss of control, surveillance or a chilling effect;
• disclosure of sensitive data or intimate inferences;
• mistaken identity and difficulty correcting it;
• manipulation, loss of autonomy or degrading treatment;
• powerlessness from a lack of explanation or an effective channel;
• fraud, impersonation, financial or reputational harm;
• cumulative impact of errors on vulnerable groups.

Each scenario should be written with a cause, an event, an affected person and a consequence. "Data leak" is too generic; "a provider reuses patient conversations to improve a service, and unauthorised staff infer clinical information from them" allows you to design concrete controls.

Step 5. Assess the initial risk

The assessment combines likelihood and severity from the perspective of the individual. Severity takes into account intensity, duration, reversibility, the number of areas of life affected and vulnerability. Likelihood looks at exposure, attacker motivation, frequency, complexity and controls already in place.

Don't reduce everything to an average. An unlikely event with irreversible harm may mean the operation should be avoided altogether. It's worth recording the uncertainty and quality of the evidence behind each score: historical data, internal testing, published literature, audits, or mere estimation.

A minimum matrix should contain:

Step 6. Design measures tied to each risk

A generic list of "encryption and training" is not enough. Every measure should state which scenario it reduces, who owns it, the deadline, supporting evidence, the expected effectiveness and the resulting residual risk.

Data-related measures

• exclude unnecessary variables and unjustified proxies;
• separate identifiers and apply pseudonymisation;
• control provenance, accuracy and representativeness;
• set differentiated retention and verifiable deletion;
• prevent secondary use by providers without a legal basis and authorisation.

Model-related measures

• evaluate performance by relevant groups and error types;
• document limitations, the intended population and prohibited uses;
• calibrate thresholds according to the cost of each error;
• test for drift and degradation;
• avoid inferences that are not necessary for the purpose.

Decision-related measures

• reserve significant decisions for competent staff;
• display sources, uncertainty and relevant factors;
• prevent automatic acceptance by default;
• enable correction, submissions and challenge;
• log when a person overrode the outcome, and why.

Security and vendor measures

• least-privilege access, authentication, encryption and audit trails;
• testing for injection, extraction and cross-tenant isolation;
• Article 28 contracts and control over sub-processors;
• processing regions, transfers and supplementary measures;
• an incident response plan and the ability to recover evidence.

Step 7. Consultation, DPO and approval

The DPO must provide advice where one has been appointed, but responsibility for the DPIA rests with the data controller. The business, privacy, security, technical, procurement and process-owner teams should all be involved, and, where appropriate, affected individuals or their representatives.

Consultation doesn't mean handing the decision to the vendor. The deployer knows the purpose and the context and must interrogate the vendor's documentation, metrics and limitations.

The approval decision must identify the risks accepted, their owner and the reasoning behind it. If, after the measures are applied, a high risk remains that cannot reasonably be mitigated, Article 36 requires prior consultation with the supervisory authority before processing begins.

Step 8. Review throughout the lifecycle

A DPIA doesn't end at launch. Article 35(11) requires it to be reviewed when the risk changes. For AI, the following should trigger a review:

• a new model, version or provider;
• a change of purpose or target population;
• new data sources or categories;
• increased autonomy or integration;
• drift, incidents or complaints;
• regulatory or contextual changes;
• persistent unequal outcomes.

Operational metrics should be tied back to the identified risks: false positives by group, overrides, complaints, unauthorised access, time to correction and automated decisions blocked.

A 30-day work plan

Week 1: scope

• appoint an owner and a team;
• describe the purpose and the decision;
• map the data, actors and flows;
• decide and document whether a DPIA is required.

Week 2: necessity and risk

• confirm legal bases and transparency;
• assess less intrusive alternatives;
• draft impact scenarios;
• assess initial risk and supporting evidence.

Week 3: measures and testing

• assign controls to risks;
• run functional, bias, privacy and security testing;
• review the provider, contracts and transfers;
• calculate the residual risk.

Week 4: decision

• obtain the DPO's advice;
• coordinate the DPIA, FRIA and conformity assessment where relevant;
• approve, restrict or halt the deployment;
• set monitoring and a review date.

Checklist for a defensible DPIA

• The processing – not just the model – described end to end.
• Mandatory-assessment criteria and the decision documented.
• Purpose, legal bases and Article 9 exceptions identified.
• Necessity and less intrusive alternatives assessed.
• Scenarios focused on consequences for people.
• Likelihood, severity, uncertainty and evidence recorded.
• Measures traced to each risk, with an owner and evidence.
• Effective human intervention and channels to challenge decisions.
• Providers, transfers and the full lifecycle included.
• Residual risk approved, or prior consultation raised.
• Monitoring and review triggers defined.

Frequently asked questions

Does every AI system need a DPIA?

No. It's required when the processing is likely to result in high risk. The decision itself must be analysed and documented.

Does being high-risk under the AI Act automatically trigger one?

Not automatically – they are different concepts covering different scopes. But many high-risk uses process personal data intensively and will likely meet the Article 35 criteria anyway.

Can the provider carry it out?

The provider can contribute documentation and analysis, but the controller must assess its own purpose, context and risks. This responsibility cannot be delegated.

Does human review rule out Article 22 GDPR?

Only if it's genuine: the person must have the competence, information, time and authority to change the decision. Routine rubber-stamping is not enough.

What's the difference between a DPIA and a FRIA?

A DPIA focuses on the risks of processing personal data; a FRIA covers broader impacts on fundamental rights for certain high-risk AI deployments. The two should complement each other.

When do you need to consult the AEPD (Spanish DPA)?

When the DPIA shows a residual high risk that the controller cannot mitigate before processing begins, under Article 36.

At Summum Consultoría we can support the analysis, coordinate privacy, business and technology stakeholders, and review the complete DPIA file, including its coordination with AI Act compliance. A DPIA alone doesn't guarantee compliance: it turns decisions and safeguards into a verifiable process.