How to Conduct an AI Impact Assessment: A Practical Template for 2026

Here’s the situation most compliance teams are in right now. You know the EU AI Act requires a Fundamental Rights Impact Assessment — or FRIA — before you deploy high-risk AI. You’ve read Article 27. You’ve looked for the official EU AI Office template that Article 27(5) promises. And you’ve found that it doesn’t exist yet.

As of March 2026, the EU AI Office has not published its standardized FRIA template questionnaire.^[1] The August 2, 2026 deadline is fixed regardless. Which means you need to build your assessment now, using the requirements that are already legally clear in the Act itself.

This guide is the practical answer to that problem. I’ll walk through exactly who must conduct a FRIA and when, what it must contain according to the Act, how to run the assessment in practice with a cross-functional team, how to integrate it with your DPIA to avoid duplicating work, how it relates to Colorado’s separate impact assessment requirement if you operate in both markets, and what a complete compliant template structure looks like.

One clarification upfront that saves a lot of confusion: the FRIA under Article 27 is a deployer obligation. It is entirely separate from — and does not substitute for — the Annex IV technical documentation and conformity assessment that providers must complete. Providers build the dossier; deployers conduct the FRIA. If you’re a deployer using a third-party AI system, you need both the provider’s documentation and your own FRIA. If you’re a provider, the FRIA is something your deployers do — though you should be providing them the information they need to do it.

This article is part of our EU AI Act Compliance Guide. For context on how to classify your AI systems before running an assessment, see our EU AI Act Classification Guide. For the provider-side documentation obligations that sit alongside the FRIA, see our Annex IV Documentation Guide.

What Is a FRIA and Why Does It Exist?

The Fundamental Rights Impact Assessment wasn’t in the European Commission’s original AI Act proposal. It was introduced by the European Parliament in June 2023,^[2] and it reflects a deliberate choice to add a layer of assessment that technical conformity processes cannot provide.

Here’s why it was added. The conformity assessment under the EU AI Act’s Annex VI and VII — which is primarily a provider obligation — evaluates whether an AI system meets the technical and safety requirements of Chapter III. It’s a standardized, largely engineering-driven process. What it doesn’t do well is assess the specific context in which an AI will actually be deployed — the real populations affected, the local sociotechnical dynamics, the specific ways that a technically compliant system might still produce harmful outcomes in practice for the people it touches.

The FRIA is specifically designed to fill that gap. It’s a deployer-side obligation because the deployer — not the provider — knows the specific context: who the users are, what decisions will be made, what vulnerable populations are involved, and what alternative options exist for people negatively affected.

The Purpose and Legal Basis of Article 27

Article 27 of the EU AI Act^[3] establishes the FRIA as a mandatory pre-deployment assessment for certain categories of deployers. The purpose is precise: to identify the specific risks of the AI system to the rights of individuals or groups of individuals likely to be affected — and to identify appropriate measures if those risks materialize.

This is different from asking whether the AI system works correctly. A technically accurate credit scoring model can still systematically disadvantage people in certain demographic groups, produce opaque decisions that deny people their right to good administration, or create access barriers that infringe on the right to social protection. The FRIA asks whether those things are happening — or might happen — in your specific deployment context, and what you’re doing about it.

The FRIA must be conducted before the first use of the high-risk AI system, and updated whenever relevant circumstances change — including changes to the system itself, the deployment context, or the characteristics of affected populations.^[2] It’s an ex ante obligation — there’s no grace period for deployers who start using a system and intend to complete the FRIA afterward. Deployers who were already using high-risk AI systems before August 2, 2026 must complete their FRIA as soon as possible and no later than that deadline.

FRIA vs. DPIA: What’s the Same and What’s Different

Every compliance team working on FRIAs needs a clear mental model of how the FRIA relates to the DPIA they’re probably already familiar with under GDPR. The two overlap significantly — but they’re not the same, and conflating them creates compliance gaps.

