FRIA Template: EU AI Act Article 27 Fundamental Rights Impact Assessment, Worked Example

A FRIA template is a fill-in record of the six things Article 27(1) of the EU AI Act asks certain deployers to assess before first using a high-risk system: the processes involved, the period and frequency of use, the people affected, the specific risks of harm, human oversight, and the measures if risks materialise. The AI Office's own template was still unpublished on 14 October 2026.

Everything below was checked on 14 October 2026 against the consolidated text of Regulation (EU) 2024/1689 on EUR-Lex, which includes the changes made by the Digital Omnibus on AI, Regulation (EU) 2026/1744. Treat it as a working draft for your legal, data protection and service teams. It is general information, not legal advice.

A FRIA is narrower than a general risk review. It binds particular deployers, it looks at the people on the receiving end rather than at the organisation, and its result goes to a regulator. If you first need to know whether a system is high-risk at all, run it through our EU AI Act checker; for the wider register of risks, pair this with our AI risk assessment template.

Who must carry out a FRIA under Article 27

Article 27(1) applies before deploying a high-risk system referred to in Article 6(2), which means a system listed in Annex III. It names three kinds of deployer:

The Act never defines “bodies governed by public law”. EU procurement law uses the same words for a defined group: Article 2(1)(4) of Directive 2014/24/EU covers bodies set up to meet needs in the general interest, without an industrial or commercial character, that have legal personality and are mostly financed, managed or supervised by public authorities. That directive lists them separately from the State and regional or local authorities (Article 2(1)(1)), and the AI Act does not say whether it borrows the narrower meaning. Until the Commission’s FRIA guidance settles the point, plan as if ministries and municipalities are in scope too, and take advice on borderline cases such as publicly owned companies.

Lenders and insurers will find the sector detail in our guide for banks and insurers, and schools and universities in our education guide. Providers do not carry out a FRIA themselves, but Article 27(2) lets a deployer rely on earlier FRIAs, or on impact assessments the provider already carried out, in similar cases.

When the FRIA is due, and when to update it

Article 27 sits in Chapter III, Section 3. Under Article 113(c)(i) as amended, that section applies to Annex III systems from 2 December 2027. The duty attaches to the first use of each system, and Article 27(2) requires an update whenever any of the six elements has changed or is no longer up to date.

Systems already on the market or in service before that date are caught only after a significant change to their design, under Article 111(2). The same paragraph sets a hard stop for high-risk systems intended for use by public authorities: they must comply by 2 August 2030 whatever their history.

Once the assessment is done, Article 27(3) requires the deployer to notify the market surveillance authority of its results, submitting the filled-out template from Article 27(5) as part of the notification. Deployers may be exempt only in the case covered by Article 46(1), where a market surveillance authority authorises a specific high-risk system for exceptional reasons such as public security or the protection of life and health.

Two neighbouring duties often land on the same team. Public authorities must register their use of an Annex III system in the EU database before using it (Articles 26(8) and 49(3)), and every deployer of an Annex III system must tell people when it makes or assists decisions about them (Article 26(11)). On penalties, Article 99(4) sets fines of up to €15 million or, for a company, 3% of worldwide annual turnover if that is higher, for breaches of the Article 26 deployer duties. It does not list Article 27, which leaves a missing FRIA to the penalty rules each Member State lays down under Article 99(1), including how far public bodies can be fined at all (Article 99(8)). The exception is the narrow group of systems the AI Office supervises itself, where Article 75c(4) extends that fine tier to unlisted provisions. Our fines and penalties guide covers the tiers.

Has the AI Office published a FRIA template questionnaire?

Not yet. Article 27(5), as replaced by the Omnibus, says the AI Office “shall develop a template for a questionnaire, including through an automated tool”, and that the template should let deployers cross-refer to their data protection impact assessment. Recital 96 gives the purpose: to facilitate compliance and reduce the administrative burden for deployers.

On 14 October 2026 we found no published template. The Commission’s page on implementing guidelines, last updated on 31 July 2026, lists “Guidelines with a template for the fundamental rights impact assessment” among the items the AI Office is still working on. The AI Act Service Desk’s Article 27 page shows the amended text and links no template.

