The EU AI Act introduces a powerful new compliance tool that many organizations are only beginning to understand: the Fundamental Rights Impact Assessment, or FRIA. Unlike technical conformity assessments that focus on system specifications, the FRIA requires deployers to examine how their AI systems affect the fundamental rights of real people - from privacy and non-discrimination to human dignity and access to justice. With high-risk obligations arriving across the phased EU AI Act rollout, organizations deploying high-risk AI systems need to understand not just what a FRIA is, but how to conduct one effectively. This guide provides a comprehensive framework, practical templates, and industry-specific examples to help you meet your obligations under Article 27 of the EU AI Act. One timing note up front: in May 2026 EU lawmakers provisionally agreed to defer the high-risk deadlines (see the updated timeline below). The FRIA requirement itself is unchanged, and until that deferral becomes law the original 2 August 2026 date still applies — so the practical advice is to keep preparing. You can build a draft assessment in minutes with our free FRIA generator.
What is a Fundamental Rights Impact Assessment (FRIA)?
A Fundamental Rights Impact Assessment is a systematic evaluation process designed to identify, assess, and mitigate potential adverse impacts of high-risk AI systems on individuals' fundamental rights. Mandated under Article 27 of the EU AI Act, the FRIA represents the world's first legally binding impact assessment specifically focused on AI and fundamental rights.
The FRIA examines potential impacts across the full spectrum of rights protected under the EU Charter of Fundamental Rights, including human dignity (Article 1), right to life and integrity (Articles 2-3), respect for private and family life (Article 7), protection of personal data (Article 8), non-discrimination (Article 21), equality between women and men (Article 23), rights of the child, elderly, and persons with disabilities (Articles 24-26), freedom of expression (Article 11), and right to an effective remedy and fair trial (Article 47).
The assessment serves as a proactive measure, helping organizations identify and address potential harms before they occur. When properly conducted, a FRIA not only ensures regulatory compliance but also provides ethical assurance and a defensible position with regulators and courts.
FRIA vs. DPIA: Understanding the Key Differences
Many organizations mistakenly assume that a FRIA is simply a new name for the Data Protection Impact Assessment (DPIA) already required under GDPR. While both assessments evaluate risk and share methodological similarities, they differ substantially in scope and focus.
The DPIA under GDPR Article 35 is primarily focused on data protection and privacy (Articles 7-8 of the Charter), triggered by high-risk processing of personal data, with the data controller as responsible party. The FRIA under AI Act Article 27 covers all fundamental rights in the EU Charter, triggered by deployment of high-risk AI systems, with the deployer as responsible party - and applies regardless of whether personal data is involved.
The EU AI Act explicitly acknowledges this complementary relationship. Article 27(4) states that if obligations under the FRIA are already met through a DPIA conducted under the GDPR, the FRIA should complement that assessment. In practice, organizations will often conduct both assessments concurrently and may consolidate them into a single integrated report - but the FRIA scope is fundamentally broader.
A crucial methodological difference is that the FRIA requires evaluation by fundamental right. It is not permissible to offset a negative impact on one right (such as non-discrimination) with a positive impact on another right (such as operational efficiency). Each right must be assessed independently.
| Dimension | DPIA — GDPR Article 35 | FRIA — AI Act Article 27 |
|---|---|---|
| Primary focus | Data protection and privacy (Charter Articles 7-8) | All fundamental rights in the EU Charter |
| Trigger | High-risk processing of personal data | Deployment of an in-scope high-risk AI system |
| Responsible party | Data controller | Deployer |
| Personal data required? | Yes — the assessment is about personal data | No — applies even when no personal data is processed |
| Assessment method | Overall risk to data subjects | Right-by-right; no offsetting one right against another |
| Relationship | Can be reused as input to a FRIA | Complements — does not replace — a DPIA (Art 27(4)) |
When is FRIA Required Under the EU AI Act?
The obligation to conduct a FRIA does not apply to every deployer of a high-risk AI system. Article 27 establishes specific categories of deployers who must complete this assessment.
Public bodies governed by public law must conduct a FRIA before deploying high-risk AI systems listed in Annex III. Such bodies are established to meet needs in the general interest, have legal personality, are financed mainly by the state or public authorities, or are subject to management supervision by public authorities.
Private entities providing public services also fall within scope. This includes entities operating in education, healthcare, social services, housing, and administration of justice. The broad term "public services" without defining criteria suggests legislative intent to cover any deployer whose services reasonably affect the public interest.
Regardless of public or private status, deployers must conduct FRIAs for AI systems intended to evaluate creditworthiness or establish credit scores (except those used for detecting financial fraud), and AI systems for risk assessment and pricing in life and health insurance.
- Public bodies using high-risk AI for public services
- Private entities providing essential services (education, healthcare, social services, housing)
- All deployers using AI for creditworthiness evaluation or credit scoring
- All deployers using AI for life and health insurance risk assessment and pricing
High-Risk AI Categories Subject to FRIA
For public bodies and private entities providing public services, FRIAs are required for AI systems across most Annex III categories.
Category 1 (Biometrics) covers remote biometric identification systems, biometric categorization based on sensitive attributes, and emotion recognition systems. Category 3 (Education) includes systems determining access or admission to educational institutions, evaluating learning outcomes, assessing appropriate education levels, and monitoring prohibited behavior during tests.
Category 4 (Employment) covers recruitment and selection systems, systems affecting work-related decisions (promotion, termination, task allocation), and performance monitoring and evaluation systems. Category 5 (Essential Services) includes systems evaluating eligibility for public assistance benefits, creditworthiness evaluation, life and health insurance risk assessment, and emergency call classification and dispatch.
Category 6 (Law Enforcement) covers victim risk assessment, polygraph-type systems, evidence reliability evaluation, offending risk assessment, and profiling systems. Category 7 (Migration) includes risk assessment systems, asylum and visa application examination, and identification systems. Category 8 (Justice) covers systems assisting judicial authorities and alternative dispute resolution.
One notable exemption: AI systems used as safety components in critical digital infrastructure, road traffic, or utility supply are not subject to FRIA requirements.
FRIA Template: Key Sections
Article 27(1) specifies the mandatory elements that every FRIA must contain. Under Article 27(5), the European AI Office must develop an official template questionnaire (including an automated tool) — but as of June 2026 it has not yet been published, and its absence does not excuse the obligation. In the meantime, structure your assessment around the six required components below. The European Center for Not-for-Profit Law (ECNL) and the Danish Institute for Human Rights also published A Guide to Fundamental Rights Impact Assessments (December 2025), with a downloadable template and a five-phase methodology built directly on the Article 27(1) elements — useful practitioner guidance while the official tool is pending (it is civil-society guidance, not a binding EU template). To produce a structured draft quickly, use our free FRIA generator or download the template.
Section 1 covers System Description and Intended Purpose. Document the deployer's processes in which the AI system will be used, aligned with its intended purpose as defined by the provider. Required information includes name and version of the AI system, provider contact information, clear description of intended purpose, specific use cases within your organization, operational context and environment, and technical specifications relevant to rights impacts.
Section 2 covers Duration and Frequency of Use. Document planned deployment start date, expected duration (indefinite, fixed term, pilot), frequency of system use (continuous, periodic, event-triggered), volume metrics (number of decisions per day/week/month), and geographic scope.
Section 3 covers Categories of Affected Persons. Identify direct users, individuals subject to AI-driven decisions, third parties indirectly affected, and specific demographic groups. Vulnerable populations requiring special attention include children, elderly, persons with disabilities, socioeconomically disadvantaged groups, minority ethnic or religious groups, non-native language speakers, and individuals with limited digital literacy.
Section 4 covers Specific Risks to Fundamental Rights. For each potentially affected right, evaluate likelihood (rare to almost certain), severity (negligible to catastrophic), reversibility (easily reversible to irreversible), and scale of affected population (individual to society-wide).
Section 5 covers Human Oversight Measures. Document designated individuals responsible for oversight, qualifications and training requirements, intervention capabilities, escalation procedures, monitoring protocols, and documentation requirements.
Section 6 covers Risk Mitigation Measures. Include technical measures (bias testing, accuracy thresholds, data quality controls, logging), organizational measures (governance structures, policies, training, review cycles), and procedural safeguards (right to human review, complaint mechanisms, accessible redress channels, fallback procedures).
| Section | What to document | Basis |
|---|---|---|
| 1. System description & intended purpose | Deployer's processes, intended purpose, provider, operational context | Art 27(1)(a) |
| 2. Duration & frequency of use | Start date, duration, frequency, volume, geographic scope | Art 27(1)(b) |
| 3. Categories of affected persons | Direct subjects, third parties, and vulnerable groups | Art 27(1)(c) |
| 4. Specific risks to fundamental rights | Risk register: each right, harm scenario, likelihood, severity, mitigation, residual risk | Art 27(1)(d) |
| 5. Human oversight measures | Oversight roles, intervention powers, qualifications and training | Art 27(1)(e) |
| 6. Measures if risks materialise | Technical & organizational measures, complaint/redress, authority notification | Art 27(1)(f) |
How to Conduct a FRIA: Step-by-Step Guide
Step 1: Determine FRIA Applicability. Confirm that a FRIA is required by checking if your AI system is classified as high-risk under Article 6 and Annex III, whether your organization is a public body or private entity providing public services, or whether the AI system falls under Annex III point 5(b) or (c) for credit or insurance assessment.
Step 2: Gather Information from the AI Provider. The FRIA process depends heavily on information that providers are required to supply under Articles 11-13, including technical documentation per Annex IV, instructions for use, system capabilities and limitations, known risks and mitigation measures, and data about training datasets and potential biases.
Step 3: Assemble Your Assessment Team. FRIAs require diverse expertise including legal/compliance professionals, data protection officers, technical experts, domain experts (HR, healthcare, finance), representatives who understand affected communities, and risk management professionals.
Step 4: Map Affected Individuals and Rights. List all categories of individuals who interact with or are affected by the system, identify which fundamental rights could be impacted for each category, and consider both direct and indirect impacts.
Step 5: Conduct the Risk Assessment. For each identified right-at-risk, describe the potential harm scenario, assess likelihood and severity, assign a risk level, and document your reasoning and evidence.
Step 6: Design Mitigation Measures. For each identified risk, propose specific measures, assess feasibility, evaluate residual risk after mitigation, document responsibility for implementation, and establish monitoring mechanisms.
Steps 7-9: Document human oversight arrangements, establish complaint and redress mechanisms, and obtain review and approval from legal counsel and organizational leadership.
Step 10 - Notify the market surveillance authority. Under Article 27(3), once the FRIA is performed the deployer must notify the relevant market surveillance authority of its results, submitting the filled-out Article 27(5) template as part of the notification (and, until that template is published, your own documentation against the Article 27(1) criteria). The notification tells the authority a high-risk system is in use and that a rights assessment was completed. The only exemption is the narrow case in Article 46(1) — where an authority has authorized placing a system on the market for exceptional reasons such as public security or the protection of life and health — and even then only for a limited period. Routine deployments are not exempt; there is no general "law enforcement" or "operational confidentiality" carve-out.
FRIA Examples by Industry
Financial Services Credit Scoring Example: A bank deploying AI for creditworthiness assessment must identify affected groups (loan applicants, with higher risk to historically underserved populations), primary rights at risk (non-discrimination, right to property, access to essential services), risk factors (training data may reflect historical biases, proxy variables could correlate with protected characteristics), and implement mitigation measures including regular bias audits, alternative assessment pathways, human review for borderline cases, and clear explanations of decision factors.
Healthcare AI Triage Example: A hospital emergency department using AI to prioritize patient care must address affected groups (all emergency patients, with heightened concern for elderly, disabled, non-native speakers), primary rights (right to life, healthcare access, human dignity, non-discrimination), risk factors (potential bias in symptom recognition across demographic groups), and ensure AI serves as decision support only with mandatory human clinical assessment.
HR Recruitment Screening Example: A corporation using AI to screen CVs must consider affected groups (all applicants, particularly those with non-traditional backgrounds, career gaps, foreign qualifications), primary rights (non-discrimination, right to work, equality between women and men), risk factors (historical hiring data may encode biases), and implement measures including anonymization of protected characteristics, regular bias testing, and human review of rejected applications in underrepresented groups.
Scoring FRIA Risks: Likelihood x Severity
For each identified risk, rate the likelihood that the harm occurs and its severity if it does. A simple matrix turns those two judgments into a single risk level you can prioritize and track. Use a consistent scale across the whole assessment, and record the reasoning behind each rating - regulators care as much about your method as your conclusions.
| Likelihood / Severity | Negligible | Minor | Moderate | Major | Catastrophic |
|---|---|---|---|---|---|
| Rare | Low | Low | Low | Medium | Medium |
| Unlikely | Low | Low | Medium | Medium | High |
| Possible | Low | Medium | Medium | High | High |
| Likely | Medium | Medium | High | High | Critical |
| Almost certain | Medium | High | High | Critical | Critical |
Worked Example: A Completed FRIA Risk Register
Section 4 is where a FRIA becomes concrete. The register below shows how a bank deploying an AI creditworthiness system might document its risks - each fundamental right at stake, the harm scenario, a likelihood and severity rating, the mitigation, and the residual risk that remains afterward. This is the level of specificity regulators and courts expect, and exactly what the FRIA generator produces.
| Fundamental right | Harm scenario | Likelihood | Severity | Risk | Mitigation | Residual |
|---|---|---|---|---|---|---|
| Non-discrimination (Art 21) | Training data reflects historical bias; proxy variables (e.g. postcode) correlate with protected characteristics, producing disparate decline rates. | Possible | Major | High | Quarterly disparate-impact testing; remove or transform proxy features; human review of all declines for underrepresented groups. | Medium |
| Access to essential services / property | An erroneous low score wrongly denies credit, limiting access to housing or essential purchases. | Unlikely | Major | Medium | Alternative manual-assessment pathway; human override; clear adverse-action explanation to the applicant. | Low |
| Protection of personal data (Art 8) | Excessive or inaccurate personal data degrades the fairness and accuracy of the decision. | Possible | Moderate | Medium | Data-minimisation review; integration with the GDPR DPIA; data-quality controls aligned with Article 10. | Low |
Integrating FRIA with Other Compliance Requirements
Alignment with GDPR DPIA: When an AI system processes personal data, you likely need both a DPIA and a FRIA. Strategies include conducting concurrently, building on existing DPIA and extending to additional rights, using consistent risk assessment frameworks, consolidating documentation, and coordinating oversight measures.
Connection to Annex IV Technical Documentation: Deployers conducting FRIAs should request Annex IV documentation from providers, use provider risk assessments as input, verify that provider-documented measures are implemented in your deployment context, and document any deployment-specific risks not covered by provider documentation.
Relationship to Conformity Assessment: While conformity assessment is primarily a provider obligation, deployers should verify the AI system has completed conformity assessment, understand what it covered, and recognize that conformity assessment addresses technical requirements while FRIA addresses deployment-specific fundamental rights impacts.
EU Database Registration: High-risk AI systems must be registered in the EU database under Article 71. Ensure your system is properly registered by the provider and that registration information is consistent with your FRIA documentation.
Penalties and Enforcement
Non-compliance with deployer obligations exposes organizations to the middle penalty tier of the EU AI Act: fines up to EUR 15 million or 3% of total worldwide annual turnover, whichever is higher (Article 99(4)). That sits below the top tier of EUR 35 million or 7% reserved for breaches of the Article 5 prohibitions (Article 99(3)). One nuance worth flagging for accuracy: Article 99(4) enumerates the deployer-obligations provision (Article 26) but does not expressly name Article 27 (the FRIA). The prevailing practitioner reading is that a FRIA failure is a deployer-obligation breach falling in this same EUR 15M / 3% tier, but the textual gap is real, and Member State penalty rules (Article 99(1)-(2)) also apply. SMEs and start-ups are capped at the lower of the percentage or the fixed amount (Article 99(6)). Market surveillance authorities have the power to investigate and require corrective actions.
Beyond formal penalties, failing to conduct proper FRIAs creates reputational risk from fundamental rights violations, legal liability if harms materialize, and operational risk if authorities require system modifications or discontinuation.
Timeline and Next Steps
The EU AI Act applies in phases. The Article 5 prohibitions and AI-literacy duties have applied since 2 February 2025; general-purpose AI (GPAI) model obligations, the governance rules, and the penalty framework since 2 August 2025. High-risk obligations — including the Article 27 FRIA — were originally set to apply from 2 August 2026 for stand-alone Annex III systems, and 2 August 2027 for high-risk AI embedded in regulated products.
In November 2025 the Commission proposed the Digital Omnibus simplification package, and on ~7 May 2026 the Council and European Parliament reached a provisional political agreement to defer the high-risk deadlines to two fixed dates: 2 December 2027 for stand-alone Annex III systems and 2 August 2028 for product-embedded ones. Crucially, this is not yet law. It still requires endorsement by the Parliament and Council, legal-linguistic revision, and publication in the Official Journal (targeted before 2 August 2026). The deferred dates take legal effect only on publication — so until then, 2 August 2026 remains the binding FRIA date, and you should keep preparing on that basis.
Note what the Omnibus does not defer: the Article 50 transparency obligations (disclosing that users are interacting with AI, and marking AI-generated content and deepfakes) still apply from 2 August 2026. The only concession is a short grace period for the machine-readable marking of generative systems already on the market, extended to 2 December 2026. In short: the FRIA timing moves, transparency timing does not.
| Obligation | Original date | After Digital Omnibus* |
|---|---|---|
| Prohibited practices (Art 5) + AI literacy | 2 Feb 2025 | Unchanged |
| GPAI models, governance, penalties | 2 Aug 2025 | Unchanged |
| Transparency (Art 50) | 2 Aug 2026 | Unchanged (marking grace to 2 Dec 2026) |
| FRIA + high-risk, stand-alone (Annex III) | 2 Aug 2026 | 2 Dec 2027 |
| High-risk embedded in products (Annex I) | 2 Aug 2027 | 2 Aug 2028 |
A Practical FRIA Preparation Roadmap
12+ months before your applicable date: Inventory all AI systems, classify by risk level, identify which require FRIAs, begin collecting information from providers, and establish governance structures.
6-12 months before: Develop FRIA templates and procedures, train personnel, conduct pilot FRIAs, and implement technical measures for human oversight.
3-6 months before: Complete FRIAs for all in-scope systems, document mitigation measures and verify implementation, establish complaint and redress mechanisms, and prepare your Article 27(3) notification submissions.
Ongoing after compliance: Monitor AI systems for changes requiring FRIA updates, track regulatory guidance from the AI Office (including the awaited official template), conduct periodic reviews, and maintain documentation and audit trails.
Frequently Asked Questions
What is the difference between FRIA and DPIA?
The DPIA under GDPR Article 35 focuses specifically on data protection and privacy rights when processing personal data. The FRIA under AI Act Article 27 has a broader scope, assessing impacts on all fundamental rights in the EU Charter - including non-discrimination, dignity, freedom of expression, access to justice, and many others. Additionally, FRIAs may be required even when no personal data is processed. While organizations can integrate both assessments, the FRIA will typically require additional analysis beyond what a DPIA covers.
Who is responsible for conducting FRIA?
The FRIA obligation falls on deployers of high-risk AI systems, not providers. However, providers play a supporting role by supplying the information deployers need to complete their assessments. In practice, deployers may rely on previously conducted FRIAs or impact assessments from providers if the circumstances are sufficiently similar - but the ultimate responsibility and accountability remains with the deployer.
How often must FRIA be updated?
The FRIA must be conducted before first deployment of the high-risk AI system. Updates are required whenever the deployer determines that any assessed elements have changed or are no longer current. This includes changes to the AI system itself, changes in deployment context, changes in affected populations, or new information about risks. Organizations should establish periodic review cycles to proactively identify when updates are needed.
Does the AI Office provide an official FRIA template?
Article 27(5) requires the European AI Office to develop a template questionnaire, including an automated tool, to help deployers comply. As of June 2026 this official template has not yet been published, and there is no hard deadline for it - but its absence does not excuse the FRIA obligation. In the meantime, build your assessment around the Article 27(1) elements. The ECNL and the Danish Institute for Human Rights published A Guide to Fundamental Rights Impact Assessments (December 2025) with a practitioner template, and you can generate a structured draft now with our free FRIA generator. When the official template is released, align your assessments to it.
Has the Digital Omnibus delayed the FRIA deadline?
Effectively yes - but it is not yet final. The EU's Digital Omnibus, provisionally agreed in May 2026, would move the high-risk application date (which the FRIA tracks) from 2 August 2026 to 2 December 2027 for stand-alone Annex III systems. However, the agreement is not yet law: it must still be formally adopted and published in the Official Journal. Until then the original 2 August 2026 date is legally binding, so prudent deployers keep preparing now. The Omnibus changes the timing, not the substance, of Article 27.
Do you have to notify anyone after completing a FRIA?
Yes. Under Article 27(3), after performing the FRIA the deployer must notify the relevant market surveillance authority of its results, submitting the Article 27(5) template once it exists (and your own documentation until then). The only exemption is the narrow Article 46(1) case - a system authorized for exceptional reasons such as public security or protection of life and health - and only for a limited period. Routine deployments are not exempt.
Can we use an existing DPIA to satisfy FRIA requirements?
Partially. Article 27(4) allows deployers to build on existing DPIAs when conducting FRIAs. If certain FRIA obligations are already met through a DPIA, the FRIA should complement rather than duplicate that assessment. However, given the FRIA broader scope covering all fundamental rights (not just data protection), additional analysis will almost always be required beyond what a DPIA covers.
What happens if we identify high risks that cannot be mitigated?
Unlike GDPR DPIAs, the FRIA is primarily a documentation requirement and does not have the power to block deployment of a high-risk AI system regardless of identified risks. However, deploying systems with unmitigated high risks to fundamental rights creates significant legal, reputational, and operational exposure. Organizations should carefully consider whether deployment is advisable when substantial risks cannot be adequately addressed.
Key Takeaways
The FRIA represents a significant new compliance requirement, but it is also an opportunity to demonstrate responsible AI deployment and build trust with customers, regulators, and the public. Organizations that invest in thorough, thoughtful FRIAs will be better positioned to identify risks early, implement effective safeguards, and navigate the evolving regulatory landscape. The timing is in flux - the Digital Omnibus would move the high-risk (and therefore FRIA) deadline to 2 December 2027, but until that becomes law the binding date remains 2 August 2026 - so the smart move is the same either way: start now. Inventory your AI systems, identify which require FRIAs, and build a first draft with the free FRIA generator or downloadable template. This article is for general information only and is not legal advice; confirm your obligations under Article 27 with qualified counsel, and re-check the regulatory status before relying on any deadline.