Element	DPIA (GDPR Article 35)	FRIA (EU AI Act Article 27)
Legal basis	GDPR Article 35	EU AI Act Article 27[3]
Focus	Personal data processing risks and data subject rights	All fundamental rights protected by the EU Charter — broader than data privacy
Who conducts it	Controller (the organization processing the data)	Deployer (the organization using the AI system)
Scope of rights covered	Privacy and data protection only	Human dignity, non-discrimination, freedom of expression, right to effective remedy, access to justice, right to social protection, and more
Timing	Before the processing operation (GDPR Art. 35)	Before first use of the AI system (AI Act Art. 27)
Notification requirement	Consult supervisory authority only if residual risk is high (GDPR Art. 36)	Must notify market surveillance authority of results in all required cases[2]
Can be combined?	Yes — Article 27(4) explicitly allows integration. DPIA first, FRIA complements it.[4]
Overlap with each other	A DPIA typically covers 30–40% of what a FRIA requires, particularly around data processing, privacy risks, and data subject impacts[1]

The practical implication: if you’ve already completed a DPIA for a high-risk AI system, start your FRIA there. Extract what’s already covered — system description, data processing risks, data subject rights impacts — and treat the FRIA as an extension into the broader fundamental rights territory the DPIA doesn’t reach. Don’t start from scratch.

FRIA vs. Annex IV Technical Documentation: Not the Same Thing

This confusion appears constantly in compliance discussions and it’s worth being absolutely direct about. The Annex IV technical dossier is a provider obligation — it’s the comprehensive technical record of how an AI system was built, trained, tested, and governed. The FRIA is a deployer obligation — it’s an assessment of how a specific deployment of that AI will affect fundamental rights in a specific context.

These are legally separate documents serving different purposes for different audiences. The Annex IV dossier goes to regulators and notified bodies reviewing the system. The FRIA goes to the market surveillance authority reviewing the deployment. A deployer using a third-party AI system needs the provider’s Annex IV documentation as input to their FRIA — specifically, the system description, performance characteristics, known limitations, and bias testing results — but the FRIA itself is a separate document that the deployer prepares about their specific deployment context.

Providers have an obligation under Article 13 to supply deployers with documentation sufficient to conduct a FRIA. If your AI provider hasn’t provided you with the information you need — performance metrics by demographic group, known failure modes, intended use limitations — ask for it explicitly and document that request. You cannot conduct a compliant FRIA without it.

Who Must Conduct a FRIA? The Complete Scope Analysis

Not every deployer of high-risk AI must conduct a FRIA. The obligation is specifically targeted, and understanding exactly which deployers fall within scope is the first decision your legal team needs to make.

Category 1: Public Bodies and Public Service Providers

The first category of obligated deployers is defined by organizational type, not by the specific AI system used. Bodies governed by public law — government ministries, local authorities, regulatory agencies, public universities, public hospitals, and other publicly funded or publicly controlled bodies — must conduct a FRIA for any high-risk AI system they deploy that falls under Annex III (with the critical infrastructure exception described below).^[3]

The “private entities providing public services” category is broader than it might initially appear. The Act uses this term without providing precise criteria — and the deliberate breadth is intentional, designed to cover entities involved in providing services that can reasonably affect the public interest.^[5] Banks, insurers, transport operators, utility companies, telecommunications providers, social housing organizations, and private healthcare providers are all strong candidates for this category. So are private companies contracted to deliver government services.

If your organization is unclear about whether it qualifies as a “private entity providing public services,” err on the side of conducting the FRIA. The cost of preparing one is substantially lower than the enforcement risk of not preparing one and having the interpretation go against you.

Category 2: Credit and Insurance AI Deployers

The second category of obligated deployers is defined not by organizational type but by what the AI does. Any deployer — public or private — that uses high-risk AI systems for the following purposes must conduct a FRIA regardless of whether they are a public body:^[3]

