Skip to main content
Praxikon

FRIA AI Act: what it is, who needs one and how to complete it

···18 min read

A FRIA (Fundamental Rights Impact Assessment) is the assessment that Article 27 of the AI Act requires before certain deployers put a high-risk AI system from Annex III into use. It is mandatory for bodies governed by public law, private entities providing public services, and deployers of AI for creditworthiness or life and health insurance, from 2 December 2027 (Regulation (EU) 2026/1744). If a public body already uses the system before that date, the duty applies only once the system is significantly changed, and by 2 August 2030 at the latest (Article 111(2)).

This page explains what a FRIA is, who must do one, what it must contain and how to complete it step by step. The editable Word file is on the FRIA template download page. Prefer to work online? Use the FRIA generator.

Provision Art. 27(1) AI ActOfficial sources AI Act, Regulation (EU) 2026/1744

What is a FRIA?

A FRIA is a written assessment, made in advance, of what a high-risk AI system can do to the fundamental rights of the people it affects. The Regulation calls it a "fundamental rights impact assessment for high-risk AI systems". The instrument is new and designed specifically for AI.

Four features define a FRIA:

  1. In advance. Article 27(1) requires the assessment before the system is put into use. You may not go live first and assess later. The FRIA must inform the deployment decision, not justify it afterwards.
  2. Broader than privacy. Where a DPIA looks at risks to personal data, a FRIA looks at all fundamental rights in the EU Charter: non-discrimination, human dignity, good administration, access to justice and more.
  3. A deployer duty. The FRIA rests with the organisation that uses the system, not with the provider that builds or sells it. The provider's CE file does not replace the FRIA.
  4. Notified and kept up to date. Once complete, you notify the results to the market surveillance authority (paragraph 3), and you update the FRIA as soon as one of its elements changes (paragraph 2).

Who must conduct a FRIA?

Not every organisation that uses AI. Article 27(1) names exactly three groups of deployers of a high-risk AI system referred to in Article 6(2), that is, a system listed in Annex III:

  1. Bodies governed by public law. Municipalities, provinces, ministries, executive agencies and independent administrative bodies. Think of a tax authority, an employment agency or a municipality using AI in social services. For municipalities specifically, see does a municipality need a FRIA?
  2. Private entities providing public services. Recital 96 refers to tasks in the public interest in areas such as education, healthcare, social services, housing and the administration of justice. A private care provider, a housing association or a private educational institution falls here as soon as it deploys a high-risk AI system from Annex III.
  3. Deployers of two financial use cases, public or private:
    • Annex III, point 5(b): AI to evaluate the creditworthiness of natural persons or establish their credit score. AI used solely to detect financial fraud is expressly excluded;
    • Annex III, point 5(c): AI for risk assessment and pricing in relation to natural persons for life and health insurance.

Banks, lenders and insurers deploying such systems therefore need a FRIA even when they provide no public service.

Two boundaries prevent the most common mistake:

  • Critical infrastructure is excluded. Systems intended for the area in Annex III, point 2 (safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating and electricity) fall outside the FRIA duty. The same organisation can still need a FRIA for another Annex III use.
  • Not every deployer of high-risk AI. A private employer using AI for recruitment (Annex III, point 4) has a high-risk system, but falls under Article 27 only if it is a body governed by public law or provides a public service. The other duties of Article 26 do apply.

From when does the FRIA duty apply?

The FRIA follows the Annex III high-risk rules. Since the Digital Omnibus (Regulation (EU) 2026/1744) those apply from 2 December 2027. For a system you put into use after that date, the FRIA must be complete before go-live.

For systems already in use before 2 December 2027, the transition rule of Article 111(2) applies: the Regulation catches them only once their design is significantly changed. For systems intended for use by public authorities there is a backstop in any case: providers and deployers must comply by 2 August 2030 at the latest. For a municipality whose algorithm has been running for years, 2 December 2027 is therefore not automatically the deadline. A new model or a new purpose can bring the date forward.

Once the FRIA is done, update it as soon as any element from paragraph 1 has changed or is no longer up to date (paragraph 2).

Article 27 paragraph by paragraph

Paragraph 1: the six elements

The assessment consists of six elements. They form the backbone of every FRIA:

(a) Process description: the deployer's processes in which the system will be used in line with its intended purpose. Describe how the system fits into your workflow, not only what it does.

(b) Period and frequency: how long and how often the system will be used. A pilot that runs once a month has a different risk profile from daily use at scale.

(c) Affected persons and groups: the categories of natural persons and groups likely to be affected by its use in the specific context. People affected indirectly count too.

(d) Specific risks of harm to those persons or groups, taking into account the information the provider gives under Article 13. This is the analytical core.

(e) Human oversight: how the human oversight measures are implemented according to the instructions for use. Who reviews, with what knowledge and with what authority?

