FRIA Template: How to Conduct an EU AI Act Fundamental Rights Impact Assessment

Who Must Conduct a FRIA — and Who Is Exempt

Article 27(1) of the EU AI Act imposes the fundamental rights impact assessment obligation on a specific, limited set of deployers. The obligation applies to three categories: bodies governed by public law, including EU institutions, agencies, and bodies; private entities providing public services, specifically in the areas of education, healthcare, social services, housing, and administration of justice; and all deployers of AI systems used to evaluate creditworthiness or establish credit scores of natural persons, or to assess and price risk in life and health insurance contracts.

The scope is narrower than the high-risk classification itself. A bank deploying an AI system for credit scoring is subject to Article 27. The same bank deploying an AI system for internal fraud monitoring is not — unless that system also performs creditworthiness evaluation as a main intended purpose. The Commission’s draft guidelines on high-risk classification, published on 19 May 2026, confirm that “creditworthiness” and “credit score” are distinct use cases under Annex III point 5(b), and that a system can trigger one or both. The guidelines also confirm that the fraud-detection exception is interpreted narrowly: fraud detection must be the system’s main intended purpose, and the exception does not extend to anti-money laundering or counter-terrorism financing systems, which are regulated separately.

For life and health insurance, no equivalent fraud-detection exception exists. An AI system intended for risk assessment or pricing in life and health insurance remains high-risk even where it incorporates a fraud-detection capability, unless that capability constitutes a genuinely standalone system separate from the risk-assessment function.

Deployer-type determination is a legal classification exercise, not an output of an IT asset inventory. It requires counsel to assess whether the entity falls within the Article 27(1) categories before any FRIA scoping begins — a step that organizations with broad AI portfolios frequently defer until too late in the compliance cycle.

The Article 6(3) Filter and What It Means for FRIA Scope

Not every AI system within an Annex III use case is high-risk. Article 6(3) allows providers to filter systems out of high-risk classification where they do not pose a significant risk of harm, provided they satisfy at least one of four alternative conditions: performing a narrow procedural task, improving the result of a previously completed human activity, detecting decision-making patterns without replacing or influencing human assessment, or performing a preparatory task to an assessment subject to meaningful human review. The system must also not materially influence the outcome of decision-making in a way that could adversely affect individuals.

The filter does not apply to Annex III systems that profile natural persons. Profiling systems — those using automated processing of personal data to assess aspects such as work performance, economic situation, health, preferences, or behaviour — are always classified as high-risk and cannot benefit from any Article 6(3) exception.

Systems filtered out of high-risk classification carry no FRIA obligation. Providers must, however, document the filter assessment before placing the system on the market and register the exempt system in the EU database to ensure traceability. Deployers cannot rely on a provider’s filter decision without verifying it: if the deployer’s actual use case diverges from the provider’s documented intended purpose, the filter analysis may not hold, and the deployer may assume provider obligations under Article 25 of the AI Act.

FRIA scoping must therefore be preceded by a documented high-risk classification review for every AI system in the deployer’s inventory. Skipping this step produces one of two failure modes: unnecessary FRIA work on systems that are not in scope, or missed obligations on systems that are.

FRIA vs DPIA — Where They Diverge in Practice

A data protection impact assessment under GDPR Article 35 covers data protection and privacy rights — Charter Articles 7 and 8. A FRIA under Article 27(1)(d) covers the full spectrum of fundamental rights in the EU Charter of Fundamental Rights, regardless of whether personal data is processed. This includes dignity, non-discrimination, freedom of expression, access to justice, and workers’ rights — categories a standard DPIA does not systematically address.

Article 27(4) explicitly provides that where a DPIA already exists, the FRIA should complement it. The two assessments can be consolidated into a single integrated report, and for most organizations this is the operationally sensible approach. The Digital Omnibus on AI, Regulation (EU) 2026/1744, reinforced this route in 2026 by expressly allowing a FRIA to incorporate or cross-refer to relevant parts of an existing DPIA, with the Commission’s forthcoming Article 27(5) template expected to support that cross-referencing format directly.
The consolidation does not reduce scope: the FRIA component must still identify specific risks of harm to affected categories of persons across the full Charter spectrum, a requirement that DPIA-derived content frequently fails to satisfy.

Organizations that treat a completed DPIA as a substitute for a FRIA will produce assessments that are legally insufficient under Article 27(1)(d). The practical test is whether the assessment identifies concrete harm scenarios for each relevant Charter right, assigns likelihood and severity, documents mitigation measures, and records residual risk. A DPIA that stops at data-protection impact does not meet this standard.

The Working FRIA Structure — Six Sections Mapped to Article 27(1)

The official template under Article 27(5) has not yet been published by the European AI Office. Article 27(1) itself, however, defines six content elements with sufficient precision to build a working structure now. The following six-section framework maps directly to Article 27(1)(a) through (f) and aligns with the five-phase methodology published by the European Center for Not-for-Profit Law and the Danish Institute for Human Rights in December 2025.

Section 1 — System Description and Deployer Processes [Art 27(1)(a)]

Document the name and version of the AI system, the provider’s identity, the intended purpose as defined by the provider, and the deployer’s specific processes in which the system will be used, including the operational context and environment. Where the deployer’s actual use diverges from the provider’s documented intended purpose, the deployer may assume provider obligations under Article 25. This must be resolved — either by correcting the use or accepting the provider obligations — before the FRIA proceeds.