First, AI systems used to evaluate the creditworthiness of natural persons or establish their credit score — except AI systems used specifically for the purpose of detecting financial fraud. Second, AI systems used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.

These categories are specifically enumerated because they represent private-sector deployments with particularly significant potential impacts on individuals’ economic rights, access to essential services, and financial dignity. A private bank is not generally a “public body” — but if it uses AI for credit scoring, it must conduct a FRIA for that system.

Who Is Exempt from FRIA

Two categories of AI systems are specifically exempt from the FRIA obligation under Article 27, even when deployed by bodies that would otherwise be required to conduct one.

First, AI systems used as safety components in the management and operation of critical digital infrastructure, road traffic, or in the supply of water, gas, heating, or electricity (Annex III, point 2). These systems are exempt because their regulatory governance typically occurs through sector-specific safety frameworks that address fundamental rights considerations through different mechanisms.

Second, deployers may be exempt from the obligation to notify the market surveillance authority — though not from conducting the FRIA itself — in exceptional circumstances related to public security, protection of life or health, environmental protection, or protection of key industrial assets.^[5] This is a notification exemption, not an assessment exemption.

Scope Decision Table: Do I Need a FRIA?

Organization Type	AI System Type	FRIA Required?	Authority Notification?
Government ministry or local authority	Any Annex III high-risk AI (except critical infrastructure)	Yes — mandatory	Yes (unless security exemption applies)
Public hospital or health authority	Clinical AI, patient triage, treatment recommendation	Yes — mandatory	Yes
Private bank	Credit scoring or creditworthiness AI	Yes — mandatory	Yes
Private life or health insurer	Risk assessment or pricing AI for natural persons	Yes — mandatory	Yes
Private transport operator	Any Annex III high-risk AI (not road infrastructure)	Yes — likely mandatory as public service provider	Yes
Private employer (not public service)	HR / recruitment AI	Not currently required unless providing public services	N/A
Private technology company (B2B SaaS)	AI product sold to enterprise clients	Provider obligations apply — but deployer FRIA not required for purely private commercial deployers	N/A
Any deployer	Critical infrastructure AI (Annex III point 2)	Exempt from FRIA obligation	N/A

What a FRIA Must Contain: The Article 27 Requirements

Article 27(1) specifies the content requirements of the FRIA in three logical groups — a descriptive section establishing context, an assessment section evaluating risk, and a mitigation section documenting responses. I’ll structure the template in Part 7 around these same three groups to make it easy to map your content to the legal requirements.

Part A: Descriptive Section

The descriptive section establishes the factual context that makes the subsequent risk assessment meaningful. Without a clear, accurate description of the deployment, no reviewer — internal or regulatory — can evaluate whether your risk assessment is adequate.^[6]

The descriptive section must include: a description of the deployer’s processes in which the high-risk AI system will be used; the period of time and frequency for which the system will be relied upon; the categories of persons and groups likely to be affected, including particularly vulnerable groups; and how the information provided by the AI provider under Article 13 was taken into account in the assessment.

What “sufficient” looks like here: Not bullet points — paragraphs that actually describe the specific deployment. “This system will be used to support credit application decisions for individual consumers applying for personal loans via the online banking platform. It will run continuously for all applications, processing approximately 800 individual assessments per day. The primary affected population is adult EU residents applying for consumer credit, including potentially vulnerable individuals in financial distress.” That level of specificity is what regulators and auditors need to evaluate whether your risk assessment is grounded in reality.

Part B: Rights Assessment Section

This is the substantive core of the FRIA and the section that most distinguishes it from technical compliance assessments. For each fundamental right that the AI deployment could plausibly affect, the assessment must identify the specific risk of harm, evaluate its likelihood and severity, and explain the reasoning behind those evaluations.^[6]

The assessment is structured around the EU Charter of Fundamental Rights — not around technical performance metrics. This shift in frame is where many compliance teams get stuck. They’re used to evaluating AI systems through accuracy, precision, recall, and bias metrics. Those matter and belong in your technical documentation. But the FRIA asks a different question: given those performance characteristics, what might happen to a person’s dignity, their right to non-discrimination, their access to justice, or their right to an effective remedy?

