EU AI Act Article 27 — Fundamental Rights Impact Assessment (FRIA)

What Article 27 actually requires

Article 27 of Regulation (EU) 2024/1689 imposes a Fundamental Rights Impact Assessment (FRIA) obligation on certain deployers of high-risk AI systems. It does not apply to providers — Article 11 already covers their documentation chain. It does not apply to every deployer — only those listed in Article 27(1).

Reg text — Article 27(1): "Prior to deploying a high-risk AI system referred to in Article 6(2), with the exception of high-risk AI systems intended to be used in the area listed in point 2 of Annex III, deployers that are bodies governed by public law, or are private entities providing public services, and deployers of high-risk AI systems referred to in points 5(b) and (c) of Annex III, shall perform an assessment of the impact on fundamental rights that the use of such system may produce."

A FRIA is not a DPIA. 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 DPIA-in-a-FRIA-jacket is the most common way to fail Article 27.

Who is covered

Article 27(1) applies to:

• Bodies governed by public law (the definition in Article 3 of Directive 2014/24/EU) — central government, regional government, municipalities, public hospitals, public universities, and any entity financed or controlled by the state.
• Private entities providing public services — for example a private company running a public transport concession or a privately-operated public health service.
• Deployers of AI systems used to evaluate creditworthiness or establish credit scores (Annex III §5(b)) — unless the system is used only to detect financial fraud, which is out of scope.
• Deployers of AI systems used for risk assessment and pricing in life and health insurance (Annex III §5(c)).

Critical exclusion. Article 27(1) explicitly excludes high-risk AI systems intended to be used in the area listed in Annex III §2 (critical infrastructure). The legislator's reasoning: critical-infrastructure AI is overwhelmingly machinery-safety AI, not fundamental-rights-impacting AI, and is already covered by sector-specific safety regimes.

If you're a private retailer deploying a hiring tool (Annex III §4(a)), you owe most of Article 26 (deployer obligations) and a GDPR Article 35 DPIA, but you do not owe a FRIA. If you're a bank offering consumer credit (Annex III §5(b)), you do owe a FRIA. Full stop.

The six elements — Article 27(1)(a)–(f)

Article 27(1) lists six things the FRIA must describe, in order:

• (a) A description of the deployer's processes in which the high-risk AI system will be used in line with its intended purpose.
• (b) A description of 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 its use in the specific context.
• (d) The specific risks of harm likely to have an impact on the categories of natural persons or groups identified pursuant to point (c), taking into account the information given by the provider pursuant to Article 13.
• (e) A description of the implementation of human oversight measures, according to the instructions for use.
• (f) The measures to be taken in the case of the materialisation of those risks, including the arrangements for internal governance and complaint mechanisms.

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

What to do — a six-step build

1. Map the deployment process end-to-end. What inputs go into the system, what outputs come out, who acts on those outputs, with what human-review gates. Section (a).
2. State frequency and time-period. Real-time? Batch overnight? A pilot capped at six months? Section (b). Hand-wave here and the rest of the document loses precision.
3. Identify affected groups. Not just "applicants." Specific groups vulnerable to the harm: under-25 applicants, applicants from low-income postal codes, applicants whose income is irregular, etc. Section (c).
4. For each affected group, list the specific risks of harm — and tie each risk back to the Article 13 instructions for use that the provider gave you. Section (d). This is where regulators actually read.
5. Document the human oversight measures that catch each risk. Who reviews, how often, with what training, with what authority to override. Section (e). Cross-reference your Article 14 implementation.
6. State the materialisation response. When (not if) a risk materialises — biased outcomes detected, complaint received from an affected person — what happens. Section (f). Internal governance + a complaint mechanism that affected persons can actually access.

When the FRIA is done, Article 27(3) requires the deployer to notify the market surveillance authority of the results, using a template that the AI Office publishes via Article 27(5).

A worked example — Bank Przykładowy deploys ScoreMate

Bank Przykładowy S.A. is a fictional mid-sized Polish consumer bank. They have bought ScoreMate, a third-party gradient-boosted credit-decision model from a Berlin vendor, and intend to deploy it for consumer loans between PLN 5,000 and PLN 80,000 across their branch network and online application flow.

Bank Przykładowy is the deployer. ScoreMate's vendor is the provider. The provider has done Article 11 documentation. The deployer (Bank Przykładowy) now owes the FRIA.

