Who needs a FRIA under Article 27 — and who doesn't

The scoping rule

Article 27 requires a fundamental rights impact assessment before the first use of a high-risk AI system listed in Annex III — but only from three kinds of deployers: bodies governed by public law, private entities providing public services (think education, healthcare, social services, housing), and deployers of two specific Annex III point 5 systems — creditworthiness and credit scoring under 5(b) (except financial fraud detection) and life and health insurance risk assessment and pricing under 5(c).

Everyone else deploying high-risk AI — a private B2B company running an internal HR screening tool, for instance — does not owe a FRIA. That team still carries the full Article 26 load: assigned human oversight, monitoring, log retention, worker notification. FRIA is a subset question layered on top of Article 26 for the deployers it captures, not a general high-risk requirement.

What the assessment must contain

Article 27 is prescriptive about content. The assessment sets out:

• The deployer's processes in which the high-risk system will be used, in line with its intended purpose.
• The period of time and frequency in which the system is intended to be used.
• The categories of natural persons and groups likely to be affected by its use.
• The specific risks of harm likely to have an impact on those categories of persons or groups.
• A description of the human oversight measures, per the provider's instructions for use.
• The measures to be taken where those risks materialise — internal governance arrangements and complaint mechanisms included.

Once complete, the deployer notifies the market surveillance authority of the outcome; the AI Office is to provide a template questionnaire to make this submission standard. And the FRIA is not one-and-done: when any of the assessed elements changes — new process, new affected population, new risk — the deployer updates it.

FRIA and your existing DPIA

If the deployment processes personal data, chances are a GDPR Article 35 data protection impact assessment already exists or is underway. Article 27 anticipates this: where a DPIA already covers some of the required elements, the FRIA complements it. In practice that means building the FRIA on top of the DPIA — reusing the process descriptions and affected-person categories, then adding what the DPIA does not ask: the fundamental-rights risk framing, oversight measures from the instructions for use, and the materialisation plan.

• Start from the DPIA's inventory of processing operations and affected groups — do not re-derive them.
• Add the AI-specific elements: intended purpose alignment, frequency and period of use, oversight assignments.
• Keep the two assessments cross-referenced in your record, each with an owner and a review date, so a change to one triggers a look at the other.

Running it as a record, not a ritual

The failure mode with impact assessments is well known from GDPR practice: a document produced once, filed, and never reopened. Article 27's update duty makes that posture untenable — the assessment is tied to elements that change routinely in a living product. The operational answer is the same one that works for the rest of the AI Act: the FRIA is an evidence item in the system's register entry, with a named owner, a review cadence, and a visible staleness flag when the system's use has drifted from what was assessed.

Frequently asked questions

Keep reading

• Article 26 deployer obligations, operationally
• What actually applies on August 2, 2026
• Annex III high-risk categories, with real product examples