The assessment must also consider both direct and indirect effects — including cascading effects where AI system decisions influence subsequent human or automated decision-making. A credit scoring system that denies a loan may also affect housing access, employment opportunities, and broader social participation. Those downstream effects belong in the assessment, not just the immediate lending decision.

Part C: Mitigation and Oversight Section

For each identified risk, the FRIA must document the specific measures taken or planned to prevent or mitigate the risk, the human oversight measures implemented, and how the organization will monitor the effectiveness of those mitigations over time.^[7]

Critically, this section must document human oversight in concrete operational terms — not organizational intent. “A manager reviews all decisions” is not mitigation documentation. “All adverse credit decisions generated by the AI system are reviewed by a qualified credit officer with full access to the application file and the AI system’s confidence score before notification to the customer, with a documented right to override the AI recommendation” is mitigation documentation. The distinction matters because in any enforcement review, regulators will ask: how did the oversight actually work, and what evidence do you have that it happened?

The EU Charter Rights Map for AI Assessments

The following rights categories from the EU Charter of Fundamental Rights are most frequently relevant in AI impact assessments.^[1] For each rights category, I’ve noted the AI risk patterns that typically create exposure.

Charter Right	Charter Article	Typical AI Risk Pattern	Most Relevant Sectors
Human dignity	Art. 1	Dehumanizing treatment; opaque automated decisions without explanation; surveillance	All sectors
Non-discrimination	Art. 21	Algorithmic bias; proxy discrimination; demographic performance gaps	Employment, credit, housing, healthcare
Right to privacy and data protection	Arts. 7 & 8	Profiling; inference of sensitive attributes; excessive data use	All sectors — primary DPIA overlap
Freedom of expression and information	Art. 11	AI content moderation; filtering affecting access to information	Media, social platforms, government
Right to an effective remedy and fair trial	Art. 47	Lack of explainability; no appeal mechanism; opaque automated decisions	All sectors — especially justice, credit, employment
Right to good administration	Art. 41	Opaque public-sector AI decisions; lack of reasons; denial of hearing	Government services, public bodies
Social security and social assistance	Art. 34	AI gatekeeping access to benefits; discrimination in social support allocation	Social services, public authorities
Right to education	Art. 14	Discriminatory admissions AI; biased academic performance evaluation	Education
Children’s rights	Art. 24	AI affecting minors’ welfare, education, custody decisions	Healthcare, education, justice

How to Run a FRIA in Practice: A Six-Step Process

The Act specifies what a FRIA must contain, not how to conduct one. The following process is built around what actually works in practice for organizations preparing their first FRIAs, drawing on the EU Charter rights framework and the integrated DPIA approach.

Step 1: Scope Confirmation and Pre-Assessment (Week 1)

Before spending time on the assessment itself, confirm two things. First, is this system actually high-risk under Annex III? If you haven’t already run a classification analysis, do it now using the classification guide linked in the introduction. Second, does your organization fall within the Article 27 FRIA obligation for this deployment? Use the scope decision table above as your starting point, and document your conclusion — including the reasoning — in the FRIA document itself. A documented in-scope determination that turns out to be conservative is far better than an undocumented decision not to conduct a FRIA that’s later challenged.

If your organization has already conducted a DPIA for this AI system, retrieve it now. The DPIA becomes the foundation of your FRIA, and you’ll identify what it already covers versus what the FRIA needs to add.

Step 2: Assemble the Right Team (Week 1–2)

A FRIA conducted by a single person — even a very good compliance lawyer — is structurally insufficient. Scholars and practitioners consistently identify multi-stakeholder involvement as essential to a meaningful assessment.^[8] The minimum team for a FRIA is five functional perspectives.