Section 2 — Duration, Frequency, and Geographic Scope [Art 27(1)(b)]

Record the start date, expected duration, frequency of use, the volume of decisions the system will affect, and the geographic and organizational scope of deployment. This section establishes the temporal and spatial boundaries within which the risk assessment in Section 4 applies.

Section 3 — Categories of Affected Persons [Art 27(1)(c)]

Identify the direct subjects of the AI system’s outputs, third parties indirectly affected by its operation, and vulnerable groups requiring specific consideration — children, persons with disabilities, and persons in vulnerable social situations. The ECNL/DIHR methodology emphasizes meaningful stakeholder engagement at this stage, before risks are identified, rather than consulting affected groups only after the assessment is drafted.

Section 4 — Specific Risks of Harm to Fundamental Rights [Art 27(1)(d)]

Produce a risk register mapping each relevant Charter right to a concrete harm scenario, with columns for likelihood, severity, mitigation measures, and residual risk. This is the section where DPIA-derived content most often falls short: the register must extend beyond privacy and data protection to cover the full Charter scope, including non-discrimination, dignity, freedom of expression, and access to justice.

Section 5 — Human Oversight Measures [Art 27(1)(e)]

Document the oversight roles, intervention powers — including the ability to override or halt system outputs — and the qualifications and training of oversight personnel. Article 26(2) imposes human-oversight obligations on deployers of high-risk systems; the FRIA must record how that oversight is implemented in practice, not merely that it nominally exists.

Section 6 — Measures if Risks Materialise [Art 27(1)(f)]

Record the technical and organizational mitigation measures in place, the complaint and redress mechanisms available to affected persons, and the internal governance and escalation procedures that activate when a risk materializes. This section connects the FRIA to the deployer’s broader incident-response and accountability framework.

The Notification Obligation Most Deployers Will Miss

Article 27(3) requires deployers to notify the relevant market surveillance authority of the FRIA results. This is an external accountability mechanism, not an internal documentation exercise. The notification must use the Article 27(5) template once published; until then, deployers must submit their own structured documentation.

The only exemption from the notification requirement is the narrow case under Article 46(1) — an exceptional authorization for reasons of public security or protection of life and health — and even then only for a limited period. Market surveillance authorities are designated at Member State level; in most Member States this is the national data protection authority or a dedicated AI authority. Deployers operating across multiple Member States must identify the correct authority in each relevant jurisdiction.

The notification requirement has a direct drafting consequence: FRIA documentation must be prepared to a standard suitable for regulatory submission from the outset. Documentation written for internal consumption and retrofitted before filing will typically require substantial rework.

Penalty Exposure and the Article 99(4) Textual Gap

Article 99(4) sets the middle penalty tier at EUR 15 million or 3% of total worldwide annual turnover for breaches of deployer obligations. The provision expressly names Article 26 — the general deployer obligations for high-risk systems — but does not expressly name Article 27. The prevailing practitioner reading is that a FRIA failure falls within this tier as a breach of deployer obligations, but the textual gap is real, and no authoritative interpretation from the Court of Justice of the EU currently resolves it.

Member State penalty rules under Article 99(1) and 99(2) also apply and may vary in how they categorize and calculate penalties. SMEs and start-ups benefit from a cap at the lower of the percentage or fixed amount under Article 99(6). The Digital Omnibus on AI, Regulation (EU) 2026/1744, introduced additional penalty considerations for small mid-cap companies alongside its calendar changes.

Legal counsel should assess penalty exposure under both the AI Act framework and applicable Member State rules before the FRIA is finalized — not after a market surveillance authority makes contact.

What the Official Template Will Change — and What It Won’t

Article 27(5) requires the European AI Office to develop a template questionnaire for the FRIA, including an automated tool. As of September 2026, the template has not been published and no hard deadline exists for its release. The absence of the official template does not excuse the obligation: Article 27(1) defines the required content elements with sufficient precision for deployers to begin now.

The ECNL/DIHR guide published in December 2025 provides a practitioner template and five-phase methodology directly built on Article 27(1). It is civil-society guidance, not a binding EU instrument, but it represents the most developed publicly available methodology currently in circulation. When the official template arrives, existing assessments built on the Article 27(1) structure will require alignment rather than wholesale reconstruction — the six content elements are the substantive core and will map directly to whatever format the AI Office ultimately publishes.

Compliance Priorities Before December 2027

The Digital Omnibus on AI moved the application date for FRIA obligations to 2 December 2027 for stand-alone Annex III systems, and to 2 August 2028 for AI systems embedded in regulated products under Annex I. The final high-risk classification guidelines are expected by the end of 2026, following the Commission’s targeted consultation which closed on 23 July 2026.

Deployers in scope should treat the interval as a working runway, not a waiting period. The immediate priorities are: inventory all AI systems and classify them against Annex III using the Commission’s draft guidelines as the working baseline; confirm deployer type for each in-scope system against the Article 27(1) categories; audit existing DPIAs for reuse potential under Article 27(4); build FRIA documentation on the six-section structure above; identify the correct market surveillance authority for notification purposes in each relevant Member State; and monitor the European AI Office for publication of the Article 27(5) template.

Organizations that complete the classification and scoping work now will be positioned to finalize FRIA documentation rapidly once the official template and final guidelines land. Those that wait will face a compressed compliance window against a fixed regulatory deadline.