(f) Measures if risks materialise, including arrangements for internal governance and complaint mechanisms.

Paragraph 2: first use and updates

The duty applies to the first use. In similar cases you may rely on previously conducted FRIAs or on existing impact assessments carried out by the provider. If during use you find that an element has changed or is no longer up to date, you update the information. A FRIA is therefore not a one-off exercise but a living document.

Paragraph 3: notification to the market surveillance authority

After the assessment you notify the market surveillance authority of the results and submit the filled-out template from paragraph 5. In the case referred to in Article 46(1) (an exemption for reasons including public security) you may be exempt from that notification.

Paragraph 4: interaction with the DPIA

If any of the duties is already met through a data protection impact assessment under Article 35 GDPR or Article 27 of Directive (EU) 2016/680, you may cross-refer in the FRIA to the relevant sections of that DPIA or include the relevant parts. Since the Digital Omnibus the cross-reference is written into the text. You do not start over, but you must add the rights that fall outside data protection.

Paragraph 5: the AI Office template

The AI Office develops a template for a questionnaire, including through an automated tool, to help deployers comply in a simplified manner. The template must also allow cross-references to the DPIA. As of 10 October 2026 it had not been published, as far as we could establish. The six elements of paragraph 1 are fixed, so you can start now.

Which fundamental rights do you assess?

Article 27 does not give a fixed list of rights. You assess the rights in the EU Charter of Fundamental Rights that can be affected in your context. The rights that come up most often:

  • Human dignity (Article 1). Systems that reduce people to a score or a profile, such as ranking welfare recipients by fraud probability.
  • Non-discrimination (Article 21) and equality before the law (Article 20). A model trained on historical data can repeat old inequalities. Indirect discrimination through proxy variables, such as postcode or household composition, is harder to spot than direct discrimination and at least as harmful.
  • Privacy and data protection (Articles 7 and 8). This is where the FRIA overlaps with the DPIA (see paragraph 4).
  • Freedom of expression and information (Article 11) and freedom of assembly and association (Article 12). Relevant for systems that filter content or analyse communication patterns.
  • Rights of the child (Article 24). In education, youth care or child protection.
  • Good administration (Article 41) and an effective remedy (Article 47). Crucial for public sector AI: does the citizen get a reasoned decision, and can they challenge the outcome?
  • Property (Article 17), social security and social assistance (Article 34) and healthcare (Article 35). For AI in benefits, housing, insurance and care.

How to complete a FRIA: seven steps

The approach below follows the legal text and matches the FRIA template. It also draws on the work of Mantelero, the guide by ECNL and the Danish Institute for Human Rights, and the European Commission's ALTAI list.

Step 1: team, system and process (element a)

  • Assemble a multidisciplinary team: a lawyer who knows fundamental rights, someone who understands the system technically, a policy adviser who knows the context and, where possible, a representative of the people affected. Recital 96 mentions involving representatives of affected groups, independent experts and civil society organisations, in particular in the public sector.
  • Which AI system are you deploying (name, version, provider) and what is its intended purpose according to the provider?
  • Where does the system enter the process: intake, prioritisation, risk scoring, support for the final decision? Who takes the final decision?
  • Who owns the system internally?

Step 2: period and frequency (element b)

  • When does the system go live, and is there an end date?
  • How often is it used: continuously, per application, periodically?

Step 3: affected persons and groups (element c)

  • Which categories are directly affected (job applicants, patients, benefit recipients, policyholders)? "Residents" or "customers" is too general.
  • Are vulnerable groups involved: children, older people, persons with disabilities, people with low literacy, migrants?
  • Who is affected indirectly, for example because their file systematically ends up lower in the queue?

Step 4: risks per fundamental right (element d)

For each relevant right, assess how likely and how serious the harm is. Use the information from Article 13, but do not stop there: provider information is input, not a substitute for your own analysis of the context.

Be concrete. "Discrimination risk present" is not an analysis. Write instead: "The system was trained on credit applications from 2010 to 2020. In that period, applications from certain postcodes were rejected more often. The system may repeat that pattern. We have asked the provider for a bias analysis and rate the risk of indirect discrimination as medium."

Step 5: human oversight (element e)

  • Who reviews the output, with what knowledge and training?
  • May that person disregard or reverse the outcome, and does that actually happen?
  • Which provider instructions do you follow? See also Article 14 on human oversight.

Step 6: measures, governance and complaints (element f)

  • Which measures do you take per risk: technical (bias testing), organisational (training) and procedural (a complaints route)?
  • Can an affected person object to an AI-supported outcome, and how?
  • Who may pause the system if it turns out badly for a group after go-live?
  • When do you reassess the FRIA?

Step 7: record and notify (paragraphs 2 and 3)

  • Write the report and check that all six elements of paragraph 1 are explicitly addressed.
  • Notify the results to the market surveillance authority, using the AI Office template once it is available.
  • If you are a public authority, also register the use in the EU database (see below).
  • Archive the FRIA and schedule a reassessment.