Legal/compliance: owns the process, maps rights implications, ensures FRIA content satisfies Article 27 requirements, manages authority notification. Data Protection Officer: brings GDPR expertise, leads the DPIA integration, identifies personal data processing risks. Technical/AI engineering: explains how the system actually works, provides performance metrics by demographic group, identifies known failure modes and edge cases. Business/operations: describes the actual deployment context — who uses it, how decisions are made, what the consequences of AI outputs are in practice. Subject matter expert on affected populations: ideally someone with lived experience of or expertise in the populations affected — a clinician for healthcare AI, an HR professional familiar with candidate experience for recruitment AI, a social worker for public benefit AI.

For public bodies deploying AI with significant social impact, involving external stakeholders — community representatives, civil society organizations, affected group representatives — adds credibility and identifies blind spots that internal teams inevitably miss.

Step 3: Gather System Documentation from the Provider (Week 2–3)

You cannot conduct a meaningful FRIA about an AI system you don’t understand. Before your assessment meetings begin, obtain from the AI provider — using your rights under Article 13^[3] — the following minimum documentation: a description of the system’s intended purpose and capabilities; performance metrics disaggregated by demographic group; known limitations and failure modes; data used to train and test the system; the Instructions for Use; and any prior impact assessments or bias evaluations the provider has conducted.

If the provider cannot or will not supply this documentation, that is itself a compliance signal. Article 13 creates a mandatory obligation on providers to supply this information. A provider who cannot produce demographic performance disaggregation hasn’t completed the Annex IV documentation that the EU AI Act requires of them. Document your requests and any gaps in the information provided.

Step 4: Conduct the Rights Impact Assessment (Week 3–5)

The assessment itself is a structured facilitated discussion, not a form to complete. For each relevant EU Charter right identified in your pre-assessment scope, the team works through four questions: Could this AI system’s operation affect this right for the populations it touches? If yes, what specific harm scenario creates the risk? How likely is that harm, and how severe would it be if it materialized? What factors in the specific deployment context amplify or reduce the risk?

Use the EU Charter rights map from Section 3 as your starting point. Not all rights will be relevant to all deployments — a scheduling optimization tool has a different rights profile than a welfare benefits allocation system. But err on the side of completeness in your initial scan. Rights that seem marginal often reveal significant implications once you start examining specific harm scenarios.

Risk quantification is required but doesn’t have to be numerical. A two-axis matrix (likelihood × severity) with documented qualitative reasoning per cell is defensible and often more meaningful than numerical scoring without substantive analysis behind it. What regulators look for is evidence of genuine deliberation — that specific scenarios were considered and evaluated on their merits — not mathematical precision.

Step 5: Design and Document Mitigation Measures (Week 4–6)

For each identified risk above an acceptable threshold, document the specific mitigation: what it is, how it works, who is responsible for it, and how its effectiveness will be monitored. Mitigation measures for AI deployments typically fall into four categories that work together rather than substituting for each other.

Technical mitigations address the AI system itself: output filtering, confidence thresholds that trigger human review, bias correction in the model, reduced scope of deployment for specific high-risk use cases. Procedural mitigations address the workflow: mandatory human review before acting on AI outputs, independent second review for high-stakes decisions, documented escalation paths. Informational mitigations address transparency: consumer notifications, explanations of AI-influenced decisions, information about appeal rights. Accountability mitigations address governance: named accountability for AI performance monitoring, regular bias auditing, incident reporting procedures linked to your Article 73 serious incident process.

One mitigation that is always required for high-risk AI systems is a meaningful human appeal mechanism. Document the specific pathway: how a person who received an adverse AI-influenced decision can request review, who conducts that review, what authority they have to override the AI recommendation, and how the outcome is communicated.

Step 6: Notify the Market Surveillance Authority (Before Deployment)

Once the FRIA is complete, deployers who fall within Article 27’s scope must notify the relevant national market surveillance authority of the results.^[2] The notification mechanism and format varies by EU member state — each state has designated its own market surveillance authority for the EU AI Act. The EU AI Office is expected to publish a notification template under Article 27(5), but as of March 2026 this template has not been released.