That leaves a practical gap, since the Article 27(3) notification must include the filled-out template. It does not stop you working: the content is fixed by the six elements in Article 27(1), so an assessment built element by element can be transferred into the official form once it exists. Civil society has filled part of the gap. The Danish Institute for Human Rights and the European Center for Not-for-Profit Law published a FRIA guide on 15 December 2025 with a downloadable template and a five-phase process, from planning and scoping to monitoring and review.

Reusing your GDPR DPIA in the FRIA

The Omnibus changed Article 27(4). The 2024 text said the FRIA “shall complement” an existing data protection impact assessment. The amended text lets the deployer include cross-references to the relevant sections of that DPIA, or copy relevant parts in, wherever a FRIA obligation is already met there. Article 26(9) adds that deployers must use the provider’s Article 13 information when they carry out the DPIA, so the same instructions for use feed both documents.

If you want one intake to produce both documents, our DPIA and FRIA use case shows the pattern.

The fundamental rights impact assessment template

Copy each table into a document or spreadsheet and replace the example column. The worked entries follow Example City, a fictional municipality that deploys a fictional “Eligibility Assistant” from an outside vendor to pre-screen applications for a means-tested housing allowance. The system checks each application and its evidence against the eligibility rules, lists missing documents and proposes “likely eligible”, “likely ineligible” or “needs review”. A caseworker decides every case. Names, dates and numbers are invented to show the level of detail each field needs.

Part 0: scope and identification

Element (a): the deployer’s processes

1. Which process does the system support, from intake to final decision, and at which step does it act?
2. What does it produce (score, label, ranking, draft text), and who acts on that output?
3. Does this use match the intended purpose in the provider’s instructions for use?
4. Which decisions stay entirely human, and could any be taken on the system’s output alone?

Element (b): period and frequency of use

1. From when, and until when: pilot dates, production start, contract term?
2. How often does it run: per application, in batches, continuously?
3. How many people or cases per month, and when are the peaks?
4. Is any extension planned to other benefits, regions or user groups?

Element (c): people and groups affected

1. Who is directly subject to the output?
2. Who is affected without being the applicant, such as household members?
3. Which groups may be affected differently: children, older people, people with disabilities, people with irregular income, non-native speakers?
4. Which groups does the provider’s documentation say the system was tested on, and which are missing?

Element (d): specific risks of harm

1. For each group in (c), which rights could be harmed? Use the Charter of Fundamental Rights as the checklist: dignity (Article 1), private life (7), personal data (8), non-discrimination (21), rights of the child (24), integration of persons with disabilities (26), social and housing assistance (34) and effective remedy (47).
2. Which limitations, accuracy figures or foreseeable misuse in the instructions for use could cause that harm?
3. How likely and how severe is each risk, before and after the measures in (e) and (f)?
4. Could reviewers come to accept proposals by habit?

Element (e): human oversight measures

1. Who oversees the output, and do they have the competence, training, authority and support Article 26(2) requires?
2. Which oversight measures from the provider’s instructions for use are implemented, and how?
3. Can the reviewer see the reasons and evidence, override the proposal and stop the system?
4. How is over-reliance measured?

Element (f): measures if risks materialise, governance and complaints

1. What happens when a risk in (d) occurs: who is told, who can suspend use, how affected people are put right?
2. Which internal governance body oversees the system, and how often does it report?
3. How do people learn that AI was involved, obtain an explanation (Article 86) and complain?
4. Which logs are kept, and for how long, so that cases can be reconstructed?

Notification, sign-off and review

How VDF AI fits

A FRIA describes how a system is used, and its weakest parts are usually elements (e) and (f), where the assessment promises oversight and redress that operations must then deliver. VDF AI runs governed agents and workflows on your own infrastructure, on-premises or air-gapped, so the records behind those promises stay with you.

Workflows can stop at a human approval step before a consequential action, every prompt, retrieval, tool call and response is written to an audit log, and role-based access control is included on every plan. Those records are the evidence for oversight checks, override rates and complaint investigations; the evidence pack approach shows how to assemble them, and our note on human oversight requirements covers designing review steps. The classification, the assessment and the notification remain the deployer’s legal responsibility.