How to Fill In a FRIA Under the EU AI Act: A Field-by-Field Guide

The Fundamental Rights Impact Assessment — FRIA — is one of the most misunderstood obligations in the EU AI Act. Many deployers assume it is a short checkbox exercise. It is not. A properly completed FRIA is a structured, documented analysis that can run to fifteen or twenty pages for a complex high-risk system. Regulators and auditors will read it.

This guide walks through every field required by Article 27 of Regulation (EU) 2024/1689, explains what belongs in each section, and flags the mistakes that cause FRIAs to fail compliance review.

Who Must Complete a FRIA

Article 27(1) of the AI Act requires a FRIA from any deployer that is:

A body governed by public law, as defined in EU public procurement law (Directive 2014/24/EU, Article 2(1)(4)); or
A private entity providing services to the public in the general interest, where that service is subject to public oversight or public funding.

Private companies deploying high-risk AI purely for internal business purposes — employee HR screening, internal fraud detection — are not automatically required to complete a FRIA, although Article 27(3) encourages all deployers to conduct equivalent voluntary assessments.

The obligation applies before deployment begins. A FRIA completed after a high-risk AI system goes live is non-compliant.

The Eight Core Sections of a FRIA

Section 1: Deployer and System Identification

What to write: Full legal name of the deploying organisation, its legal form, registered address, and the name of the responsible person for the AI deployment. Then identify the AI system by its commercial name, the name of the provider, the provider's EU Declaration of Conformity reference number, and the version deployed.

Common mistake: Listing the system name without the provider's Declaration of Conformity reference. Auditors use this reference to cross-check the provider's published documentation. If you do not have it, request it from your provider before deployment.

Section 2: Description of the Intended Use in Your Specific Context

What to write: This section goes beyond copying the provider's instructions for use. Describe precisely how your organisation will use the system — which specific decisions the AI will inform or make, which staff will interact with it, at what stage of a process the AI output is generated, and what happens downstream from that output.

If you are a municipality deploying an AI benefit eligibility screening tool, describe which benefits are in scope, how many applications the system will process monthly, and what the case worker does with the AI's output.

Common mistake: Pasting the provider's product description into this field. The FRIA must reflect your specific deployment context, not the provider's generic system description.

Section 3: Categories of Natural Persons Affected

What to write: Identify all groups of people whose rights or interests are affected by the AI system's operation. This includes direct subjects (the people about whom the AI makes a decision) and indirect subjects (third parties who may be affected by that decision).

For each group, note any characteristics that make them potentially vulnerable: age (minors, elderly), disability status, migration or refugee status, socioeconomic position, limited digital literacy, or membership of a minority group. The AI Act's Recital 47 specifically calls attention to vulnerability as an aggravating factor in fundamental rights assessments.

Common mistake: Identifying only the primary user group. A school admissions AI affects not only applicants but also applicants' families and, indirectly, excluded communities.

Section 4: Fundamental Rights at Risk

What to write: Systematically work through the EU Charter of Fundamental Rights and identify which rights may be affected by the AI system's outputs. The most commonly implicated rights for high-risk AI are:

Article 1 (Human dignity)
Article 7 (Respect for private and family life)
Article 8 (Protection of personal data — intersects with GDPR)
Article 20 (Equality before the law)
Article 21 (Non-discrimination)
Article 24 (Rights of the child, if minors are affected)
Article 41 (Right to good administration — for public bodies)
Article 47 (Right to an effective remedy and fair trial)

For each right identified as potentially affected, assess the likelihood and severity of the potential impact on a scale: no risk, low risk, medium risk, high risk. Provide a brief rationale for each assessment.

Common mistake: Listing only data protection rights. Non-discrimination (Article 21) and the right to an effective remedy (Article 47) are equally important and frequently overlooked.

Section 5: Discrimination Risk Assessment

What to write: This is a standalone section because the AI Act treats discrimination risk with particular weight. Identify whether the AI system's training data, decision logic, or outputs could produce differential outcomes for individuals or groups sharing a protected characteristic under EU non-discrimination law (sex, racial or ethnic origin, religion or belief, disability, age, sexual orientation).

Describe whether you have reviewed the provider's technical documentation for evidence of bias testing, and summarise what that review found. If the provider has not disclosed bias testing results, note that gap explicitly — it may affect your procurement decision.

Common mistake: Stating "no discrimination risk identified" without any supporting analysis. This will not survive regulatory scrutiny. Even if your conclusion is low risk, document the reasoning.

