266. EU AI Act Article 27 FRIA: What It Is and Who Must Comply (2026)

Last Updated: September 30, 2026

The EU AI Act is not just a law for AI developers. It imposes direct obligations on the organisations that deploy AI systems — and one of those obligations is a structured pre-deployment assessment that most compliance teams have never encountered. It is called the Fundamental Rights Impact Assessment, or FRIA. It is required under Article 27 of Regulation (EU) 2024/1689. It became a legal obligation on August 2, 2026. And it is distinct from — not replaced by — the GDPR’s Data Protection Impact Assessment.

This guide covers everything a compliance team, legal department, or AI governance function needs to know about Article 27 FRIAs: who is legally required to conduct one, which AI systems are in scope, the six content elements Article 27 mandates, the notification obligation to the market surveillance authority, and the relationship between a FRIA and an existing DPIA. It also covers the one compliance gap that regulators are most likely to find: organisations that completed a DPIA and assumed they had covered their obligations — when in fact a FRIA requires a separate, broader assessment addressing rights a DPIA was never designed to evaluate. For organisations also managing GDPR Article 35 compliance for their AI systems, our companion guide to DPIA for AI systems covers that parallel obligation in full.

All regulatory information in this article reflects EU AI Act Regulation (EU) 2024/1689 as amended by the Digital Omnibus for AI (Regulation (EU) 2026/1744, which entered into force July 27, 2026) and publicly available Commission guidance through September 30, 2026. This article is a compliance guide, not legal advice. Organisations with specific deployment scenarios should seek qualified legal counsel.

The Article 27 Reality Check: A DPIA protects data. A FRIA protects people. Completing a DPIA for your AI system does not discharge your FRIA obligation — and the EU AI Act is explicit on this point. Article 27 covers rights that GDPR was never designed to reach: non-discrimination, human dignity, freedom of expression, workers’ rights, and access to justice. If your organisation deploys high-risk AI and falls within the Article 27 scope, both assessments are required.

⚖️ 1. What Is a FRIA? Article 27 Explained

A Fundamental Rights Impact Assessment is a structured, documented analysis of how deploying a specific high-risk AI system may affect the fundamental rights of the people that system touches — conducted before the system is first put into use. It is established by Article 27 of the EU AI Act. It is a deployer-side obligation: the assessment duty falls on the organisation putting the AI system into operation, not on the vendor or developer who built it.

The FRIA is one of the few provisions in the EU AI Act that moves beyond technical compliance requirements. Where most of the Act focuses on documentation, conformity assessments, and technical robustness, Article 27 requires deployers to genuinely reflect on why, where, and how a high-risk AI system will be used — and what consequences that use may have for the rights of the people it affects. The rights in scope are those protected under the EU Charter of Fundamental Rights: human dignity, non-discrimination, freedom of expression, the right to an effective remedy, access to justice, workers’ rights, children’s rights, and the right to good administration. Data protection is included, but it is one right among many — not the defining scope of the assessment.

The FRIA became legally enforceable on August 2, 2026, when the high-risk AI provisions of the EU AI Act came into full effect. For Annex III systems — the category of high-risk AI systems defined by use case rather than by embedded product — the Digital Omnibus for AI (Regulation (EU) 2026/1744) extended the general Annex III compliance deadline to December 2, 2027. However, the Article 27 FRIA obligation for the specific deployer categories listed in Article 27(1) — public bodies, private public-service providers, and credit/insurance deployers — was not deferred by the Digital Omnibus and is in force now. Organisations in those categories who are currently deploying in-scope high-risk AI systems without a completed FRIA are already non-compliant.

👥 2. Who Must Conduct a FRIA? The Three Deployer Categories

Article 27 does not apply to every organisation that deploys a high-risk AI system. The obligation is narrower than the high-risk classification itself. Three specific categories of deployers are subject to the FRIA requirement — and understanding whether your organisation falls within one of them is the essential first step of any Article 27 compliance programme.

Category 1: Bodies governed by public law. Any public authority, government agency, municipality, national ministry, public university, public hospital, public housing authority, or EU institution that deploys a high-risk AI system listed in Annex III must conduct a FRIA. This is the broadest of the three categories and encompasses the full range of public sector entities across EU member states. The only exception is AI systems used as safety components in critical infrastructure — specifically road traffic management, water, gas, heating, or electricity supply systems (Annex III, point 2). All other Annex III systems deployed by public bodies trigger the obligation.

