EU AI Act Article 27 FRIA: how to run a fundamental rights impact assessment

Article 27 of the EU AI Act requires certain deployers of high-risk AI systems to run a fundamental rights impact assessment (FRIA) before deployment. The population in scope is narrower than most read it: public-sector bodies, private entities providing public services, and deployers of credit-scoring or life and health insurance AI. This guide covers the six things a FRIA must cover, how it relates to a GDPR DPIA, the notification step to the national market surveillance authority, and how to scope your first FRIA without over-engineering it. Annex III high-risk obligations apply from 2 December 2027 under the post-Omnibus timeline.

What a FRIA actually is

A FRIA, a fundamental rights impact assessment, is a structured document a deployer of certain high-risk AI systems must produce before putting the system into use. Its purpose is to identify the natural persons or groups likely to be affected by the deployment, the specific risks of harm the deployment creates, and the measures the deployer has in place to mitigate those risks and to act when they materialise. Article 27 of Regulation (EU) 2024/1689 sets out the requirement.

The FRIA is a deployer-side document. It runs in parallel to the provider-side conformity assessment under Article 43. Where the conformity assessment looks at the AI system in the abstract (does the model meet the technical requirements of Article 8 to 15), the FRIA looks at the deployment in context: who uses it, on whom, with what oversight, against what specific harms.

Who actually must do a FRIA

This is the most misread provision in Article 27. The default assumption is that every deployer of every high-risk AI system must do a FRIA. The actual scope is narrower.

Article 27(1) requires a FRIA only from two specific categories of deployer:

That said: even if Article 27 does not legally bind you, running a FRIA-pattern document is generally good practice for any high-risk AI deployment. The discipline of writing down who's affected, what risks exist, and what oversight is in place is sound regardless of regulation. Many large enterprises produce FRIA-style documents voluntarily because it's the cheapest evidence of due diligence in the event of an incident.

When the FRIA must be done

Before the high-risk AI system is put into use. Article 27(1) is explicit: deployers shall perform an assessment prior to deploying a high-risk AI system. A FRIA done after deployment does not satisfy the obligation.

The FRIA is also not a one-and-done. Article 27(2) requires the deployer to update the FRIA when material elements change: new affected populations, new use cases, substantial modifications to the AI system, new categories of personal data processed, new findings from post-market monitoring. The frequency of updates depends on the context; a rapidly-evolving credit-scoring model may need quarterly FRIA refreshes, a stable public-service deployment annually.

The six things every FRIA must cover

Article 27(1) sets out six required elements. A FRIA missing any of them is not compliant.

(a) Description of processes where the system is used

The deployer's processes in which the high-risk AI system will be used in line with its intended purpose. In practical terms, this is the business-process narrative: what work is the AI augmenting or automating, who interacts with it, where does its output flow next, what decisions does it inform.

(b) Time period + frequency of use

How long the system is intended to be used (a one-off project, a permanent deployment, a multi-year contract), and how often it produces output (real-time, batch, on-demand). This sets the scale of the FRIA's other findings: an AI that runs once per quarter against 1,000 cases is very different in fundamental-rights exposure from an AI that runs in real-time on every customer interaction.

(c) Categories of natural persons + groups affected

This is the heart of the assessment. The deployer must identify the natural persons and groups likely to be affected by the system's use in the specific context. Direct subjects (the persons the AI makes or influences decisions about) are obvious. Less obvious but equally required: indirect subjects (people whose data is in the training set without being subjects of the live deployment), bystander groups (people the system observes but doesn't decide about), and vulnerable subgroups (minors, persons with disabilities, ethnic minorities, persons with low digital literacy).

(d) Specific risks of harm

For each category of affected person, what are the specific harms the AI deployment could cause? Take the information given by the provider under Article 13 (the instructions for use) as input, but go beyond it. A credit-scoring AI's specific risks include: discriminatory denial of credit, mispricing, loss of autonomy in financial decisions, downstream effects on housing or employment access for declined applicants. Each risk needs to be articulated, not bundled.

(e) Human oversight measures

What human oversight is in place, who provides it, what competence + training do they have, what authority do they have to intervene or override the system. This must align with the human-oversight obligations under Article 26(2). The FRIA is where the deployer documents that the human-oversight design is more than a checkbox.

(f) Measures if risks materialise

What governance structure handles incidents, what complaint mechanisms are open to affected persons, what corrective actions are pre-planned, who is responsible for triggering them, what timelines apply. This is where the FRIA connects to Article 73 incident reporting and Article 26(5) deployer-to-provider notification. Our AI incident response guide walks the reporting clocks (2 / 10 / 15 days from awareness).

FRIA versus GDPR DPIA: similar, not identical

A FRIA looks like a DPIA, and Article 27(4) explicitly allows them to integrate. But they are not the same document.

