Fundamental rights impact assessment (FRIA)

What is a fundamental rights impact assessment?

A fundamental rights impact assessment, shortened to FRIA nearly everywhere, is a written analysis you make before you put a high-risk AI system into use. It answers one question: what could this system do to the people it decides about, and what will you do about that? The duty sits in Article 27 of the EU AI Act, Regulation (EU) 2024/1689.

The assessment is not about whether the model is accurate or whether the servers are locked down. It is about human dignity, non-discrimination, the right to education, workers' rights and the right to challenge a decision that goes against you. Those are the things a scoring system quietly erodes when it is wrong in the same direction, for the same group of people, month after month.

Not every organisation owes one, and the group that does is a lot narrower than most coverage suggests.

Who has to do one, and who does not

Article 27(1) draws the line in a single sentence. The duty falls on the deployer, the organisation that uses a high-risk AI system under its own authority, in three situations.

• Bodies governed by public law. A municipality, an OCMW, a public hospital, a federal agency, a school run by a public authority.

• Private entities providing public services. Recital 96 describes these as private organisations linked to tasks in the public interest, and it names education, healthcare, social services, housing and the administration of justice. A private hospital or a subsidised school is in. A bakery is not.

• Any deployer of two named Annex III systems. Point 5(b), systems that evaluate the creditworthiness of people or establish a credit score, with fraud detection explicitly carved out. And point 5(c), systems for risk assessment and pricing in life and health insurance. A commercial lender or insurer owes a FRIA without doing anything public at all.

The paragraph also carves out one area. High-risk systems under Annex III point 2, AI used as a safety component in critical infrastructure such as road traffic or the supply of water, gas, heating and electricity, fall outside the FRIA duty even when a public body deploys them.

Add that up and most private companies are out. Take a Belgian SME that buys an AI tool to screen job applications. The system is high-risk, it sits in Annex III point 4 on employment, and the deployer duties in Article 26 apply in full, from named people doing the oversight to keeping the logs. Article 27 does not apply. The company is not a public body, it provides no public service, and CV screening is neither 5(b) nor 5(c). Anyone telling that company to file a FRIA is reading the article wrong.

What Article 27 asks you to write down

Six things have to be in the assessment, and they are more concrete than the phrase fundamental rights makes them sound.

1. The processes the system will be used in
   Your own processes, where the system runs in line with its intended purpose. Not what the vendor says the product does, what you do with it.

2. The period and the frequency of use
   A tool that runs on every file every day carries a different risk from one you switch on twice a year.

3. The people it touches
   The categories of natural persons and groups likely to be affected in your specific context.

4. The specific risks of harm
   Not risk in the abstract, but the harms likely to land on the groups you just named, using the information the provider gave you.

5. How human oversight is actually carried out
   How you implement the oversight measures, following the instructions for use. Here Article 27 leans on Article 26 and on Article 14.

6. What happens when a risk materialises
   The measures you take when it goes wrong, including internal governance arrangements and complaint mechanisms. Somebody has to be able to complain, and somebody has to answer them.

Recital 96 adds a suggestion rather than a duty: you may involve the people likely to be affected, independent experts and civil society organisations. For a public body running a system on its own residents, that involvement is usually what makes the answers worth reading.

FRIA versus DPIA

These two get treated as the same exercise with a different cover page. What separates them is what each one protects.

A DPIA under GDPR Article 35 protects personal data. It starts from a processing operation, asks whether the data is necessary and proportionate for the purpose, and works out what could go wrong for the people in the dataset. Its unit of analysis is the processing. A FRIA protects rights, and only some of those rights are about data: non-discrimination, dignity, the right to education, workers' rights, access to an effective remedy. A system can respect every line of GDPR and still push the same group of applicants to the bottom of the list every time. Its unit of analysis is the system inside your process.

Article 27(4) says how the two fit together. Where you have already met part of these obligations through a DPIA under GDPR Article 35, or under Article 27 of the law enforcement directive, the FRIA complements that assessment instead of replacing it, and you may cross-reference the relevant sections rather than copy them across. So the answer to "do we need both" is yes, and the second one is a lot shorter when the first was done properly.

What a workable FRIA looks like

No official form exists yet, so what follows is the shape the six elements naturally take. Five sections, each of which somebody already in your organisation can write.

1. The system and the decision. One page: what the system does, which decision it feeds, who signs that decision off, what happens to the output afterwards. Name the provider and the version.

2. The people. Who is on the receiving end, and which of them stand in a weaker position: applicants who do not speak Dutch at home, tenants, minors, people with a disability, temporary staff.

3. The risks, named one at a time. Not "risk of bias", but "applicants with an address outside the province are ranked lower, because location correlates with the historical hiring data the model learned from". A risk written that way is one you can test and one you can fix.

4. The oversight, with names in it. Who reviews what, at which moment, with what authority to overrule the system. Article 26(2) already asks for named people with the competence and the authority, so this section copies a decision you made earlier.

5. The route when it goes wrong. Who a person complains to, what happens to that complaint, who can switch the system off, and what you do with the affected files meanwhile. Article 85 gives anyone the right to complain to a market surveillance authority, which is a poor first stop if there is no internal one.

Five pages that name three concrete risks with an owner each beat forty pages of restated legal text.

When it starts, and what you file

The obligation attaches to the first use of the system. In similar cases you may rely on an assessment you carried out earlier, or on one the provider carried out. If any of the six elements changes during use, or stops being up to date, you update it. A new group of people in scope, a new model version, a rollout to three more branches: all triggers.

Once it is done, Article 27(3) tells you to notify the market surveillance authority of the results and to submit the filled-out template with that notification. The one exemption is the narrow case in Article 46(1), where an authority has authorised a specific system for exceptional reasons of public security or the protection of life and health.

Article 27(5) instructs the AI Office to develop a template questionnaire, including an automated tool. That template has not been published, which is neither an excuse nor a reason to wait. The European Center for Not-for-Profit Law and the Danish Institute for Human Rights published a guide with a questionnaire template in December 2025, built on the Article 27(1) elements, and it is the most usable interim document.

On timing, the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, moved the stand-alone high-risk obligations from 2 August 2026 to 2 December 2027, and Article 27 moved with them. High-risk AI built into regulated products under Annex I follows on 2 August 2028. Nothing in the article was rewritten, only the date it bites.

The short version for a company that owes nothing

Plenty of the companies we work with read the scope test, find themselves outside it, and stop. That is a fair compliance answer. There is still a case for writing two pages, and the trigger is not the law but the shape of the system. If a model sorts people, staff or customers, and the sorting is hard to see from the outside, the questions in Article 27 are the ones you will be asked anyway. A candidate asks why she was rejected. A works council asks what the scheduling tool optimises for. In neither room does "we are not in scope" answer the question.

Two pages does it: which people the system touches, the two or three ways it could treat one group worse, who checks that and how often, and what you do when somebody objects. And the day your system does move into Annex III, because you start pricing insurance or because you win a public contract, you are updating a document rather than starting one.