GovCompass
Knowledge base
ReferenceAccountabilityHuman oversight

Art. 27 EU AI Act: Fundamental Rights Impact Assessment (FRIA)

By Michel Venniker· · Aligned with the consolidated EU AI Act, including the 2026 Omnibus amendments.

Art. 27 requires certain deployers, public bodies and private deployers in defined sectors such as credit and insurance, to conduct a Fundamental Rights Impact Assessment (FRIA) before deploying a high-risk AI system, examining the impact on fundamental rights and the mitigation measures.

Updated: June 2026

Introduction: fundamental rights at the centre of AI governance

Article 27 of the EU AI Act requires public authorities and certain other deployers to conduct a Fundamental Rights Impact Assessmentimpact assessmentThe design-time discipline of describing a system, mapping stakeholders, identifying harms, rating probability × severity, choosing mitigations and documenting a signed decision — the skeleton under DPIAs, FRIAs and AIAs.Open full entry → (FRIAFRIAFundamental Rights Impact Assessment — required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry →) before deploying high-risk AI systems. The FRIA is not a technical document, it is a governance instrument that requires organisations to explicitly evaluate the impact of AI deployment on the fundamental rights guaranteed by the EU Charter of Fundamental Rights and applicable national law.

The requirement reflects a core principle of the EU AI Act: AI governance is not purely a technical compliance exercise. The highest-stakes AI decisions, those made by public authorities that affect people's access to services, benefits, and justice, demand a structured fundamental rights analysis before deployment.

Who must conduct a FRIA?

Art. 27.1 requires a FRIA from:

  • Public authorities deploying high-risk AI systems
  • Bodies operating in the public interest (e.g. public hospitals, universities, social housing organisations)
  • Private entities providing services in the public interest that are directly regulated or publicly funded

Pure private sector deployers are not directly obliged by Art. 27, though best practice, and increasingly, procurement requirements from public clients, is driving FRIA adoption more broadly.

Which fundamental rights are assessed?

A FRIA must assess potential impacts on all applicable fundamental rights. Key rights in AI contexts include:

  • Dignity (Art. 1 Charter): Does the AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs — predictions, content, recommendations or decisions — that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → treat individuals with respect and without degradation?
  • Non-discrimination (Art. 21 Charter): Does the AI system risk producing discriminatory outcomes based on race, gender, religion, disability, age, sexual orientation, or other protected characteristics?
  • Privacy and data protection (Art. 7–8 Charter): Linking to the GDPR DPIADPIAData Protection Impact Assessment — required before likely-high-risk processing (systematic profiling with significant effects, large-scale special categories, public monitoring); AI development triggers it constantly.Open full entry → obligation
  • Right to a fair hearing (Art. 47 Charter): For AI used in administrative decisions, is there a genuine right to challenge AI-assisted outcomes?
  • Freedom of expression and information (Art. 11 Charter): For AI affecting content moderation or information access
  • Children's rights (Art. 24 Charter): Heightened scrutiny for AI systems affecting minors
  • Rights of the elderly and disabled (Art. 25–26 Charter): Accessibility and equal treatment considerations

The FRIA process: six steps

Step 1: scoping

Define the AI system being assessed, its intended purpose, the categories of individuals it affects, and the decisions it informs or makes. A scoping document should be produced at the outset.

Step 2: stakeholder identification

Identify all groups whose rights could be affected: direct users of the AI system's outputs, individuals whose data is processed, vulnerable groups with heightened risk, and public interests (e.g. democratic accountabilityaccountabilityThe principle that a named human or organization answers for an AI system's outcomes, through ownership, documentation, audit trails and redress — never the system itself.Open full entry →).

Step 3: rights mapping

For each identified stakeholder group, map the specific rights at risk. This is not a checklist exercise, it requires substantive analysis of how the AI system's functioning could interfere with or threaten specific rights.

Step 4: risk assessment

For each identified rights risk: assess the probability of occurrence, the severity of potential harm, and the breadth of impact. Produce a risk matrix that prioritises the most significant risks for mitigation.

Step 5: mitigation measures

For each significant risk: document the specific technical, organisational, or procedural measures that will reduce or eliminate the risk. Mitigation measures must be concrete and verifiable, not vague commitments to "take care" of the issue.

