EU AI Act Art.27 Fundamental Rights Impact Assessment (FRIA): Who Must Conduct It and How Before August 2, 2026
Post #1 in the sota.io EU AI Act FRIA 2026 Series
The EU AI Act's August 2, 2026 compliance deadline is 59 days away. Most providers of high-risk AI systems know they need CE marking, conformity assessment, and technical documentation. What is less commonly understood is Art.27 — a separate, deployer-side obligation that applies to a specific subset of organisations deploying high-risk AI in practice.
Art.27 mandates a Fundamental Rights Impact Assessment (FRIA): a structured analysis of how a high-risk AI deployment may affect the fundamental rights of the people it touches. This is not a provider obligation. It falls on the deployer — and only on certain deployers. Getting the scoping right is the first challenge.
This post covers who must conduct an Art.27 FRIA, what it must contain, when it must be completed, and what the procedure looks like in practice. Subsequent posts in this series will go deeper into the methodology, documentation templates, and sector-specific considerations.
What Is the Fundamental Rights Impact Assessment?
A Fundamental Rights Impact Assessment is a written analysis performed by a deployer of a high-risk AI system. It identifies and evaluates risks to fundamental rights — rights protected under the EU Charter of Fundamental Rights — that may arise from the specific use of that system in a specific operational context.
The FRIA is distinct from the provider's conformity assessment. The provider's conformity assessment (under Art.43) evaluates whether the AI system as a product meets the technical requirements of the AI Act: accuracy, robustness, data governance, transparency, human oversight. The FRIA sits one level up: it asks whether this particular deployment, by this particular deployer, for this particular purpose, with these particular affected individuals, is likely to affect their fundamental rights in ways that need to be identified, documented, and mitigated.
The rights in scope are broad — everything protected by the EU Charter: dignity, freedom, equality, solidarity, citizens' rights, justice. In practice, the rights most often implicated by high-risk AI are:
- Non-discrimination (Art.21 Charter) — automated decisions affecting employment, credit, welfare
- Privacy and data protection (Arts.7-8 Charter) — profiling, monitoring, biometric processing
- Fair trial and due process (Art.47 Charter) — automated decisions affecting access to justice or public services
- Freedom of movement (Art.45 Charter) — border control and migration AI systems
- Right to education (Art.14 Charter) — AI in educational access and assessment
- Right to work and fair conditions (Arts.15-16 Charter) — recruitment and worker management AI
The FRIA must be conducted before deployment — not as a retrospective audit but as an upfront obligation that shapes how the system is used.
Who Must Conduct a FRIA Under Art.27?
This is where most compliance teams make their first mistake: they assume the FRIA is universal. It is not. Art.27 has a specific scope.
Art.27(1) applies to:
- Bodies governed by public law as defined in EU public procurement law — essentially national, regional, and local government entities and bodies substantially funded or controlled by the state
- Private entities providing public services — specifically, private-law entities that provide public services in areas listed in Annex III of the AI Act
The second category is the harder call. A private company running an outsourced welfare benefits platform for a municipality is likely in scope. A SaaS vendor selling HR software to private employers is generally not — the employer (as deployer) may be in scope, but not as a provider of public services unless the employer is itself a public body.
Who is clearly in scope:
| Deployer type | In scope? |
|---|---|
| National government ministry using AI for benefits eligibility | Yes — Art.27(1)(a) public body |
| Municipal authority using AI for urban planning | Yes — Art.27(1)(a) public body |
| Hospital authority (public) using AI for patient triage | Yes — Art.27(1)(a) public body |
| Private debt collection agency using AI scoring | No — private service to private creditors |
| Outsourced job centre running public employment services | Likely yes — Art.27(1)(b) private entity providing public services |
| University (public) using AI for student admissions | Yes — Art.27(1)(a) public body |
| Private bank using AI for creditworthiness assessment | No — private financial service |
| Private company running government-contracted welfare assessments | Likely yes — depends on contract structure |
One important nuance: Art.27 applies only when the deployer is using a high-risk AI system as classified under Annex III. If the AI tool does not fall into an Annex III category, the FRIA obligation does not apply even if the deployer is a public body.
What Must the FRIA Contain?
Art.27(2) lists the minimum content of the FRIA. Deployers in scope must document:
1. Description of the Deployer's Processes
The FRIA must describe the processes in which the high-risk AI system will be used. This means identifying:
- The specific operational context (what decision or process does the AI support?)
- The frequency and scale of use (how many individuals are affected per day, month, year?)
- The geographic scope (which regions, jurisdictions, or facilities?)
- The categories of individuals affected (employees, claimants, students, patients, etc.)
This contextual description is foundational. A FRIA for an AI system used to triage 5,000 social benefit applications per month requires much more depth than one used to schedule a handful of internal meetings.
2. The Period and Frequency of Use
The FRIA must specify how long the deployment will run and at what frequency the system operates. This matters because the rights impact of an AI system used for a one-time pilot differs significantly from one embedded in daily operational workflows affecting hundreds of people.
This section should include:
- The planned deployment start date and planned review or sunset date
- Frequency of automated or semi-automated decisions (daily, weekly, batch)
- Whether the system is used continuously or episodically
3. Categories of Natural Persons Affected
Art.27(2)(c) requires the FRIA to identify the categories of natural persons (i.e., human individuals) that the system will affect or is likely to affect. This is intentionally broad — it includes not just the primary subjects of the AI's decisions but potentially secondary affected parties.
For example, an AI system used in criminal justice risk assessment directly affects the individual being assessed. But it may also affect family members, victims, or communities. The FRIA must scope out this broader population.
4. Specific Risks to Fundamental Rights
This is the analytical core of the FRIA. Deployers must identify the specific risks to the fundamental rights listed in the EU Charter that are likely to materialise from the deployment. This is not a generic risk list — it must be specific to the system, the use case, and the affected population.
The analysis should include:
- Which specific fundamental rights are most likely to be affected
- How the AI system may create, amplify, or perpetuate those risks (e.g., biased training data, opaque decision logic, lack of contestability)
- The severity and reversibility of potential rights impacts
- Vulnerable groups who may face disproportionate impact (children, elderly, disabled persons, ethnic minorities)
5. Measures to Address the Risks
The FRIA cannot be purely diagnostic. It must document the measures the deployer has put in place (or intends to put in place) to address the identified risks. These may include:
- Human oversight arrangements — who reviews AI-assisted decisions before they take effect
- Contestability mechanisms — how affected individuals can challenge decisions
- Data minimisation practices — limiting the personal data the AI system processes
- Bias monitoring — how the deployer will track and address discriminatory patterns in outputs
- Communication to affected individuals — how and when individuals are informed that AI is involved in decisions affecting them (also required under Art.26(6))
6. Engagement with Data Protection Impact Assessment (DPIA)
Where a DPIA has been conducted under GDPR Art.35 for the same processing activity, Art.27(3) of the AI Act requires the FRIA to be conducted in conjunction with the DPIA. Deployers must coordinate between their AI Act compliance team and their data protection function to avoid duplicating effort while ensuring both obligations are met.
In practice, many high-risk AI deployments by public bodies will already require a DPIA. The FRIA and DPIA should be developed in parallel, with shared input on the processing description, affected persons categories, and risk analysis. They are separate documents but should cross-reference each other.
When Must the FRIA Be Completed?
Art.27(1) is unambiguous: the FRIA must be conducted before deploying the high-risk AI system. This is a prerequisite, not a post-hoc documentation requirement.
For the August 2, 2026 deadline: deployers currently operating high-risk AI systems (or who will deploy them by August 2, 2026) should treat today as the start of their FRIA process. 59 days is sufficient to complete a FRIA for most systems, but not if the process is started in mid-July.
Key timeline milestones:
| Activity | Recommended completion |
|---|---|
| Confirm FRIA scope (is Art.27 applicable?) | Immediately — by June 15, 2026 |
| Gather system documentation from provider | By June 22, 2026 |
| Map affected persons and processes | By June 30, 2026 |
| Conduct rights risk analysis | By July 14, 2026 |
| Define and document mitigation measures | By July 21, 2026 |
| Finalise and sign FRIA document | By July 28, 2026 |
| Deploy (or confirm ongoing deployment is compliant) | August 2, 2026 |
How Does the FRIA Relate to Other Deployer Obligations?
The FRIA does not exist in isolation. Art.27 sits alongside a broader set of deployer obligations under Art.26.
Art.26 deployer obligations include:
- Using the high-risk AI system only in accordance with the instructions for use provided by the provider
- Monitoring the system's operation with reference to the instructions for use
- Ensuring human oversight of AI-assisted decisions
- Informing natural persons that they are subject to AI-assisted decision-making where the system involves natural persons (Art.26(6))
- Suspending use and notifying the provider where the system poses risks
- Retaining logs (where technically feasible) in accordance with applicable law
The FRIA should document how these Art.26 obligations are implemented in the specific deployment context. The human oversight arrangements required under Art.26, for example, are directly relevant to the FRIA's mitigation measures section.
Where the deployer is also processing personal data, GDPR obligations apply in parallel — including data subject rights under GDPR Arts.13-15 (transparency, access) and Art.22 (automated decision-making). The intersection of GDPR Art.22 and EU AI Act Art.27 is particularly important for deployers using AI to make fully automated decisions with significant effects.
Who Conducts the FRIA Internally?
Art.27 does not specify a designated role for conducting the FRIA, but best practice and emerging guidance from data protection authorities point toward a cross-functional approach:
- Legal / compliance — ensures the FRIA meets the Art.27 requirements and coordinates with DPIA obligations
- AI system owners — describe the operational context, frequency, affected persons
- Data protection officer (DPO) — coordinates with DPIA; DPOs in public bodies often have mandatory involvement under GDPR Art.37
- Human rights or equality leads — provide expertise on specific fundamental rights risks
- IT / AI team — explains the system's technical logic, data inputs, and output mechanisms
The FRIA should be reviewed and signed off at an appropriate level of seniority — typically a director-level official or equivalent in a public body. This is not just good practice: it ensures accountability and demonstrates to regulators that the assessment was taken seriously.
Registering the FRIA
Art.27(4) requires deployers to register the completed FRIA in the EU AI database established under Art.71. This is the same EU AI database that providers use to register their high-risk AI systems before placing them on the market.
The practical mechanics of deployer registration in the EU database are still being developed by the Commission. What is clear is:
- Registration is mandatory for deployers in scope of Art.27
- It must occur before or concurrent with deployment
- The EU database is being established by the Commission with a target operational date aligned to the August 2, 2026 deadline
Deployers should monitor the Commission's EU AI Office communications for updates on the registration interface. The current provider registration portal for EUDB is already operational — deployer registration functionality is expected to be added before August 2026.
Common Pitfalls to Avoid
Pitfall 1: Assuming the Provider's Conformity Assessment Covers the Deployer
The provider's conformity assessment satisfies the provider's obligations under Art.43. It does not substitute for the deployer's FRIA. Deployers that receive a conformity assessment certificate from their AI vendor and assume they are done are exposed.
Pitfall 2: Generic Risk Identification
A FRIA that lists "discrimination" and "privacy" as risks without tying them to the specific system, specific use case, and specific affected population will not satisfy Art.27. The regulation requires specificity. Regulators reviewing FRIAs will look for evidence that the deployer actually analysed its own deployment, not copied a template.
Pitfall 3: No Mitigation Measures
Some deployers complete the diagnostic sections of the FRIA but fail to document concrete mitigation measures. The FRIA is not complete without a documented plan for addressing identified risks.
Pitfall 4: Conducting the FRIA After Deployment
Art.27 is explicitly a pre-deployment obligation. A FRIA completed after the AI system has been live for months may be accepted by regulators as a remediation measure, but it does not constitute compliance with Art.27's forward-looking requirement.
Pitfall 5: Siloing the FRIA from GDPR Compliance
Where a DPIA is required, Art.27(3) mandates coordination. A deployer that conducts the FRIA and DPIA independently — with no cross-referencing and no shared process — risks duplicating effort and creating inconsistencies that regulators will find problematic.
What's Next in This Series
This first post has established the foundations: who Art.27 applies to, what the FRIA must contain, and the critical August 2026 timeline.
Upcoming posts in the EU AI Act FRIA 2026 Series will cover:
- Post #2: FRIA methodology — how to conduct the rights risk analysis in practice
- Post #3: Sector-specific FRIA considerations (social welfare, employment, law enforcement, healthcare)
- Post #4: FRIA and DPIA coordination — avoiding duplication while meeting both obligations
- Post #5: FRIA documentation templates and EU database registration walkthrough
If you are a public body or private entity providing public services and you are deploying high-risk AI systems, the Art.27 FRIA is not optional. The 59-day window before August 2, 2026 is tight but workable if the process starts now.
Summary: Art.27 FRIA at a Glance
| Question | Answer |
|---|---|
| Who must conduct a FRIA? | Public bodies + private entities providing public services |
| When? | Before deploying the high-risk AI system |
| What triggers it? | Deploying a high-risk AI system (Annex III) |
| What must it contain? | Processes, period, affected persons, rights risks, mitigation measures |
| Where is it registered? | EU AI database (Art.71) |
| How does it relate to DPIA? | Must be conducted in conjunction with DPIA (Art.27(3)) |
| Deadline? | August 2, 2026 |
The FRIA is the deployer's commitment to fundamental rights — not a box-ticking exercise, but a structured analysis that shapes how high-risk AI is used responsibly in public and quasi-public contexts. Getting it right before August 2 is both a legal obligation and a signal to citizens, regulators, and oversight bodies that your organisation takes AI governance seriously.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.