Category 2: Private entities providing public services. Private organisations that are not technically governed by public law but which deliver public services — in areas including education, healthcare, social services, housing, and the administration of justice — are also within scope when they deploy Annex III high-risk AI systems. A private company contracted to run a public employment service, a private healthcare provider operating on public commission, or a social housing management company are examples of entities that may fall into this category. The key test is whether the entity is performing a function that would otherwise be a public-sector responsibility.

Category 3: All deployers of AI systems for creditworthiness evaluation or insurance risk pricing. Regardless of whether they are public or private, and regardless of whether they provide public services, any deployer using an AI system to evaluate creditworthiness, establish credit scores of natural persons, or assess and price risk in life and health insurance contracts is subject to Article 27. This category captures banks, lenders, insurers, and fintech platforms operating in these specific domains. The Commission’s May 2026 draft guidance confirms that creditworthiness evaluation and credit scoring are treated as distinct use cases, and that both can independently trigger the FRIA obligation.

Who is not subject to Article 27: A standard private company deploying high-risk AI — for example, in recruitment, performance management, or content moderation — is not required to conduct a formal FRIA under Article 27, provided it does not fall into Category 2 or 3 above. Those private deployers have separate obligations under Article 26 (deployer duties including human oversight, instructions for use, and informing affected individuals), but the formal FRIA document is not among them. This is a point of significant compliance confusion: many private-sector organisations have been preparing FRIAs under the impression that all high-risk AI deployments require one. Only the three categories above are in scope.

📋 3. The Six Mandatory Elements of a FRIA

Article 27(1) sets out the minimum content every FRIA must contain. These six elements are not optional structure suggestions — they are the legal floor. A FRIA that does not address all six elements is an incomplete FRIA and does not satisfy the Article 27 obligation. When the EU AI Office publishes its official template questionnaire (required under Article 27(5) and not yet released as of September 30, 2026), that template will map directly onto these six content elements. Assessments built on this structure now will require alignment, not reconstruction, when the official template arrives.

Element (a): Process description. A description of the deployer’s processes in which the high-risk AI system will be used, in line with its intended purpose. This is not a system description — it is a deployment context description. It answers the question: specifically how, in what workflow, and for what decisions will this system operate in your organisation? A welfare benefit eligibility screening system used by a municipality requires a description of exactly how caseworkers interact with the system’s outputs, which decisions the system informs, and how those decisions are made.

Element (b): Time and frequency. A description of the period within which, and the frequency with which, each high-risk AI system is intended to be used. This element captures the scale of exposure. A system running continuous real-time scoring on thousands of individuals daily presents a fundamentally different rights risk profile than a system run quarterly on a defined cohort. Duration, frequency, and volume all belong here.

Element (c): Affected persons. The categories of natural persons and groups likely to be affected by the system’s use in the specific deployment context. This element requires genuine scope analysis — not a generic list of users, but a specific identification of who is affected, including those who are not direct users of the system but whose circumstances are assessed by it. Job applicants, benefit claimants, insurance policyholders, and student cohorts are examples of affected groups that need to be specifically identified and characterised.

Element (d): Specific risks of harm. The specific risks of harm likely to affect the categories of persons identified in element (c), taking into account the information provided by the provider under Article 13 of the EU AI Act. Article 13 requires providers to furnish deployers with transparency information about the system’s purpose, performance characteristics, limitations, and known risks. The FRIA must use that provider information — and the deployer’s own deployment context — to identify specific, credible risks of harm. Generic statements (“the system may discriminate”) do not satisfy this element. Specific risk pathways, tied to specific affected groups and specific deployment contexts, are required.

Element (e): Human oversight measures. A description of how human oversight measures will be implemented in the specific deployment, in accordance with the system’s instructions for use. The AI Act’s human oversight requirements under Article 14 require that high-risk AI systems can be monitored, intervened upon, and overridden by human operators. The FRIA must document specifically how those oversight mechanisms will function in your deployment — not merely assert that they exist. Who reviews outputs? Under what conditions can a system decision be overridden? What is the escalation path when the system produces an anomalous result?

Element (f): Mitigation measures and complaint mechanisms. The measures to be taken if the identified risks materialise, including arrangements for internal governance and complaint mechanisms. This is the remediation layer — and it is where many FRIA drafts are weakest. Article 27 requires deployers to document not just what they will do to prevent harm, but what they will do when prevention fails. Complaint mechanisms must be AI-specific: general GDPR complaint pathways do not cover the full scope of rights that a FRIA addresses. A meaningful complaint mechanism for an AI-assisted decision must include a path for affected individuals to challenge the decision, understand how the AI contributed to it, and access human review.

🔄 4. FRIA vs DPIA: What Overlaps, What Does Not