In the meantime: document your FRIA thoroughly, retain all records, and prepare for notification as soon as the official template and notification procedures are published by the EU AI Office or your national authority. Do not delay the FRIA itself waiting for the template — the assessment must be complete before deployment regardless.

FRIA–DPIA Integration: Doing One Assessment, Not Two

Organizations that have mature DPIA processes can dramatically reduce the effort required for FRIA compliance by integrating the two assessments. The EU AI Act explicitly enables this — Article 27(4) states that if a DPIA has already been conducted, the FRIA shall complement it rather than replace it.^[4]

The Integrated Assessment Approach

The most efficient approach is to conduct the DPIA first, then extend it into the FRIA. Not because the DPIA takes precedence, but because most organizations have existing DPIA processes and templates that can be adapted. Starting with what you already have and building outward is more efficient than building two separate documents.

In practice, the integrated FRIA-DPIA document has three parts: a shared context section (system description, deployment scope, affected populations — used by both assessments); the DPIA-specific section covering personal data processing, legal basis, data subject rights, and Article 36 consultation assessment; and the FRIA-specific section extending the rights analysis to the non-data-protection Charter rights that the DPIA doesn’t address. The two-section structure makes it clear what each assessment covers and allows each to be extracted as a standalone document if required by different regulatory recipients.

What DPIA Covers, What FRIA Adds

Assessment Element	DPIA Covers This?	FRIA Covers This?	Note
System description and purpose	Yes	Yes	Use single shared section — no duplication needed
Affected populations identification	Yes (data subjects)	Yes (all affected persons)	FRIA is broader — extends beyond data subjects to all affected individuals
Data protection and privacy risks	Yes — primary focus	Yes (as one Charter right)	DPIA section covers this; FRIA section cross-references it
Non-discrimination and algorithmic bias	Partially (where bias = data protection violation)	Yes — explicitly required	FRIA adds significant content here; DPIA only partially covers this
Right to explanation and transparency	Partially (Art. 22 GDPR automated decisions)	Yes — Art. 47 right to remedy	Both cover this from different angles; integrate to avoid duplication
Right to good administration	No	Yes	FRIA-only section — particularly relevant for public bodies
Social security and social assistance rights	No	Yes	FRIA-only section — relevant for welfare AI, benefits allocation
Children’s rights	Partially (special category data protections)	Yes — broadly	FRIA extends beyond data protection to welfare and development
Human oversight documentation	Partially (data subject rights enforcement)	Yes — specifically required	FRIA section must document specific oversight mechanisms
Authority notification requirement	Only for high-risk DPIA (Art. 36 consultation)	Mandatory for all required FRIA deployers	FRIA notification is broader — all required deployers must notify

EU FRIA vs. Colorado Impact Assessment: Dual-Market Design

Organizations operating in both EU and US markets — specifically Colorado — face the practical question of whether one assessment can satisfy both requirements. The good news: yes, with thoughtful design. The two assessments share significant substantive overlap but differ in scope, format, and procedural requirements.

Element	EU AI Act FRIA (Article 27)	Colorado SB 24-205 Impact Assessment
Who must conduct it	Public bodies, public service providers, credit/insurance AI deployers	All deployers of high-risk AI systems affecting Colorado residents
Primary rights focus	All fundamental rights in the EU Charter	Specifically algorithmic discrimination against protected classes
Frequency	Before first use; update when circumstances change	Annual — before first deployment and every year thereafter
Government notification	Yes — notify market surveillance authority[3]	No — retain internally; produce on AG request
Bias testing required	Yes — Charter Article 21 non-discrimination coverage	Yes — central purpose of the assessment
Consumer rights	Charter right to effective remedy and explanation	Right to notification and human appeal of adverse decisions
Retention	No specific retention period stated in Article 27; retain with AI system records	3 years minimum following final deployment[9]
Safe harbor benefit	No explicit safe harbor; notification creates regulatory record	Rebuttable presumption of compliance when following NIST AI RMF[9]