(a) Deployer's processes. "ScoreMate v3.1 will be invoked in two processes: (i) online consumer loan applications via bankprzykladowy.pl, where the model scores each application in real time and returns one of auto-approve (≥720), auto-decline (<520), or human-review (520–719); (ii) in-branch assisted applications, where a relationship manager enters the data and the same gates apply. All declines and all auto-approvals above PLN 40,000 trigger mandatory human review under Article 14(4)(d) regardless of score."

(b) Period and frequency. "Continuous, 24/7. Expected ~120,000 invocations/year (~330/day). Initial six-month pilot in Mazowieckie voivodeship; full rollout from month seven."

(c) Affected categories. "Loan applicants resident in Poland aged 18–75, with the following sub-groups identified for fundamental-rights monitoring: applicants with thin credit files (≤2 years history), applicants whose primary income source is irregular (gig economy, self-employed), applicants residing in postal codes with median income in the lowest decile, and women on parental leave."

(d) Specific risks of harm. "(i) Disparate impact on thin-file applicants — Article 13 instructions for use document a 9.2pp lower auto-approval rate for thin-file vs. established-file applicants on the provider's validation cohort. (ii) Disparate impact on irregular-income applicants — variance-of-income features in the model are known to disadvantage gig workers (provider TEVV report §4.3). (iii) Risk of digital exclusion — applicants without internet access route to in-branch flow, which has a 2.1× longer human-review queue and may delay urgent loan decisions. (iv) Risk that women on parental leave are scored against historic income features that under-represent the pre-leave earning trajectory. Each risk is evidenced in §4 of the provider's Annex IV file."

(e) Human oversight measures. "Two reviewers per disputed decision, both completed the in-house ScoreMate training (32 hours, certified by ML governance). Override rate is monitored monthly; a >15% override rate triggers re-validation of the model under our Article 9 procedure. Branch reviewers have authority to override auto-decisions of any score; portal applicants in the auto-decline band are routed to a relationship manager within 48h."

(f) Materialisation response. "On detection of disparate impact >5pp on any monitored sub-group: (i) immediate provider escalation under Article 26(5); (ii) within 5 business days, model is paused for the affected sub-group and decisions revert to manual review; (iii) the AI Governance Committee (Compliance Director + Chief Risk Officer + Head of Retail) reviews within 10 business days. Complaint mechanism: a dedicated form at bankprzykladowy.pl/ai-decision and a 14-day response SLA, public-facing."

That FRIA is roughly four pages once typeset. It's not the only kind of FRIA — public-sector deployers will have substantially different (a) and (c) sections. But it's a defensible shape.

How a FRIA differs from a DPIA

Many deployers will produce a single combined document covering both. That works, but the FRIA-specific sections must be clearly labelled as such so the market surveillance authority can locate them on request.

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. Annex A.5.2 demands a process for individuals and groups; the FRIA is its EU AI Act mandated form.
• NIST AI RMF MAP 5.1 — Likelihood and magnitude of each identified impact are characterized based on expected use. A FRIA characterises likelihood and magnitude of fundamental-rights impacts.
• NIST AI RMF MAP 5.2 — Practices and personnel for supporting regular engagement with relevant AI Actors and integrating feedback. FRIA stakeholder consultation is exactly this.

A team that has a working FRIA process is, practically, two-thirds of the way to ISO 42001 Clause 6.1.4 audit defensibility.

Penalties

Article 99(4)(c) sets non-compliance with Article 26 deployer obligations at up to €15 million or 3% of worldwide annual turnover. Article 27 itself is referenced through the deployer-obligation chain — failure to perform a FRIA where required is in scope for the same tier.

For public-sector deployers (most FRIA-required deployers), the more salient cost is reputational and electoral, not financial. A high-profile credit-scoring or welfare-eligibility incident without a FRIA in place is a politically devastating event.

Common mistakes

1. Writing the FRIA as a one-off document. Article 27(2) requires the deployer to update the FRIA when the situation changes (intended purpose, deployment context, affected groups). Treat it as a living document with version control.
2. Confusing FRIA scope with DPIA scope. A DPIA covers data-subject rights. A FRIA covers fundamental rights — non-discrimination, dignity, access to justice, freedom of movement, social security. The Charter of Fundamental Rights is the reference frame.
3. Skipping section (f). "We will deal with risks if they happen" is not a Section (f). Document the named decision-maker, the SLA, the complaint mechanism URL, the escalation path.
4. Burying the FRIA in a contracts folder. Article 27(3) requires you to notify the market surveillance authority of the results. If you can't produce the FRIA on 14 days' notice, you've failed.

Download 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 public-private toggle. Download the FRIA template (Pro tier).

For the long-form pillar with more deployment scenarios, see FRIA explained.

---

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