FRIA Explained — Fundamental Rights Impact Assessment Under Article 27

What a FRIA is

A Fundamental Rights Impact Assessment (FRIA) is a deployer-side document required by Article 27 of Regulation (EU) 2024/1689. It is the deployer's analysis of how a high-risk AI system, when used in the deployer's specific context, may affect the fundamental rights of the people that use of the system can reach.

The Charter of Fundamental Rights of the European Union is the reference frame: dignity, non-discrimination, fair trial, social security, freedom of movement, freedom of expression, data protection. A FRIA is broader than a GDPR Data Protection Impact Assessment — it covers the full Charter, not only data-protection rights.

Who has to do one

Article 27(1) identifies four deployer categories that owe a FRIA before deploying a high-risk AI system (with the explicit exclusion of Annex III §2 critical infrastructure systems):

1. Bodies governed by public law (Directive 2014/24/EU Article 3 definition) — central government, regional government, municipalities, public hospitals, public universities, and any entity financed or controlled by the state.
2. Private entities providing public services — for example a private operator of a public transport concession, a private operator of a public-school cafeteria meal-allocation system.
3. Deployers of credit-assessment AI under Annex III §5(b) — except where the system is used exclusively for fraud detection.
4. Deployers of life and health insurance risk-assessment / pricing AI under Annex III §5(c).

Other deployers — private retailers using hiring tools, private employers using workplace monitoring — owe Article 26 duties and (where personal data is processed) a GDPR Article 35 DPIA, but not a FRIA.

What goes in it — the six elements

Article 27(1) lists the six elements:

• (a) Description of the deployer's processes that will use the AI system in line with its intended purpose.
• (b) The period of time within which, and the frequency with which, each high-risk AI system is intended to be used.
• (c) The categories of natural persons and groups likely to be affected by use in the specific context.
• (d) The specific risks of harm likely to impact each category, taking into account the Article 13 information the provider supplied.
• (e) The implementation of human oversight measures, per the instructions for use.
• (f) Measures to be taken if those risks materialise — internal governance and complaint mechanisms.

Six points. The one that carries the weight is (d). The others are scaffolding.

FRIA vs DPIA — the difference matters

The most common FRIA failure mode is producing a DPIA in a FRIA jacket. They overlap, they often live in the same document, and the person writing them is usually the same person. But they answer different questions.

A combined document is fine if the FRIA-specific sections are clearly labelled. A DPIA that says "fundamental rights" once but never enumerates Charter rights or affected-group risks is not a FRIA.

Two worked examples

Example 1 — public-sector deployer

Ministry of Internal Affairs of a Member State deploys a high-risk AI system that triages applications for social-housing benefits (Annex III §5(a) — public benefits).

(a) Processes. "All complete applications received via the e-government portal are scored by the model and routed into one of three queues: priority review (top 10% of need scores), standard review (middle 80%), or low-priority review (bottom 10%). Caseworkers process queues in order. Final decisions are made by caseworkers, not by the model."

(b) Period and frequency. "Continuous, 24/7. ~140,000 applications per year."

(c) Affected categories. "All housing-benefit applicants. Sub-groups for fundamental-rights monitoring: applicants in temporary accommodation, single-parent households, applicants with disabilities, recently-arrived migrants and refugees, elderly applicants (≥75)."

(d) Specific risks. "(i) Risk of disparate impact on recently-arrived migrants — historic training data under-represents migrant applicants. (ii) Risk of de-prioritisation of disabled applicants whose paperwork is harder to complete digitally. (iii) Risk that applicants in temporary accommodation are scored against features that capture address-stability, disadvantaging them. (iv) Risk that the routing into "low-priority" queue effectively delays decisions beyond statutory timelines for vulnerable groups. Each risk is evidenced in §4 of the provider's Annex IV file and documented in our Article 9 deployer-side risk register."

(e) Human oversight. "Each of the three queues is processed by a caseworker who can override the routing or escalate to a senior caseworker. Caseworker training: 24-hour curriculum on the system's limitations, with mandatory refresher every 12 months. Override rate is monitored monthly; >10% override rate triggers re-validation under Article 9. The "low-priority" queue has a maximum 14-day SLA after which the application auto-escalates to standard review regardless of model output."

(f) Materialisation. "On detection of disparate impact >5pp on any monitored sub-group: (i) Ministry's AI Governance Board meets within 5 business days; (ii) the system is paused for the affected sub-group and applications revert to manual processing; (iii) provider is notified under Article 26(5). Complaint mechanism: a dedicated form on the e-government portal with a 10-day response SLA, plus the ordinary administrative-appeal route under national law."

That FRIA is roughly five pages once typeset. The Ministry notifies the Member-State market-surveillance authority via the Article 27(3) template.

Example 2 — private-sector credit deployer

Bank Przykładowy S.A. deploys ScoreMate, a third-party gradient-boosted credit-decision model, for consumer loans between PLN 5,000 and PLN 80,000. See the worked example in our Article 27 reference page for the full six-element walkthrough.

The credit case is the most-deployed FRIA scenario in the EU. Banks that have not yet stood up a FRIA process by mid-2026 are running real exposure.

What the AI Office template will and won't tell you

Article 27(5) requires the AI Office to develop a template questionnaire to facilitate the FRIA. As of mid-2026, the template is in consultation. It will provide:

• A standardised structure for the six elements.
• Suggested affected-group categories per Annex III deployment scenario.
• A standard notification format to market surveillance authorities under Article 27(3).

It will not answer:

• Which Charter rights are most relevant to your specific use case.
• Where the threshold of "specific risk of harm" sits for your sub-groups.
• Whether your human-oversight design is sufficient under Article 14.
• Whether your stop-control / pause arrangement is fast enough to be meaningful.

These are judgment calls for the deployer.

Common FRIA failure modes

1. DPIA-as-FRIA. Charter rights enumerated once, then the document reverts to data-protection logic. Regulators read this as a non-FRIA.
2. No specific affected sub-groups. "Loan applicants" is not a sub-group. "Applicants with thin credit files in the lowest income decile" is.
3. Section (d) under-specified. Vague harm narratives ("the system might be biased") with no provider Article 13 evidence cited.
4. Section (f) is wishful thinking. "We will deal with risks if they materialise" — no SLA, no decision-maker, no complaint mechanism.
5. No update cadence. Article 27(2) requires updates when situation changes. Treat the FRIA as a living document.
6. Notification to market surveillance never filed. Article 27(3) is a procedural step, not a discretionary one.

Inline crosswalk to ISO 42001 and NIST AI RMF

• ISO/IEC 42001:2023 Clause 6.1.4 — AI system impact assessment. The FRIA is the AI-system impact assessment in EU-context terms.
• ISO/IEC 42001:2023 Annex A.5.2 — AI system impact assessment process.
• NIST AI RMF MAP 5.1 — Likelihood and magnitude of each identified impact are characterised based on expected use.
• NIST AI RMF MAP 5.2 — Practices and personnel for supporting regular engagement with relevant AI Actors.

What we ship — the FRIA template

Governancer Pro includes a 15-page Article 27 FRIA template (.docx) with the six elements pre-structured, a filled example for a public-sector deployer, and a private-sector toggle for credit / insurance deployers. Download the FRIA template (Pro tier).

Internal links

• Article 27 — primary reference.
• Article 26 — deployer obligations.
• Article 14 — human oversight (informs Section (e) of every FRIA).
• Annex III — high-risk categories.

---

Disclaimer. This pillar is a reference summary of EU AI Act Article 27 / FRIA. It is not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text from Regulation (EU) 2024/1689.