DPIA and fundamental rights impact assessment in AI: how to decide which assessment you need before using sensitive data

The starting question is not whether AI is involved, but what happens to each person

An assistant that summarises case files, a model that ranks applications, or a tool that estimates risk may use similar techniques and yet create very different obligations and potential harms. The assessment must start with the actual processing and effect: what information goes in, what output the system produces, who receives it, what action it triggers, and what consequences it may have for a specific person.

This distinction matters especially where health, biometric, employment, financial, insurance, children’s, or dependent persons’ data are involved. It also matters where the system infers information that nobody explicitly provided, such as a priority, propensity, risk category, or supposed eligibility. The fact that an inference does not appear on a form does not remove its relevance for data protection or fundamental rights.

The purpose of an assessment is not to declare that a model is ethical, safe, or compliant in the abstract. It is to document whether a defined use is necessary and proportionate, what plausible harms it may cause, what evidence will make those harms detectable, what controls will reduce them, and which accountable person has real authority to stop the use. A template completed by a provider may contribute technical information, but it cannot by itself resolve matters that depend on the purpose, affected population, operating rules, and legal framework of the organisation deploying the system.

Four layers of risk that should be kept separate

The data protection impact assessment, commonly known as a DPIA, focuses on risks to people’s rights and freedoms arising from the processing of personal data. The General Data Protection Regulation requires it before processing where the processing is likely to result in a high risk. It is not an expanded privacy notice: it must describe the processing, assess necessity and proportionality, analyse risks, and establish measures to address them.

The fundamental rights impact assessment provided for by the Artificial Intelligence Act starts from a different point. For certain deployers of high-risk AI systems, it must be carried out before the first use. It analyses how the intended use may affect affected persons or groups and is linked to the deployment context. It may cover risks of discrimination, unequal access to services, dignity, protection of children, freedom of expression, effective remedy, or other safeguards, in addition to risks related to personal data.

Technical security and operational risk are additional layers. The first covers, among other matters, robustness, failures, cybersecurity, performance degradation, and traceability. The second examines how people use the output: pressure to meet targets, excessive automation, lack of time to review, absence of correction routes, or incentives that turn a recommendation into a de facto automated decision. A robust dossier connects all four layers, but does not confuse them or assume that passing a technical test eliminates legal or social risks.

Decision tree before deployment

There is no reliable rule that turns every use of AI into a DPIA, nor one that allows a DPIA to be ruled out because human review exists. The decision requires gathering the facts of the case and comparing them with the GDPR, the lists of processing operations subject to DPIAs published by the competent supervisory authority, and, where relevant, the Artificial Intelligence Act.

First, determine whether personal data are involved. They may appear in input data, usage logs, outputs, or inferences. Then identify whether factors that commonly raise risk are present: special categories of data, profiling, systematic evaluation, decisions producing legal effects or similarly significant effects, systematic monitoring, large-scale processing, vulnerable persons, combination of datasets, novel technologies, or an asymmetric power relationship. These factors do not operate as a mechanical checklist; they help justify a conclusion and prevent foreseeable risks from being overlooked.

Next, analyse whether the system and its intended use fall within a high-risk category under the Artificial Intelligence Act. Classification depends on the effective use and relevant legal categories, not on the product name or a commercial statement. If it does, verify whether the deployer falls within the cases required to conduct a fundamental rights impact assessment before the first use. Where the workflow also processes personal data with likely high risk, both assessments may be necessary.

If, after the intended measures are applied, the processing still entails a high risk that the controller cannot mitigate, the GDPR requires prior consultation with the supervisory authority before processing begins. The conclusion must not be presented as a risk merely accepted internally where the law requires that consultation.

What a DPIA must contain and why it is not the same as a privacy notice

A DPIA must include a systematic description of the processing operations and their purposes, including the legitimate interest pursued where relevant. It must also contain an assessment of necessity and proportionality, an assessment of risks to people’s rights and freedoms, and the measures envisaged to address them. It is therefore not enough to list data categories, include generic security clauses, or state that there is a business interest in automation.

In an AI workflow, the systematic description should cover collection, preparation, training where applicable, inference, validation, human intervention, communication of the output, logs, and deletion. It must identify both direct data and inferences. For example, a fraud score, clinical priority, or attrition prediction may be personal data where it relates to an identified or identifiable person and is used to evaluate them.

A privacy notice informs people about processing and may be necessary to meet transparency obligations. However, it does not replace the prior internal assessment of risks, necessity, proportionality, and measures. Nor does a generic assessment produced by the provider replace the controller’s analysis, because the provider will normally not know precisely the population served, local data, thresholds, action taken by staff, or available complaint mechanisms.

