Fundamental Rights Impact Assessment (FRIA) Under EU AI Act Article 27

A Fundamental Rights Impact Assessment is a documented, process-based evaluation that certain deployers of high-risk AI systems must complete before putting a system into use. Unlike the technical conformity assessment procedures that providers perform under Annex VI or VII of the AI Act, a FRIA is not a testing or certification exercise. It is a structured written analysis of how a specific AI system's deployment could affect the fundamental rights of the people subject to its outputs, drawing on the protections set out in the EU Charter of Fundamental Rights.

The distinction matters operationally: conformity assessment addresses whether a system meets technical safety and essential requirements, while the FRIA addresses whether and how its use in a specific organizational context creates risk of harm to real people. Governance teams that treat these as the same exercise will miss obligations that fall specifically on deployers rather than providers.

Who Must Conduct a FRIA

Article 27 does not apply to every deployer of a high-risk AI system listed in Annex III. The obligation is scoped to three deployer categories:

• Bodies governed by public law
• Private operators providing public services
• Deployers using high-risk AI systems to evaluate creditworthiness, or to assess and price life and health insurance risk

Organizations outside these categories that deploy Annex III high-risk systems are still subject to other deployer obligations, including risk management and human oversight duties under Article 26, but the FRIA requirement specifically does not extend to them under the current text. This scoping distinction is the first determination any governance team should make, since it directly affects whether FRIA becomes a mandatory workstream or a voluntary best practice for a given deployment.

Required Content of the Assessment

Article 27 sets out specific elements the FRIA document must address:

• The deployer's processes for using the high-risk AI system, its intended purpose, and the period and frequency of use
• The categories of natural persons and groups likely to be affected by the specific context of deployment
• The specific risks of harm to those persons or groups, taking into account information the provider has supplied
• The human oversight measures that will govern the system's use
• The measures to be taken if the identified risks materialize, including internal governance arrangements and complaint mechanisms

These are content requirements rather than a prescribed methodology. The Act does not mandate a specific technical process for arriving at these conclusions, which means deployers currently have latitude in how they structure the assessment internally, as long as the required elements are present and documented.

Avoiding Duplication with GDPR and Other Impact Assessments

Article 27 explicitly addresses overlap with existing assessment obligations. Where a deployer has already conducted a data protection impact assessment under Article 35 of the GDPR for the same system, the FRIA is meant to be conducted in conjunction with that assessment, complementing rather than duplicating it. Similarly, if a deployer is already required under other EU or national law to produce an impact assessment with equivalent content, that assessment can be extended to satisfy Article 27 rather than requiring a separate, standalone document.

Notification and the Pending AI Office Template

Once a FRIA is completed, Article 27 requires the deployer to notify the results to the relevant market surveillance authority using a template. That template, along with an automated tool to support completion, is a deliverable assigned to the AI Office. As of the research period covered here, no finalized version of that template had been identified in available guidance.

This creates a period of interim uncertainty: deployers preparing for the 2 August 2026 obligation date need to build documentation processes now, using the statutory content requirements in Article 27(1) as the baseline, while remaining prepared to reconcile that documentation against the official template once it is published. Governance teams should treat current FRIA drafting as a living document rather than a final artifact.

Connecting FRIA to Operational Governance

A completed FRIA is only useful if the measures it describes, particularly human oversight and risk mitigation steps, are actually implemented and evidenced in the running system. Article 27(1)(e) requires the assessment to describe human oversight measures, and those measures need to connect directly to the human oversight obligations deployers already carry under Article 26. In practice, this means the FRIA should not sit as a standalone compliance document disconnected from how the AI system is actually operated.

Governance and compliance evidence works best when the mitigation measures named in the FRIA, such as escalation paths, oversight checkpoints, or restrictions on system use, are enforced and logged at runtime rather than described only on paper. This is where operational governance tooling becomes relevant: runtime policy enforcement and audit logging can provide the ongoing evidence that the oversight measures documented in a FRIA are actually operating as described, which supports both internal audit and the external notification obligations under Article 27.

Trussed AI's runtime governance capabilities, including policy enforcement, monitoring, and audit logging for AI agents, are built to generate exactly this kind of operational evidence trail, though a FRIA document itself remains a governance and legal deliverable that compliance teams must own.