There's a misconception that circulates with too much ease: the idea that if you've already done your Data Protection Impact Assessment (DPIA), you've also covered the Fundamental Rights Impact Assessment (FRIA). It's a tempting shortcut, and generally wrong. The two assessments are similar enough to be confused and different enough that confusing them gets costly. It's worth separating them with precision.
Two instruments, two laws, two subjects
The DPIA — Data Protection Impact Assessment — originates in Article 35 GDPR. Its subject is the processing of personal data. It is required when processing is likely to result in a high risk to the rights and freedoms of natural persons: new technologies, large-scale processing of special categories of data, systematic monitoring, and the cases on supervisory authorities' lists. In essence, it asks: does this data processing put people at risk, and how do I mitigate it?
The FRIA — Fundamental Rights Impact Assessment — originates in Article 27 of the AI Act. Its subject isn't data, but the high-risk AI system and its impact on the fundamental rights of the people affected by its use. It's required of certain deployers of high-risk systems under Annex III. It asks something different: does this AI system, by how it decides and about whom, affect fundamental rights — and what governance and human oversight measures do I put around it?
The subject is different. The trigger is different. The legal basis is different. Sharing a methodology — identifying risks, assessing them, mitigating them, documenting them — doesn't make them the same document.
Where they overlap (and why that's confusing)
The overlap is real. A single high-risk AI system that processes personal data can require both assessments at once. And a good part of the context, purpose and affected-persons analysis is shared. It's understandable that whoever has done one feels they've already done the other.
The Digital Omnibus recognises that overlap and seeks to reduce duplication: Article 27(4), in its current wording, lets the deployer include cross-references to the relevant sections of the DPIA, or relevant parts of it, in the FRIA. But this needs to be read carefully. That you can reuse DPIA analysis as an input to the FRIA is good practice for efficiency. That the DPIA replaces the FRIA as a general rule is not what the framework says. They are structurally independent instruments: one covers the risk to data, the other the risk to fundamental rights, and there are impacts on rights that a well-done DPIA simply isn't designed to capture.
What one covers that the other doesn't
An example clarifies the difference. Imagine a system that ranks and prioritises candidates in a recruitment process.
The DPIA will deal with the processing: what personal data is processed, on what legal basis, how long it's retained, what security measures protect it, whether there are international transfers.
The FRIA will deal with something else: whether the system can introduce discrimination, how it affects the right to fair treatment, what happens to rejected candidates, what human oversight exists over its decisions, what ensures a person isn't excluded because of a bias in the model. These are questions about rights, not about data. A competent DPIA may touch on them, but answering them isn't its function.
The calendar: each on its own clock
Here's another point the confusion obscures. The DPIA is a GDPR obligation in force today: if your processing falls under Article 35, the assessment is required now, regardless of the AI Act.
The FRIA follows the high-risk calendar of Annex III. Under the Digital Omnibus, that date moves to 2 December 2027. In other words: you can have the DPIA obligation today and not yet have the FRIA obligation for the same system. Treating them as the same document erases that difference in timing and leads to mistakes in both directions — believing you're covered when you're not, or getting ahead of yourself with the wrong logic.
What to do in practice
Three sober recommendations:
- Don't merge the documents. Keep the DPIA as a DPIA and the FRIA as a FRIA, even if they share sections. Each answers to a different authority and a different law.
- Reuse, don't replace. Make use of the DPIA's context and affected-persons analysis as an input to the FRIA. It's efficient, and the Omnibus favours it. But complete the FRIA with what's proper to it: the impact on fundamental rights and human oversight.
- Place each one on its own calendar. The DPIA, whenever the processing requires it (today). The FRIA, when the high-risk Annex III system reaches its date of application.
The distinction isn't an academic technicality. It's the difference between genuinely documenting due diligence and believing you've documented it. In AI governance, that difference is everything.
This article is for informational purposes only and does not constitute legal advice.