FRIA, DPIA, ALTAI and IAMA

Many organisations already work with other impact assessments. This is how they relate:

  • DPIA (Article 35 GDPR): required for processing with a high privacy risk, focused on personal data. The FRIA is broader. You may cross-refer to the DPIA or include parts of it (Article 27(4)), and in practice the two are often combined in one document. A detailed comparison with a decision tree is in DPIA and FRIA compared.
  • ALTAI (Assessment List for Trustworthy AI): a voluntary checklist from the European Commission from 2020, based on the 2019 ethics guidelines. Not a legal duty, but useful preparation.
  • IAMA (Impact Assessment for Human Rights and Algorithms): a Dutch instrument for algorithmic decision-making in government. It is rights-oriented and overlaps strongly with the FRIA; organisations already using the IAMA have a head start.

Who does what: DPO, provider, works council and affected people

The data protection officer (DPO) knows impact assessments from DPIA practice, but a FRIA also requires knowledge of non-discrimination law, administrative law and access to justice. Three models are common: the DPO coordinates and a multidisciplinary team does the rights analysis; a separate AI compliance function leads the FRIA with the DPO advising on privacy; or the DPO does the whole FRIA, which requires training beyond privacy.

The provider must give you information under Article 13 (instructions for use and characteristics of the system). Ask for it actively, record what you received and agree contractually that you are informed fully and on time.

Works councils often have co-determination rights when AI monitors or evaluates staff, for example under Article 27(1) of the Dutch Works Councils Act. Involve them early.

Affected people themselves, or their representatives, can show you what you miss from behind a desk. A municipality deploying an enforcement algorithm in a neighbourhood does well to involve residents.

Notification, registration and supervision

  • Notification. After the FRIA you notify the results to the market surveillance authority (Article 27(3)). In the Netherlands, the Dutch Data Protection Authority and the RDI are intended as coordinating supervisors, alongside sector supervisors such as DNB and the AFM. The formal designation follows only with the Dutch AI Regulation Implementation Act, which has not yet been adopted (Government of the Netherlands, 20 April 2026).
  • Registration. Public authorities that use a high-risk AI system from Annex III register themselves and the use in the EU database (Article 49(3)). This includes a summary of the findings of the FRIA (Annex VIII, Section C, point 4). The AI Act does not require you to publish the full FRIA. Publication in a national algorithm register, such as the Dutch one, is an additional national route.
  • Penalties. Article 99(4) sets fines of up to 15 million euros or 3 percent of worldwide annual turnover for, among others, the deployer duties of Article 26. Article 27 is not on that list; penalties for it follow from the national rules member states adopt under paragraph 1. A missing FRIA therefore remains an enforcement risk, and without a FRIA you stand on weak ground if a system causes harm.

Common mistakes

  1. Treating the FRIA as a checkbox. A FRIA filled in by one person in two hours misses the point: it must be able to change the deployment.
  2. Starting too late. You need information from the provider, conversations with affected people and a thorough analysis. That takes weeks, not hours.
  3. Looking only at privacy. Non-discrimination, good administration and access to justice are often missed by privacy teams.
  4. Letting the provider do the work. The provider file is input; the deployer owns the FRIA.
  5. Keeping human oversight vague. If nobody can explain who can override the system, oversight is not in place.
  6. Not updating. Systems get updates, target groups shift. Build a fixed reassessment into your AI governance.

By sector

  • Government and municipalities: benefits, enforcement and the allocation of care or housing directly affect good administration and judicial protection. Worked out in does a municipality need a FRIA?
  • Banks and lenders: always need a FRIA for credit scoring (point 5(b)). Non-discrimination is the largest risk; attach a bias analysis.
  • Insurers: need a FRIA for risk assessment and pricing in life and health insurance (point 5(c)), with attention to chronically ill and other vulnerable policyholders.
  • Healthcare and education: as private entities providing a public service, they need a FRIA for high-risk AI from Annex III, such as AI that determines access to care or education.

Template, generator and help

  • Download the FRIA template: an editable Word file in English and Dutch. Version 2.0 was checked against the law on 6 October 2026 and contains a scope test, the six elements of Article 27(1) with fill-in tables, a risk score, the link with the DPIA and a worked, fictional credit example.
  • FRIA generator: build a FRIA report online, step by step.
  • Case check: submit your case and get a reasoned first view on high-risk status and the FRIA duty, with the source for each conclusion.
  • Want the FRIA carried out or reviewed by an AI and privacy legal adviser? See the signed assessment.

Frequently asked questions about the FRIA

Newsletter

Every Tuesday, the AI Act week ahead in 5 minutes

A practical briefing on deadlines, new guidance and enforcement, so you know what matters this week. No spam and you can unsubscribe in one click.

Practical and short · No spam · One-click unsubscribe