FRIA vs DPIA: How the EU AI Act and GDPR Impact Assessments Differ and Connect

A DPIA (Data Protection Impact Assessment) is a GDPR instrument under Article 35 GDPR (Regulation (EU) 2016/679): it assesses risks to personal data and the privacy of data subjects. A FRIA (Fundamental Rights Impact Assessment) is an EU AI Act instrument under Article 27 of Regulation (EU) 2024/1689: it assesses risks of harm to fundamental rights from deploying a high-risk AI system.

They are sibling impact-assessment instruments with overlapping content — but they are not substitutes. Each rests on a distinct legal basis, fires on a distinct trigger, and answers to a distinct authority. A FRIA can build on an existing DPIA, and the AI Act expressly encourages that. But a DPIA does not discharge the Article 27 obligation, and a FRIA does not satisfy Article 35 GDPR.

This page sets out, in order: what each assessment is, who must perform which and when, a side-by-side comparison table, how the two overlap so you avoid duplicate work, when the FRIA obligation actually starts to bite, and how the penalty regimes differ.

---

FRIA vs DPIA: the one-sentence distinction

Two different laws, two different harms

The cleanest way to hold the two apart is by the harm each is built to catch. A DPIA exists to protect personal data and privacy — it is data-centric. A FRIA exists to protect fundamental rights in the round — non-discrimination, human dignity, access to essential public and private services, fair process, and the right to an effective remedy. Privacy is one fundamental right among many; the FRIA lens is therefore broader than the DPIA lens, even though they share a centre of gravity around the affected individual.

That difference flows directly from the parent regulations. The GDPR governs the processing of personal data, full stop. The EU AI Act governs AI systems by risk tier, and the FRIA is one of the duties it places specifically on the deployer of a high-risk AI system.

Why the comparison matters for high-risk AI deployers

If your company already runs DPIAs, the instinct is to ask whether the AI Act simply bolts another section onto a form you already complete. It does not. The FRIA is a separate, signed-off output with its own legal trigger, its own scope, and — critically — its own notification duty to a different regulator. Treating it as "the DPIA plus a paragraph" is how companies end up with an assessment that satisfies neither law. The rest of this page shows where the two genuinely converge and where they must stay distinct.

---

What a DPIA is (GDPR Article 35)

When a DPIA is triggered

Under Article 35(1) GDPR, a DPIA is required where a type of processing — in particular one using new technologies — is likely to result in a high risk to the rights and freedoms of natural persons. Systematic and extensive profiling with significant effects, large-scale processing of special category data, and large-scale systematic monitoring of a publicly accessible area are the textbook triggers under Article 35(3). The assessment must be carried out before processing begins.

Who performs it and what it must contain

The DPIA is the data controller's obligation, performed with the advice of the Data Protection Officer where one is designated. Its minimum content is fixed by Article 35(7) GDPR:

1. a systematic description of the envisaged processing operations and the purposes of the processing;
2. an assessment of the necessity and proportionality of the processing in relation to those purposes;
3. an assessment of the risks to the rights and freedoms of data subjects; and
4. the measures envisaged to address those risks, including safeguards and security measures.

Where a high residual risk remains after mitigation, Article 36 GDPR obliges the controller to consult the supervisory authority before processing starts. The DPIA lens stays data-centric throughout: lawful basis, data minimisation, retention, security, and the rights of data subjects. For the AI-specific mechanics — how to scope a DPIA when the processing sits inside a model — see the DPIA for AI systems.

---

What a FRIA is (EU AI Act Article 27)

Who is in scope under Article 27

A FRIA is required under Article 27(1) of Regulation (EU) 2024/1689 before certain deployers put a high-risk AI system into use. This is a deployer-side obligation, distinct from the provider's conformity assessment and risk-management duties. It binds two groups: deployers that are bodies governed by public law, or private entities providing public services; and any deployer of the high-risk systems in Annex III point 5(b) (creditworthiness and credit scoring) and Annex III point 5(c) (risk assessment and pricing in life and health insurance). Most other private-sector deployers do not owe a standalone FRIA. For the full obligation, see Article 27 and the FRIA.

What an Article 27 FRIA must contain

Article 27(1) sets the content elements. The deployer must describe:

• the deployer's processes in which the high-risk AI system will be used, in line with its intended purpose;
• the period of time and frequency over which the system is intended to be used;
• the categories of natural persons and groups likely to be affected by its use in the specific context;
• the specific risks of harm likely to affect those persons or groups, taking the provider's information into account;
• the human oversight measures, according to the instructions for use; and
• the measures to be taken if those risks materialise, including internal governance arrangements and complaint mechanisms.

