A Fundamental Rights Impact Assessment gets described as a cousin of the GDPR’s Data Protection Impact Assessment, but the two ask different questions. A DPIA looks at what data is being processed and whether that processing is lawful. A FRIA looks at how a system’s use affects people once it’s running: whether it treats them fairly, whether it creates disadvantage for particular groups, whether someone who disagrees with an outcome has a real way to challenge it.
Most of Chapter III deals with technical requirements: documentation, logging, risk classification. Article 27 asks a deployer to reason about the actual context of use rather than the system’s specifications.
Who has to do a FRIA
Three categories of deployer are in scope, and only for high-risk systems under Annex III (Annex I systems sit outside this article, as does the critical-infrastructure category in Annex III point 2):
- Bodies governed by public law.
- Private entities providing public services.
- Any deployer, public or private, using AI for creditworthiness evaluation or credit scoring (excluding fraud detection), or for risk assessment and pricing in life and health insurance.
That third category pulls commercial banks and insurers into scope directly. Whether the deployer is a public body doesn’t matter here. A private insurer pricing health cover with an AI system is caught the same way a municipal benefits system would be. For pension providers, the trigger depends on whether the specific use case falls under credit scoring or insurance pricing as defined in Annex III point 5, rather than pension administration generally. Check that against your own Annex III classification rather than assuming the sector is covered wholesale.
Six things the assessment has to cover
Article 27(1) lists six required elements.
| Element | What it requires |
|---|---|
| (a) Process description | How the deployer’s own processes will use the system, consistent with its intended purpose as the provider specified it |
| (b) Time and frequency | The period and frequency of use for each system |
| (c) Affected persons | The categories of people or groups likely to be affected in that specific context |
| (d) Specific risks of harm | Risks to those people’s fundamental rights, factoring in what the provider disclosed under Article 13 |
| (e) Human oversight | How oversight measures will be implemented, per the provider’s instructions for use |
| (f) Mitigation and governance | What happens if a risk materialises: internal governance and a complaint mechanism |
Element (d) ties the deployer’s assessment to whatever the provider disclosed in its technical documentation and transparency information. A deployer can’t do this work in isolation from what the provider hands over.
Fine exposure explained
A fair amount of current commentary states flatly that failing to conduct a FRIA carries a €15 million or 3%-of-turnover fine. Checking that claim against Article 99(4) directly shows that that paragraph lists a specific, closed set of provisions, Article 16 (provider obligations), Article 22 (authorised representatives), Article 23 (importers), Article 24 (distributors), Article 25(2) and (4), Article 26 (deployer obligations), Articles 31/33/34 (notified bodies), and Article 50 (transparency). Article 27 is not on that list.
That doesn’t mean skipping a FRIA is risk-free. Article 99(1) still requires Member States to set penalties for any infringement of the Regulation, named tier or not, and those penalties have to be effective, proportionate, and dissuasive. In practice, a missing or superficial FRIA is also the kind of gap that surfaces during an investigation into something else entirely, a discrimination complaint, an Article 26 deployer-obligation review, a market surveillance audit. The absence of a named tier changes the legal mechanism, not the practical exposure.
Building the assessment in practice
The Act doesn’t prescribe a methodology. Most teams asked to produce a FRIA for the first time don’t know where to start. A workable approach treats elements (c) and (d) together as the analytical core: a matrix with the affected groups identified in (c) on one axis and the categories of fundamental rights at stake (non-discrimination, privacy, access to remedy) on the other, scored for likelihood and severity. That matrix is what makes elements (e) and (f) concrete. Oversight measures and mitigation steps should map onto the highest-severity cells, not read as boilerplate attached at the end.
A FRIA written entirely by legal or compliance tends to miss what the business line and the model-owning team already know about edge cases and failure modes. The Act encourages, where appropriate, involving affected groups, independent experts, or civil society organisations in the assessment. Not a requirement, but a strong signal about what a credible FRIA looks like compared with a templated one.
No official template exists yet. Article 27(5) requires the AI Office to publish a standard questionnaire, including an automated tool, but as of the most recent guidance available, that template hasn’t been released. In the meantime, the ECNL and the Danish Institute for Human Rights published a practitioner guide to Fundamental Rights Impact Assessments in December 2025 that offers a reasonable interim structure alongside the six statutory elements.
A worked example: Credit scoring
Take a bank deploying an AI system to score loan applications. Element (a) describes how the model sits in the underwriting workflow. Element (b) sets out that it runs continuously on every incoming application. Element (c) identifies applicants as the affected group, potentially disaggregated by postal code, age, or income bracket if the model’s inputs correlate with those factors. Element (d) is where the real work happens: does the model’s output distribution show disparate rejection rates across those subgroups, and does the provider’s Article 13 documentation disclose known limitations that bear on that risk? Element (e) describes the human reviewer’s role and authority to override a decision. Element (f) sets out what happens if a pattern of disparate outcomes is detected: internal escalation, a review of the affected decisions, a channel for a declined applicant to challenge the outcome.
A model can pass every technical check, have current documentation, and still produce a discriminatory pattern that only shows up once it’s been running against production data for months. That’s the gap a FRIA is meant to catch before deployment, and the one post-market monitoring is meant to catch after.
It attaches to first use, then has to be kept current
The obligation applies at first use of a given system. For similar cases, the deployer can rely on a FRIA already conducted, or on an assessment the provider carried out. If anything in the six elements changes or goes stale during use, the deployer has to update it, which means the matrix above needs a review cadence rather than a one-time sign-off.
Once complete, the deployer notifies the market surveillance authority using the template the AI Office is required to build under Article 27(5). Deployers using the Article 46(1) sandbox derogation are exempt from that notification. Which authority that is depends on the Member State. In the Netherlands, that split of responsibility across sectoral regulators is worth checking before assuming a single point of contact.
Reusing DPIA work
Article 27(4) lets a deployer avoid rebuilding what already exists. Where a GDPR Article 35 DPIA covers some of the same ground, the FRIA can cross-reference or incorporate the relevant sections directly, as long as it complements rather than replaces the DPIA. For a bank or insurer already running DPIAs on the same credit or pricing systems, that’s the sensible starting point. Map what the DPIA already covers, then build the FRIA around what it doesn’t: the fundamental-rights angle a DPIA was never built to catch.
FRIA compliance checklist
- Confirmed the deployer falls into one of the three in-scope categories, and the system is classified under Annex III rather than Annex I
- Affected-groups and fundamental-rights matrix built, covering elements (c) and (d) together
- Provider’s Article 13 disclosures reviewed and factored into the risk assessment under element (d)
- Human oversight measures under element (e) mapped directly to the highest-severity cells in the matrix, not written as generic boilerplate
- Mitigation plan and complaint mechanism under element (f) tested for whether a declined or affected person could actually use it
- Cross-referenced against any existing GDPR Article 35 DPIA for the same system, to avoid duplicating work
- Review cadence set for updating the FRIA if any of the six elements changes or goes stale
- Confirmed which national market surveillance authority the completed assessment will be notified to
- Timeline checked against the corrected dates: 2 December 2027 for Annex III systems, 2 August 2028 for Annex I systems
Frequently asked questions
No. It can reference or reuse relevant DPIA content where the two overlap, but it has to complement the DPIA rather than substitute for it.
No. Only public bodies, private entities providing public services, and deployers using AI for credit scoring or life and health insurance pricing, and only for Annex III systems outside the critical-infrastructure exemption.
Article 27 isn't named in the Article 99(4) fine tier, unlike Article 26 or Article 50. Member States still have to set general penalties under Article 99(1), and a missing FRIA can still surface as a serious finding in an investigation triggered by another provision.
Not yet. The AI Office has to publish one under Article 27(5), but it hadn't been released as of the most recent available guidance. The ECNL/DIHR practitioner guide is a reasonable interim reference.
The relevant national market surveillance authority, notified through the AI Office's standard template once it exists.
