A Fundamental Rights Impact Assessment (FRIA) under EU AI Act Article 27 has four core sections: system description, process description, rights impact analysis, and mitigation/governance measures. It's required only for specific deployers — public bodies, private operators of public services, and any deployer using AI for creditworthiness or life/health insurance pricing — not every high-risk system trigger's one.
Most AIGP candidates first meet the Fundamental Rights Impact Assessment (FRIA) as an abstract acronym buried inside Article 27 of the EU AI Act, sandwiched between FRIA and DPIA in a comparison table. That is the wrong way to learn it. The exam does not test whether you can recite the definition — it tests whether you can recognize, given a scenario, which sections of a FRIA a deployer would actually need to complete, and why. Candidates who only memorize the acronym consistently lose points on exactly this kind of applied question.
This guide gives you a working FRIA structure, section by section, with the kind of fill-in-the-blank scaffolding you can practice against using your own hypothetical deployments. It's built directly from the Article 27 obligations, not a generic risk-assessment template repurposed for AI, since generic templates are precisely what leads candidates to write the vague "will ensure fairness" style answers that consistently lose points.
A FRIA is not a DPIA with an AI label. It assesses impact on fundamental rights — non-discrimination, dignity, fair trial, freedom of expression — not just personal data processing. Candidates who blur the two lose points on scenario questions.
Who Actually Has to Complete One
Article 27 limits the FRIA obligation to a specific population: deployers that are bodies governed by public law, or private operators providing public services, plus deployers of high-risk AI systems used to evaluate creditworthiness or to price life and health insurance. If a system is high-risk but the deployer is a private company outside those categories, no FRIA is triggered — that distinction alone shows up repeatedly in exam scenario questions. If you haven't yet worked through how the EU AI Act sorts systems into risk tiers in the first place, that's worth doing before this template, since the FRIA obligation sits entirely downstream of that classification.
| Deployer Type | FRIA Requirement |
|---|---|
| Public Body Deployer | Required for any high-risk system in scope of Annex III |
| Private Operator, Public Service | Required — same standard as public bodies |
| Creditworthiness Evaluation | Required regardless of deployer type |
| Life/Health Insurance Pricing | Required regardless of deployer type |
The Template, Section by Section
Below is the structure broken into the blanks you would actually fill in for a real deployment. Practice this against two or three hypothetical systems — a hiring algorithm, a credit-scoring tool, a public benefits eligibility system — and the exam's scenario questions stop feeling abstract.
Worked Example — Public Benefits Eligibility System
| Field | Entry |
|---|---|
| System | Automated eligibility scoring for housing assistance |
| Affected Group | Low-income applicants, including non-native language speakers |
| Right at Stake | Non-discrimination; access to social assistance |
| Mitigation | Mandatory human review for all denials; quarterly disparate-impact audit by protected category |
FRIA vs. DPIA: The Distinction the Exam Tests Most
If you already hold a CIPP or have done DPIAs under GDPR, the instinct is to treat a FRIA as a variant of that process. Resist it. A DPIA asks: does this processing create risk to personal data? A FRIA asks a broader question: does this system's use create risk to a fundamental right, independent of whether personal data is involved at all.
A useful exam heuristic: if a question scenario describes a system affecting eligibility, access, or treatment of a person or group — and a GDPR-trained instinct says "this needs a DPIA" — check whether it also needs a FRIA. The two assessments frequently run in parallel, addressing different obligations under different legal bases, and Article 27(4) explicitly allows reusing parts of an existing DPIA to avoid duplicating work, provided the rights-specific elements are still addressed.
Where the FRIA Sits in the Broader Compliance Timeline
The FRIA obligation under Article 27 applies from August 2026, alongside the broader set of high-risk system obligations. It is not retroactive in the sense of requiring assessment of historical use, but any system still in active deployment after that date and falling into the deployer categories above needs one completed before, or as part of, that deployment continuing.
For the exam specifically, expect FRIA questions to appear either as direct definitional recall (less common) or as scenario-based "spot the missing obligation" questions, where a fact pattern describes a public-sector deployment and asks what the deployer failed to do. Knowing the four-section structure above is usually enough to identify the gap correctly.
How the FRIA Interacts With the Provider's Documentation
A FRIA does not exist in isolation from the rest of the high-risk compliance package. Deployers are expected to draw on the provider's instructions for use and the system's technical documentation when completing Sections 1 and 2 above — particularly the intended purpose and any limitations the provider has already identified. A deployer who skips this and writes their own characterization of the system's purpose, disconnected from what the provider actually declared, creates an inconsistency that a market surveillance authority is specifically positioned to catch during review.
This is also where the relationship between the FRIA and the EU AI Act's broader conformity assessment regime becomes relevant for exam purposes. Understanding how a system gets classified into the high-risk tier in the first place makes the FRIA obligation feel less like an isolated checklist and more like the natural next step once that classification has already been made.
Common Mistakes Candidates Make on FRIA Questions
Across practice question sets and exam debriefs, the same handful of errors show up repeatedly. Knowing them in advance is often worth more than memorizing the template itself, since the exam tends to test recognition of these exact traps.
- Confusing "high-risk system" with "FRIA-triggering deployer." Every FRIA-triggering scenario involves a high-risk system, but not every high-risk system triggers a FRIA. The deployer category is the gate, not the system's risk tier alone.
- Writing mitigation measures as intentions rather than controls. "We will ensure fairness" is not a measure. "Quarterly disparate-impact testing reviewed by a named compliance officer" is. Exam answer choices are often written to separate vague-but-comforting language from specific, auditable controls.
- Treating the FRIA as a one-time document. Article 27 ties the assessment to the period and frequency of use, which means a system whose deployment context changes (new population, new use case, new geography) should trigger a fresh or updated FRIA, not a footnote to the old one.
- Forgetting the notification step. Completing the four sections above is necessary but not sufficient. Article 27(3) requires notifying the relevant market surveillance authority, and exam scenarios frequently test whether candidates remember this final administrative step exists at all.
Practice Approach
Take three systems you can describe in two sentences each — a hiring tool, a fraud-detection system for a public utility, and a university admissions assistant — and run each through all four sections above without looking at notes. The systems that feel hardest to fill in are usually the ones with the least concrete human oversight described, which is itself a useful signal: vague oversight language is a recurring wrong-answer trap on the actual exam.
Once the four-section structure feels automatic, layer in timing: practice identifying not just what goes in each section but when the FRIA needs to be completed relative to deployment, and what changes would require revisiting it. That timing layer is where scenario questions tend to get harder, and it's also where a solid grasp of how the FRIA differs from the DPIA and AIA more broadly pays off, since several exam questions are built specifically around that boundary.
Before analyzing content, ask two gating questions in order: (1) is the system high-risk, and (2) does the deployer fall into one of the four triggering categories? Only if both are true does the four-section template above become relevant to the question at all — and a surprising number of exam points are lost by candidates who skip straight to Section 3 without confirming the gate first.
Frequently Asked Questions
Does every high-risk AI system require a FRIA?
No. The FRIA obligation is gated by deployer type — public bodies, private operators of public services, and deployers doing creditworthiness or insurance pricing — not by the system's risk tier alone. A private company deploying a high-risk system outside those categories doesn't trigger the FRIA requirement.
Can an existing DPIA be reused for a FRIA?
Partially. Article 27(4) allows reusing elements of an existing DPIA to avoid duplicating work, but the rights-specific elements — fundamental rights implicated, likelihood/severity of rights-based harm — still need to be addressed separately, since a DPIA's data-protection focus doesn't automatically cover them.
Who is responsible for completing the FRIA — the provider or the deployer?
The deployer. While deployers draw on the provider's instructions for use and technical documentation to complete certain sections, the obligation to conduct and submit the FRIA rests with the deployer operating the system, not the entity that built it.
What happens if a deployer skips the notification step in Section 4?
Completing the four assessment sections without notifying the relevant market surveillance authority leaves the Article 27(3) obligation unmet. On the exam, scenario questions frequently test exactly this gap — a fact pattern where the analysis is thorough but the administrative notification step was never mentioned.
Does a FRIA need to be made public?
Certain elements are subject to publication requirements through a database the AI Office maintains, though the specifics of what must be published versus retained internally are worth confirming against the current implementing guidance rather than assumed, since this is an area still being operationalized as the August 2026 deadline approaches.
The FRIA isn't a variant of the DPIA, and it isn't required for every high-risk system — it's a rights-focused assessment gated to specific deployer categories under Article 27. Master the four-section structure, the deployer-gating logic, and the notification requirement, and most FRIA scenario questions on the AIGP exam become a matter of pattern recognition rather than recall.
Related reading: DPIA vs. AIA vs. FRIA: AI governance acronyms explained and EU AI Act risk classifications with real-world examples.