Crucially, Article 27(3) provides that where these elements are already covered by another obligation — such as a DPIA — the FRIA may complement that assessment rather than repeat it. The fundamental-rights lens reaches beyond privacy: discrimination, dignity, access to essential services, fair process, and effective remedy all sit inside the FRIA.

Notifying the authority

The FRIA is not an internal-only document. Under Article 27(4)-(5), once the assessment is performed the deployer must notify the market surveillance authority of the results, using the template the AI Office will provide, and must update the FRIA whenever any of its elements changes or is no longer up to date. You can extend an existing intake into the assessment with the FRIA template.

---

Who must do which: scope and trigger compared

Public bodies and public-service providers

DPIA scope is universal across sectors: any controller carrying out likely-high-risk processing under Article 35 GDPR owes a DPIA, whether or not AI is involved at all. FRIA scope is narrower. The first in-scope group is public bodies and private entities providing public services — think a municipality, a public benefits agency, or a private operator delivering an essential public service through a high-risk AI system.

Annex III point 5(b) and 5(c) deployers

The second in-scope group is sector-specific regardless of public/private status: deployers of Annex III point 5(b) creditworthiness and credit-scoring systems (fraud detection is excluded) and Annex III point 5(c) life and health insurance risk-assessment and pricing systems. A bank scoring loan applicants and an insurer pricing health cover both owe a FRIA even though they are private companies. A FRIA only ever applies to high-risk AI systems — defined by Article 6 as a safety component of an Annex I product or an Annex III use case. A DPIA, by contrast, can apply to processing with no AI in it whatsoever.

When you need both

It is common to owe both at once. A public authority deploying an Annex III decision system processes personal data (triggering a DPIA) and affects fundamental rights through a high-risk AI system (triggering a FRIA). The timing differs: a DPIA is due before processing starts; a FRIA is due before first putting the high-risk system into use, and is then kept current. A practical dual-trigger example is high-risk employment decision systems used in recruitment and HR — they screen personal data and shape access to work, so both assessments fire.

---

FRIA vs DPIA comparison table

The two assessments overlap in content but never substitute for each other — different laws, different regulators, different triggers.

---

How they overlap: building a FRIA on an existing DPIA

What you can reuse

Article 27(3) is the explicit do-once-satisfy-many provision: the FRIA may complement an existing DPIA where the same elements are already covered. The reusable overlap is real. The systematic description of the use case, the categories of affected persons, and parts of the risk analysis can be shared between the two documents. If your DPIA already maps who is affected and how, you carry that straight across rather than re-deriving it.

What the FRIA adds that a DPIA never covers

The two then diverge. FRIA-only additions are: fundamental-rights harms beyond data protection (discrimination, access to services, fair process); human oversight measures specific to the AI system; complaint mechanisms; and notification to the market surveillance authority. DPIA-only additions are: the lawful basis for processing; the necessity and proportionality analysis; data minimisation and retention; and Article 36 GDPR prior consultation where residual risk stays high. Many deployers will extend a DPIA into a FRIA in practice — but the FRIA remains a separate, separately signed-off output on its own legal trigger. For the full obligation-by-obligation map, see the GDPR and EU AI Act crosswalk, and for the conceptual treatment, how GDPR and the AI Act intersect.

---

When the FRIA obligation actually bites: the high-risk timeline

The statutory date vs the agreed deferral

Article 27 does not have its own FRIA deadline; it tracks the high-risk Annex III timeline under Article 113. As enacted, the statute set 2 August 2026 as the date stand-alone high-risk Annex III obligations (Article 6(2)) apply. The Digital Omnibus reached provisional political agreement on 6-7 May 2026, with COREPER confirming the text around 13 May 2026, agreeing to defer those obligations from 2 August 2026 to 2 December 2027 (and Annex I product-embedded obligations from 2 August 2027 to 2 August 2028).

Freshness caveat: as of June 2026 this deferral is agreed but not yet law. It still needs the European Parliament plenary vote, formal Council adoption, and publication in the Official Journal. Until all three happen, the statute still reads 2 August 2026 for high-risk Annex III. The new dates are fixed calendar dates — the standards-contingent "stop the clock" proposal was rejected, so the delay is not tied to harmonised-standards availability.

What has not been delayed

Not everything moved. The Article 5 prohibitions have applied since 2 February 2025, and the GPAI obligations (Articles 51-55) since 2 August 2025 — neither is affected by the FRIA timeline. A separate 2 December 2026 deadline was added for content-marking and the CSAM/'nudifier' ban. Deployers should not treat 2 December 2027 as breathing room: FRIA inputs depend on provider documentation and DPIAs that take months to assemble, so the work starts well before the date bites.