The most important misunderstanding in Article 27 compliance is the belief that a completed DPIA discharges the FRIA obligation. It does not. Article 27(4) is explicit on this: where obligations overlap, the FRIA “shall complement” the DPIA — meaning the FRIA adds to the DPIA, not the other way around. A DPIA on its own does not satisfy Article 27. And a FRIA, even a comprehensive one, does not remove the obligation for a GDPR Article 35 DPIA where personal data processing triggers that requirement separately.

The practical difference is scope. A DPIA focuses on risks to personal data processing under GDPR — it assesses whether data collection, storage, and use is lawful, proportionate, and secure. A FRIA is broader: it assesses the impact of the AI system on the full spectrum of fundamental rights protected under the EU Charter of Fundamental Rights. That includes data protection (Charter Article 8), but it also includes non-discrimination (Charter Article 21), human dignity (Charter Article 1), freedom of expression (Charter Article 11), the right to an effective remedy (Charter Article 47), workers’ rights (Charter Articles 27–32), children’s rights (Charter Article 24), and the right to good administration (Charter Article 41). A DPIA addresses none of these rights directly.

The good news for compliance teams is that Article 27(4) explicitly permits joint assessment. Where genuine overlap exists — for example, where the AI system processes personal data and both a DPIA and a FRIA are required — the two assessments can be conducted together and documented in a single integrated report. The integrated document must cover both the GDPR Article 35 content requirements and the Article 27(1) six elements. The key test is whether the combined document actually addresses both sets of obligations in full — not whether it is physically presented as one document or two. For organisations already managing GDPR Article 35 compliance for AI systems, our DPIA for AI systems guide covers the nine EDPB criteria and the six GDPR failure points that regulators most commonly identify.

📣 5. The Notification Obligation: The Step Most Deployers Will Miss

Completing the six-element FRIA document is not the end of the Article 27 obligation. It is step one of two. Article 27(3) requires that once the FRIA is complete, the deployer notifies the relevant national market surveillance authority of the results — by submitting the completed template questionnaire referenced in Article 27(5). This notification obligation is unconditional for in-scope deployers. It is not triggered only by high residual risk (as prior consultation under GDPR Article 36 is). It applies regardless of what the FRIA finds. Even a FRIA that concludes the risk to fundamental rights is low and well-mitigated must be submitted to the authority.

The only exemption from the notification requirement is the narrow case under Article 46(1) — exceptional circumstances involving public security, the protection of life and health, environmental protection, or the protection of key industrial and infrastructural assets. This exemption is not a general carve-out for sensitive deployments. It is an emergency provision applicable in specific, documented circumstances. The practical reality for most in-scope deployers is that notification is mandatory with no operational exemption.

There is currently a procedural gap: as of September 30, 2026, the EU AI Office has not yet published the official Article 27(5) template questionnaire. The AI Office is required to develop this template, including an automated tool to support completion. Until the template is available, deployers should document their completed FRIA against the six Article 27(1) elements and notify their relevant market surveillance authority using whatever submission mechanism that authority makes available. The authority to notify is the market surveillance authority designated in each EU member state — not the Data Protection Authority, unless the member state has designated the DPA for this role.

Organisations with existing AI deployments that triggered the Article 27 obligation before August 2, 2026 should treat the FRIA as overdue and prioritise completion. The Digital Omnibus for AI extended the general Annex III system compliance deadline but did not defer the notification obligation for deployers already in scope. Being currently non-compliant with a notification obligation that has been active since August 2, 2026 represents meaningful regulatory exposure — particularly for public sector organisations, which are the most visible category of Article 27 deployers. For a structured pre-deployment and vendor evaluation process that covers Article 27 alongside the broader EU AI Act obligation set, see our AI vendor evaluation checklist and our AI governance framework guide.

⚡ 6. When to Conduct a FRIA: Timing and Update Obligations

Article 27 is explicit on timing: the assessment must be conducted before the high-risk AI system is first put into service. Conducting the FRIA after deployment is the most straightforward Article 27 compliance failure — and, given that the obligation has been in force since August 2, 2026, any in-scope deployer currently operating a qualifying system without a completed FRIA is already in breach.

The FRIA is not a one-time exercise. Article 27 requires deployers to update the assessment if the underlying circumstances change materially. A significant expansion of the use case, a change to the affected population, the introduction of new model versions that alter the system’s risk profile, or the identification of harms that were not anticipated in the original assessment all constitute material changes that require an updated FRIA. Deployers should build a FRIA review trigger into their AI system change management process — not treat it as a one-time pre-deployment checkbox.

