DPIA and FRIA for AI Systems: Two Assessments, One Workflow

When an AI system processes personal data in ways that are likely to result in a high risk to individuals, two legal frameworks may both demand a formal impact assessment — and neither waives the other. The GDPR's Data Protection Impact Assessment (DPIA, Article 35 GDPR) and the EU AI Act's Fundamental Rights Impact Assessment (FRIA, Article 27 of Regulation (EU) 2024/1689) are distinct duties. Getting the scoping right is not paperwork management; it is the difference between compliant deployment and a supervisory finding.

What a DPIA Is — and When It Is Required

A DPIA is a documented risk assessment required under Article 35 GDPR before processing personal data in ways likely to result in a high risk to the rights and freedoms of natural persons. The obligation sits with the data controller and must be completed before processing begins.

Three categories always trigger a DPIA under Article 35(3) GDPR:

1. Systematic and extensive evaluation of personal aspects, including profiling, where decisions produce legal or similarly significant effects
2. Large-scale processing of special-category data (GDPR Article 9: health, biometric, genetic, racial or ethnic origin, political opinions, religious beliefs, sexual orientation)
3. Systematic monitoring of publicly accessible areas on a large scale

AI systems in hiring, lending, healthcare diagnostics, and insurance pricing almost invariably meet category 1 or 2. An automated credit-scoring model at a regional bank ticks both — it profiles individuals at scale and its outputs determine access to credit, a significant effect within the meaning of GDPR Article 22.

Where the three presumptions do not resolve the question, the EDPB's nine-criteria framework applies: a DPIA is required when two or more criteria are present — scoring/profiling, automated decisions with significant effect, systematic monitoring, sensitive data, large-scale processing, data matching, vulnerable data subjects, innovative technology, or processing that prevents individuals from exercising rights. Most consequential AI deployments satisfy three or four.

What a FRIA Is — and Who Owes It

The Fundamental Rights Impact Assessment is an EU AI Act obligation, not a GDPR one. Article 27 of Regulation (EU) 2024/1689 requires certain high-risk AI deployers to conduct a FRIA before putting a high-risk AI system into operation.

The scope is narrower than it might appear. Article 27 applies to:

• Public-body deployers of any high-risk AI system listed in Annex III
• Private deployers of high-risk AI systems falling specifically under Annex III point 5(b) (creditworthiness assessment, credit scoring — excluding fraud detection) or point 5(c) (life insurance and health insurance risk assessment and pricing)

Private employers deploying AI for recruitment (Annex III point 4(a)) or employee monitoring (point 4(b)) do not owe a FRIA under Article 27 unless they are also a public body. This is a common misreading: the FRIA obligation does not follow all Annex III uses; it follows specific categories of deployer.

The FRIA must cover: a description of the processes in which the AI system is used, the period and frequency of use, the categories of natural persons affected, the specific risks to fundamental rights, the measures taken to address those risks, and which other persons or bodies were involved in conducting the assessment. Article 27(4) expressly permits the FRIA to build on an existing DPIA — you may incorporate your DPIA's findings rather than reproduce them.

DPIA vs FRIA: The Core Distinctions

The two instruments share a family resemblance — both ask "what harm could this do to people?" — but they differ in legal basis, scope, procedural obligations, and the range of rights they examine.

The DPIA is a GDPR instrument enforced by national data protection authorities. The FRIA is an EU AI Act instrument enforceable by the AI Act's market-surveillance authorities once the high-risk regime applies (2 December 2027 for stand-alone Annex III systems, under the Digital Omnibus agreed in May 2026). The two enforcement tracks are separate; satisfying one does not discharge the other.

What Each Assessment Must Cover

DPIA: Article 35(7) GDPR requirements

The minimum statutory content is: (a) a systematic description of the processing operations and their purposes; (b) an assessment of necessity and proportionality; (c) an assessment of the risks to rights and freedoms; (d) the measures envisaged to address those risks.

For AI systems, "systematic description" requires substance — model type, input features, output categories, decision mechanism, affected populations, and data flows. The risk assessment must address discrimination (proxy features producing protected-characteristic disparities), opacity (GDPR Article 22 right to explanation for solely automated significant decisions), data accuracy, security, and scope creep. Mitigation measures must be specific and documented with ownership and review schedules. If residual risk remains high after mitigation, GDPR Article 36 requires prior consultation with the supervisory authority — typically up to eight weeks.

FRIA: Article 27 requirements

The FRIA asks deployers to document: the processes and context of use; the period and frequency; the categories of affected natural persons; the specific fundamental rights at risk; and the measures taken to address identified risks. Where a DPIA already captures some of this — particularly the affected-person categories and harm analysis — Article 27(4) allows the FRIA to reference and build on it rather than repeat it.

The FRIA's rights-in-scope are broader than a DPIA's. Beyond privacy, it should address: non-discrimination under Article 21 of the EU Charter of Fundamental Rights; access to education, employment, and essential services; human dignity; the right to an effective remedy; and — for public-sector AI in justice or democratic contexts — due process and free elections.

Running Both Assessments Together

For deployers who owe both, a parallel workflow beats two sequential processes. The DPIA's processing description provides the factual spine for the FRIA's context-of-use section; the DPIA's affected-person analysis maps to the FRIA's "categories of natural persons" requirement; the DPIA's discrimination-risk section addresses the FRIA's core non-discrimination concern.