A GDPR DPIA (data protection impact assessment) under Article 35 GDPR focuses on risks to data subjects' rights and freedoms arising from the processing of personal data. It covers lawful basis, data minimisation, transfer mechanisms, security measures, consent and rights handling.

A FRIA under EU AI Act Article 27 focuses on risks to fundamental rights arising from the deployment of a high-risk AI system, regardless of whether personal data is involved. Its scope is broader: discrimination risks, fair-trial impacts, dignity, freedom of expression, non-personal-data effects all fit. A FRIA on a credit-scoring AI might find a personal-data risk (DPIA territory) and also a fundamental-rights-of-the-decision risk like discriminatory denial (FRIA-only territory).

Article 27(4) is the bridge: where a high-risk AI system processes personal data, the FRIA and the DPIA can be integrated into one document, but the FRIA's additional fundamental-rights dimensions must still be covered. Practically: bring your existing DPIA into the FRIA as the personal-data section, then add separate sections for the additional FRIA-required elements (categories of affected persons including non-data-subjects, specific non-data risks, human oversight design, incident response).

Notifying the market surveillance authority

Article 27(3) requires the deployer, once the FRIA is complete, to notify the national market surveillance authority of the results. The notification is not a fishing expedition; it is a structured submission using the template questionnaire the AI Office is developing under Article 27(5).

In practical terms:

The AI Office template (in development)

Article 27(5) empowers the AI Office to develop a template questionnaire, including through an automated tool, to facilitate FRIA completion. As of mid-2026 the template is still in consultation; the AI Office has indicated it will be published before the Annex III high-risk deadline of 2 December 2027.

Until the template lands, deployers should structure their FRIA around the six required elements in Article 27(1)(a) to (f) and be ready to migrate the format when the template is published. Several large public bodies (EU institutions, national administrations) have already published FRIA-pattern templates that are reasonable interim starting points. The AI Office's expected template is likely to be longer and more structured than these voluntary ones; design your internal FRIA process to be migration-ready rather than format-locked.

A practical FRIA process

For a first-time FRIA on a deployment, the workflow typically looks like this. Budget 4 to 8 weeks for the first one; subsequent FRIAs against the same template are much faster.

Week 1: Scoping + provider information

Confirm whether Article 27 applies to your deployment (public-body status, public-service status, or Annex III(5)(b)/(c) credit/insurance use case). Request the Article 13 instructions for use from the provider plus the Article 53(b) downstream-provider information pack if the model is a GPAI. Gather your existing DPIA if one exists. Identify the cross-functional FRIA team: product owner, compliance lead, data protection officer, legal counsel, optionally a fundamental-rights advisor.

Week 2 to 3: Affected persons + risks

Run structured workshops to identify (c) categories of affected persons and groups and (d) specific risks of harm. Use the provider's intended-purpose statement as input but explicitly look for use-case-specific risks the provider could not have anticipated. Cover vulnerable subgroups separately; over half of FRIA-finding deficiencies cluster around inadequate attention to vulnerable populations.

Week 4 to 5: Oversight + materialisation

Document (e) human oversight design (who oversees, what competence, what authority to intervene, what training) and (f) materialisation measures (governance, complaints, corrective actions, escalation paths). Connect to your incident response runbook.

Week 6: Review + sign-off

Internal legal review. DPO sign-off where personal data is involved. Senior accountable officer sign-off (the deployer's accountable executive, typically the head of the business unit, not the IT lead). Lock the FRIA, version it, store it in the AI inventory.

Week 7: Authority notification

Submit the FRIA + supporting documentation to the national market surveillance authority per Article 27(3). Build a calendar reminder to update on material changes; quarterly is a reasonable default for actively-evolving deployments.

Penalties for missing or inadequate FRIA

Failure to conduct a FRIA when required falls under Article 99 Tier 2: up to EUR 15 million or 3% of global annual turnover, whichever is higher. Article 27 sits within the Article 8 to 49 high-risk obligation block that Article 99(4) penalises at the Tier 2 ceiling. Article 99(7) mitigating + aggravating factors apply: nature and gravity of the violation, intent versus negligence, mitigation actions, cooperation, prior infringements, size of the undertaking.

Beyond the administrative fine, missing or inadequate FRIA creates significant civil liability exposure under the AI Liability Directive: affected persons can claim that the absence of a FRIA shows a presumption of fault. Article 27 is also typically the first document a market surveillance authority will request when investigating a complaint about a high-risk system; not having it makes everything else harder. Our Fine Calculator runs the Article 99 math for your turnover.

Tools that connect to the FRIA

Free tools we built that intersect with Article 27.

Sources

• Article 27 on EUR-Lex
• Article 26 deployer obligations on EUR-Lex
• Annex III high-risk categories on EUR-Lex
• GDPR Article 35 DPIA on EUR-Lex
• Commission AI Act Service Desk on Article 27
• Regulation (EU) 2024/1689 (consolidated) on EUR-Lex

Frequently asked questions