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 category | Which Annex III systems | Examples | Notes |
|---|---|---|---|
| Bodies governed by public law | Any Article 6(2) high-risk system except point 2 | Benefits eligibility scoring, school admissions, public employment services, migration case triage, police risk tools | Includes local and regional authorities and public agencies |
| Private entities providing public services | Any Article 6(2) high-risk system except point 2 | Private operators of outsourced public services such as healthcare, education or social housing allocation | Whether a service is a "public service" may need legal analysis under national law |
| Deployers of Annex III point 5(b) systems | Creditworthiness evaluation or credit scoring of natural persons | Banks, lenders, buy-now-pay-later providers using AI scoring | Systems used for detecting financial fraud are excluded from 5(b) |
| Deployers of Annex III point 5(c) systems | Risk assessment and pricing for natural persons in life and health insurance | Insurers using AI underwriting or pricing models | Other 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) element | What to document | Evidence sources |
|---|---|---|
| (a) Processes | The deployer's processes in which the system will be used in line with its intended purpose | Process maps, decision flows, where the AI output enters a human or automated decision |
| (b) Period and frequency | How long and how often the system is intended to be used | Deployment plan, volumes, pilot and production phases |
| (c) Affected persons and groups | Categories of natural persons and groups likely to be affected in the specific context | Population data, vulnerable groups, protected characteristics present in the population |
| (d) Specific risks of harm | Risks of harm likely to affect those categories, taking into account the provider's Article 13 information | Instructions for use, accuracy and bias metrics, known limitations, data protection impact assessment |
| (e) Human oversight | How the oversight measures in the instructions for use will be implemented | Named oversight roles, competence and authority (Article 26(2)), override and escalation procedures |
| (f) Measures if risks materialise | Measures to take if risks materialise, including internal governance and complaint mechanisms | Incident 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
| Assessment | Legal basis | Focus | How to combine |
|---|---|---|---|
| Fundamental rights impact assessment | AI Act Article 27 | All fundamental rights of affected persons in the deployer's context | The master document for in-scope deployers |
| Data protection impact assessment | GDPR Article 35 (or Directive (EU) 2016/680 Article 27); AI Act Article 26(9) | Risks to individuals from personal data processing | Cross-reference or include parts under Article 27(4); see the DPIA Guide: Running a Data Protection Impact Assessment |
| Provider risk management | AI Act Article 9 | Risks across the system lifecycle as designed | Input to element (d) through Article 13 information |
| AI system impact assessment | ISO/IEC 42005, ISO/IEC 42001 | Voluntary method for impacts on individuals, groups and society | A 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
- 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.
- 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.
- Collect provider information: instructions for use, Article 13 information, accuracy and bias metrics and any provider impact assessment you may rely on.
- 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.
- Draft the FRIA against elements (a) to (f), cross-referencing the DPIA rather than copying it, and recording residual risks and decisions.
- 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.
- Notify and register: notify the market surveillance authority with the template; public authorities also complete Article 49 registration through Article 26(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
- European Commission AI Act Service Desk: Article 27 Fundamental rights impact assessment for high-risk AI systems
- European Commission AI Act Service Desk: Article 26 Obligations of deployers of high-risk AI systems
- European Commission AI Act Service Desk: Annex III High-risk AI systems
- European Commission AI Act Service Desk: Article 113 Entry into force and application
- European Commission AI Act Service Desk: Article 99 Penalties
- European Commission AI Act Service Desk: Article 46 Derogation from conformity assessment procedure
- EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
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.