---

Penalties and how to produce both without duplicating work

How fines differ between the two regimes

Penalty exposure differs by instrument. A DPIA failure falls under the GDPR fining regime (up to €20,000,000 or 4% of worldwide turnover under GDPR Article 83(5)). A FRIA failure falls under Article 99 of Regulation (EU) 2024/1689. The AI Act tiers are:

• up to €35,000,000 or 7% of total worldwide annual turnover, whichever is higher, for Article 5 prohibited-practice breaches (Article 99(3));
• up to €15,000,000 or 3% for most other obligation breaches, including deployer duties such as the Article 27 FRIA (Article 99(4)); and
• up to €7,500,000 or 1% for supplying incorrect, incomplete or misleading information to notified bodies or authorities (Article 99(5)).

Article 99(6) sets a proportionate cap for SMEs and start-ups — the lower of the percentage or the fixed amount. A single AI incident touching personal data can attract fines under both regimes, from two different authorities, assessed independently.

Producing a connected DPIA and FRIA

Treat the DPIA and FRIA as one connected evidence chain: a shared use-case description, a shared affected-persons analysis, and two divergent legal lenses bolted on top. The trap is letting the shared facts drift between documents — a different system description in the DPIA than in the FRIA undermines both.

---

How Confir helps

Confir produces both the DPIA structure for AI systems and the Article 27 FRIA from a single guided intake. The intake captures the use-case description and the categories of affected persons once, then routes those shared facts into both outputs — so the DPIA and the FRIA stay consistent rather than diverging across two forms.

The synthesis engine is deterministic and rule-based: the same intake produces the same obligation mapping and the same assessment structure every time — the same logic every time, no model inference, no hallucination. Where the Article 27 notification duty applies, Confir versions the FRIA so that when an element changes you can re-notify the market surveillance authority from a clean, dated record rather than reconstructing what was assessed.

---

Frequently Asked Questions

What is the difference between a FRIA and a DPIA?

A DPIA is a GDPR Article 35 assessment of risks to personal data and privacy. A FRIA is an EU AI Act Article 27 assessment of risks to fundamental rights from deploying a high-risk AI system. They have different legal bases and focuses: a DPIA is data-centric, while a FRIA covers broader rights such as non-discrimination and access to services.

Does a FRIA replace a DPIA?

No. A FRIA does not replace a DPIA, and a DPIA does not satisfy the Article 27 FRIA obligation. They are separate instruments under separate laws. Article 27(3) lets a FRIA build on and complement an existing DPIA where content overlaps, but each assessment must still be completed and signed off on its own legal basis.

Who has to do a Fundamental Rights Impact Assessment under the EU AI Act?

Under Article 27, the FRIA applies to deployers that are bodies governed by public law or private entities providing public services, plus any deployer of the high-risk systems in Annex III point 5(b) on creditworthiness and credit scoring and Annex III point 5(c) on risk assessment and pricing in life and health insurance.

When is a DPIA required?

Under Article 35 GDPR, a DPIA is required before processing begins when that processing is likely to result in a high risk to the rights and freedoms of natural persons, especially when using new technologies. It is the controller's duty, taken with DPO advice. If high residual risk remains, Article 36 requires consulting the supervisory authority first.

Can a FRIA be based on an existing DPIA?

Yes. Article 27(3) of the EU AI Act allows the FRIA to complement an assessment you have already done, such as a DPIA, where the same elements are covered. You can reuse the use-case description, affected-persons analysis and parts of the risk assessment, but you must still add fundamental-rights harms, oversight measures and authority notification.

When does the FRIA requirement under Article 27 start to apply?

The FRIA tracks the high-risk Annex III timeline. As enacted, that date is 2 August 2026. The Digital Omnibus agreed in May 2026 to defer it to 2 December 2027, but as of June 2026 this is agreed and not yet law, pending the European Parliament vote, Council adoption and Official Journal publication, so the statute still reads 2 August 2026.

What are the penalties for failing to do a FRIA?

Failing a deployer obligation such as the Article 27 FRIA falls under Article 99(4), with fines up to €15,000,000 or 3% of worldwide annual turnover, whichever is higher. The top tier of €35,000,000 or 7% (Article 99(3)) applies to Article 5 prohibited practices, and €7,500,000 or 1% applies to supplying incorrect information.

---

Related guides

• Article 27 and the FRIA
• the DPIA for AI systems
• the GDPR and EU AI Act crosswalk
• how GDPR and the AI Act intersect
• the FRIA template
• high-risk employment decision systems