FRIA: impact assessment for AI systems

The AI Act requires deployers of high-risk systems to carry out a fundamental rights impact assessment before deployment. We explain what a FRIA is, when it is mandatory, which sections it should include and how to complete it step by step with a practical example.

The AI Act does not only classify AI systems by risk level. For high-risk systems, it imposes specific obligations on deployers (the companies that deploy and use these systems). One of the most relevant—and least known—is the FRIA: Fundamental Rights Impact Assessment.

A FRIA is a structured document that requires a company to analyse, before putting a high-risk AI system into operation, how it may affect people’s fundamental rights. It is not a bureaucratic formality. It is a systematic assessment that identifies risks, defines safeguards and documents the deployment decision.

If you use AI to select employees, assess credit risk, manage social benefits, detect insurance fraud or for any other use case included in Annex III of the AI Act, you need a FRIA. And failing to carry one out—or doing it badly—can result in a significant penalty.

In this article we explain exactly what a FRIA is, when it is mandatory, what structure it has and how to complete each section with a practical example based on a candidate pre-screening system.

What is a FRIA and why does the AI Act require it?

A FRIA is the mechanism established by the AI Act for deployers of high-risk systems to assess the impact of their use on the fundamental rights of affected people. It is regulated by Article 27 of the Regulation.

The logic is simple: if an AI system makes or supports decisions that affect fundamental rights (employment, credit, education, justice or access to essential services), the company using it must assess those impacts before putting it into production, not afterwards.

A FRIA is mandatory for deployers of high-risk systems classified under Annex III of the AI Act. This includes:

Employment and worker management: recruitment, promotion, performance assessment and AI-based task allocation.
Access to essential services: creditworthiness assessment, calculation of insurance premiums and access to social benefits.
Migration and border control: risk assessment of asylum applicants and document verification.
Administration of justice: recidivism risk assessment and evidence analysis.
Critical infrastructure: management of electricity grids, water supply and traffic.

Important: The FRIA is the deployer’s obligation, not the provider’s. If you buy a high-risk AI system from a third party, the FRIA is your responsibility as the company deploying it. The provider must give you the technical information, but you carry out the impact assessment.

FRIA vs DPIA: two complementary assessments

If you already know the DPIA (Data Protection Impact Assessment) under the GDPR, the FRIA will feel familiar. But they are not the same. A DPIA assesses the impact on the protection of personal data. A FRIA assesses the impact on the full range of fundamental rights: equality, non-discrimination, due process, professional freedom, access to essential services, privacy and data protection.

In practice, for an AI system that processes personal data and is classified as high risk, you will need both assessments. The good news is that they share a structure and can be integrated: the FRIA can refer to the DPIA for everything relating to data protection, avoiding duplication.

DPIA (GDPR): Mandatory when personal data is processed with a high risk to the rights of data subjects. Focus: privacy, data minimisation and legal basis.
FRIA (AI Act): Mandatory for deployers of high-risk systems (Annex III). Focus: fundamental rights in the broad sense (equality, non-discrimination, due process and access to services).

A FRIA does not replace a DPIA. They are complementary. For many AI systems you will need both.

The 9 sections of a complete FRIA

Based on industry best practices and the requirements of the AI Act, a complete FRIA should include the following sections:

Cover page and metadata. Identification of the system, version, date, owners (product owner, deployer, provider and DPO), organisational scope and applicable regulations (GDPR, DSA, DMA and NIS2).
Description of the use case and affected populations. Intended use of the system, deployment channel, decisions it supports and excluded assumptions. Affected populations and people, with particular attention to vulnerable groups. Expected effects: benefits and potential harms.
Decision and consequence map. Complete flow: input → processing → output → effect on the person. AI Act classification of the system (prohibited, high-risk Annex III, embedded high-risk Annex I, limited or minimal). Identification of automated decisions with legal effects.
Potentially affected rights. Analysis of each relevant fundamental right: non-discrimination, due process, freedom of expression, privacy, access to essential services and professional freedom.
Risk analysis (probability × severity). Enumeration of specific risks by right, with source, scenario, detection signals and exposed groups. Scale: probability 1–5, severity 1–5, risk = P×S. A risk ≥15 is considered high.
Measures and safeguards. Usage limits, abstention conditions, human oversight (who, when and with what authority), transparency and explainability, non-discrimination testing, and error and incident management.
Residual risk and decision. Summary table: initial risk → measures → residual risk. If the risk remains high, alternatives or prior consultation with the authority. Decision: Approved / Approved with conditions / Not approved.
Publication and participation. Public summary (without sensitive information), appeal channel for affected people, challenge deadlines and participation by third parties.
Document integration and approvals. Links to the technical documentation, the DPIA and the checklists for control gates. Signatures from the product owner, data owner, legal/DPO, security/CISO and management. Approval date, next review and review history.

Practical example: FRIA for a candidate pre-screening system

Let’s see how the FRIA applies to a real case: a company that uses an AI platform to pre-screen candidates in recruitment processes. The system receives CVs, extracts attributes, generates a score and issues a recommendation to advance or reject.

Classification and populations

The system is classified as high risk under Annex III of the AI Act (access to employment). Affected populations include young people, people over 55 and underrepresented groups. The impact of an error is significant: systematic bias can exclude entire groups from employment opportunities.

Risk analysis

