Fundamental Rights Impact Assessment
Also called: FRIA.
Where it comes from: EU AI Act, Article 27.
Applies from: December 2027.
Timing: completed before the system is put into use.
Who It Applies To
This is the first thing to establish, and it is narrower than people assume.
The obligation reaches specific categories of deployer rather than everyone deploying a high-risk system. The categories are set out in the Article.
Two questions, in order:
- Is the system high-risk under the Act
- Does your organization fall within the deployer categories the Article names
A high-risk system alone does not create the obligation. Both have to be true.
This is a question for counsel. Get the applicability answer before building the assessment, not after.
What It Examines
The Data Protection Impact Assessment asks what happens to the data.
The Fundamental Rights Impact Assessment asks what happens to the people.
The questions it is built around:
- Which rights could be affected
- What happens to a specific person when the system gets it wrong
- Whether the system creates disadvantage for particular groups
- Who is accountable for the outcomes
- What oversight exists
- Whether affected people can meaningfully challenge a decision
That last one is the heart of it, and it is the question a data protection assessment does not ask.
What It Has to Cover
The deployer's own use, described concretely:
- The processes in which the system will be used
- How long you intend to use it and how often
- The categories of people likely to be affected
- The specific risks of harm to those categories
- The human oversight arrangements in place
- What happens if a risk materialises — governance, escalation, complaint routes
Note the emphasis on your deployment. This is not an assessment of the technology in general. It is an assessment of what you are doing with it, to whom, in your context.
A Note on the Template
The official template contemplated by the Act has not been published.
Organizations are building the assessment from the Article's own requirements. Where structured guidance exists, it comes from civil society and human rights bodies rather than the regulator.
Practical consequence: document your reasoning about structure as well as substance. If the format is later standardized, you want a record of why you built it the way you did.
Where the Information Probably Lives
| What you need | Where to look |
|---|---|
| High-risk classification | Prior governance record; vendor documentation; counsel |
| Whether you fall in the deployer categories | Counsel |
| The processes the system supports | Business lead; process documentation |
| Intended duration and frequency of use | Business lead; the business case |
| Categories of people affected | Business lead; HR; the customer record system |
| Whether vulnerable groups are included | Business lead; the population served |
| Specific risks of harm | Business lead; prior incidents; complaint records |
| Human oversight arrangements | Business lead; process documentation; IT configuration |
| Who can override the system | Business lead; the named owner |
| Escalation route | Incident response documentation; security |
| Complaint mechanism | Customer service; HR for employee-facing systems |
| Provider information about the system | Vendor documentation; the instructions for use |
| Existing data protection assessment | Privacy team — reuse what overlaps |
On the last row. Where a Data Protection Impact Assessment already exists for the same deployment, the factual sections overlap substantially. Reuse the description of the processing rather than rewriting it.
The analysis does not overlap. The facts do.
Who Supplies What
Counsel:
- Whether the obligation applies at all
- Whether the assessment is sufficient
You or the privacy function:
- Structure and assembly
- Coordinating the input
- The record
The business:
- What the system does in practice
- Who is affected
- What happens when it is wrong
People closer to those affected:
- Employee representatives, where the system touches workers
- Customer-facing teams, where it touches customers
- Anyone who handles complaints about the current process
That last group is easy to overlook and worth including. The people who field complaints already know how the existing process fails people.
Common Gaps
- Built before applicability was confirmed. Establish whether you are in scope first.
- Assessed the technology rather than the deployment. The Article asks about your use, in your context.
- Affected groups described too broadly. "Customers" is not a category of person likely to be affected. Which customers, in what circumstances?
- Human oversight described as existing rather than functioning. Who can override it, do they have the information to do so, and does it happen in practice?
- No complaint route. If someone is affected and disagrees, what do they do?
- Nobody outside the project consulted. The assessment is about people. Talk to someone who represents them.
- Treated as a document exercise. If the assessment surfaces a serious risk and nothing changes, it has not done its job.
One Practical Note
This assessment is not a compliance artifact bolted onto a decision already made.
It is intended to inform whether and how to deploy. An assessment produced after the deployment decision, to justify it, satisfies the form and misses the point — and that is visible to anyone reading it.
Applicability and content requirements should be confirmed against the current text of the Act, and applicability specifically should be confirmed with counsel before relying on this handout.
Sources
- EU Artificial Intelligence Act, Regulation (EU) 2024/1689 — Article 27, with Annex III for the high-risk categories and Article 26 for the wider deployer obligations
- The applicability categories are set out in Article 27(1). Read them directly.
- The template contemplated by Article 27(5) had not been published at the time of writing
Structured methodologies have been published by civil society and human rights organizations rather than by the regulator. Where you rely on one, record which and why.
Applicability specifically should be confirmed with counsel. A high-risk classification alone does not create the obligation.
Use and reuse
Free to use, share, and adapt within your organization. Attribution appreciated, not required. No warranty of any kind — this is practitioner guidance, not legal advice, and sufficiency is determined by your counsel.
LegisGate · Regulatory Intelligence for AI Deployments · legisgate.com
Written by compliance and audit practitioners who spent decades on the other side of the table.
Version 1.0 · Current as of August 2026 · Verify time-sensitive claims against current sources before relying on them.