We'd like to set analytics cookies to measure which pages are useful. They are not needed to run the site, and declining changes nothing about what you can do here. Privacy Policy.
The FRIA forces the deployer — the party that actually points the system at people — to name who is affected, what could go wrong for them, and what happens when it does. It is the deployer-side counterpart to the provider's risk-management system.
Every template on this page is readable in full right here, copyable as Markdown, and downloadable as a PDF. No sign-up, no e-mail address, no click-to-reveal.
Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
Deployers that are bodies governed by public law, private operators providing public services, and deployers of high-risk systems used to evaluate creditworthiness or to price and assess risk for life and health insurance. Everyone else deploying high-risk AI has Article 26 duties but no FRIA duty.
Before the first use of the high-risk system. Where the elements are already covered by a data protection impact assessment, the FRIA complements it rather than repeating it. If any element changes, the assessment is updated.
With the Annex III high-risk regime, from 2 December 2027. Public-sector procurement cycles run longer than that, so the assessment is usually needed well before the deadline.
Article 27 — Article 27, Article 26
Article 27 requires specified deployers of high-risk AI systems to perform an assessment of the impact on fundamental rights that the use of the system may produce, prior to putting it into use. The six elements below are the ones the article enumerates.
Answering it as a system description instead of an impact assessment. Sections 3, 4 and 6 are the ones with teeth: named categories of affected people, named harms, and a route by which an affected person can complain and be heard.
6 sections. Each one carries what to write and — the part templates normally leave out — what an assessor is looking for when they read it.
Describe the processes in which the high-risk system will be used in line with its intended purpose — where in your workflow the output lands, and what happens next.
Whether a human decision genuinely sits between the output and the person affected, or whether the output is in practice the decision. Assessors probe this first because it changes the weight of everything after it.
The period of time over which, and the frequency with which, the system is intended to be used.
That this matches deployment reality. A pilot described as 'six-month trial, one region' that has been running organisation-wide for two years is a live and easily verified discrepancy.
The categories of natural persons and groups likely to be affected by the system's use in your specific context — including people affected indirectly.
Specificity, and whether vulnerable groups were considered separately. 'Our customers' is not a category; 'applicants for social housing, including minors in the household' is.
The specific risks of harm likely to impact the categories of persons or groups identified above, taking account of the information the provider gives in the instructions for use.
Whether the instructions for use were actually read. The provider's stated limitations and known failure modes should be visible in this section — if the risks here bear no relation to them, the assessment was written without the documentation.
The human-oversight measures you will implement, according to the instructions for use — who reviews what, with what competence, and with what authority to override or stop.
Authority and capacity, not job titles. A reviewer who cannot in practice refuse the output, or who is expected to review hundreds of cases a day, is not oversight — and Article 14 is explicit that oversight has to be effective.
The measures to be taken if the identified risks materialise, including internal governance arrangements and the complaint mechanisms available to affected people.
A named escalation route with a named owner, and a complaint channel an affected person could actually find and use. This section is where paper assessments are separated from real ones.
The same document in two portable forms. The Markdown pastes into Notion, Confluence, Google Docs or a repository; the PDF is laid out to be printed and written on, with ruled fill-in areas and a sign-off block.
# Fundamental Rights Impact Assessment (FRIA)
**Legal basis:** Article 27, Article 26 — Regulation (EU) 2024/1689 (EU AI Act).
> Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
**Who fills this in:** Deployers that are bodies governed by public law, private operators providing public services, and deployers of high-risk systems used to evaluate creditworthiness or to price and assess risk for life and health insurance. Everyone else deploying high-risk AI has Article 26 duties but no FRIA duty.
**When:** Before the first use of the high-risk system. Where the elements are already covered by a data protection impact assessment, the FRIA complements it rather than repeating it. If any element changes, the assessment is updated.
| Field | Value |
| --- | --- |
| Organisation | |
| AI system | |
| Version / reference | |
| Document owner | |
| Date | |
| Version of this document | |
## 1. Deployment context and processes
*What to write:* Describe the processes in which the high-risk system will be used in line with its intended purpose — where in your workflow the output lands, and what happens next.
*What an auditor looks for:* Whether a human decision genuinely sits between the output and the person affected, or whether the output is in practice the decision. Assessors probe this first because it changes the weight of everything after it.
_[Your text here]_
## 2. Period and frequency of use
*What to write:* The period of time over which, and the frequency with which, the system is intended to be used.
*What an auditor looks for:* That this matches deployment reality. A pilot described as 'six-month trial, one region' that has been running organisation-wide for two years is a live and easily verified discrepancy.
_[Your text here]_
## 3. Categories of persons and groups affected
*What to write:* The categories of natural persons and groups likely to be affected by the system's use in your specific context — including people affected indirectly.
*What an auditor looks for:* Specificity, and whether vulnerable groups were considered separately. 'Our customers' is not a category; 'applicants for social housing, including minors in the household' is.
_[Your text here]_
## 4. Specific risks of harm
*What to write:* The specific risks of harm likely to impact the categories of persons or groups identified above, taking account of the information the provider gives in the instructions for use.
*What an auditor looks for:* Whether the instructions for use were actually read. The provider's stated limitations and known failure modes should be visible in this section — if the risks here bear no relation to them, the assessment was written without the documentation.
_[Your text here]_
## 5. Human oversight measures
*What to write:* The human-oversight measures you will implement, according to the instructions for use — who reviews what, with what competence, and with what authority to override or stop.
*What an auditor looks for:* Authority and capacity, not job titles. A reviewer who cannot in practice refuse the output, or who is expected to review hundreds of cases a day, is not oversight — and Article 14 is explicit that oversight has to be effective.
_[Your text here]_
## 6. Measures if risks materialise
*What to write:* The measures to be taken if the identified risks materialise, including internal governance arrangements and the complaint mechanisms available to affected people.
*What an auditor looks for:* A named escalation route with a named owner, and a complaint channel an affected person could actually find and use. This section is where paper assessments are separated from real ones.
_[Your text here]_
---
Template by Conformly — getconformly.com/templates/fria-fundamental-rights-impact-assessment. Free to copy and adapt. Not an official document. This is a working draft built from the text of Regulation (EU) 2024/1689 — it is not issued or endorsed by the European Commission, any national authority or any notified body, and it is not legal advice. Fill it in with your own facts and have it reviewed by counsel before you rely on it.
One row per AI system, with the columns the EU database will ask for — so the register you keep internally is the register you can file from.
The nine-section technical file a provider of a high-risk AI system has to draw up before the system goes on the market.
The dossier you send to the market-surveillance authority, and the clock that starts the moment you become aware.
Not sure this document is yours to write? Classify the system first — or browse all 7 templates.