The most efficient dual-market design: build a single assessment with a shared core (system description, affected populations, bias/discrimination testing, human oversight measures) and two market-specific modules. Module A covers EU Charter rights analysis and authority notification procedures. Module B covers Colorado’s specific impact assessment format, algorithmic discrimination findings, and consumer notification workflow documentation. Both modules draw from the same underlying bias testing and human oversight work — that work is done once.

For organizations also subject to NYC Local Law 144 (annual independent bias audits for employment AI), the same bias testing exercise that serves the EU FRIA’s non-discrimination analysis and Colorado’s discrimination assessment can serve as the basis for the NYC bias audit report, formatted per NYC’s requirements. One set of tests, three regulatory deliverables.

Complete FRIA Template Structure

The following template satisfies the content requirements of Article 27(1) while being designed for practical use by cross-functional compliance teams. Adapt it to your system — this is a structure, not a rigid script. The EU AI Office template when published may require adjustments, but building to these substantive requirements now means any adjustments will be minor additions rather than rebuilds.

All Sections with Guidance Notes

What “Sufficient” Looks Like for Each Section

The most common failure mode in FRIAs is generic language where specific analysis is required. Three principles distinguish assessments that pass regulatory review from those that don’t.

Specificity to the deployment context. Section 4 must reference the actual demographic performance data from the specific AI system being assessed — not generic industry benchmarks. “Performance accuracy varies by gender with women receiving 12% fewer positive outcomes in preliminary testing, pending bias remediation scheduled for Q2 2026” is specific. “The system may have bias risks” is not.

Evidence-grounded risk ratings. Likelihood and severity ratings must be accompanied by narrative reasoning — what specific scenarios drive the rating, what evidence from testing or analogous deployments informs it. A risk register with numbers but no reasoning cannot be defended.

Operational specificity in mitigation documentation. Every mitigation measure must have a named owner, a specific mechanism, and a monitoring method. “Human review will be conducted” fails this test. “All adverse [decision type] decisions are reviewed by [role title] within [timeframe], with the decision and override rationale recorded in [system name]. Monthly bias audit reports are reviewed by [role] and escalated to [role] if disparate impact exceeds [threshold]” passes it.

The 6 Most Common FRIA Mistakes

Mistake 1: Conducting the FRIA after deployment. The FRIA is an ex ante obligation — it must be complete before the first use of the AI system. No version of “we’re doing the FRIA now and we’ll have it done by next quarter” is compliant if the system is already running. If your organization is in this situation, complete the FRIA immediately, document the circumstances, and notify the authority with a note on the timeline discrepancy. Acting promptly and transparently is far better than hoping no one notices.

Mistake 2: Treating the FRIA as a one-time document. Article 27 requires updates when relevant circumstances change. New use cases, changes to the AI system, changes to the deployment context, significant demographic shifts in the affected population, or discovery of unexpected bias issues all trigger a FRIA review. Build a maintenance obligation into your FRIA process — it’s not done when the initial assessment is signed off.

Mistake 3: Confusing FRIA scope with DPIA scope. A DPIA covers personal data risks and data subject rights. The FRIA covers all fundamental rights — including rights that have nothing to do with personal data, like the right to good administration, access to justice, or freedom of expression. Organizations with mature DPIA processes often produce FRIAs that are essentially DPIAs with the title changed. That is not a compliant FRIA. Make sure Section 4.5–4.8 in the template above actually has substance — those non-data-protection rights are where most FRIAs are thin.

Mistake 4: Internal-only process without diverse perspectives. A FRIA completed entirely by the legal team without input from technical staff, the DPO, operational teams, or affected stakeholder representatives will miss the risks that those perspectives would have identified. The European consumer rights organization CECU has specifically noted that FRIAs risk becoming box-ticking exercises when conducted purely as internal self-assessments.^[8] Build the multi-stakeholder team described in Step 2 before you start writing.