There is a practical shortcut for deployers managing multiple similar deployments: Article 27 permits a single FRIA to cover materially similar deployments of the same system in comparable contexts. A municipality deploying the same welfare eligibility AI system across ten district offices using the same workflow does not need ten separate FRIAs — one assessment covering the common deployment pattern, with noted variations where relevant, satisfies the requirement. This reuse provision is valuable for large public sector organisations managing AI deployments at scale — but it requires honest evaluation of whether the deployments are genuinely comparable. Differences in affected populations, decision types, or oversight mechanisms may make separate assessments necessary even where the underlying system is identical.

🏛️ 7. Sector Scenarios: Who Triggers Article 27 in Practice

The abstract categories in Article 27 become clearer when mapped to real deployment scenarios. The following examples illustrate which deployments trigger the FRIA obligation, which do not, and where the line sits in ambiguous cases.

Municipal social benefits AI — FRIA required. A municipality deploys an AI system to score welfare benefit eligibility applications and flag applications for manual review. The municipality is a body governed by public law. The system is high-risk under Annex III (access to essential public services). The FRIA is mandatory. The affected population — benefit applicants — includes vulnerable individuals, and the risk of discriminatory scoring patterns is a specific harm that must be addressed in element (d).

Private bank credit scoring AI — FRIA required. A bank deploys an AI system to generate creditworthiness scores for personal loan applications. The bank is a private entity, but credit scoring is explicitly captured in Annex III point 5(b) and falls within the Category 3 deployer scope regardless of public/private status. The FRIA is mandatory. Non-discrimination analysis across protected characteristics — age, ethnicity, gender — is a core element of the risk assessment.

Private health insurer risk-pricing AI — FRIA required. A health insurer uses an AI system to assess individual health risk and calculate insurance premiums. Life and health insurance risk assessment and pricing falls within Annex III point 5(c). The FRIA is mandatory. No fraud-detection exception applies: where an AI system incorporates both risk-pricing and fraud-detection functions, the system remains in scope unless the fraud-detection capability is a genuinely standalone system separate from the risk-assessment function.

Private recruitment platform AI — FRIA not required under Article 27. A private HR technology company offers an AI-powered CV screening tool used by employer clients. The company is not a body governed by public law, does not provide public services in the Article 27 sense, and does not operate in credit scoring or insurance pricing. Article 27 does not apply. The company has Article 26 obligations as a deployer (human oversight, user notification, instructions for use) — and employers using the tool may have their own Article 26 obligations — but neither the company nor its clients must conduct a formal Article 27 FRIA.

Private outsourced employment service — FRIA required. A private company is contracted by a national employment agency to provide job matching and eligibility screening services using AI. Despite being a private company, it is providing public services — employment services — on behalf of a public authority. It falls within Category 2 of the Article 27 deployer scope. The FRIA is mandatory. This is one of the most commonly missed triggers: private outsourcing of public service functions does not transfer the FRIA obligation back to the contracting public body — both may have obligations, and the deployer (the private company actually operating the system) cannot rely on the contracting authority’s separate compliance programme.

⚠️ 8. The Five FRIA Compliance Failures Regulators Will Find

Based on the structure of Article 27 and the compliance gaps that DPA enforcement experience with DPIAs has consistently identified, the following five failure modes are the most predictable Article 27 vulnerabilities for in-scope deployers.

Failure 1: Completing the FRIA after deployment. Article 27 is explicit that the assessment must be completed before first use. Post-deployment FRIAs do not satisfy the legal requirement. They may have mitigation value — demonstrating good faith effort — but they are not a compliance solution. Any in-scope deployer that put a qualifying system into operation after August 2, 2026 without a completed FRIA is already non-compliant and should prioritise remediation.

Failure 2: Treating the DPIA as a FRIA substitute. As Section 4 above documents in full, a DPIA does not discharge the Article 27 obligation. Organisations that present a GDPR Article 35 DPIA as their FRIA compliance document are non-compliant. The rights a FRIA must address — non-discrimination, dignity, workers’ rights, freedom of expression, access to justice — are not covered by a DPIA. A supervisor presenting a combined DPIA/FRIA that does not actually contain the six Article 27(1) elements in respect of the non-data rights will identify this gap immediately.

Failure 3: Missing the notification to the market surveillance authority. The FRIA document is only half the obligation. Notification of results to the relevant market surveillance authority is mandatory under Article 27(3) for all in-scope deployers — not only those whose assessment identifies high residual risk. Organisations that complete a thorough FRIA and file it internally without notifying the relevant authority are still non-compliant on the notification obligation.