Gender/age bias in variables derived from the CV. Probability: 3. Severity: 5. Risk: 15 (HIGH). The model may indirectly penalise women with career breaks or people over 55 for not having certain recent certifications.
Opacity in the reason for rejection. Probability: 3. Severity: 4. Risk: 12 (MEDIUM). If the candidate cannot understand why they were rejected, they cannot exercise their right to an effective appeal.
Excessive data at early stages. Probability: 2. Severity: 3. Risk: 6 (LOW). Collecting more data than necessary during the screening stage breaches the GDPR’s data-minimisation principle.

Measures and safeguards

Against bias: non-discrimination testing for protected groups (four-fifths disparate-impact rule), model reweighting and blind sampling of CVs for validation.
Against opacity: a simplified explanation of the criteria for candidates, an appeal channel with a defined deadline and human review with the authority to reverse the model’s decision.
Against excessive data: data minimisation by phase, progressive collection as the process advances, limited retention and log anonymisation.

Decision

The high risks are reduced to medium level with the proposed measures. Decision: Approved with conditions. Deployment is conditional on the results of bias testing and training for human reviewers.

Traffic light: If you apply the AI governance framework’s traffic-light system—Green (GO), Amber (FIX), Red (KILL)—this system starts at Amber. It moves to Green only once bias tests have been passed and the effectiveness of the safeguards has been verified.

The 5 most common mistakes when carrying out a FRIA

Doing it after deployment. A FRIA is a pre-deployment assessment. If you do it afterwards, it does not fulfil its preventive function and the AI Act considers this non-compliance.
Copying the DPIA and calling it a FRIA. A DPIA only covers data protection. A FRIA must analyse all affected fundamental rights. They are complementary, not interchangeable.
Failing to identify vulnerable groups. A generic analysis that does not identify who is most exposed to the risk is insufficient. The FRIA requires specificity: which groups? Why?
Omitting the appeal channel. Affected people have the right to challenge automated decisions. If your FRIA does not define an appeal channel with clear deadlines, it is incomplete.
Failing to link it to the technical documentation. A FRIA does not exist in isolation. It must be integrated with the system’s technical documentation and the DPIA. Without this documentary integration, you lose traceability.

The FRIA within the AI governance system

A FRIA is not an isolated document. It is integrated into your organisation’s AI governance framework. In the governance model based on the 5 Pillars of AI Transformation, the FRIA forms part of the Compliance Pillar and connects with:

The gate system (control gates): The FRIA is completed at Gate 2 (pre-deployment). If the FRIA identifies high residual risks that cannot be mitigated, the gate closes: the system is not deployed.
The AI Steering Committee: The company’s AI committee reviews and approves FRIAs before authorising deployment. The FRIA is one of the key inputs in the GO/FIX/KILL decision.
The technical documentation: The FRIA is attached to the AI system’s technical documentation, together with the technical documentation, performance tests and DPIA.
Human oversight (HITL): The human-oversight measures defined in the FRIA must be implemented operationally and monitored in production.
The Lite AI Policy: The principles of proportionality, accountability and reversibility in your company’s AI policy are put into practice in the FRIA.

The ultimate goal is for the FRIA not to be a static document that is filed away and forgotten. It should be reviewed periodically (at least whenever there are substantial changes to the system) and its safeguards should be monitored in production.

Quick checklist: do you need a FRIA?

Before going deeper into deadlines and penalties, answer these five questions to determine whether your AI system requires a FRIA:

Does your AI system make or support decisions that affect people? If it only automates internal processes without an impact on individuals (such as optimising logistics routes), you probably do not need a FRIA.
Is your use case in Annex III of the AI Act? Review the list: employment, credit, insurance, education, migration, justice, critical infrastructure and essential services.
Are you the deployer (not only the provider)? If you use a third-party AI system under your authority and for your purpose, you are the deployer and the FRIA is your responsibility.
Are there vulnerable groups among the affected people? Children, older people, people with disabilities, job applicants and recipients of social benefits.
Does the decision have legal or similar effects? Granting or denying credit, access to employment, access to benefits or risk assessment with consequences.

If you answered yes to questions 1, 2 and 3, you need a FRIA. If you also answered yes to 4 or 5, your FRIA requires a greater level of depth and detail.

Deadlines and penalties

The AI Act establishes a phased application. The obligations for high-risk systems, including the FRIA, apply in full from August 2026. Penalties for failing to comply with deployer obligations can reach €15 million or 3% of global turnover.

But do not wait until August 2026. A FRIA requires an internal process (identifying systems, classifying them, assessing impacts, defining safeguards and obtaining approvals). If you start now, you will be prepared. If you wait until the last moment, you risk deploying systems without the required assessment or bringing projects to a standstill because of missing documentation.

Practical advice: Start by inventorying all the AI systems you use or plan to use. Classify each one under Annex III of the AI Act. For high-risk systems, start the FRIA using the 9-section template. You do not need to complete everything at once: begin with sections 1–3 (description and classification) and progress gradually.

Conclusion: a FRIA is prevention, not bureaucracy

A FRIA may look like another item on the list of regulatory obligations. But its real value is operational: it forces you to think about risks before they materialise, define safeguards before problems appear and document your decisions before someone questions them.

A well-designed FRIA is not a 50-page document that nobody reads. It is a structured, pragmatic analysis that protects your company and the people affected by your AI systems.

If you need help carrying out a FRIA for your AI systems, classifying your use cases under the AI Act or integrating the impact assessment into your governance framework, Impulsa3 has the experience and templates to support you through the process.

impulsa3.com · Digital Transformation and AI for SMEs and ecommerce · servicios@impulsa3.com