Mistake 5: Forgetting the authority notification obligation. Unlike the DPIA — where supervisory authority consultation is only required when residual risk remains high — the FRIA notification to the market surveillance authority is mandatory for all required deployers. This is not optional and is not conditional on finding serious risks. Even a FRIA that concludes risks are low and well-mitigated must be notified to the relevant authority.

Mistake 6: Not getting the provider documentation you need. You cannot assess the fundamental rights implications of an AI system you don’t understand. If your AI provider hasn’t given you demographic performance disaggregation, known failure modes, and documentation of training data limitations, you cannot conduct a meaningful bias analysis in Section 4. Request this documentation formally, document the request, and if it isn’t provided, escalate — the provider has a legal obligation under Article 13 to supply it.

Frequently Asked Questions: AI Impact Assessment

Who must conduct a FRIA under the EU AI Act?

Two categories of deployers. First, deployers that are bodies governed by public law or private entities providing public services — this covers government bodies, banks, insurers, utilities, transport operators, healthcare providers, and social services organizations.^[3] Second, deployers using high-risk AI specifically for creditworthiness evaluation, credit scoring, or life and health insurance risk assessment and pricing (Annex III points 5(b) and 5(c)). Purely private commercial deployers outside these categories are not currently required to conduct a FRIA, though doing so voluntarily demonstrates responsible governance. Critical infrastructure AI (Annex III point 2) is specifically exempt.

What is the difference between a FRIA and a DPIA?

Scope. A DPIA (GDPR Article 35) focuses on personal data risks and data subject rights. A FRIA (EU AI Act Article 27) covers all fundamental rights protected by the EU Charter — including non-discrimination, right to good administration, freedom of expression, and social security rights that fall outside GDPR’s scope entirely. A comprehensive DPIA typically covers 30–40% of what a FRIA requires.^[1] Under Article 27(4), if you’ve already completed a DPIA for the same system, the FRIA complements rather than replaces it — you can run them as an integrated single document.

Has the EU AI Office published an official FRIA template?

No — not as of March 2026. Article 27(5) provides for the EU AI Office to publish a standardized template questionnaire, but it has not yet been published.^[1] Organizations must not wait for this template before starting preparation. The substantive requirements of Article 27(1) are already legally clear and sufficient to begin building your assessment now. The August 2, 2026 deadline is fixed regardless of when the official template appears.

When must a FRIA be conducted and updated?

Before the first use of the AI system, and updated whenever relevant circumstances change — including changes to the AI system, the deployment context, or the characteristics of affected populations.^[2] Deployers already using high-risk AI systems before August 2, 2026 must conduct their FRIA as soon as possible and no later than that date. The FRIA is not a one-time document — it’s a living assessment with a maintenance obligation.

Does Colorado’s AI Act require an impact assessment?

Yes — but a different one. Colorado SB 24-205 (effective June 30, 2026) requires deployers to conduct an annual impact assessment specifically focused on algorithmic discrimination risks.^[9] Colorado’s assessment is narrower in rights scope than the EU FRIA, doesn’t require government notification, must be completed annually, and must be retained for three years. Organizations in both markets can design a unified assessment with a shared core and market-specific modules to satisfy both requirements efficiently.

What are the most common FRIA mistakes?

Six patterns appear consistently. Conducting the FRIA after deployment rather than before (it’s an ex ante obligation). Treating it as a one-time document (it must be updated when circumstances change). Limiting scope to data protection only and missing broader fundamental rights coverage. Running it as an internal-only exercise without diverse perspectives from technical, operational, and affected stakeholder teams. Forgetting the mandatory authority notification obligation. And failing to obtain the provider documentation needed to conduct a meaningful bias analysis. The last one is particularly common — you cannot assess what you don’t understand, and many providers don’t proactively supply the demographic performance disaggregation that a solid Section 4 requires.