Join our Newsletter — 33% off our NHI Course
Home› Guides› EU AI Act Fundamental Rights Impact Assessment: Who…
Guide AI Regulation & Law

EU AI Act Fundamental Rights Impact Assessment: Who Must Do One and How

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 8 November 2026 13 min read
On this page

Article 27 of the EU AI Act requires certain deployers of high-risk AI systems to assess the impact on fundamental rights before they first use the system, and to notify the results to the market surveillance authority. The duty is narrower than many summaries suggest: it applies to public bodies, private entities providing public services, and deployers of credit scoring and life or health insurance pricing systems, not to every high-risk deployment. It is also more specific than a generic AI impact assessment, with six required elements and a notification step. This guide sets out who must carry out a fundamental rights impact assessment (FRIA), what it must contain, how it relates to the GDPR data protection impact assessment, the dates after the Digital Omnibus on AI, and how to run one. It is for compliance, legal, risk and AI governance teams; the broader method for assessing AI impacts is in the ISO/IEC 42005 AI System Impact Assessment Guide.

Key takeaways

  • Only some deployers must do one: bodies governed by public law, private entities providing public services, and deployers of Annex III point 5(b) credit scoring and 5(c) life and health insurance pricing systems, for high-risk systems under Article 6(2) other than critical infrastructure.
  • Six elements are mandatory: the deployer's processes, period and frequency of use, affected groups, specific risks of harm, human oversight measures, and measures if risks materialise, including governance and complaint routes.
  • It is notified, not filed away: the deployer must notify the market surveillance authority of the results using the AI Office template, unless the Article 46(1) exceptional authorisation case applies.
  • Reuse the DPIA, do not duplicate it: as amended by the Digital Omnibus, Article 27(4) lets deployers cross-reference or include parts of a GDPR Article 35 data protection impact assessment.
  • The date moved: Chapter III Sections 1 to 3, which include Article 27, now apply to Annex III systems from 2 December 2027 under Article 113 as amended, so there is time to build the process properly.

Scope: who and what is covered

Article 27(1) sets three tests: the system must be a high-risk AI system under Article 6(2) (the Annex III use cases), it must not be in the Annex III point 2 critical infrastructure area, and the deployer must be in one of three categories. Providers do not carry this duty in their role as provider; they supply the information deployers need under Article 13.

Deployer categoryWhich Annex III systemsExamplesNotes
Bodies governed by public lawAny Article 6(2) high-risk system except point 2Benefits eligibility scoring, school admissions, public employment services, migration case triage, police risk toolsIncludes local and regional authorities and public agencies
Private entities providing public servicesAny Article 6(2) high-risk system except point 2Private operators of outsourced public services such as healthcare, education or social housing allocationWhether a service is a "public service" may need legal analysis under national law
Deployers of Annex III point 5(b) systemsCreditworthiness evaluation or credit scoring of natural personsBanks, lenders, buy-now-pay-later providers using AI scoringSystems used for detecting financial fraud are excluded from 5(b)
Deployers of Annex III point 5(c) systemsRisk assessment and pricing for natural persons in life and health insuranceInsurers using AI underwriting or pricing modelsOther insurance lines are not in 5(c)
  • Not in scope: Annex I product systems (AI that is a safety component of regulated products), Annex III point 2 critical infrastructure systems, private deployers outside the categories above (for example a retailer using an Annex III point 4 recruitment tool), and systems that are not high-risk. Those deployers still have Article 26 duties.
  • Check classification first: the FRIA question only arises once a system is confirmed as high-risk. See the EU AI Act High-Risk AI Systems Guide.
  • Check your role: rebranding, substantially modifying or repurposing a system can make a deployer a provider. See the EU AI Act Provider vs Deployer Obligations Guide.

Key obligations

What the assessment must contain