Step 6: residual risk assessment and sign-off

After mitigation, assess residual risks. If residual risks remain significant, the deployerdeployerAn organization using an AI system under its own authority in its activities — carrying operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → must decide whether to proceed with deployment, subject to additional safeguards, or to decline deployment. Sign-off should be at senior management level (typically the AI Officer or DPO).

FRIA documentation

The FRIA must be documented and submitted to the market surveillance authority upon request. Required elements: scoping documentation, rights mapping, risk assessment matrix, mitigation measures, residual riskresidual riskThe risk remaining after mitigations — compared against risk appetite and accepted in writing by someone with authority, or the project doesn't proceed.Open full entry → assessment, and sign-off record.

Compliance checklist

  1. Has your organisation determined whether it is a public authority or body operating in the public interest under Art. 27?
  2. For each high-risk AI system: has a FRIA been conducted before deployment?
  3. Does the FRIA cover all applicable fundamental rights (not just privacy/data protection)?
  4. Are mitigation measures concrete, verifiable, and assigned to responsible persons?
  5. Has the FRIA been reviewed by the DPO and/or legal counsel?
  6. Is the FRIA documented and available for supervisory review?
  7. Is there a process for reviewing the FRIA when the AI system or its context changes?
Legal referencesArt. 27

More on Accountability

Art. 10 EU AI Act: data and data governance for high-risk AI

Reference

Art. 10 requires that the training, validation, and testing data for high-risk AI systems meets quality criteria: relevant, sufficiently representative, and as free of errors and complete as possible for the intended purpose. It also requires documented data governance practices covering collection, preparation, bias examination, and gap mitigation, and it permits the limited processing of special-category data where strictly necessary to detect and correct bias, under safeguards.

Art. 12 EU AI Act: record-keeping and logging for high-risk AI

Reference

Art. 12 requires high-risk AI systems to technically allow for the automatic recording of events (logs) over their lifetime. The logging must enable traceability of the system's functioning at a level appropriate to its intended purpose, support post-market monitoring, and help identify situations that may lead to risk or substantial modification. It is a design obligation on the provider that makes the system auditable by construction.

Art. 19 EU AI Act: keeping the automatically generated logs

Reference

Art. 19 requires providers of high-risk AI systems to keep the logs that the system automatically generates (under Art. 12) for as long as they control them, for a period appropriate to the intended purpose and at least six months unless other law requires longer. It is the retention counterpart to the Art. 12 logging capability, and it works alongside the deployer retention duty in Art. 26.6.

Art. 26.1 EU AI Act: following provider instructions as a deployer

Reference

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.

More on Human oversight

Art. 14 EU AI Act: designing high-risk AI for human oversight

Reference

Art. 14 requires providers to design and build high-risk AI systems so that they can be effectively overseen by humans during use. The system must let an overseer understand its capabilities and limits, watch for anomalies, resist automation bias, correctly interpret outputs, decide not to use the system, and intervene or stop it through a kill switch (Art. 14(4)(e)). It is the design obligation that makes the deployer oversight duty of Art. 26.2 possible.

Art. 26.2 EU AI Act: human oversight of high-risk AI

Reference

Art. 26.2 requires deployers to ensure that the people assigned to oversee a high-risk AI system have the competence, training, and authority to do so effectively. Valid oversight is substantive, not formal: the overseer must understand the system, be trained on its limitations, and hold genuine authority to override its outputs.

Art. 4 EU AI Act: AI literacy obligations for organisations

Reference

Art. 4 has required organisations since 2 February 2025 to ensure a sufficient level of AI literacy among staff who operate or use AI systems, proportionate to the system and the role. It applies to all AI use, not only high-risk systems, and must be demonstrable.

Agentic AI: governing actions, not just decisions

Analysis

Data governance asks whether you can trust the data. AI governance asks whether you can trust the decision. Agentic governance asks a third question that neither was built to answer: can you contain what the system does? Agentic AI is the eighth GovCompass element. It binds the other seven under the conditions that autonomy creates, because an AI system that takes actions on your behalf must satisfy all seven elements continuously, across multi-step and multi-agent chains, without a human checkpoint between each step.