FRIA template: what to include in a fundamental rights impact assessment
The AI Act implementation roadmap already points toward FRIA support materials. This page translates that into a practical template structure for teams.
A FRIA (Fundamental Rights Impact Assessment) under Article 27 of the EU AI Act is a structured process that deployers of certain high-risk AI systems must complete before putting the system into use. It identifies potential adverse impacts on people’s fundamental rights (such as non-discrimination, privacy, dignity, and fair treatment) and documents the mitigations needed to address them.
This operational FRIA template, evidence guide, and worked recruitment screening example help teams move from legal text to practical documentation. It aligns with the requirements in Article 27 while the European AI Office finalizes its official guidelines and template during 2026.[1][2]
Use it as a living document that informs deployment decisions, not a compliance checkbox.
Current law status (May 2026) Article 27 of the EU AI Act requires deployers of high-risk AI systems (listed in Annex III) to carry out a fundamental rights impact assessment in specified cases — particularly when the deployer is a public authority, provides public services, or the use involves processing that may significantly affect rights. The assessment must occur prior to first use and be updated where relevant. High-risk obligations follow the phased timeline, with the AI Office preparing supporting guidelines including a template in the course of 2026. This page provides a practical, ready-to-use framework based on the legal text and official implementation support materials. It is not legal advice, nor a substitute for the forthcoming official template. Proposed simplifications or timeline adjustments under the Digital Omnibus are labeled separately where relevant and do not alter the core Article 27 obligation.
When a FRIA matters
A FRIA enters the conversation the moment your organization acts as a deployer of a high-risk AI system under Annex III of the AI Act and meets one of the triggers in Article 27. This typically includes public bodies, private operators providing public services, or uses that process special-category data or could disproportionately affect vulnerable groups.[3]
It matters first for teams in recruitment, credit scoring, education, insurance, law enforcement, and public service delivery. If you are evaluating, procuring, or integrating an AI tool that makes or supports decisions about access to jobs, loans, education, benefits, or justice, a FRIA helps you understand concrete impacts on people before deployment or continued use.
Unlike general risk registers, a FRIA focuses specifically on EU Charter of Fundamental Rights impacts (non-discrimination, privacy, data protection, dignity, equality, effective remedy, and others). It forces explicit consideration of affected persons, severity, likelihood, and human oversight — turning abstract rights into operational safeguards.
See also: Annex III high-risk AI systems: the categories to watch for classification help and Recruitment AI and the EU AI Act or Credit scoring, insurance, and essential-service AI for sector-specific context.
The forthcoming official guidelines will provide further clarity on practical application and a template. Until then, this framework gives deployers a structured starting point that maps directly to Article 27 expectations.
The core FRIA sections
A strong FRIA contains these core elements. Treat it as a living record updated throughout the system lifecycle.
The table below translates the legal obligation into practical questions and evidence requests. It expands on the elements in Article 27 (description of the system, intended purpose and use context, affected persons, potential impacts on fundamental rights, severity and likelihood, and mitigation measures).
FRIA template outline
| Section | Question to answer | Evidence to attach |
|---|---|---|
| System and purpose | What is the AI system? What is its intended purpose, capabilities, limitations, and how will it be used in our specific context? | Provider technical documentation, instructions for use, deployment architecture diagram, intended use statement |
| Affected persons | Who are the directly and indirectly affected individuals or groups? Which vulnerable groups (e.g. by age, disability, ethnicity, socioeconomic status) may be disproportionately impacted? | Stakeholder map, data protection impact assessment excerpts, user personas, demographic analysis of target population |
| Decision context | In what real-world decision process is the AI embedded? What human role remains? What are the consequences of an incorrect or biased output? | Process flow diagram, human oversight protocol, description of appeal or review routes |
| Rights impacts | Which fundamental rights (non-discrimination, privacy, dignity, equality of opportunity, effective remedy, etc.) could be adversely affected? How? | Rights mapping table, legal analysis referencing EU Charter and relevant case law |
| Severity / likelihood | For each identified risk scenario, what is the potential severity and likelihood of harm? Use consistent scales (e.g. negligible–catastrophic; rare–almost certain). | Risk scoring methodology, testing or audit reports, historical incident data from similar systems |
| Mitigations | What technical, organizational, and procedural measures reduce each risk to an acceptable level? How will effectiveness be measured? | Mitigation plan with assigned owners, test results (fairness metrics, robustness tests), updated instructions for use |
| Human oversight | How is meaningful human oversight designed? What information, tools, and training do overseers receive? How are they protected from automation bias? | Oversight procedures, training records, competency matrix, override logging mechanism |
| Governance & review cycle | Who owns the FRIA? What is the review cadence (e.g. annually or after substantial modification)? What escalation routes exist for new risks or incidents? | Governance policy excerpt, post-market monitoring plan, version-controlled FRIA register, incident response procedure |
This structure ensures the FRIA remains connected to real deployment decisions rather than becoming a static appendix.
How to gather evidence
A credible FRIA stands on verifiable evidence, not assumptions. Focus on artifacts you can realistically obtain or generate.
Key evidence types and collection methods:
- Stakeholder inputs: Conduct structured interviews or workshops with affected persons or their representatives, frontline users (e.g. recruiters, loan officers), and internal compliance teams. Use prompts such as: “Walk me through a typical case. Where could the AI output lead to unfair treatment?” Document anonymized feedback and attendance records.
- Vendor / provider documentation: Request the provider’s technical documentation, risk management summary, dataset descriptions, fairness testing results, and instructions for use. Ask specifically for any existing fundamental rights analysis or bias audits. Cross-check against your intended use context.
- Human oversight design: Document the exact information provided to human reviewers, override mechanisms, training programs, and performance metrics for oversight (e.g. override rate, time to review). Include logs or mock scenarios showing oversight in action.
- Appeal or review routes: Map exactly how an individual can understand, contest, or seek human review of an AI-supported decision. Record the communication template sent to data subjects and the internal escalation workflow.
- Metrics and testing records: Collect fairness metrics (e.g. demographic parity, equalized odds), accuracy by subgroup, robustness test results, and cybersecurity assessments. Require providers to share disaggregated performance data where possible.
- Internal records: Include data protection impact assessments (DPIA), previous internal audits, post-market monitoring plans, and incident logs from pilot deployments.
Store everything in a version-controlled repository. The EU AI Act Evidence Scanner can help flag missing or weak artifacts early.
Where evidence gaps exist, note them explicitly in the FRIA and treat them as risks until closed.
A worked example
Scenario: A mid-sized financial services company deploys an AI-powered recruitment screening tool (Annex III point 4) to evaluate CVs and initial interview transcripts for customer service roles. The tool scores candidates on “cultural fit,” communication skills, and predicted retention. It supports — but does not fully automate — shortlisting. The company is a private deployer but handles large volumes of applications and processes personal data including inferred characteristics.
Summary of key FRIA entries (abridged for illustration):
- System and purpose: AI tool analyzes textual and video inputs to produce a 0–100 compatibility score and ranked shortlist. Intended to reduce screening time while maintaining quality. Limitations: trained primarily on historical successful hires (risk of past bias perpetuation).
- Affected persons: Job applicants (especially younger candidates, non-native speakers, people with disabilities affecting speech or CV format, ethnic minorities). Indirectly affects current employees involved in hiring.
- Rights impacts: Non-discrimination (Article 21 Charter), equality of opportunity, dignity (if biased outputs lead to stereotyping), right to effective remedy (if applicants cannot understand or contest decisions).
FRIA example risk log
| Risk | Who is affected | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| False negative for qualified applicants (e.g. non-traditional CVs rejected) | Candidates from underrepresented educational backgrounds or with career gaps | Medium | High | Human review of all scores below threshold; regular fairness testing on new applicant cohorts | HR Director |
| Bias risk (model perpetuates historical gender or ethnic patterns in “cultural fit”) | Female applicants, ethnic minorities, older candidates | High | High | Disaggregated performance metrics reviewed quarterly; diverse training data augmentation where possible; independent bias audit annually | Compliance Lead & AI Vendor |
| Lack of contestability | All applicants | Medium | Medium | Automated explanation generated for every rejection; clear appeal route via human recruiter within 14 days; plain-language rejection notice | Recruitment Manager |
| Poor user understanding (recruiters over-rely on score without scrutiny) | Recruiters and ultimately candidates | Medium | Medium | Mandatory training on automation bias; override rate monitored monthly; “explainability dashboard” provided | Learning & Development Lead |
This example shows how the FRIA drives concrete actions: updated vendor contract clauses for ongoing fairness data, new recruiter training module, modified candidate communication, and a six-month review cycle. The completed FRIA is stored centrally and referenced in the organization’s quality management system.
The same approach applies to education/proctoring or credit-scoring support uses — always ground the assessment in your specific deployment context.
Common mistakes
- Treating the FRIA as a one-off legal exercise instead of a living operational tool reviewed after substantial modifications or new evidence of harm.
- Copying the provider’s generic risk assessment without adapting it to your use context, affected population, or oversight setup.
- Focusing exclusively on technical accuracy while neglecting dignity, equality of opportunity, or effective remedy.
- Failing to collect or retain sufficient evidence, leaving the organization unable to demonstrate compliance during audits or investigations.
- Omitting meaningful input from affected persons or their representatives, resulting in blind spots about real-world impacts.
- Setting unrealistic review cycles (e.g. “every five years”) that do not match the pace of model updates or incident reporting.
- Confusing provider and deployer responsibilities — the deployer owns the site-specific FRIA even when the provider supplies supporting documentation.
Action checklist
- Confirm whether your AI system is high-risk and whether Article 27 triggers apply (use the classification guidance on the AI Act Service Desk).
- Request and review all available provider documentation early in procurement.
- Map affected persons and relevant Charter rights specific to your deployment context.
- Run initial risk scenarios with cross-functional input (legal, technical, operations, and where possible external stakeholders).
- Document mitigations with clear owners, metrics, and testing plans.
- Design and record human oversight processes before first use.
- Store the FRIA and supporting evidence in a centralized, version-controlled location.
- Schedule the first review cycle and integrate it into your post-market monitoring activities.
- Run your evidence package through the EU AI Act Evidence Scanner to identify gaps before final sign-off.
Ready to operationalize your FRIA? Use the EU AI Act Evidence Scanner to validate your documentation or download our free sample completed FRIA report for a recruitment screening use case. It shows exactly how the template populates in practice and links directly to the artifacts you should retain.
Frequently asked questions
Do all AI systems need a FRIA? No. The obligation applies only to deployers of certain high-risk AI systems under the specific conditions set out in Article 27. Most limited-risk or minimal-risk systems do not require one. GPAI models as such are not subject to this deployer obligation.
Can a vendor provide enough input for our FRIA? Vendors can and should supply substantial supporting material (technical documentation, testing results, risk summaries). However, the deployer remains responsible for the context-specific assessment, including local affected persons, oversight design, appeal routes, and ongoing monitoring. A vendor package alone is rarely sufficient.
What evidence makes a FRIA stronger? Concrete, disaggregated test results; documented stakeholder input; version-controlled mitigation plans with assigned owners and effectiveness metrics; clear human oversight procedures with training records; and a realistic review cadence tied to post-market monitoring. Auditor-friendly evidence shows decisions were informed by data, not assumptions.
Sources
- AI Act Service Desk – Article 27: Fundamental rights impact assessment for high-risk AI systems (ai-act-service-desk.ec.europa.eu)
- European Commission: Supporting the implementation of the AI Act with clear guidelines (digital-strategy.ec.europa.eu, 4 December 2025)
- Regulation (EU) 2024/1689 (eur-lex.europa.eu)
- AI Office and governance pages (digital-strategy.ec.europa.eu)
All legal statements are anchored exclusively in these primary official EU sources. This page is for operational readiness and does not constitute legal advice.
Turn this reading into an actionable report
Use the free scanner to map your likely role, detect likely obligations, and see which evidence is missing.