Article 27(1) elementWhat to documentEvidence sources
(a) ProcessesThe deployer's processes in which the system will be used in line with its intended purposeProcess maps, decision flows, where the AI output enters a human or automated decision
(b) Period and frequencyHow long and how often the system is intended to be usedDeployment plan, volumes, pilot and production phases
(c) Affected persons and groupsCategories of natural persons and groups likely to be affected in the specific contextPopulation data, vulnerable groups, protected characteristics present in the population
(d) Specific risks of harmRisks of harm likely to affect those categories, taking into account the provider's Article 13 informationInstructions for use, accuracy and bias metrics, known limitations, data protection impact assessment
(e) Human oversightHow the oversight measures in the instructions for use will be implementedNamed oversight roles, competence and authority (Article 26(2)), override and escalation procedures
(f) Measures if risks materialiseMeasures to take if risks materialise, including internal governance and complaint mechanismsIncident procedure, suspension criteria, complaint and redress routes, link to Article 26(5) reporting

When, how often and who is told

  • Before first use: the obligation applies to the first use of the system (Article 27(2)). Do it before production, not after the pilot has become the service.
  • Reuse in similar cases: a deployer may rely on previously conducted FRIAs or on existing impact assessments carried out by the provider in similar cases, but must check that they fit its context.
  • Keep it current: if any element changes or is no longer up to date during use, the deployer must take the necessary steps to update the information. New population, new purpose, new model version or new decision process are typical triggers.
  • Notify: after the assessment, notify the market surveillance authority of the results, submitting the filled-out template referred to in Article 27(5). The Article 46(1) case, where an authority has exceptionally authorised a system for reasons such as public security or protection of life and health, may exempt the deployer from notification.
  • Template: Article 27(5), as amended, tasks the AI Office with developing a simplified questionnaire template, possibly with an automated tool, that allows cross-references to a data protection impact assessment. At our check on 8 November 2026 we did not find an official template published; confirm on the AI Office pages before notifying.

How the FRIA relates to other assessments

AssessmentLegal basisFocusHow to combine
Fundamental rights impact assessmentAI Act Article 27All fundamental rights of affected persons in the deployer's contextThe master document for in-scope deployers
Data protection impact assessmentGDPR Article 35 (or Directive (EU) 2016/680 Article 27); AI Act Article 26(9)Risks to individuals from personal data processingCross-reference or include parts under Article 27(4); see the DPIA Guide: Running a Data Protection Impact Assessment
Provider risk managementAI Act Article 9Risks across the system lifecycle as designedInput to element (d) through Article 13 information
AI system impact assessmentISO/IEC 42005, ISO/IEC 42001Voluntary method for impacts on individuals, groups and societyA good method and evidence structure; does not by itself satisfy Article 27

Timeline and current status

  • Regulation (EU) 2024/1689 entered into force on 1 August 2024, with a general date of application of 2 August 2026 under Article 113.
  • The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It amended Article 113 and Article 27(4) and (5).
  • 2 December 2027: Chapter III Sections 1 to 3, including Article 27, apply to high-risk systems under Article 6(2) and Annex III (Article 113(c)(i) as amended). This is the date FRIA duties bite.
  • 2 August 2028: the same sections apply to Annex I product systems (Article 113(c)(ii)), which are outside Article 27 anyway.
  • Pending: the AI Office template under Article 27(5). Dates and text have already changed once, so recheck the consolidated text on the Commission's AI Act Service Desk before relying on them. The EU AI Act Implementation Timeline Tracker follows every date.

Enforcement and penalties

  • Market surveillance authorities receive FRIA notifications and supervise deployers. Each Member State designates its own authorities, so confirm which body receives notifications in each country where you deploy.
  • Fine tiers: Article 99 sets up to EUR 35 million or 7% of worldwide turnover for prohibited practices, up to EUR 15 million or 3% for the operator obligations listed in Article 99(4), and up to EUR 7.5 million or 1% for supplying incorrect or misleading information to authorities. SMEs, start-ups and (after the omnibus) small mid-caps get the lower of the two amounts for the relevant tiers.
  • Article 27 is not named in Article 99(4). That list covers deployer obligations under Article 26, transparency under Article 50 and others, but not Article 27. Penalties for a missing FRIA will depend on how Member States implement their general penalty rules and on how authorities treat related failures, such as Article 26 human oversight or monitoring duties, or misleading notifications under Article 99(5). Do not read the omission as a safe harbour.
  • Public authorities: under Article 99(8) each Member State decides to what extent administrative fines can be imposed on public authorities and bodies, so public sector exposure differs by country.
  • Beyond fines: a FRIA that is missing or superficial is likely to be the first document requested in a complaint, judicial review or data protection investigation of an automated decision.

