EU AI Act
Article 27 obliges certain deployers to assess the impact on fundamental rights before putting a high-risk system into use, and to notify the market surveillance authority of the result. It is a deployer duty, it is time-bound to first use, and it asks a different question from the provider’s risk assessment.
§ 1 — When it applies
2 December 2027
Annex III standalone high-risk systems. Moved from 2 August 2026 by the Digital Omnibus — a sixteen-month extension driven by undesignated national authorities and the absence of harmonised standards, not by any relaxation of the Section 2 requirements themselves.
§ 2 — In practice
Article 27 is a deployer duty, and that alone makes it unusual: most of the high-risk regime binds providers. It also has a hard edge that the rest of the Act mostly lacks. The assessment must be carried out prior to deploying the system. An assessment dated after go-live does not become compliant by being thorough, which makes this one of the few AI Act obligations where the date on the document is itself the finding.
The scope question is narrower than most deployers assume, and getting it wrong in either direction is costly. The gateway comes first: Article 27(1) attaches only to systems that are high-risk under Article 6(2), which means Annex III systems. An Annex I embedded high-risk system — an AI safety component inside a medical device, say — carries no FRIA duty however public the deployer. Within Annex III the duty reaches bodies governed by public law, private entities providing public services, and deployers of the systems used for creditworthiness assessment and for insurance risk assessment and pricing, with point 2, critical infrastructure, expressly excluded. Article 27(2) then limits the work rather than expanding it: the assessment is required for the first use, and where a later deployment is similar the deployer may rely on a previously conducted assessment and update it instead of starting again.
The most common substantive failure is answering the wrong question. Article 9 asks the provider whether the system is acceptably safe in general. Article 27 asks this deployer what this deployment does to the fundamental rights of the specific categories of person it will be pointed at, in this context, at this scale, with these arrangements for human oversight and redress. A provider risk assessment re-badged as a fundamental rights impact assessment answers a question nobody asked of the deployer.
§ 3 — Who it binds
Annex III systems only: Article 27 attaches to systems high-risk under Article 6(2), not to the Annex I embedded systems under Article 6(1). Within that set — bodies governed by public law, private entities providing public services, and any deployer of the systems used for creditworthiness assessment (point 5(b)) or for life and health insurance pricing (point 5(c)). Point 2, critical infrastructure, is expressly excluded.
§ 4 — What discharges it
The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.
01
The date is the control. Article 27 says "prior to deploying", so an assessment dated after go-live does not cure the breach, however good its content. Where a system was already in use before the obligation applied, the record should show when it was brought into scope.
02
A deployer that concluded it is out of scope needs that conclusion written down against the Article 27(1) categories. The absence of an assessment and the absence of a reasoned decision not to make one look identical from outside, and only one of them is defensible.
03
Article 27(3) requires the deployer to notify the authority of the results, submitting the filled-out template referred to in Article 27(5) — the AI Office questionnaire. The evidence is that submission and its acknowledgement, not the internal assessment sitting complete on a shared drive.
04
A tightened escalation route, a narrowed set of affected persons, a new redress path — or a recorded decision that no change was warranted, and on what basis. Findings that reach nothing leave the assessment reading as a formality, which is how an authority receiving it under Article 27(3) will treat it.
§ 5 — Worked example
A city authority procures an AI system to triage housing benefit applications, flagging cases for manual review. It goes live in March. In June, preparing for an audit, the authority realises no fundamental rights impact assessment was carried out, and completes one — a careful, forty-page document that identifies risks to applicants and proposes mitigations.
Has the authority cured the breach?
No. It has done something worth doing and has not undone the breach, because Article 27 attaches to a point in time and that point has passed. The authority is a body governed by public law deploying an Annex III system, so it was in scope from the start; the June document is evidence of the failure as much as a remedy for it. What it should now do is complete the assessment properly, notify the market surveillance authority under Article 27(3), record when the system was brought into scope and why the assessment was late, and — the part most often skipped — show that the findings changed something about the deployment. An assessment that identifies risks to applicants and results in no change to oversight, escalation or redress invites the obvious question about what it was for.
§ 6 — What a weak answer looks like
An assessment written by the wrong people. A FRIA produced entirely inside legal or compliance, without the caseworkers who will operate the system and without anyone who can speak for the people it will be pointed at, reliably identifies the risks already known to the organisation and misses the ones specific to this deployment. Article 27(3) sends the result to the market surveillance authority, so the document is read by someone outside the organisation — a test most internal drafting is not written to survive.
§ 7 — Exposure
Determined by national law
Article 27 is not enumerated in Article 99(4). Exposure arises under the penalties each Member State lays down pursuant to Article 99(1), which must be effective, proportionate and dissuasive but vary by jurisdiction. Check the implementing law of the Member State in which the deployer operates rather than assuming the Union ceilings apply.
§ 8 — Elsewhere
Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.
GDPR and data-protection law
Article 27(4) allows a deployer that has already carried out a GDPR data protection impact assessment to complement it rather than duplicate it. The scopes overlap without coinciding: a DPIA is organised around personal data, a FRIA around fundamental rights more broadly.
A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.
§ 9 — Where this is assessed
Examined in 2 credentials, in the domains named on each card.
Roles and duties · 20% of the paper
The EU AI Act as enacted: the risk-tier structure, the roles the Act defines, the obligations attaching to each, and the timeline on which they apply.
Impact and risk assessment · 20% of the paper
AI governance in government: public-sector AI use, algorithmic accountability and transparency obligations, and AI in public procurement.
§ 10 — provenance
This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.
§ 11 — Also read