Failure 4: Generic risk identification that is not deployment-specific. Element (d) — specific risks of harm — fails when it contains generic statements about AI risks rather than specific, deployment-context risk pathways tied to identified affected groups. A credit scoring FRIA that notes “the system may produce discriminatory outcomes” without specifying which protected characteristics, which population segments, and what the deployment-specific risk factors are, does not satisfy Article 27(1)(d). The provider’s Article 13 transparency documentation is the starting point — but the deployer must add deployment-context specificity that the vendor cannot provide.

Failure 5: Complaint mechanisms that do not cover the full FRIA scope. Element (f) requires AI-specific complaint mechanisms — pathways for affected individuals to challenge AI-assisted decisions, understand the AI’s role in those decisions, and access human review. Pointing to a general GDPR data subject rights procedure as the sole complaint pathway does not satisfy this element. The rights a FRIA covers — access to justice, the right to good administration, effective remedy — require complaint mechanisms that go beyond data access and deletion rights. Organisations that have robust GDPR complaint channels but no AI-specific escalation and challenge pathway for automated-decision review are almost universally deficient on element (f).

❓ Frequently Asked Questions: EU AI Act FRIA (Article 27)

What does FRIA stand for?

Fundamental Rights Impact Assessment. It is the mandatory pre-deployment assessment required under Article 27 of the EU AI Act (Regulation (EU) 2024/1689) for specific categories of deployers of high-risk AI systems. It evaluates potential impacts on the fundamental rights protected under the EU Charter of Fundamental Rights — a broader scope than the data-focused DPIA under GDPR Article 35.

Is the FRIA the same as a DPIA?

No. They overlap but are not the same, and one does not substitute for the other. A DPIA under GDPR Article 35 assesses risks to personal data processing. A FRIA under EU AI Act Article 27 assesses the full spectrum of fundamental rights — including non-discrimination, human dignity, freedom of expression, workers’ rights, and access to justice — that a DPIA was never designed to evaluate. Article 27(4) permits a joint assessment document where genuine overlap exists, but the combined document must fully satisfy both sets of content requirements.

Who must complete an EU AI Act FRIA?

Three categories of deployers: (1) bodies governed by public law deploying any Annex III high-risk AI system except critical infrastructure safety components; (2) private entities providing public services (education, healthcare, social services, housing, justice) deploying those same systems; and (3) any deployer — public or private — using AI for creditworthiness evaluation, credit scoring, or life and health insurance risk assessment and pricing. Standard private companies deploying high-risk AI in other domains are not subject to Article 27, though they have separate Article 26 obligations.

When must a FRIA be completed?

Before the high-risk AI system is first put into service. Article 27 is explicit on this point. Post-deployment FRIAs do not satisfy the legal obligation. The Article 27 obligation entered into force on August 2, 2026. In-scope deployers who put qualifying systems into operation after that date without a completed FRIA are already non-compliant and should prioritise remediation immediately.

What are the penalties for not completing a FRIA?

Failure to complete a required FRIA is a breach of deployer obligations under the EU AI Act. Non-compliance with deployer obligations can trigger administrative fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher, under Article 99(4) of the EU AI Act. The notification obligation — submitting FRIA results to the market surveillance authority — carries the same penalty framework. Non-compliance with both the documentation and notification obligations simultaneously represents compounded exposure within the same penalty tier.

Does the Digital Omnibus for AI change the FRIA deadline?

Partially. The Digital Omnibus (Regulation (EU) 2026/1744, in force July 27, 2026) extended the general Annex III high-risk system compliance deadline from August 2, 2026 to December 2, 2027. However, the Article 27 FRIA obligation for the specific deployer categories in Article 27(1) — public bodies, private public-service providers, and credit/insurance deployers — was not deferred. Those organisations are subject to the obligation now. The deadline extension applies to the broader Annex III provider obligations, not to Article 27 deployer-side assessment requirements for the named categories.

Do we need one FRIA per AI system?

Not necessarily. Article 27 permits a single FRIA to cover materially similar deployments of the same system in comparable contexts. A public authority deploying the same AI system across multiple offices using the same workflow and affecting similar populations can rely on one assessment covering the common pattern. Where deployments differ materially — in affected population, decision type, oversight mechanism, or risk profile — separate assessments are required even if the underlying technology is the same.

📌 Key Takeaways

🔗 Related Articles

• 📖 DPIA for AI Systems: A Step-by-Step Compliance Guide (2026)
• 📖 EU AI Act Explained: What It Means for Your Business (2026)
• 📖 AI Governance 101: How to Build a Framework for Your Business
• 📖 The AI Audit Checklist: Vendor Evaluation for Enterprise Deployments
• 📖 AI Risk Assessment 101: A Practical Guide for Business Leaders