What it means for AI agents and non-human identities

Many in-scope systems are no longer a single model behind a form. Eligibility checks, credit decisions and claims triage increasingly run as agentic workflows that call tools, read records and write decisions through service accounts and API keys. The FRIA elements map directly onto how those identities are designed.

  • Element (a) processes: document which agents and service identities act in the decision process, what systems they can read and write, and where a human sees the output. An agent with write access to a case management system is part of the process, not a tool beside it. See the Agent Identity and Access Guide.
  • Element (e) oversight: human oversight is only real if the agent cannot act beyond it. Scope credentials so decisions with legal or similarly significant effects need a human approval step the agent cannot bypass.
  • Element (f) measures: the ability to suspend use (Article 26(5)) needs a tested kill switch: disabling the agent's identity, revoking its tokens and falling back to a manual process.
  • Logs: deployers must keep logs under their control for at least six months (Article 26(6)). Tie agent actions to a distinct identity per agent so the record shows which agent did what, under which version and on whose behalf. See the Agent Identity Recertification guide.
  • Change triggers: a new tool permission, model version or data source for an agent is a change to the FRIA elements and should trigger the Article 27(2) update check.

Compliance steps

  1. Inventory and classify: list AI systems, mark Annex III high-risk ones and record whether your organisation is a public-law body, a public service provider, or deploys 5(b) or 5(c) systems. See the AI Register and AI Inventory Template.
  2. Assign ownership: a business owner for each in-scope system, with legal, data protection, equality or human rights expertise and the AI governance function involved.
  3. Collect provider information: instructions for use, Article 13 information, accuracy and bias metrics and any provider impact assessment you may rely on.
  4. Engage affected groups: Article 27 does not mandate consultation, but element (c) and (d) evidence is far stronger with input from frontline staff, user representatives and civil society where relevant.
  5. Draft the FRIA against elements (a) to (f), cross-referencing the DPIA rather than copying it, and recording residual risks and decisions.
  6. Pilot under the FRIA's controls: run the system in a limited pilot with oversight, logging and complaint routes live, and measure outcomes by group before full use. Rollback means suspending the system and reverting to the previous process.
  7. Notify and register: notify the market surveillance authority with the template; public authorities also complete Article 49 registration through Article 26(8).
  8. Review: on every material change and at least annually, update the FRIA and renotify where the results change.

Small and large deployers: a small credit provider using one vendor scoring model can lean heavily on provider information and its DPIA. A national agency running several Annex III systems needs a standard FRIA methodology, a central register and a review board. See the AI Impact Assessment Template.

Measuring the process

  • Coverage: in-scope high-risk systems with a completed and notified FRIA before first use (target 100%).
  • Currency: FRIAs reviewed after each material change and within the last 12 months.
  • Outcome monitoring: error, override and complaint rates broken down by affected group.
  • Oversight effectiveness: share of high-impact decisions reviewed by a competent human, and time to suspend a system in a test.
  • Complaint handling: complaints resolved within the defined period, and changes made as a result.

Practitioner checklist

  • Confirm for each AI system whether it is Annex III high-risk and whether your organisation is in an Article 27 deployer category.
  • Schedule FRIAs to finish before first use, and well before 2 December 2027 for systems already planned.
  • Cover all six Article 27(1) elements with evidence, not statements.
  • Cross-reference the GDPR DPIA under Article 27(4) instead of duplicating it.
  • Name competent human overseers with the authority to override and suspend.
  • Give every AI agent in the process its own scoped identity, logged for at least six months.
  • Set up complaint and redress routes before go-live.
  • Notify the market surveillance authority with the AI Office template once it is available, and keep evidence of notification.
  • Define change triggers that force an Article 27(2) update.

Standards and references

Related NHI Mgmt Group resources: ISO/IEC 42005 AI System Impact Assessment Guide · EU AI Act High-Risk AI Systems Guide · DPIA Guide: Running a Data Protection Impact Assessment · EU AI Act Compliance Guide. This guide summarises Article 27 of the EU AI Act as amended by the Digital Omnibus on AI and is not legal advice.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org