FRIA: A Complete Guide to the Fundamental Rights Impact Assessment Under the AI Act
A FRIA is mandatory under Article 27 of the AI Act, but only for specific deployers of high-risk AI. Learn who must carry one out, the six required elements, how it complements your DPIA, and how to do one step by step.
If your organisation is preparing to deploy a high-risk AI system, you have probably come across a new obligation with an unfamiliar acronym: the FRIA. It sits alongside the data protection impact assessment you already know, it draws on documents your AI supplier is meant to hand you, and it applies to a surprisingly narrow group of organisations. Getting the scope wrong in either direction, doing one when you needn't or skipping one when you must, is a costly mistake.
A Fundamental Rights Impact Assessment (FRIA) is a pre-deployment obligation under Article 27 of the EU AI Act (Regulation (EU) 2024/1689). There are still very few clear, primary-source explanations of what it actually requires, especially in a European public-sector and financial-services context. This guide is built to be that resource.
Below you will find exactly who has to carry out a FRIA, the six elements the law requires, how a FRIA relates to your GDPR data protection impact assessment, a practical step-by-step method, worked examples for a municipality, a bank and an insurer, and what the Digital Omnibus changes mean for your timeline.
What Is a FRIA?
A FRIA is a structured analysis a deployer carries out before putting a high-risk AI system into use, to identify the specific risks the system poses to people's fundamental rights and to set out what will be done if those risks materialise. It is one of the few obligations in the AI Act that looks beyond the technology itself and asks a harder question: what does this system do to the people on the receiving end of its decisions?
The purpose is set out in Recital 96 of the regulation. The deployer must identify the specific risks to the rights of individuals or groups likely to be affected, and identify the measures to be taken if those risks occur. The assessment has to be done before the system is put into service and updated when the deployer judges that the relevant factors have changed.
The FRIA was not in the European Commission's original 2021 proposal. It was added by the European Parliament in 2023, out of a concern that high-risk AI in the hands of public authorities and essential-service providers could quietly erode rights like non-discrimination, dignity and access to justice unless someone was required to look for that harm in advance.
The AI Act defines "risk" in Article 3(2) as the combination of the probability of harm occurring and the severity of that harm. That severity-times-likelihood logic is exactly what the risk-assessment part of a FRIA has to work through, right by right.
FRIA vs DPIA: The Difference That Trips Everyone Up
The single most common misunderstanding about the FRIA is that it either replaces, or is replaced by, the data protection impact assessment (DPIA) you already run under GDPR Article 35. It does neither.
Article 27(4) is explicit. Where an obligation under the FRIA is already met through a DPIA, the FRIA "shall complement that data protection impact assessment". In plain terms, the FRIA supplements the DPIA. A DPIA on its own does not discharge your FRIA obligation, and a FRIA does not remove your need for a DPIA. They are separate but complementary instruments, and where both apply you can sensibly run them as one integrated exercise, as long as the fundamental-rights scope genuinely reaches beyond data protection.
The reason they cannot collapse into each other is that they cover different ground:
| Aspect | DPIA (GDPR Art. 35) | FRIA (AI Act Art. 27) |
|---|---|---|
| Legal basis | GDPR Article 35 | AI Act Article 27 |
| Focus | Risks arising from processing personal data | Risks to the full range of Charter fundamental rights |
| Rights covered | Primarily data protection (Charter Art. 8) | Non-discrimination, dignity, effective remedy, good administration, and more |
| Who is affected | People whose personal data is processed | Anyone affected, including people whose data is never processed |
| Trigger | High-risk processing of personal data | Deploying certain high-risk AI systems |
| Relationship | Stands alone | Complements the DPIA where they overlap |
A good way to picture it: a DPIA asks whether you are handling people's data lawfully and safely. A FRIA asks whether the system, taken as a whole, treats people fairly. A credit-scoring model can pass a DPIA on data handling and still decline applicants from certain postcodes far above the baseline. That is indirect discrimination the DPIA was never built to catch, and it is precisely what a FRIA is for.
If you already have mature DPIA processes, they are the natural spine to extend into a FRIA rather than starting from a blank page.
Who Must Actually Carry Out a FRIA?
This is where most articles overreach. The FRIA is a narrow, targeted obligation, and most ordinary private companies are not directly caught by it. Article 27(1) only bites when three conditions are met at the same time.
First, the system must be a high-risk AI system under Article 6(2) and Annex III. Second, it must not be an Annex III point 2 critical-infrastructure system, because those are expressly carved out of the FRIA obligation. Third, you must fall into one of the specific deployer categories the article lists.
| Deployer category | Typical examples | FRIA required? |
|---|---|---|
| Bodies governed by public law | Ministries, municipalities, regions, public agencies | Yes, for any in-scope high-risk system |
| Private entities providing public services | Education, healthcare, social services, housing, justice | Yes, for any in-scope high-risk system |
| Deployers of Annex III 5(b) systems | Banks, lenders and fintechs using creditworthiness or credit-scoring AI | Yes, even though private |
| Deployers of Annex III 5(c) systems | Life and health insurers using AI for risk assessment and pricing | Yes, even though private |
| Other private deployers | A company using a high-risk recruitment tool (Annex III point 4) | No FRIA under Art. 27, but full Art. 26 duties still apply |
Two points are worth underlining. The reference to "private entities providing public services" is deliberately broad. Recital 96 links it to public-interest tasks such as education, healthcare, social services, housing and the administration of justice, so a private hospital, a publicly funded school or a social-housing association can be caught. And credit and insurance deployers are pulled in even though they are private, and even where they buy the model off the shelf.
There is also a filter in Article 6(3). An Annex III system is not automatically high-risk if it only performs a narrow procedural task, improves the result of a completed human activity, detects decision patterns without replacing human judgement, or does preparatory work. That filter switches off, though, the moment the system profiles natural persons. A credit-scoring model profiles by design, so it cannot use the filter to escape.
If you are still working out whether the AI Act applies to you at all, start with our guide on who should comply with the AI Act and our explainer on what counts as an AI system. For the full picture of the regulation, see our complete AI Act Guide.
The Six Mandatory Elements of a FRIA
Article 27(1) sets out six minimum elements every FRIA must contain. Until the official template arrives, getting these six right is the whole job. They break naturally into three parts: describing the deployment, assessing the risks, and setting out the mitigations.
| Element | What Article 27(1) requires |
|---|---|
| (a) Processes | A description of the deployer's processes in which the system will be used, in line with its intended purpose |
| (b) Time and frequency | A description of the period of time and the frequency with which the system is intended to be used |
| (c) Affected people | The categories of natural persons and groups likely to be affected in the specific context |
| (d) Specific risks | The specific risks of harm to those people, taking into account the provider's information under Article 13 |
| (e) Human oversight | A description of how human oversight measures are implemented, in line with the instructions for use |
| (f) Mitigation | The measures to take if the risks materialise, including internal governance and complaint mechanisms |
Elements (a) to (c) are the descriptive part. Element (d) is the assessment. Elements (e) and (f) are where you show what you will actually do about the risks you found, including giving affected people a way to complain and be heard.
When Must a FRIA Be Done, and How Often?
The obligation attaches to the first use of the system, so the FRIA has to be completed before you put it into service. For public authorities, the natural moment to start is procurement, well before go-live, so that what you learn can still shape the decision to buy or the terms you buy on.
You do not have to reinvent the wheel every time. Article 27(2) lets you rely, in similar cases, on FRIAs you have already carried out, or on an existing assessment the provider has done. A provider's FRIA is a useful starting point, but it is only that. It cannot capture the risks that are specific to your context, your processes and the people you serve, so treat it as raw material rather than a finished deliverable.
A FRIA is a living document. Where the information in it is no longer up to date, you must take the necessary steps to refresh it. In practice, review it at least once a year and whenever something material changes: a new version of the model, a new group of affected people, a new use case, or an incident that shows a risk has become real.
Notifying the Authority and the AI Office Template
Once the FRIA is done, Article 27(3) requires you to notify the market surveillance authority of the results, submitting a filled-out template as part of that notification. This is a separate channel from anything you do under GDPR. A FRIA notification goes to the AI Act authority, not the data protection regulator, although in Denmark the same body may wear both hats for systems that involve personal data. There is a narrow exemption tied to Article 46(1) for certain exceptional authorisations.
The template itself is where things are still unsettled. Article 27(5) requires the AI Office to develop a template questionnaire, including an automated tool, to make compliance simpler. As things stand, that template has not been published, and there is no hard deadline for it. Its absence does not pause or excuse your obligation. Build your assessment on the six statutory elements now, and remap to the official template once it appears.
How a FRIA Connects to Your Supplier's Documents
A FRIA is not meant to be written in isolation. It plugs directly into the documents the provider of the high-risk system has to give you.
The instructions for use under Article 13 feed element (d), because you have to take the provider's information into account when you assess the risks of harm, and they feed element (e), because the human oversight you describe has to match what those instructions set out. Behind the scenes, the provider's risk management system under Article 9 and the technical documentation under Article 11 and Annex IV supply much of the substance your assessment draws on. If your supplier has not handed these over, you cannot complete a proper FRIA, which makes them a contractual must-have rather than a nice-to-have.
Running in parallel is Article 26, which sets out the deployer's broader duties: use the system according to the instructions, assign competent and trained people to oversight, keep the automatically generated logs for at least six months, monitor operation, suspend and report where a serious risk appears, and inform workers where the system is used in the workplace.
How to Carry Out a FRIA: A Step-by-Step Method
The most developed methodology to date is Danish. The Danish Institute for Human Rights, together with the European Center for Not-for-Profit Law, published A Guide to Fundamental Rights Impact Assessments with an accompanying template. The steps below combine the statutory elements with that model.
Step 1: Classify and Scope
Confirm the system is high-risk, that it is not an Annex III point 2 critical-infrastructure system, and that you are an obligated deployer. Document your reasoning even where you conclude a FRIA is not required, so you have a record of the decision. Assemble a multidisciplinary team and set a budget.
Step 2: Describe the Deployment (elements a and b)
Set out the intended purpose, the processes the system sits inside, the input data, the outputs, the decision it supports or automates, and the period and frequency of use.
Step 3: Map the Affected People (element c)
Identify who is affected, directly and indirectly, in this specific context. Pay particular attention to people in vulnerable situations, such as children, the elderly, minorities and benefit claimants, who may be harmed in ways that are easy to overlook.
Step 4: Assess the Risks to Rights (element d)
For each relevant Charter right, build a realistic typical scenario and a worst-case scenario, then score the severity and the likelihood of harm, taking the provider's Article 13 information into account. Prioritise the most severe impacts. Distinguish absolute rights, where a real risk should stop deployment, from qualified rights, where you assess necessity and proportionality.
Step 5: Define Oversight and Mitigation (elements e and f)
Specify concrete human oversight measures in line with the instructions for use, and set out mitigations in three families: organisational (meaningful oversight, complaint and redress procedures, transparency, AI literacy), technical (cybersecurity, log management, representative input data, bias testing) and contractual (provider duties on data quality, cooperation on updates, explainability). Favour measures that prevent harm over those that merely soften it.
Step 6: Decide, Notify and Report
Reach a reasoned recommendation to deploy or not to deploy, notify the market surveillance authority of the results, and publish an appropriate summary, with restricted handling where law enforcement or migration is involved.
Step 7: Monitor, Review and Consult
Put post-deployment monitoring in place, update the FRIA when relevant factors change, and engage affected groups and their representatives throughout. Consulting the people who will live with the system is both a Recital 96 best practice and a genuine quality check on your own assumptions.
Worked Examples
A Municipality Deploying a Benefits or Fraud-Signal System
A municipality using an AI system to flag possible benefit fraud must carry out a FRIA. The work centres on mapping affected citizens, testing for indirect discrimination through proxies such as postcode or household composition, and documenting that a caseworker substantively reviews every flag before any action is taken. The oversight has to be real, not a rubber stamp. The rights in play include dignity, non-discrimination, social security and assistance, good administration and the right to an effective remedy.
A Bank Using a Third-Party Credit-Scoring Model
A bank deploying a credit-scoring model has to carry out a FRIA even though it is a private company and even if it bought the model from a vendor. The classic failure mode is a system that handles data lawfully yet declines applicants from certain areas at a much higher rate. The central questions are whether the model discriminates indirectly and whether an applicant can understand and challenge the score that shaped the decision.
A Life or Health Insurer Pricing Risk with AI
An insurer using AI for risk assessment and pricing in life or health insurance is squarely in scope. The focus falls on disproportionate impact on low-income or higher-risk individuals and on how transparent the pricing logic is to the people it affects.
FRIA in Denmark: Authorities and National Rules
Denmark was one of the first Member States to legislate for the AI Act. The Act on Supplementary Provisions to the AI Regulation (Law No. 467 of 14 May 2025) came into force on 2 August 2025 and sets up the national enforcement structure.
The Danish Agency for Digital Government (Digitaliseringsstyrelsen) is the notifying authority, a market surveillance authority and the single national point of contact. Datatilsynet, the Danish Data Protection Agency, is a market surveillance authority for biometric and personal-data-related matters and, in practice, for high-risk systems that involve personal data. The Danish Court Administration covers the courts' non-judicial use of AI. The exact split for supervising high-risk systems, and therefore where a FRIA notification should land, is still settling, which is one more reason to treat the AI Act and GDPR as a single, joined-up exercise rather than two separate silos.
Because Danish DPIA practice already requires an assessment for most substantive public-sector AI, most Danish public bodies will find they have a strong foundation to build a FRIA on top of, rather than starting cold.
Penalties for Getting It Wrong
Deployer obligations sit in the middle tier of the AI Act's penalty regime. Under Article 99(4), breaches can attract administrative fines of up to 15 million euro, or up to 3% of total worldwide annual turnover for the preceding financial year, whichever is higher. For small and medium-sized enterprises and start-ups, it is the lower of the two figures that applies.
It is worth correcting a figure that circulates in some articles. The ceiling for deployer obligations is not 30 million euro or 6%. The top tier of 35 million euro or 7% is reserved for the prohibited practices in Article 5, and the lowest tier of 7.5 million euro or 1% applies to supplying incorrect or misleading information. Beyond the fines, an authority can order a system suspended or withdrawn, which is often more disruptive to a business than the fine itself.
What the Digital Omnibus Changes
The timeline around high-risk obligations has been moving. The Digital Omnibus, a simplification package, defers the standalone Annex III high-risk obligations, and the FRIA that tracks them, from the original date of 2 August 2026 to 2 December 2027. The European Parliament endorsed the package in June 2026 and the Council gave its final approval shortly after, with the change taking legal effect on publication in the Official Journal.
Because the date has been in flux, the sensible approach is to build to the obligation rather than to a specific deadline. Use any deferral as runway to produce a rigorous, defensible assessment, not as a reason to pause. Note too that the transparency obligations in Article 50 were not deferred, so parts of the AI Act continue to apply on the original schedule.
FRIA as Part of Ongoing AI Governance
A FRIA works best when it is not a one-off document but an output of a standing AI governance system. Embedding recurring FRIA and DPIA cycles, provider-documentation management and post-deployment review inside a framework such as ISO 42001, the first AI management-system standard, gives you auditability and stops each new system from being handled as a fresh emergency. If you already run governance, risk and compliance processes, the FRIA slots into them rather than sitting apart.
Getting Started
The practical first move is not to write a FRIA. It is to build an inventory of your AI systems and, for each one, work out whether it is high-risk, whether the Article 6(3) filter is even available, and whether you are an obligated deployer. That classification tells you where a FRIA is mandatory and where it is not, and it is the record you will want if an authority ever asks.
Managing FRIAs, DPIAs, provider documentation and ongoing reviews across a portfolio of AI systems is exactly the kind of work a dedicated platform is built for. Our AI Act framework helps you classify systems, run and store assessments, and keep everything audit-ready in one place.
Want to see how it works in practice? Book a demo and we will walk you through it.
Frequently Asked Questions about the FRIA
.png)
.legal compliance platform Run FRIAs and DPIAs Without the Spreadsheet Chaos
-
Classify every AI system and flag where a FRIA is mandatory
-
Run and store FRIAs and DPIAs as one integrated assessment
-
Keep provider documentation and Article 13 instructions linked
-
Track reviews, updates and notifications over time
-
Generate audit-ready reports for supervisory authorities
.jpeg)
.jpg)
.jpg)
.jpg)
-1.png)
.jpeg)
.jpg)