Section 6: Measures to Mitigate Identified Risks

What to write: For each risk identified in sections 4 and 5, describe the specific measure your organisation is implementing to mitigate or manage that risk. Measures should be concrete and operational, not generic.

Examples of concrete mitigation measures:

Human review mandatory for all negative decisions, with a minimum 48-hour reconsideration window
Quarterly bias audits of AI output disaggregated by gender, nationality, and disability status
Appeals mechanism documented in the instructions given to affected persons
Specific training provided to case workers on how to interrogate and override AI outputs
Logging of all AI outputs and case worker decisions, retained for five years

Common mistake: Writing "human oversight will be maintained" without specifying who, how, with what authority, and with what recourse for affected individuals.

Section 7: Human Oversight Arrangements

What to write: This section overlaps with Article 14 provider obligations but addresses the deployer's specific operational arrangements. Document:

Which roles in your organisation are responsible for overseeing the AI system
What authority those roles have to override, suspend, or escalate AI outputs
How oversight decisions are documented and retained
What triggers an escalation (e.g., confidence threshold below a defined level, output in a defined edge-case category)
How you will inform affected individuals that an AI system has been used in a decision about them (Article 50 transparency obligation)

Common mistake: Describing oversight in terms of the system's technical capabilities rather than your organisation's actual operational process.

Section 8: Consultation and Sign-Off

What to write: Record who was involved in preparing the FRIA — job titles, departments, and whether external expertise was engaged. Record any consultation with data protection authorities, equality bodies, or affected communities. Record the date the FRIA was approved and the name and title of the approving official.

For public bodies, Article 27(6) requires consultation with data subjects or their representatives where feasible. Document whether this was done and, if not, why it was not feasible.

Common mistake: Treating the FRIA as a solo compliance task. Article 27 expects cross-functional input — legal, operational, HR, and ideally affected community representatives.

Keeping the FRIA Up to Date

A FRIA is not a one-time document. Article 27(5) requires deployers to review and update the FRIA whenever there is a substantial change to the system or its deployment context. A new version of the AI system, a change in the population being assessed, or a new use case all trigger a review obligation.

Build a review cadence into your governance calendar: annual minimum, or on any material change, whichever comes first.

How DilAIg Helps

DilAIg's 50-question audit generates your FRIA automatically alongside the three other mandatory documents — Technical Documentation, Declaration of Conformity, and Transparency Notice. The audit covers every Article 27 field and produces a document ready for review by your legal team, your DPA, and national market surveillance authorities.

Start your free audit at dilaig.com and generate your FRIA in under an hour.

FAQ: Completing a FRIA Under the EU AI Act

Q: Is a FRIA the same as a DPIA under GDPR? No, but they are closely related. A DPIA (Data Protection Impact Assessment) under GDPR Article 35 assesses risks to personal data rights. A FRIA under AI Act Article 27 assesses risks to the full range of fundamental rights in the EU Charter. For high-risk AI systems that process personal data — which is most of them — you need both. They can be conducted simultaneously and documented in a coordinated way to avoid duplication.

Q: Does a private hospital need to complete a FRIA? Most likely yes. Private hospitals providing services under national health insurance systems or public health frameworks are providing services of general public interest. The "private" legal form of the entity does not exempt it if the service itself is a public interest service. In doubt, consult your national supervisory authority.

Q: Can the AI provider complete the FRIA on behalf of the deployer? No. The FRIA is a deployer obligation and must reflect the deployer's specific use context. Providers can assist by providing detailed technical documentation that supports the FRIA — but they cannot substitute for the deployer's own analysis of its context, affected populations, and operational oversight arrangements.

Q: What happens if we skip the FRIA? Failure to conduct a FRIA where required is a violation of Article 27. National market surveillance authorities can order corrective action, impose fines, and prohibit use of the AI system pending compliance. Under the AI Act's enforcement structure, fines for non-compliance with obligations (other than prohibited AI) can reach €15 million or 3% of global annual turnover, whichever is higher.

Key Takeaways

A FRIA is required before deployment by all public bodies and entities providing public interest services that deploy high-risk AI systems.
The FRIA covers eight structured sections: identification, deployment context, affected persons, rights at risk, discrimination risk, mitigation measures, human oversight, and sign-off.
Copying the provider's system description is not sufficient — the FRIA must reflect your specific deployment context.
The FRIA must be reviewed and updated whenever there is a material change to the system or deployment context.
A FRIA is a living compliance document, not a one-time checkbox. Build it into your governance calendar.