EU AI Act Article 27: Who Must Run a Fundamental Rights Impact Assessment (FRIA), What It Contains, and How It Fits With Your DPIA
EU AI Act Article 27: Who Must Run a Fundamental Rights Impact Assessment, and What It Contains
Most EU AI Act guidance is written for providers. Article 27 is different: it lands on deployers, the organisations that use a high-risk AI system someone else built. It requires a fundamental rights impact assessment (FRIA) before the system is used for the first time. If you are a public body, a private firm delivering a public service, a lender or an insurer, this is probably the most concrete deployer task on your list.
Who has to do a FRIA
Article 27 does not apply to every deployer of high-risk AI. It covers deployers of high-risk systems under Article 6(2) that are bodies governed by public law, private entities providing public services, or deployers of the systems in Annex III points 5(b) and 5(c)[1], meaning creditworthiness and credit scoring, and risk assessment and pricing for life and health insurance. Systems in Annex III point 2 (critical infrastructure) are excluded[1].
In practice that brings in hospitals, universities, municipalities, social-security agencies, banks, consumer lenders and life or health insurers. A private company using a CV-screening tool is not caught by Article 27 on that basis alone, although it still has the Article 26 deployer duties (see our guide to every Article 26 obligation).
The FRIA is a deployer duty. A provider's conformity work does not discharge it, although the provider's instructions for use are a required input.
The six things a FRIA must cover
The assessment must describe, at a minimum[1]:
- Processes: the deployer's processes in which the system will be used, in line with its intended purpose.
- Duration and frequency: how long and how often the system will be used.
- Affected people: the categories of natural persons and groups likely to be affected.
- Specific risks of harm: risks to those groups, using the information the provider supplied.
- Human oversight: the oversight measures, based on the instructions for use.
- Mitigation and redress: what happens if the risks materialise, including internal governance and complaint mechanisms.
Document the process the system supports, who operates it, and the decisions it informs. Start from the provider's intended purpose and note any local deviation.
List the people who will be scored, ranked or decided about, including indirect groups such as dependants or applicants who are rejected.
Walk through the Charter rights most likely to be touched: non-discrimination, privacy and data protection, access to services, effective remedy.
Confirm who can override the system, what training they have, and how an affected person can complain or get a human review.
Record mitigations and residual risk, then notify the market surveillance authority using the AI Office questionnaire.
FRIA and DPIA: complementary, not interchangeable
Many deployers already run GDPR Article 35 data protection impact assessments. Article 27 lets you lean on them: if the obligations are already met through a DPIA, the deployer may cross-reference it or include relevant parts, and the FRIA then complements the existing DPIA rather than replacing it[1][2].
| FRIA (AI Act Art. 27) | DPIA (GDPR Art. 35) | |
|---|---|---|
| Scope of harm | Fundamental rights broadly | Risks to personal data and related rights |
| Trigger | Specific deployers of listed high-risk AI | Processing likely to result in high risk |
| Who does it | Deployer | Controller |
| Authority notification | Results go to the market surveillance authority | Prior consultation only if risk remains high |
| Reuse | Earlier FRIAs and provider assessments for similar cases | Existing DPIAs for similar processing |
A sensible design is one combined assessment with a clearly labelled rights section, so evidence is written once and both regimes can read it.
Notification and the AI Office template
After the assessment, the deployer must notify the market surveillance authority of the results using a questionnaire template that the AI Office is required to develop, which may take the form of an automated tool[1]. The template is also meant to allow DPIA cross-references. Watch for it: until it is published, treat any third-party FRIA template as a drafting aid rather than the format authorities will expect. [3] is a useful overview of how the Act and the Digital Omnibus fit together.
When does this apply?
Under the Digital Omnibus (Regulation (EU) 2026/1744) the Annex III high-risk obligations apply from 2 December 2027, and those for Annex I systems from 2 August 2028[1][3]. A FRIA is due before first use, so any system you plan to go live with after that date needs one in place. Because assessments take time and depend on provider documentation, deployers buying systems now should write the FRIA inputs into contracts today.
A practical action plan
- Inventory systems that fall under Annex III 5(b), 5(c) or the public-service categories and identify the owner of each.
- Ask vendors for instructions for use, performance data across groups and known limits. These feed items 4 and 5 above.
- Reuse your DPIA structure and add a rights-impact section.
- Define the complaint and human-review route before launch, not after the first complaint.
- Assign someone to track the AI Office template and your national authority's notification process.
Does a private employer using a recruitment AI need a FRIA?
Not under Article 27 on that basis alone. Article 27 targets public-law bodies, private entities providing public services, and deployers of credit-scoring and life or health insurance systems. Other Article 26 duties still apply.
Can we reuse a FRIA across several deployments?
For a first use you may rely on earlier FRIAs or provider impact assessments for similar cases, but you must update the assessment when relevant elements change or become outdated.
Is the FRIA the same as a DPIA?
No. A DPIA can be cross-referenced and included, but the FRIA covers fundamental rights more broadly and complements the DPIA rather than replacing it.
Who receives the results?
The market surveillance authority, using the AI Office questionnaire template once available.
When must it be done?
Before the high-risk system is first used. For Annex III systems the application date is now 2 December 2027.
This article is general information, not legal advice.
Sources: Article 27, AI Act; Freshfields, EU AI Act Unpacked: FRIA; ActuIA, obligations in force and delays under Omnibus 2026/1744.
Related reading
Article 14 EU AI Act: Engineering Human Oversight That Actually Works
Article 14 is a design obligation, not an HR policy. Here's how to engineer the five oversight capabilities, split provider vs deployer duties, handle the biometric two-person rule, and build an audit-ready evidence trail.
EU AI Act Article 13: What Your Instructions for Use Must Contain, and What Deployers Should Demand From Vendors
Article 13 turns the instructions for use into the contract between a high-risk AI provider and its deployers. Here is what Article 13(3) requires, the evidence deployers should ask for, and where harmonised standards stand after 14 October 2026.
GPAI Models With Systemic Risk: The Safety and Security Chapter of the Code of Practice, Explained
Providers of the most capable general-purpose AI models carry extra duties. Here is what the Safety and Security chapter of the GPAI Code of Practice asks for, the incident timelines, and the dates that matter now the AI Office can enforce.