There's a misconception that circulates with too much ease among those who deploy AI systems that process personal data: 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.
The figure compares the two instruments in three columns — who, when and what: the FRIA under Article 27, owed by certain deployers before first use and with six contents; the DPIA under Article 35 GDPR, owed by the controller before the processing and with four minimum contents; and, between them, the reuse of material that Article 27(4) allows.
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, and the difference isn't that one looks at data and the other at rights: both assess risks to people. The difference lies in the subject matter, in who owes each one and in what each has to contain.
Where the real difference lies
Three axes, and none of them is "data versus rights":
- Subject matter. The DPIA assesses a processing of personal data; the FRIA, the use of a high-risk AI system in specific processes.
- Who owes it, and when. The DPIA is owed by the controller where the processing is likely to result in a high risk to people's rights and freedoms (Article 35 GDPR). The FRIA is owed only by certain deployers: bodies governed by public law and private entities providing public services when they deploy high-risk systems under Annex III — except its point 2 —, and deployers of the systems in Annex III, point 5(b) and (c) (Article 27(1)).
- Content. Article 27(1) asks for six contents of its own: the processes in which the system will be used, the period and frequency of use, the categories of affected persons, the specific risks of harm, the human oversight measures and what will be done if the risks materialise. Article 35(7) GDPR sets a different minimum content, and it includes "(c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1".
That point (c) dismantles the usual shortcut. Imagine a system that ranks and prioritises candidates in a recruitment process. Its DPIA can't stop at the legal basis, retention and security of the data: it has to assess the risks to the candidates' rights and freedoms, discrimination among them. What the FRIA adds isn't "rights", which the DPIA already looks at, but its own content: how the system is used in the process, whom it affects, what human oversight there is over its decisions and what will be done if the risk materialises.
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 six contents of Article 27(1), human oversight among them.
- Place each one on its own calendar. The DPIA, whenever the processing requires it (today), which can happen even when the system is not high-risk under the AI Act. 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.