Lists of processing operations requiring a DPIA, and lists of exceptions, may vary depending on the competent supervisory authority. An organisation operating in several Member States must document which authority and which list it considered. Where reasonable doubt exists, a proportionate and early assessment may reveal that the design needs to change before the cost of reversing it becomes high.

Fundamental rights impact assessment: scope and coordination with the DPIA

The Artificial Intelligence Act provides for a fundamental rights impact assessment for certain deployers before the first use of high-risk AI systems. The duty is not triggered by every piece of software that uses AI. It requires verification both that the system falls within the applicable high-risk categories and that the deployer falls within the cases set out by the law. Contexts requiring particular attention include certain uses by public bodies or entities providing public services, and certain high-risk uses related to areas such as credit, insurance, or emergency services, depending on the applicable classification and legal scope.

The assessment must be contextual. The same system may present different risks if used to support an internal work queue, to filter access to an essential service, or to prioritise actions affecting a person. It should describe groups that may be affected, possible consequences, human oversight measures, and relevant information and complaint mechanisms. It should also take into account whether practical barriers exist to challenging or correcting an outcome.

Where the system processes personal data and the DPIA is mandatory, the two assessments should be coordinated rather than blindly duplicated. A shared inventory of data, purpose, participants, versions, and controls reduces inconsistencies. Even so, a distinct response must be retained for each obligation: the DPIA must demonstrate the analysis required by the GDPR, while the fundamental rights assessment must address the elements of the Artificial Intelligence Act that apply to the deployment.

The application timetable for the Artificial Intelligence Act includes transitional rules and has been amended. Before concluding that an obligation is already enforceable in a particular case, document the intended use date, the legal version consulted, the system category, and the applicable transitional provision. This guide does not replace that case-specific legal check.

Minimum inventory and testing that must accompany the dossier

Before measuring accuracy or bias, build an inventory that makes the analysis reproducible. It must establish the approved purpose and excluded purposes; the basis and limits of the processing; data sources; provided, observed, and inferred attributes; affected persons; recipients; retention periods; provider; model and version; thresholds; and the actions that the output allows or triggers. If an organisation cannot describe these elements, it will be difficult for it to demonstrate necessity, proportionality, or traceability.

Testing must respond to plausible harms, not only to an aggregate metric. If a score determines the order of service, false negatives that delay urgent cases and false positives that unfairly displace other cases matter. If performance may differ across groups, the assessment must explain which groups were analysed, why they are relevant, what limitations affect the test data, and what will be done if sufficient evidence does not exist. In some cases, collecting attributes to measure disparities itself creates data protection risks; this calls for specific justification and safeguards, not an automatic omission of the analysis.

Abstention and degradation must also be tested. A system may be safer if it abstains when information is incomplete or its confidence does not exceed a threshold, but that abstention must send the case to a real human route within defined time limits. Simulate incidents: incorrect data, population changes, a provider outage, inconsistent outputs, access or rectification requests, and operational pressure to skip reviews. Record what evidence would make the problem detectable and who would act.

Redesign controls, residual risk, and authority to stop the system

The outcome of an assessment should not be reduced to approving or rejecting a product. It often makes it possible to redesign the workflow to reduce exposure and harm. Options include minimising variables, not using particularly sensitive categories where they are not necessary, separating a recommendation from the final decision, limiting the system to an administrative task, reducing the initial scale, raising the abstention threshold, preventing certain secondary uses, and enabling competent review before adverse effects occur.

Human review is a control only if it has capacity, information, time, and authority. A person who confirms hundreds of scores per hour or does not know the model’s limitations may create an appearance of control without changing the risk. Define which outputs require review, what signals allow the recommendation to be overridden, what training the team receives, what time limit applies, and how disagreement is recorded. Overrides may reveal a data, threshold, or design problem that requires the assessment to be reopened.

Residual risk must be described concretely: what harm remains possible, who may be affected, with what estimated likelihood and severity, what controls remain active, and what uncertainties persist. Acceptance cannot be implicit. It must be assigned to a person or body with authority to assume it, and it must coexist with independent authority to stop or reverse the system when a safety, quality, discrimination, non-compliance, or incident threshold is triggered.

Reopen the assessment before material changes, not after harm has occurred. Common triggers include changes to the model, provider, data, population, purpose, threshold, integration, automated action, volume, applicable law, or evidence of unequal performance. Periodic reviews help, but do not replace these triggers based on specific changes.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.