Who has to do it, and when.
The chapeau does four things in one sentence. It pins the obligation to deployers, not providers. It scopes to high-risk AI systems referred to in Article 6(2), which is the Annex III route. It carves out Annex III point 2, critical infrastructure. It identifies three trigger limbs that pull the obligation onto a specific deployer.
Limb one. Bodies governed by public law. Public hospitals operating under public-law statutes. Public broadcasters. Government departments and their agencies. The category travels with the Member State's administrative-law definition of public-law bodies, and the EU AI Act adopts it without redefining it.
Limb two. Private entities providing public services. Recital 96 explains the category: Private entities providing such public services are linked to tasks in the public interest such as in the areas of education, healthcare, social services, housing, administration of justice. The test is the service, not the corporate form.
Limb three. Deployers of high-risk AI systems referred to in points 5(b) and (c) of Annex III. Two specific Annex III categories where the FRIA bites every deployer regardless of public or private status. Annex III(5)(b) covers AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score. Annex III(5)(c) covers AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance. A private bank running an Annex III(5)(b) credit-scoring agent on retail applicants is squarely inside Article 27 even though it is neither a public-law body nor a public-service provider.
The exclusion is Annex III point 2, AI systems used as safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity. The legislative judgement is that critical-infrastructure high-risk systems carry their fundamental-rights weight through other obligations, not through the FRIA.
The temporal anchor is prior to deploying. The verb is operative. The deployer cannot run the FRIA after the system is in service, then back-fill the file. Article 27(2) tightens this further. The obligation applies to the first use of the high-risk AI system. First use is the moment the deployer puts the system into service for its intended purpose against real subjects, not a pilot against synthetic data.
The six contents elements, verbatim.
Article 27(1) continues. For that purpose, deployers shall perform an assessment consisting of the following six elements. Each is reproduced verbatim, then read for what it requires of the deployer's evidence file.
Six elements, taken together, are the spec. The deployer signs against them. The market surveillance authority reads against them under Article 27(3). The notable structural point is that Article 27(1) does not ask the deployer to score risk, draw a residual-risk line or produce a probability matrix. It asks for description and identification. The judgement layer is the regulator's, not the deployer's.
The list is closed, not illustrative. Six bullets, not seven. The AI Office template under Article 27(5) is structured against these six, and the notification under Article 27(3) is filed on that template.
First use, similar cases, and the update obligation.
Three sentences, three rules. First, the FRIA is a first-use obligation. The deployer who puts the high-risk system into service for the first time is on the hook. A deployer who buys an established system from a previous operator is, on most readings, still a new deployer and still on the first-use hook for that deployment.
Second, the similar cases reliance rule. A deployer running the same high-risk AI system across multiple comparable use cases is not required to perform a fresh FRIA for each. It may rely on a previously conducted FRIA, or on an impact assessment the provider has already carried out, where the cases are similar. The deployer carries the burden of arguing similarity if challenged. Same provider, same intended purpose, same affected-population profile is the conservative test.
Third, the update obligation. The trigger for an update is content change, not calendar. The deployer must update where any of the elements in Article 27(1)(a) to (f) has changed or is no longer up to date. The natural triggers are a change in the process under (a), a change in cadence under (b), a change in the population under (c), the emergence of a new harm vector under (d), a change to the oversight staffing under (e), or a change to the governance or complaint channel under (f). The FRIA is a living document with a content-driven refresh cadence, not an annual ritual.
Notification to the market surveillance authority.
The notification is the operative deliverable. The FRIA is performed inside the deployer's organisation. The result is reported outside. The recipient is the market surveillance authority designated under Article 70, the same authority that supervises the high-risk system under Article 74 and that can request the logs under Article 26(6).
What is filed is the AI Office template, filled out, not the deployer's internal working file. The template under Article 27(5) is the legible artefact. Internal working files, redlines and stakeholder consultation notes are not part of the notification, though they remain producible on demand under the cooperation duty in Article 26(12).
The Article 46(1) exemption is narrow. On a duly justified request, a market surveillance authority may authorise the placing on the market or putting into service of specific high-risk AI systems within its Member State's territory for exceptional reasons of public security or the protection of life and health of persons, environmental protection or the protection of key industrial and infrastructural assets. It is a derogation on timing, not a waiver: the authorisation runs for a limited period while the necessary conformity assessment procedures are being carried out, and those procedures must still be completed without undue delay. Where Article 46(1) is invoked, the FRIA notification can be waived. The FRIA itself is not waived, only the filing.
Article 27(4) and the GDPR Article 35 cross-walk.
Read the paragraph as it now stands, not as first enacted. Until 27 July 2026 Article 27(4) said the FRIA shall complement the DPIA. The Digital Omnibus replaced the paragraph outright. The word complement is gone, and with it the reading that the FRIA is a mandatory add-on layered over the DPIA.
What replaced it is a permission, not a duty. The deployer may include cross-references to the relevant sections of the DPIA, or include relevant parts of it in the FRIA. The drafting turns a duplication problem into a drafting convenience: where the DPIA already carries the analysis, the FRIA can point at it or lift it. What has not changed is that the FRIA remains a separate obligation. A deployer still cannot file the DPIA in place of the FRIA, because the Article 27(1)(a) to (f) elements still have to be present in the FRIA — by cross-reference or by inclusion, but present.
The cross-reference to Article 27 of Directive (EU) 2016/680 carries the same logic into the law-enforcement processing regime. A police-authority deployer that already has a Law Enforcement Directive impact assessment for a given processing operation may cross-refer to it rather than restate it.
The practical reading of the carve-out runs element by element. The deployer's FRIA file references the DPIA where the DPIA has already done the work. For Article 27(1)(c) categories of affected persons, the DPIA's data-subject inventory often covers most of the ground. For Article 27(1)(d) specific risks of harm, the DPIA's necessity-and-proportionality assessment will overlap on personal-data-related harms but will not cover non-data-related fundamental-rights harms. For Article 27(1)(e) oversight measures and Article 27(1)(f) governance and complaints, the DPIA usually has skeletal coverage. The FRIA fills these in.
The two assessments are parallel under different regimes. GDPR Article 35 attaches to the controller and is scoped to personal data. EU AI Act Article 27 attaches to the deployer and is scoped to fundamental rights more broadly. A single deployer is often both controller and deployer of the same high-risk AI system, which is why Article 27(4) exists to keep the two from forcing duplicate analysis.
The AI Office template under Article 27(5).
The closing paragraph delegates the form to the AI Office. The substance is fixed in Article 27(1)(a) to (f). The instrument is the template the AI Office develops. The phrase including through an automated tool contemplates a structured questionnaire or web form, not free-text Word documents lodged by email.
The Digital Omnibus added the second sentence. It carries the amended Article 27(4) permission into the form itself: the template must, where relevant, let the deployer cross-refer to DPIA sections or lift parts of the DPIA into the FRIA. The form and the paragraph it serves now move together.
On the template's status we are stating a gap rather than a date. Article 27(5) imposes no deadline on the AI Office — read the paragraph again above; there is no date in it — and as at 28 July 2026 we have not verified a published final template against a Commission source. So we are not going to name a publication date or a consultation stage. The deployer-side posture does not depend on knowing: assemble the six elements of Article 27(1)(a) to (f) internally, in that structure, and the eventual filing is a transcription job.
Two structural notes. The template is a facilitation device, not a substantive expansion of the obligation. If the AI Office template asks a question that goes beyond Article 27(1)(a) to (f), the deployer's answer is grounded in the article, not in the template's wording. And the automated-tool route does not displace the deployer's obligation to actually conduct the assessment. Filling the form is the notification. Performing the assessment is the obligation.
How Article 27 sits inside the wider regulation.
Article 27 does not stand alone. The article is one node in a cross-reference web that the deployer's evidence file has to honour. The five touchpoints are Article 26(9), GDPR Article 35, Article 14, Annex III, and Article 70.
What Article 27 requires, and what the evidence package does not hold.
The gap first. The signed warrant-v1 evidence package carries no fundamental rights impact assessment. Its schema, api/spec/warrant-v1-evidence.schema.json, sets additionalProperties: false at the root, and the nine properties the root permits are classification, actions, authorizations, obligations, coverage_by_regime, deferred_regimes, risk_tier, refusal_reason and trace_metadata. There is no deployer root and no fria root. Because the root is closed, a field name absent from that list is prohibited, not merely unimplemented. No field on the package evidences any element of Article 27(1).
The obligation corpus is the second half of the gap. At corpus digest 6871ee8b it carries 20 regimes and 223 cited sub-clauses, and not one of them is an Article 27 sub-clause: the EU AI Act ids in the corpus cover Articles 12, 13, 14, 15, 50 and Annex IV. So no obligation row on any package cites Article 27, and there is no field mapping to print. Anyone who needs Article 27 evidence today should read this section as a statement of what to build, not of what ships.
What the Article 27 elements attach to instead is the deployer's own governance record. The Regulation puts the assessment on the deployer, has it filed with the market surveillance authority under Article 27(3), and leaves the file inside the deployer's organisation. A Warrant-attested trace can sit alongside that file — the per-action authorization rows speak to how a given decision was authorised, which is evidence about the oversight the FRIA describes under Article 27(1)(e) — but the FRIA itself is a separate artefact Warrant does not produce, hold or sign. The table below is the element-by-element reading, with the package position stated on each row.
classification.jurisdictions and classification.domain narrow which regimes a trace is assessed against; neither identifies the deployer or its Article 27 trigger.
actions[].subject is a single free-text string per action, unclassified, and it describes the subject of one action rather than a population.
obligations.<action_id>[].compliance, which marks a mapped obligation satisfied, gap, uncertain or unvalidated — a per-clause compliance verdict, not a harm assessment.
authorizations[].human_oversight_appropriate is the assessment's judgement, per action, on whether human oversight was appropriate for that action. It is not a record that a human was present, and it is not an oversight plan. Staffing, intervention points and escalation paths stay in the deployer's record.
trace_metadata.timestamp on a package is the time that package was sealed, not a first-use date and not an assessment date.
The honest summary of the table: eleven Article 27 elements, one of which the package speaks to in part, and ten it does not reach at all. A structured, package-level FRIA record is a schema Warrant has not published and does not emit. When it exists it will be a new schema version with its own root, and this section will name the fields it actually carries.
Questions a compliance officer asks first.
Read the source directly.
- Regulation (EU) 2024/1689 · EUR-Lex CELEX:32024R1689
- Article 27 fundamental rights impact assessment · annotated text
- Article 26 deployer obligations · 26(9) is the DPIA hand-off, 26(12) is the cooperation duty
- Article 46 derogation from conformity assessment · 46(1) is the Article 27(3) notification carve-out
- Article 70 designation of national competent authorities and market surveillance authorities
- Article 113 entry into force and application dates
- Regulation (EU) 2016/679 (GDPR) · Article 35 data protection impact assessment
- Sister reading · Article 26 deployer obligations
- Per-obligation Warrant evidence field mapping
Authored by Warrant Compliance, the regulatory-analysis function at Warrant. [email protected]. Editorial commentary on regulatory text. Not legal advice. The verbatim quotations of the Article 27(1) chapeau, Article 27(1)(a) to (f), and Article 27(2) and (3) reflect the official English-language text of Regulation (EU) 2024/1689 as published in the Official Journal of the European Union on 12 July 2024. Article 27(4) and (5) are quoted as replaced by Regulation (EU) 2026/1744, published in the Official Journal on 24 July 2026 and in force from 27 July 2026. Verified against the consolidating instruments on 6 August 2026.