Last reviewed: April 10, 2026
Jurisdictions covered: EU
Time required: 4-8 hours for the first FRIA; 1-2 hours per subsequent system
What you will have at the end: A completed Fundamental Rights Impact Assessment ready for market surveillance authority notification
Prerequisites: You have identified your AI system as high-risk under Annex III. If you have not done this yet, start with our Annex III classification guide.
Regulatory uncertainty: The European AI Office has not yet published the official FRIA template mandated by Art. 27(5). The template below is based on the legal requirements of Art. 27(1)(a)-(f) and the EU Fundamental Rights Agency’s 2025 guidance report. We will update this guide when the official template is released. Last checked: 2026-04-10.
EU AI Act FRIA Template: A Step-by-Step Guide
Article 27 of the EU AI Act creates a new obligation that has no precedent in EU tech regulation. Before you put a high-risk AI system into use, you must assess its effect on the fundamental rights of the people it will affect (EU AI Act Art. 27). This is the Fundamental Rights Impact Assessment, or FRIA. It is not a GDPR Data Protection Impact Assessment. It is not a technical risk assessment. It is a separate, mandatory exercise that covers rights your DPIA does not touch (for the full picture of where the AI Act and GDPR conflict, see our GDPR overlap analysis): equality, dignity, access to remedies, workers’ rights, children’s rights.
The deadline is August 2, 2026. The official template from the AI Office does not exist yet. This guide gives you a working FRIA template you can use today, walks through each section with two worked examples, and explains exactly where the FRIA ends and the DPIA begins.
Key Takeaways
What a FRIA Is and Why It Is Mandatory
A Fundamental Rights Impact Assessment is a structured evaluation of how a high-risk AI system affects the fundamental rights of the people it touches. The legal basis is Art. 27 of the EU AI Act.
The FRIA exists because AI systems listed in Annex III affect people in ways that go beyond data protection. A credit scoring algorithm does not just process personal data. It determines whether someone gets a loan. A recruitment AI does not just match keywords. It decides who gets an interview and who does not. These decisions engage the right to non-discrimination, the right to an effective remedy, the right to fair working conditions, and other rights protected by the EU Charter of Fundamental Rights.
The GDPR’s DPIA was designed for data protection risks. It does not require you to assess whether your AI system discriminates against people with disabilities, whether it undermines access to public services for minority groups, or whether affected persons have a meaningful way to challenge its decisions. The FRIA does.
The obligation became part of the final text after sustained advocacy by the EU Fundamental Rights Agency and civil society organizations. The FRA’s 2025 research found that most organizations using high-risk AI focus exclusively on GDPR-driven data protection and technical risk management; bias testing, where it exists, is inconsistent and ad hoc (FRA, 2025). Art. 27 is meant to close that gap.
Who Must Conduct a FRIA
Not every organization deploying high-risk AI needs a FRIA. Art. 27 applies to a specific set of deployers. All three criteria must be met:
Criterion 1: The AI system is high-risk under Art. 6(2), meaning it falls under one of the Annex III categories.
Criterion 2: The system does not fall under Annex III Area 2 (critical infrastructure). Critical infrastructure AI is explicitly excluded from the FRIA obligation (EU AI Act Art. 27(1)).
Criterion 3: The deployer is one of the following:
A private company using AI for internal recruitment? No FRIA required under Art. 27, unless that company is providing a public service. A municipal government using AI to triage welfare applications? FRIA required. A bank using AI for credit scoring? FRIA required, even though it is a private entity, because Art. 27 specifically includes Area 5(b) deployers.
Practical tip: Even if your organization falls outside Art. 27’s scope, we recommend conducting a fundamental rights assessment voluntarily. The FRA’s research shows that organizations doing so are better prepared for enforcement and face fewer reputational risks. The EU AI Act’s Art. 95 explicitly encourages voluntary adoption of high-risk practices by non-covered organizations.
Step-by-Step: How to Conduct a FRIA
The six steps below follow the structure of Art. 27(1)(a)-(f). Each step maps to a section of the template that follows.
Step 1: Describe How You Will Use the AI System
Document the specific processes in which the high-risk AI system will be used, in line with its intended purpose (Art. 27(1)(a)). Also record how long you intend to use it and how frequently (Art. 27(1)(b)).
Be precise. “We use AI for hiring” is not enough. Describe the exact stage of the process: screening CVs, ranking candidates, conducting video interviews, recommending shortlists. Describe who in your organization interacts with the system’s outputs and what decisions those outputs feed into. State whether the system runs continuously or is deployed for specific campaigns.
The provider’s instructions for use (Art. 13) are your starting point. They describe the system’s intended purpose, capabilities, and limitations. Your description must connect those capabilities to your actual business process.
Step 2: Identify Affected Persons
List the categories of natural persons and groups likely to be affected by the system’s use in your specific context (Art. 27(1)(c)).
Go beyond the obvious. A recruitment AI affects job applicants. But it also affects the recruiting team (whose professional judgment is being supplemented or overridden), existing employees (if the system changes the composition of the workforce), and potentially customers or service users (if hiring decisions affect service delivery). Identify vulnerable groups explicitly: people with disabilities, ethnic minorities, older workers, non-native language speakers, people from lower socioeconomic backgrounds.
Estimate the scale. How many people will be affected per year? Hundreds? Thousands? Millions? The scale matters for assessing proportionality.
Step 3: Assess Fundamental Rights Risks
This is the core of the FRIA. For each category of affected persons, identify specific risks of harm, taking into account the information provided by the AI system’s provider (Art. 27(1)(d)).
You must assess risks across the full spectrum of fundamental rights, not just data protection. The FRA’s 2025 guidance recommends covering at minimum (FRA Opinion 4, 2025):
For each right, assess: Does the AI system create a risk of harm to this right? How likely is that harm? How severe would it be? What evidence do you have (bias audits, testing results, incident reports from the provider)?
Step 4: Document Human Oversight Measures
Describe how you implement human oversight measures according to the provider’s instructions for use (Art. 27(1)(e)).
This is where most organizations fail. The FRA warns that stating “a human reviews all decisions” is insufficient (FRA, 2025). Research on automation bias shows that human reviewers routinely defer to AI outputs without meaningful scrutiny (Bućinca et al., 2021, DOI: 10.1145/3449287).
Document five things: (1) Who specifically performs oversight (name the role, not just “a human”). (2) What training they have received on the AI system’s limitations. (3) What authority they have to override, reverse, or stop the system. (4) How much time they have to review each decision. (5) What tools or information they have access to for making independent judgments.
If the answer to any of these is “we have not decided yet,” your human oversight is not yet adequate.
Step 5: Define Risk Mitigation Measures
Describe the measures you will take if the identified risks materialise, including internal governance arrangements and complaint mechanisms (Art. 27(1)(f)).
Two categories of measures:
Internal governance: Who is responsible for monitoring the system’s fundamental rights effects on an ongoing basis? What triggers a review? (A complaint? A quarterly audit? A media report?) What is the escalation path? Who has the authority to suspend the system if a rights violation is detected?
Complaint mechanisms for affected persons: How can someone who believes their rights were violated by your AI system raise a concern? Is the mechanism accessible, transparent, and responsive? Does it meet the requirements of Art. 86, which gives affected persons a right to a clear and meaningful explanation of the AI system’s role in the decision?
Step 6: Complete Documentation and Sign Off
Record the date, the assessor’s identity and qualifications, the market surveillance authority notification status, and the next scheduled review date.
The FRIA is not a one-time exercise. Art. 27(2) requires you to update it whenever any element changes or is no longer up to date. A software update from the provider, a change in the population you serve, a new use case for the same system — any of these triggers a review.
Once complete, you must notify the relevant market surveillance authority with the results (Art. 27(3)).
The FRIA Template
Use this template to structure your assessment. Each section corresponds to the legal requirements of Art. 27(1)(a)-(f). Fill in every field. Where guidance notes appear in brackets, replace them with your specific information.
Section 1: System Description
| Field | Your Entry |
|---|---|
| Deployer organization | [Legal name, registration number] |
| AI system name and version | [As provided by the AI system provider] |
| Provider name | [Name of the organization that developed/placed the system on the market] |
| Annex III category | [Area number and sub-area, e.g., “Area 4(a): Recruitment and selection”] |
| Intended purpose (from provider’s instructions for use) | [Copy the intended purpose statement from the provider’s Art. 13 documentation] |
| Your specific use case | [How your organization uses this system — be precise about the business process] |
| Period of use | [Start date and planned duration, e.g., “From September 2026, ongoing”] |
| Frequency of use | [Continuous / daily / weekly / per campaign — specify] |
| EU database registration number | [If registered under Art. 49; note: database not yet publicly accessible] |
Section 2: Affected Persons
| Field | Your Entry |
|---|---|
| Primary affected persons | [Categories: job applicants, patients, welfare claimants, etc.] |
| Secondary affected persons | [Persons indirectly affected: employees, family members, communities] |
| Vulnerable groups identified | [Specific groups: persons with disabilities, ethnic minorities, children, elderly, non-native speakers — list all relevant] |
| Estimated scale of effect | [Number of persons affected per year] |
| Geographic scope | [Which EU Member States / regions] |
Section 3: Fundamental Rights Risk Assessment
Complete one row per identified right. Add rows as needed.
| Fundamental Right | Risk Description | Likelihood (High/Medium/Low) | Severity (High/Medium/Low) | Evidence Basis | Risk Level |
|---|---|---|---|---|---|
| Non-discrimination (Charter Art. 21) | [Describe specific discrimination risks, e.g., “System may score candidates from certain ethnic backgrounds lower due to training data reflecting historical hiring patterns”] | [H/M/L] | [H/M/L] | [Bias audit results, testing data, provider disclosures] | [H/M/L] |
| Privacy and data protection (Charter Art. 7, 8) | [Describe data processing risks beyond DPIA scope] | [H/M/L] | [H/M/L] | [DPIA findings, data inventory] | [H/M/L] |
| Effective remedy (Charter Art. 47) | [Can affected persons challenge decisions? Is the process accessible?] | [H/M/L] | [H/M/L] | [Complaint mechanism audit] | [H/M/L] |
| Human dignity (Charter Art. 1) | [Does the system reduce persons to data points in ways that undermine dignity?] | [H/M/L] | [H/M/L] | [Process review] | [H/M/L] |
| [Domain-specific right] | [Varies by use case — see Step 3 guidance above] | [H/M/L] | [H/M/L] | [Relevant evidence] | [H/M/L] |
Section 4: Human Oversight
| Field | Your Entry |
|---|---|
| Designated oversight role | [Job title and department of the person(s) performing oversight] |
| Training received | [Specific training on the AI system, its limitations, and fundamental rights risks] |
| Override authority | [Can the oversight person override, reverse, or stop the system? Yes/No — describe the mechanism] |
| Time allocated per decision | [Average time available to review each AI-assisted decision] |
| Independent judgment tools | [What information or tools does the reviewer have to form an independent view?] |
| Automation bias safeguards | [What measures prevent the reviewer from rubber-stamping AI outputs?] |
Section 5: Risk Mitigation and Complaint Mechanisms
| Field | Your Entry |
|---|---|
| Risk mitigation measures | [For each high-risk finding in Section 3, describe the specific mitigation] |
| Internal governance owner | [Name/role of person responsible for ongoing fundamental rights monitoring] |
| Review triggers | [Events that trigger a FRIA update: system update, population change, complaint, incident] |
| Escalation path | [Who is notified if a fundamental rights issue is detected? What is the timeline?] |
| Complaint mechanism | [How can affected persons raise concerns? Channel, response time, independence] |
| Art. 86 explanation process | [How do you provide clear, meaningful explanations of the AI’s role in decisions to affected persons?] |
| System suspension criteria | [Under what conditions will the system be suspended pending review?] |
Section 6: Sign-Off and Notification
| Field | Your Entry |
|---|---|
| Assessment date | [Date of completion] |
| Assessor name and role | [Person(s) who conducted the assessment] |
| Assessor qualifications | [Relevant expertise: fundamental rights, AI governance, domain knowledge] |
| Senior management approval | [Name, role, date of approval] |
| Market surveillance authority notified | [Yes/No — if yes, date and authority name] |
| DPIA cross-reference | [If a DPIA was also conducted, reference its identifier and date] |
| Next review date | [Date — must be updated if circumstances change per Art. 27(2)] |
Worked Example A: Healthcare AI for Patient Triage
A municipal hospital in the Netherlands deploys an AI system that triages emergency department patients by severity, recommending priority levels to intake nurses. The system is provided by a commercial vendor and processes patient symptoms, vital signs, and medical history.
Why a FRIA is required: The hospital is a body providing a public service. The system falls under Annex III Area 5(a) (evaluating eligibility for public healthcare services) and Area 5(d) (emergency triage). Both criteria trigger Art. 27.
How the template looks filled in:
Section 1 (System Description): The hospital states the system is used in its emergency department to assign ESI (Emergency Severity Index) levels 1-5. It runs 24/7 and processes approximately 45,000 patient encounters per year. The intended purpose from the provider’s documentation: “Decision-support tool for emergency triage; does not replace clinical judgment.”
Section 2 (Affected Persons): Primary affected persons are emergency department patients. Vulnerable groups include elderly patients (who may present atypically), non-Dutch speakers (whose symptoms may be inadequately captured in text fields), persons with psychiatric conditions (who may be under-triaged by symptom-based models), and children.
Section 3 (Risk Assessment highlights):
| Fundamental Right | Risk | Likelihood | Severity |
|---|---|---|---|
| Non-discrimination (Charter Art. 21) | System trained on historical data may under-triage patients from ethnic minorities whose symptoms present differently than training population | Medium | High |
| Right to health (Charter Art. 35) | Incorrect triage priority could delay life-saving treatment | Low | Critical |
| Human dignity (Charter Art. 1) | Reducing patients to data points without adequate clinical context | Medium | Medium |
| Effective remedy (Charter Art. 47) | Patients unlikely to know AI was involved in triage, limiting ability to challenge | High | Medium |
Section 4 (Human Oversight): Intake nurses review every AI-recommended triage level before assigning it. Nurses received 8 hours of training on the system’s logic and known limitations. Nurses have full authority to override the AI recommendation. Average review time: 90 seconds per patient. Safeguard against automation bias: the system displays its confidence score, and cases below 80% confidence are flagged for senior nurse review.
Section 5 (Risk Mitigation): Monthly bias audits comparing triage outcomes across demographic groups. Patient complaint channel through hospital patient advocate. If disparity detected, system suspended for that patient cohort pending investigation. Quarterly reporting to hospital board. Art. 86 explanations provided through the patient advocate on request.
Worked Example B: Recruitment AI for a National Employment Agency
A national employment agency in France uses an AI system to screen and rank applications for public-sector job postings. The system processes CVs, cover letters, and structured questionnaire responses to produce a ranked shortlist for hiring managers.
Why a FRIA is required: The employment agency is a body governed by public law. The system falls under Annex III Area 4(a) (recruitment and selection). Art. 27 applies.
How the template looks filled in:
Section 1 (System Description): The system screens applications for approximately 12,000 public-sector positions per year across 26 government departments. It runs during each recruitment cycle (average 6 weeks per campaign). The provider’s intended purpose: “Automated CV screening and ranking based on job-relevant criteria; outputs a ranked shortlist for human review.”
Section 2 (Affected Persons): Primary affected persons are job applicants — approximately 380,000 per year. Secondary affected persons include hiring managers (whose professional judgment is shaped by AI rankings) and current employees (workforce composition changes over time). Vulnerable groups: applicants with disabilities (non-standard CV formats, career gaps), applicants with non-French names (name-based bias risk), older applicants (age-correlated career patterns may be penalized), applicants with non-EU educational backgrounds.
Section 3 (Risk Assessment highlights):
| Fundamental Right | Risk | Likelihood | Severity |
|---|---|---|---|
| Non-discrimination (Charter Art. 21) | System may penalize career gaps (correlated with disability, parenting, illness) and non-standard educational paths | High | High |
| Fair working conditions (Charter Art. 31) | AI-mediated access to public employment affects the right to fair conditions in obtaining work | Medium | High |
| Effective remedy (Charter Art. 47) | Rejected applicants receive no explanation of AI’s role in shortlisting; no appeals process specific to AI-assisted decisions | High | High |
| Privacy (Charter Art. 7, 8) | System processes sensitive inferences from CV data (age, ethnicity, disability indicators) | Medium | Medium |
Section 4 (Human Oversight): Each department’s HR lead reviews the AI-generated shortlist. HR leads completed a 12-hour training programme covering bias indicators, override procedures, and the agency’s non-discrimination obligations under French law (Code du travail Art. L1132-1) and the EU Charter. HR leads may add candidates the AI excluded or remove candidates the AI ranked highly. Average review time: 15 minutes per shortlist of 20 candidates. Safeguard: HR leads must document their reasoning if they accept the AI shortlist without modifications.
Section 5 (Risk Mitigation): Annual bias audit by an external auditor comparing selection rates across protected characteristics. Applicant complaint channel through the agency’s equal opportunity office, with a 15-business-day response commitment. If disparate effect detected (four-fifths rule threshold), system suspended for that job category. Art. 86 explanation: every rejected applicant who requests it receives a written explanation of the AI system’s role and the criteria applied.
Common Mistakes to Avoid
Treating the FRIA as a checkbox exercise. The FRA’s 2025 research found that organizations performing impact assessments often treat them as compliance documentation rather than genuine risk analysis. Fill in the template with real findings, not boilerplate. If you cannot identify specific risks, you have not done the analysis.
Confusing FRIA with DPIA. These are different instruments covering different rights. A completed DPIA does not satisfy Art. 27. If your AI system processes personal data and is high-risk under Annex III, you need both. The FRIA must complement the DPIA with additional analysis of non-data rights: equality, dignity, access to remedies, domain-specific rights (EU AI Act Art. 27(4)).
Claiming human oversight exists when it does not. “A human reviews the output” is not human oversight. If that human lacks training, lacks override authority, lacks time, or lacks access to independent information, the oversight is illusory. Document the specifics, or acknowledge the gap and fix it.
Skipping vulnerable group identification. Generic statements like “all applicants are treated equally” miss the point. The FRIA requires you to identify specific categories and groups likely to be affected (Art. 27(1)(c)). If your system affects job applicants, which job applicants face heightened risk? Name them.
Forgetting the notification requirement. Completing the FRIA is not enough. You must notify the market surveillance authority with the results (Art. 27(3)). Missing this step means non-compliance even if your assessment was thorough.
Not updating the FRIA. Art. 27(2) requires updates whenever elements change. A provider issues a software update that changes the model? Update the FRIA. You expand the system to a new department? Update the FRIA. Treat it as a living document.
FRIA vs DPIA: How They Differ
This is the question we get most often. Here is the definitive comparison.
| Dimension | FRIA (EU AI Act Art. 27) | DPIA (GDPR Art. 35) |
|---|---|---|
| Legal basis | EU AI Act Art. 27 | GDPR Art. 35 |
| Trigger | Deployment of Annex III high-risk AI by specified deployers | Processing likely to result in high risk to data protection rights |
| Rights covered | Full spectrum: privacy, equality, non-discrimination, dignity, effective remedy, workers’ rights, children’s rights, health | Data protection and privacy specifically |
| Who performs | Deployer | Data controller |
| Timing | Before first use; update when elements change | Before processing begins; review when nature/scope changes |
| Can one replace the other? | No. Art. 27(4) is explicit: FRIA must complement DPIA | No. Both remain independently mandatory |
| Template | AI Office developing template (not yet published as of March 2026) | Available from CNIL, ICO, EDPB, and most national DPAs |
| Notification | Must notify market surveillance authority with completed FRIA | Must consult DPA only if high residual risk remains after mitigation |
| Scope | AI system’s effect on fundamental rights of affected persons | Processing activity’s effect on data protection rights |
When you need both: If your AI system is high-risk under Annex III, you are a deployer covered by Art. 27, and the system processes personal data in a way that triggers a DPIA, both are mandatory. Most Annex III systems processing personal data will trigger both.
How to manage them together: Conduct the DPIA first. It will generate findings on data protection risks that feed into the FRIA. Then conduct the FRIA, using the DPIA’s data protection findings as input and adding analysis of non-data rights. Cross-reference the two documents. Do not duplicate effort, but do not skip the FRIA’s broader scope.
We recommend assigning the DPIA to your Data Protection Officer and the FRIA to your AI Compliance Officer or the team member responsible for AI governance. The DPO can contribute to the FRIA but should not own it alone — the FRIA covers rights beyond data protection expertise.
What to Do This Week
The August 2, 2026 deadline is roughly four months away. Here is a prioritised action list.
Monday: Determine if Art. 27 applies to you. Check the three criteria above. Are you a public body, a public-service provider, or a deployer of credit scoring or insurance pricing AI? If yes, Art. 27 applies. If no, consider doing a voluntary FRIA anyway.
Tuesday-Wednesday: Inventory your high-risk AI systems. List every AI system your organization deploys that falls under an Annex III category. For each system, gather the provider’s instructions for use and intended purpose statement.
Thursday: Assign FRIA ownership. Designate who will conduct each FRIA. We recommend a team that includes someone with fundamental rights or legal expertise, someone with technical understanding of the AI system, and someone from the business unit that uses the system.
Friday: Start your first FRIA. Pick the system with the highest risk profile and complete the template above. Your first FRIA will take 4-8 hours. Subsequent ones will be faster because you will have the process established.
Next week: Review human oversight. For every high-risk AI system, verify that your human oversight measures meet the specificity test in Step 4. If your oversight consists of “a person checks the output,” that is not enough. Document who, what training, what authority, how much time, and what tools.
Ongoing: Watch for the official template. When the AI Office publishes the Art. 27(5) template, you will need to transpose your FRIA into that format for the market surveillance authority notification. Bookmark the AI Act Service Desk for updates.
Disclaimer: This content is for informational and educational purposes only. It does not constitute legal advice. AI regulation varies by jurisdiction and changes frequently. Consult qualified legal counsel for advice specific to your organization’s circumstances and jurisdiction. Reg-Intel is not a law firm and does not provide legal services.
Jurisdiction note: This content covers the EU exclusively. The FRIA obligation under Art. 27 applies to deployers subject to the EU AI Act. For jurisdiction-specific compliance decisions, consult local legal counsel familiar with the applicable regulatory framework.
Last verified: 2026-04-10