Complete the DPIA screening and description first, then extend the risk analysis to cover the full fundamental-rights charter beyond privacy. Consolidate mitigation measures in a single control register; DPO review for the DPIA and FRIA sign-off can be scheduled in the same session.

One structural note: the FRIA must be submitted to the market-surveillance authority on request; the DPIA stays internal unless GDPR Article 36 consultation is triggered. The FRIA should be presentable as a stand-alone record even if it internally references DPIA sections.

DPO Involvement: Mandatory for the DPIA, Advisable for the FRIA

GDPR Article 35(2) requires the DPO to be consulted when carrying out a DPIA — not optional. The DPO must provide advice, and their opinion, whether followed or not, must be documented.

The AI Act imposes no equivalent statutory DPO role in the FRIA. But most FRIA-triggering systems also require a DPIA, so the DPO will already be involved. Including them in FRIA sign-off produces a single, consistent rights-impact record. For systems in creditworthiness or insurance contexts, both assessments may be examined by the data protection authority and the AI Act market-surveillance authority — a joined-up, DPO-endorsed record is the stronger position.

Keeping Both Assessments Current

Neither is a one-time filing. Review the DPIA whenever processing changes materially — model retraining, new use cases, new input data, or changed output distribution. GDPR Article 35 sets no fixed interval; supervisory guidance typically recommends annual review for high-risk processing.

The FRIA requires updating before any significant change to the nature, scope, context, or purpose of deployment. A model retraining that shifts the affected population, or a new country rollout, should each trigger a review.

The safest approach is a shared trigger list: any event that prompts DPIA review also prompts FRIA review. A single gate, jointly signed off by the DPO and compliance owner, is cleaner than two separate review calendars.

How Confir Helps

For deployers who owe a FRIA — public bodies and private operators in the creditworthiness or life/health-insurance space — Confir runs the Article 27 FRIA as part of its structured compliance assessment. The intake collects the Article 27 required elements: use context, affected populations, fundamental-rights risk mapping, and mitigation measures. The assessment is deterministic and rule-based: the same inputs produce the same structured output, with every finding linked to the specific provision that triggered it.

Confir also structures the GDPR-adjacent inputs within its AITO (Transparency and Human Oversight) and AITR (Data and Technical Robustness) assessment areas, so the factual record that informs an FRIA is already captured in a consistent format. This is not legal advice and does not replace the DPO's DPIA review — but it reduces the duplication burden for compliance teams running both instruments in parallel.

Frequently Asked Questions

Does an AI DPIA replace the EU AI Act FRIA?

No. They have different legal bases, different triggering conditions, and different procedural requirements. A DPIA is required under Article 35 GDPR when AI processing is likely to result in high risk to data subjects' rights. A FRIA is required under Article 27 of Regulation (EU) 2024/1689 for specific categories of high-risk AI deployer. Completing one does not discharge the other — though Article 27(4) permits the FRIA to build on an existing DPIA to avoid duplicating the same factual analysis.

Which deployers actually owe a FRIA under Article 27?

Two categories of deployer: public bodies deploying any Annex III high-risk AI system; and private entities deploying high-risk AI systems under Annex III point 5(b) (creditworthiness/credit scoring, excluding fraud detection) or point 5(c) (life and health insurance risk assessment and pricing). Most private employers deploying AI for recruitment or employee monitoring do not owe a FRIA — a common misreading of Article 27's scope.

When in the process must a DPIA be completed?

Before processing begins. Article 35(1) GDPR states the assessment must be carried out "prior to the processing." An AI system already live without a completed DPIA is in breach of GDPR. A retrospective assessment must be conducted immediately, and if residual risk remains high, Article 36 GDPR prior consultation with the supervisory authority may be required.

What is the DPO's role in an AI DPIA?

Mandatory under Article 35(2) GDPR. The DPO must be consulted when the DPIA is being carried out. The controller must document the DPO's advice and whether it was followed. There is no equivalent statutory DPO requirement in the Article 27 FRIA, but involving the DPO in FRIA sign-off is advisable when the same system requires both assessments.

Can a DPIA and a FRIA share documentation?

Yes, by design. Article 27(4) of the AI Act explicitly permits the FRIA to build on or complement an existing DPIA. In practice, the DPIA's processing description, affected-person categories, and harm analysis should form the factual spine of the FRIA. The FRIA then extends that analysis to cover the full fundamental-rights charter beyond privacy — non-discrimination, dignity, access to services, due process. A shared control register avoids maintaining two separate mitigation inventories.

How often must an AI DPIA be reviewed?

Whenever the processing changes materially — model retraining, new input categories, expanded use cases, or changes to output distribution. There is no statutory fixed interval, but most supervisory authority guidance recommends at least annual review for ongoing high-risk processing. A review trigger aligned with the FRIA review schedule (which also requires updating before significant changes to deployment) is the most practical approach.

What happens if residual risk remains high after DPIA mitigation?

Article 36 GDPR requires prior consultation with the competent supervisory authority before processing begins. This typically takes up to eight weeks. The authority may provide written advice, impose conditions, or recommend against proceeding. Deployment timelines must account for this window from the outset.

Related guides

• Article 27 FRIA template
• public sector AI compliance
• fintech AI compliance requirements
• insurance sector AI rules
• vendor due diligence questionnaire
• Article 27 compliance guide