EU AI Act Article 27: The Practical Guide to Fundamental Rights Impact Assessments (FRIA) for Deployers
Most compliance teams preparing for the EU AI Act's August 2026 deadline are focused on conformity assessments, technical documentation, and human oversight logs. The Fundamental Rights Impact Assessment - the FRIA - tends to arrive late on the agenda, if it arrives at all.
That's a problem. Article 27 of the EU AI Act requires certain deployers of high-risk AI systems to complete a FRIA before first deployment, with the obligation applying from 2 August 2026 for stand-alone Annex III high-risk systems. Miss it, and you're in breach from day one of enforcement - not after a grace period.
This guide is written for compliance, legal, and product teams at organisations that deploy high-risk AI. It answers the four questions that matter most: Do you owe a FRIA at all? What must it contain? How does it relate to your existing GDPR DPIA? And what do you do right now, given that the official template still hasn't been published?
What Is a FRIA - and Why Does It Exist?
A FRIA is a structured pre-deployment review required under Article 27 of the EU AI Act. Where a Data Protection Impact Assessment focuses on data - what you collect, how you store it, and whether processing is lawful - a FRIA focuses on people: whether your system treats them fairly, whether it creates systemic disadvantage, and whether those affected by its decisions have a meaningful path to challenge them.
A FRIA is not a DPIA, not a conformity assessment, and not a NIST AI RMF impact assessment. It covers the full spectrum of fundamental rights in the EU Charter of Fundamental Rights, not only data protection.
Article 27 is one of the few provisions in the AI Act that diverges from the predominantly technical compliance requirements and requires deployers to reflect on why, where, and how the high-risk AI system will be deployed. That makes it qualitatively different from the rest of the deployer obligations checklist - and harder to delegate to a technical team alone.
Do You Actually Owe a FRIA? The Scoping Question
This is where many organisations go wrong - either assuming they're in scope when they're not, or (more dangerously) assuming they're out of scope when they are.
Article 27 applies to three distinct groups of deployers, not to all deployers of high-risk AI. Those three groups are: (1) public bodies deploying any Annex III high-risk AI system except those in point 2 (critical infrastructure); (2) private entities providing public services deploying those same systems; and (3) any deployer - public or private - using AI systems for creditworthiness evaluation (Annex III, point 5(b)) or life and health insurance risk assessment and pricing (Annex III, point 5(c)).
The third category is the one that surprises teams most. Organisations using AI for creditworthiness assessment, credit scoring, or risk assessment and pricing for life and health insurance fall under this category regardless of whether they are a public or private organisation. A fintech lender, an insurtech pricing platform, or a traditional bank using an AI credit model all owe a FRIA - even if they have no public-sector character whatsoever.
A FRIA obligation does not apply to every deployer of a high-risk AI system. An ordinary private company deploying, say, an AI-powered recruitment screening tool or a warehouse safety system is subject to other Article 26 obligations - but not Article 27 - unless it falls into one of the three categories above.
Use the decision widget below to check your organisation's position quickly.
The Six Required Elements: A Practical Walkthrough
Article 27(1) specifies six elements that every FRIA must address, labelled (a) through (f). These are: the deployer's processes in which the system will be used per its intended purpose; the period and frequency of intended use; the categories of natural persons and groups likely to be affected; the specific risks of harm to those persons, taking account of the information given by the provider pursuant to Article 13; a description of human oversight measures per the instructions for use; and measures to be taken if those risks materialise, including arrangements for internal governance and complaint mechanisms.
Here is what each element demands in practice.
(a) Description of the deployer's processes
This is not a copy-paste of the provider's system description. It requires you to describe your operational context: which business process the AI feeds into, who makes decisions based on its outputs, and how those outputs flow through your organisation. A credit bureau deploying a scoring model and a bank deploying the same model will write very different answers here.
(b) Period and frequency of use
Document how long the deployment is intended to run and how often the system will generate outputs affecting individuals. A system that scores loan applications in real time, 24/7, carries a different risk profile than one used quarterly for portfolio review. This element also triggers the update obligation: if the deployment scope changes materially, the FRIA must be revised.
(c) Categories of affected persons and groups
A FRIA represents a systematic evaluation process designed to identify, assess, and mitigate potential impacts on individuals' fundamental rights. Unlike traditional technical conformity assessments, FRIAs examine the broader societal implications of AI deployment, addressing risks such as algorithmic bias, privacy infringements, and discriminatory outcomes. Map not just the primary users of the system's outputs, but anyone who may be indirectly affected - including groups who never interact with the system directly. A system can affect rights without those individuals having direct contact with it. A social housing allocation algorithm affects the rights of people who never interact with the software directly.
(d) Specific risks of harm
A FRIA under AI Act Article 27 covers all fundamental rights in the EU Charter - including rights that have no connection to personal data. A credit scoring model that discriminates on the basis of postcode (a proxy for ethnicity) implicates the non-discrimination right whether or not the model processes any personal data directly. Any FRIA that omits a structured Charter rights analysis beyond the data-protection chapter is legally deficient.
This element requires you to draw on the provider's Article 13 transparency documentation - the instructions for use, known limitations, and performance characteristics. If your provider hasn't supplied adequate Article 13 documentation, that is itself a compliance gap to resolve before you can complete a defensible FRIA.
(e) Human oversight measures
Describe the specific oversight mechanisms you have implemented, mapped to the provider's instructions for use. This includes the identity and competence of designated oversight personnel and the authority of oversight personnel to override, halt, or reverse AI outputs. Generic statements about "human review" will not satisfy this element. Name the role, the decision point, and the authority.
(f) Measures if risks materialise
This section focuses on risk mitigation, including the implementation of human oversight measures, as well as measures to address the risks upon materialisation. This includes internal governance arrangements and complaint mechanisms. Affected persons have a right to explanation under Article 86 of the AI Act; your complaint mechanism should be designed with that right in mind.
The FRIA must be completed BEFORE deployment. Article 27(1) is unambiguous on this point. A retrospective FRIA — completed after the system is already live — does not satisfy the legal obligation. For organisations that have already deployed in-scope systems, the practical deadline is 2 August 2026: the FRIA must be completed before that date, not after.
The DPIA Relationship: Complement, Don't Conflate
Most compliance teams working on high-risk AI systems will already be running GDPR Data Protection Impact Assessments. The good news is that Article 27 explicitly allows you to leverage that work. The risk is assuming the DPIA alone is sufficient.
The FRIA under Article 27 focuses specifically on the impact of the high-risk AI system on fundamental rights - non-discrimination, privacy, freedom of expression, human dignity - whereas the DPIA under GDPR Article 35 assesses risks to personal data protection. Article 27(4) allows deployers to combine both assessments where the AI system processes personal data, but the FRIA scope is broader than data protection.
If any of the obligations laid down in Article 27 is already met through the data protection impact assessment conducted pursuant to Article 35 of Regulation (EU) 2016/679, the fundamental rights impact assessment shall complement that data protection impact assessment. The word "complement" is deliberate: a DPIA alone never satisfies the FRIA obligation.
The practical approach most organisations are taking: build one shared evidence base, produce two formatted deliverables. Track which sections map to which regulation in an evidence register. The FRIA goes to the market surveillance authority; the DPIA goes to the data protection supervisory authority. Some member states may designate the same authority for both - verify locally.
| Dimension | GDPR DPIA (Art. 35) | AI Act FRIA (Art. 27) |
|---|---|---|
| Legal basis | GDPR Regulation (EU) 2016/679 | EU AI Act Regulation (EU) 2024/1689 |
| Who owes it | Any controller processing high-risk personal data | Specific deployers of Annex III high-risk AI systems |
| Scope of rights covered | Data protection rights only | Full EU Charter of Fundamental Rights |
| Submitted to | Data protection supervisory authority | National market surveillance authority (AI Act) |
| Timing | Before processing begins | Before first deployment of the AI system |
| Can they be combined? | Yes — where the AI system processes personal data | Yes — FRIA complements the DPIA; does not replace it |
Notification and the Missing Template
Once the FRIA is complete, the obligation doesn't end with an internal sign-off. Once the assessment has been performed, the deployer shall notify the market surveillance authority of its results, submitting the filled-out template referred to in paragraph 5 of this Article as part of the notification.
Article 27(3) requires that the FRIA be notified to the national market surveillance authority before first deployment. The Act does not specify an advance notice period; practical guidance from early member state implementations suggests at least 30 calendar days to allow authorities to raise questions.
There is a complication. Article 27(5) requires the EU AI Office to develop a template questionnaire - including an automated tool - to simplify compliance, but as of mid-2026 that template had not yet been published. While the EU AI Office is required by Article 27(5) to publish a template questionnaire, that template had not been published as of early 2026. Organisations should not wait for it. The Article 27(1) requirements are sufficiently specific to support documentation now, and the template, when published, will require mapping existing assessments to it rather than starting from scratch.
There is a second complication on the receiving end. As of early 2026, only 8 of 27 EU member states had formally designated their single point of contact or market surveillance authority under the AI Act. This represents a significant implementation lag. Compliance teams should monitor the AI Act national implementation plans page for updates in their relevant jurisdictions. The absence of a designated authority in your member state does not suspend the obligation to complete the FRIA - it only creates uncertainty about where to send the notification.
What Happens If You Don't Do It
Non-compliance with Article 27 is not a minor procedural lapse. Non-compliance with Article 27 constitutes an infringement of Chapter III of the AI Act, subject to administrative fines of up to €15 million or 3% of global annual turnover.
Non-compliance with Article 27 is a Chapter III infringement, subject to fines up to EUR 15 million or 3% of global annual turnover - whichever is higher.
The financial exposure is only part of the picture. The practical consequence often precedes the fine: a market surveillance authority enquiry triggered by a complaint will request the FRIA, and its absence is a standalone finding of non-compliance. In other words, a single complaint from an affected individual can trigger an investigation that immediately surfaces the missing document.
National market surveillance authorities will have full investigation and enforcement powers from August 2026.
Start Now: A Practical Checklist
The official template is not yet available. The market surveillance authority in your jurisdiction may not yet be formally designated. Neither of those facts changes your obligation - or the deadline.
Check whether your organisation is a body governed by public law, a private entity providing public services, or a deployer of AI systems for credit scoring or life/health insurance pricing (Annex III, points 5(b)/(c)). Use the decision tree above. If in doubt, run the FRIA — the cost of an unnecessary assessment is far lower than the cost of a missed obligation.
List every AI system your organisation deploys that falls within Annex III. For each, confirm the provider, the intended purpose, and whether you have received Article 13 instructions for use. Missing provider documentation is a gap to resolve before you can complete element (d) of the FRIA.
Element (d) of the FRIA requires you to assess risks 'taking account of the information given by the provider pursuant to Article 13.' Request this documentation from your AI system providers now. If a provider cannot supply it, that is a red flag about the system's compliance status.
If you have an existing DPIA for the system, map it against the six Article 27(1) elements. Identify which elements are already addressed and which require additional analysis — particularly the Charter rights analysis beyond data protection (non-discrimination, access to justice, human dignity, freedom of expression).
Build your internal template around the six elements: (a) deployer processes, (b) period and frequency, (c) affected persons, (d) specific risks of harm, (e) human oversight measures, (f) measures if risks materialise. When the official AI Office template is published, map your existing document to it — you will not need to start over.
Check the European Commission's AI Act national implementation plans page for your member state's designated authority. If no authority has been formally designated yet, document your monitoring process and prepare the notification package so it can be submitted immediately upon designation.
Obtain internal sign-off from legal, compliance, and the relevant business owner. Record the date of completion. The FRIA must be completed — and the notification submitted — before the system goes live. For systems already deployed, the deadline is 2 August 2026.
A FRIA completed today may not remain valid if the system changes materially. Establish review triggers: significant model updates, changes to the affected population, new use cases, or changes to the deployment context. For similar subsequent deployments, the FRIA can be updated rather than redone from scratch.
Frequently Asked Questions
Does a private company that is not providing public services ever owe a FRIA?
Yes — if it deploys high-risk AI for creditworthiness evaluation or credit scoring (Annex III, point 5(b)), or for risk assessment and pricing in life and health insurance (Annex III, point 5(c)). The obligation in those two categories applies to any deployer, public or private. Outside those categories, ordinary private deployers generally do not owe a FRIA under Article 27, though they remain subject to other Article 26 deployer obligations.
Can we rely on the AI system provider's impact assessment instead of doing our own FRIA?
Partially. Article 27(2) allows a deployer to rely on previously conducted impact assessments carried out by the provider in similar cases. However, a provider's generic assessment will rarely address your specific processes, your specific affected populations, or your complaint mechanism. The notification obligation under Article 27(3) also rests on the deployer, not the provider. Treat provider assessments as useful inputs, not substitutes.
What if the official AI Office FRIA template still hasn't been published by our deployment date?
Proceed without it. The substantive requirements in Article 27(1) are already clear and legally binding. Build your FRIA around the six elements in Article 27(1)(a)–(f). When the official template is published, map your existing document to it — you will not need to start from scratch. Waiting for the template is not a defence against non-compliance.
Is the FRIA a public document?
Not automatically. The Act does not require FRIAs to be published. They are submitted to the market surveillance authority and retained by the deployer. However, Article 86 grants affected persons a right to explanation of individual decision-making that may require sharing relevant FRIA sections on request. Some member states may impose additional transparency requirements on public-sector FRIAs.
How often does the FRIA need to be updated?
The FRIA must be completed before first deployment. It should be updated when circumstances change materially — significant model updates, changes to the affected population, new use cases, or changes to the deployment context. For similar subsequent deployments, the existing FRIA can be updated rather than redone from scratch. For AI systems with continuous or periodic retraining, treat the FRIA as a living document connected to the system's operational reality.
Does the FRIA apply to AI systems already deployed before 2 August 2026?
Yes. For in-scope systems already in service, the practical deadline is 2 August 2026 — the FRIA must be completed before that date. The obligation applies from the date the system is first used after the Article 27 application date. Organisations that have already deployed in-scope systems should treat the obligation as applicable from 2 August 2026 and complete the FRIA before that date.
This post is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel for advice specific to your organisation's situation.
Related reading
Harmonised Standards and Presumption of Conformity Under the EU AI Act: A Plain-English Guide to Articles 40 and 41
What "presumption of conformity" actually buys you under Articles 40 and 41, why the CEN-CENELEC standards are delayed, and what high-risk AI providers must do right now.
EU AI Act Article 9: A Plain-English Guide to the Risk Management System for High-Risk AI
Article 9 of the EU AI Act requires a continuous, lifecycle-wide risk management system for every high-risk AI system. Here's exactly what that means and how to build one.
Article 22 EU AI Act: The Plain-English Guide to Authorised Representatives for Non-EU Providers
If you build high-risk AI outside the EU and want to sell into the EU market, Article 22 requires you to appoint an EU authorised representative by written mandate - before you go live. Here's exactly what that means.