How to Write a Fundamental Rights Impact Assessment (FRIA) Under the EU AI Act: A Practical Guide

A Spanish bank has been using an AI-powered credit scoring model for 18 months. The data processing is GDPR-compliant. The technical documentation is current. Every Data Protection Impact Assessment box has been checked. By all conventional compliance standards, the organisation is well-governed.

Then an internal audit surfaces something nobody programmed or approved. Applicants from certain postal codes in Madrid and Barcelona are being declined at a rate far above the statistical baseline. The pattern looks, unmistakably, like indirect discrimination.

The data processing was lawful. The technical documentation was accurate. The DPIA was complete. But none of those instruments were designed to catch this kind of harm — because they were not looking at the right thing. They were looking at data. Not at people.

Under the EU AI Act, that gap has a name. It has a legal deadline. And it carries a fine of up to €15 million or 3% of global annual turnover.

It is called the Fundamental Rights Impact Assessment (FRIA).

The FRIA is one of the least-understood obligations in the EU AI Act. Most affected organisations do not know they are subject to it. Many that do know assume it is just an expanded version of the DPIA they already complete for GDPR. It is not. This guide explains what a FRIA is, who must conduct one, how it differs from a DPIA, and exactly how to write one — section by section — so that when AESIA asks to see it, your organisation has a document that demonstrates genuine, rigorous compliance.

The Compliance with the EU AI Act and Ethics in AI certification from the Spanish Compliance Institute includes a dedicated FRIA workshop — a step-by-step completion framework with ready-to-use templates. Currently  €79.99 €49.99. Join 89+ professionals already certified.

What Is a Fundamental Rights Impact Assessment?

A Fundamental Rights Impact Assessment (FRIA) is a mandatory structured evaluation that certain deployers of high-risk AI systems must complete before putting those systems into operation. It is required under Article 27 of the EU AI Act, with obligations applicable from the high-risk system deadlines under the Act.

The FRIA asks a question that technical risk assessments and DPIAs do not: do the people affected by this AI system's decisions have their fundamental rights adequately protected?

Not their data. Their rights — as human beings, as citizens, as workers, as borrowers, as patients, as members of groups that AI systems have historically treated unequally.

The FRIA draws on the EU Charter of Fundamental Rights, which enshrines 54 rights and principles across seven titles covering dignity, freedoms, equality, solidarity, citizens' rights, justice, and general principles. A FRIA requires the deployer to assess which of these rights the AI system could affect, how seriously, and what the organisation is doing to protect them.

It was not in the original European Commission draft of the AI Act. It was introduced by the European Parliament in June 2023, specifically to ensure that compliance with the EU AI Act would not stop at technical checklists — that it would require organisations to genuinely reckon with the human consequences of their AI deployments.

The deadline and the penalty:

FRIA obligations are tied to the high-risk system deadlines under the EU AI Act. For Annex III standalone high-risk systems, the Digital Omnibus provisional agreement (7 May 2026) has moved the deadline to 2 December 2027. For organisations already using these systems before that date, the FRIA must be completed as soon as possible and no later than the applicable deadline.

Non-compliance with Article 27 constitutes an infringement of Chapter III of the EU AI Act, subject to fines of up to €15 million or 3% of global annual turnover.

Who Must Conduct a FRIA Under Article 27?

Not every deployer of a high-risk AI system is required to conduct a formal FRIA. Article 27 applies to specific categories of deployers. Understanding whether you are in scope is the first step.

Category 1: Bodies Governed by Public Law

Any public authority, government agency, municipality, public university, public hospital, public housing authority, or similar body governed by public law that deploys a high-risk AI system under Annex III is required to conduct a FRIA.

In Spain, this includes national and regional government departments, local councils (ayuntamientos), public universities, public health system providers (hospitales públicos), and the full range of public agencies and administrative bodies at national, regional, and local level.

Category 2: Private Entities Providing Public Services

Private companies providing services in the public interest are also in scope, even though they are not public bodies. The EU AI Act's Recital 96 identifies examples of public service areas: education, healthcare, social services, housing, and administration of justice.

This is broader than it first appears. A private hospital providing publicly-funded healthcare, a private company operating a publicly contracted employment service, a private university offering degree programmes, or a private social care provider may all fall within this category. If your service could reasonably affect the public interest, AESIA's interpretation of the scope is likely to be expansive.

Category 3: Deployers of Credit Scoring and Insurance AI

Private deployers that are not public bodies and do not provide public services are still required to conduct a FRIA if they use high-risk AI systems in two specific areas:

• AI used to evaluate the creditworthiness of natural persons or establish credit scores (Annex III, point 5(b)) — with the exception of AI used for fraud detection
• AI used for risk assessment and pricing in life and health insurance (Annex III, point 5(c))

This category directly captures Spain's most AI-intensive sector. Banks using credit scoring models (CaixaBank, BBVA, Santander, and thousands of other Spanish credit institutions), insurance companies using AI for life and health pricing, and fintech lenders using automated creditworthiness tools all fall squarely within the FRIA requirement.

Who Is Exempt

AI systems used as safety components in critical infrastructure — specifically the management of road traffic, water supply, gas supply, heating, or electricity — are explicitly exempt from Article 27.

The Practical Scope Is Wider Than It Appears

Even if your organisation is not technically required to conduct a formal FRIA, the discipline of a FRIA-style assessment is sound governance practice for any deployer of a high-risk AI system. The underlying question — how does this system affect the people it touches, and what are we doing to protect their rights? — is one every deployer should be able to answer. AESIA's investigations will ask questions that require it.

FRIA vs DPIA: Why Your Existing Assessment Is Not Enough

This is the most important misconception to correct: a FRIA is not a DPIA, and a completed DPIA does not satisfy the FRIA obligation.

Many compliance teams who hear about the FRIA for the first time assume it is a rebranded DPIA — perhaps with a broader scope. The reality is more significant. The two assessments have different objects, different triggers, different scopes, and different purposes. Understanding the differences is essential for building a compliant process.

The overlap: Research estimates that a comprehensive DPIA covers approximately 30–40% of what a FRIA requires, primarily in the areas of data protection, privacy, and some non-discrimination aspects where data processing is involved. This overlap is recognised in Article 27(4), which allows deployers whose DPIA already satisfies equivalent FRIA content to use that DPIA as a complement to — not a replacement for — their FRIA.

What a DPIA cannot catch: A DPIA looks at data processing. It cannot identify whether your AI system produces discriminatory outputs based on postal codes, whether your loan approval algorithm disadvantages ethnic minorities without processing ethnic data directly, whether your performance management AI produces outcomes that violate workers' rights, or whether your social benefit eligibility tool creates barriers that affect the right to access essential services. These are fundamentally human rights questions — not data processing questions.

The practical approach: For most organisations deploying high-risk AI systems that process personal data — which is most of them — the most efficient compliance path is an integrated FRIA-DPIA document: a single structured assessment that addresses both GDPR and EU AI Act requirements simultaneously. This reduces duplication, builds a comprehensive picture of risk, and produces a document that satisfies both AESIA and the AEPD.

For a full guide on how the EU AI Act and GDPR interact in the Spanish regulatory environment, see: EU AI Act vs GDPR in Spain: What Your Business Must Do to Comply With Both.

The Fundamental Rights You Must Assess

The FRIA requires you to assess potential impacts against the rights enshrined in the EU Charter of Fundamental Rights. Not all rights will be relevant to every deployment — a credit scoring model will not implicate freedom of assembly, and an HR screening tool will not trigger the right to maritime safety. Your assessment should identify which rights are genuinely at stake for your specific system and context.

The most commonly relevant rights for high-risk AI systems in Spanish organisations:

Right to Human Dignity (Article 1) The most foundational right in the EU Charter. AI systems that treat individuals as data points rather than persons, or that produce decisions so opaque that individuals cannot understand or contest them, risk violating dignity. Relevant to virtually every high-risk deployment.

Right to Non-Discrimination (Article 21) Prohibits discrimination based on sex, race, colour, ethnic or social origin, genetic features, language, religion, political opinion, disability, age, or sexual orientation. AI systems trained on historical data carry significant risk of perpetuating or amplifying existing discriminatory patterns. This right is central to FRIA analysis for employment, credit, insurance, and education AI.

Right to Privacy and Data Protection (Articles 7–8) The overlap with GDPR. Covered substantially in your DPIA but must still be addressed in the FRIA to ensure the assessment is complete. AI systems that make inferences about individuals from seemingly innocuous data create privacy risks that DPIAs may not fully capture.

Right to an Effective Remedy (Article 47) Individuals affected by AI-driven decisions must have a meaningful path to challenge those decisions. Does your deployment allow affected individuals to understand the basis of the decision? Is there a human review process they can request? Can they effectively contest an outcome? This right is frequently overlooked in technical compliance assessments.

Rights of Workers (Article 31) Particularly relevant for employment AI — CV screening, performance evaluation, workforce monitoring. Workers have the right to fair and just working conditions. AI systems that monitor, evaluate, or determine employment outcomes must be assessed against this right.

Rights of the Child (Article 24) Directly relevant for AI systems used in education, child welfare services, or any context where minors are among the affected population.

Right to Equality Between Men and Women (Article 23) Goes beyond non-discrimination to require positive equality measures. AI systems in employment and financial services must be assessed for gender equity in outcomes, not only the absence of explicit discrimination.

Right to Access to Social Security and Social Assistance (Article 34) Relevant for AI systems used in public benefit eligibility, social housing allocation, or welfare assessment — systems where errors or biases can cut individuals off from essential support.

 The Six-Step FRIA Process

This is the practical process for completing a FRIA that satisfies Article 27's requirements and withstands AESIA scrutiny. The EU AI Office was required to publish an official template questionnaire under Article 27(5), but as of May 2026 that template had not yet been published. Your FRIA must therefore be built from Article 27(1)'s requirements directly. When the official template is published, existing assessments will need to be mapped to it — but organisations that have already completed a rigorous Article 27(1)-based assessment will find that a straightforward exercise.

Step 1: Assemble Your Assessment Team

A FRIA is not a single-function exercise. Effective assessment requires:

• Legal or compliance lead — responsible for Article 27 requirements and AESIA notification
• Technical representative — someone who understands how the AI system works, what data it uses, and how it produces outputs
• Business unit representative — the person who uses the system daily and understands its actual deployment context, not just its intended use
• DPO or privacy officer — to integrate the FRIA with existing DPIA obligations where applicable

For high-risk systems affecting large or vulnerable populations, including representatives of affected groups or their representatives in the assessment process strengthens the quality and defensibility of the FRIA. This is not legally required but is recognised as best practice by both the ECNL-Danish Institute for Human Rights framework and AESIA's guidance.

Document who participated in the assessment and their role. This forms part of the audit trail.

Step 2: Describe the Deployment in Concrete Terms

This is the descriptive section required by Article 27(1). It must be specific enough to support genuine rights analysis. "We use AI for hiring" is not a compliant description. The required level of specificity looks more like:

"We deploy [system name/vendor] to screen and rank applications for [job categories] roles. The system ingests CV data and application form responses, applies a scoring model to rank candidates, and produces a ranked shortlist. Human hiring managers review the top-ranked candidates. The system processes approximately [X] applications per [month/quarter/year]. Candidates below a threshold score are automatically excluded from consideration. The system has been configured with the following parameters [describe]. It was last updated [date]."

This section must cover:

• The specific processes in which the system will be used
• The period of time and frequency of use
• The geographic and organisational scope of deployment
• The decisions the system informs or makes
• The categories of natural persons and groups likely to be affected
• Any vulnerable groups in the affected population (people with disabilities, minority ethnic groups, elderly individuals, young people)

Step 3: Map Affected Groups and Their Potential Rights Risks

For each category of affected person identified in Step 2, work through the relevant fundamental rights listed in Section 4 above. For each right, ask:

• Is this right potentially affected by this AI system in this specific deployment?
• If yes, how — what is the specific mechanism of potential harm?
• Who within the affected population is most at risk?
• Are there groups who may be disproportionately affected?

Not every right will be relevant to every system. Be specific. A credit scoring model in a Spanish bank requires deep analysis of non-discrimination (Article 21), right to effective remedy (Article 47), privacy (Articles 7–8), and human dignity (Article 1). It does not meaningfully engage the right of maritime workers.

Build a rights-impact matrix: A simple grid with fundamental rights on one axis, affected groups on the other, and an assessment of likelihood and severity for each combination. This is the analytical core of your FRIA and the document that demonstrates genuine assessment rather than template completion.

For each right-impact combination, rate:

• Likelihood — how probable is this harm? (Rare / Possible / Likely / Almost Certain)
• Severity — how serious would the harm be? (Negligible / Minor / Moderate / Serious / Critical)

Prioritise your mitigation effort on high-likelihood, high-severity combinations.

Step 4: Assess Risks Using the Provider's Instructions

Article 27(1) specifically requires that your risk assessment take into account the instructions for use provided by the AI system provider. This is a critical requirement that many organisations overlook.

The provider's technical documentation and instructions for use will describe the system's intended use cases, its known limitations, any identified risk factors, and the contexts in which the system should and should not be used. Your FRIA must demonstrate that you have reviewed these materials and have assessed whether your specific deployment context falls within the system's intended use or represents a use case where the provider has flagged increased risk.

Document specifically which provider materials you reviewed, the date of review, and how they informed your risk assessment.

Step 5: Design and Document Mitigation Measures

For every identified risk of harm to fundamental rights, your FRIA must document what your organisation is doing about it. The mitigation section must cover three areas:

Human oversight measures — who reviews the AI system's outputs before they result in consequential decisions, how frequently, with what authority to override the system, and what training they have received. This connects directly to Article 14's requirements. See our complete guide on building EU AI Act-compliant human oversight.

Internal governance arrangements — what escalation paths exist when the system produces a questionable result? Who has decision-making authority? What governance committee or function oversees this deployment? How are concerns raised, investigated, and resolved?

Complaint mechanisms — how can an individual affected by the system's decisions challenge those decisions? What information are they given about the AI's role? What human review is available? How are complaints tracked and resolved? What redress is available when errors are identified?

For each mitigation measure, document: what the measure is, who is responsible for implementing it, by what date it was or will be implemented, and how it will be monitored for effectiveness.

Step 6: Document, Register, and Notify

Once the assessment is complete, you must:

Produce a formal FRIA document structured around Article 27(1)'s requirements, covering all three sections (descriptive, assessment, mitigation). The documentation must be thorough enough to demonstrate to AESIA that a genuine, rigorous assessment was conducted — not that a template was filled in.

Register in the EU database — FRIA results must be registered in the EU database of high-risk AI systems. Commercially sensitive information may be protected, but the general principle is transparency.

Notify AESIA — see Section 7 below for the specific notification requirements.

File for internal governance — the FRIA should be held alongside your other technical documentation and risk management records, updated when required, and available on request from AESIA at any time.

What a FRIA Must Contain: The Article 27(1) Requirements

For reference, here are the specific elements required by Article 27(1) of the EU AI Act, mapped to the steps above:

Beyond this regulatory minimum, best-practice FRIA documentation also includes: the methodology used for the assessment, records of any stakeholder consultations, a risk matrix showing likelihood and severity ratings, assigned ownership for each mitigation measure, implementation timelines, and a monitoring and review schedule.

How to Notify AESIA of Your FRIA Results

Article 27 requires deployers to notify the competent market surveillance authority of their FRIA results when first use of the high-risk AI system begins. In Spain, that authority is AESIA.

The notification requirement serves two purposes: it gives AESIA visibility into high-risk AI deployments across Spanish territory, and it creates an accountability mechanism — once AESIA has been notified, it may comment on the assessment within three months, and deployers must provide written feedback on any serious concerns raised.

The notification process in Spain:

AESIA provides guidance on notification formats and procedures through aesia.digital.gob.es. As AESIA's procedures continue to develop in line with the national AI law currently in the parliamentary process, organisations should check the AESIA website for the current notification format and submission channel.

What to include in the notification:

• Identification of the deploying organisation
• Description of the high-risk AI system being deployed (system name, provider, purpose)
• Reference to the FRIA conducted (date, version)
• A summary of the key risks identified and mitigations implemented
• Confirmation that the full FRIA is available on request

Exception: AESIA can exempt specific deployments from the notification requirement in exceptional circumstances, including for reasons of public security. This exemption is narrow and requires AESIA's explicit confirmation.

For an in-depth guide to AESIA's notification processes and what the agency examines when reviewing submitted documentation, see: AESIA: Spain's AI Regulator Explained.

When Must You Update Your FRIA?

A FRIA is not a one-time exercise. Article 27 requires updates whenever the deployer determines that assessed elements have changed or are no longer current. In practice, this means:

Mandatory review triggers:

• The AI system itself is updated, retrained, or significantly modified
• The deployment context changes — new use cases, different user populations, expanded geographic scope
• New information about the system's risks emerges (from post-market monitoring, internal audits, or public incidents involving similar systems)
• The categories of affected persons change materially
• A complaint or incident reveals a risk that was not identified in the original assessment
• The provider issues updated instructions for use or technical documentation

Best practice: Establish a formal FRIA review cycle — at minimum annually — and a change management process that flags AI system modifications requiring FRIA review. For ML systems with continuous or periodic retraining, where model behaviour in production can drift meaningfully from the version originally assessed, treat the FRIA as a living document that requires active maintenance.

A FRIA completed in 2026 for a credit scoring model that has been significantly retrained in 2027 is not a valid FRIA for the 2027 deployment. The date of the assessment matters, and AESIA will ask about review history when examining documentation.

FRIA for Spanish Organisations: Sector-Specific Examples

Credit Scoring at Spanish Banks

BBVA, CaixaBank, Santander, and thousands of Spanish credit institutions using AI-based creditworthiness assessment are directly in scope for Article 27. The FRIA for a credit scoring system must address:

• Non-discrimination (Article 21): Does the model produce systematically different outcomes for applicants of different ethnic origins, postcodes, or other characteristics that serve as proxies for protected characteristics? How is bias detection and mitigation documented?
• Right to effective remedy (Article 47): Can an applicant who is declined understand why? Is there a meaningful human review process they can request? What information are they given?
• Human dignity (Article 1): Does the system treat applicants as individuals or as statistical profiles? Are the limitations of the model acknowledged in the human review process?

For Spanish financial institutions, the FRIA must also consider the AEPD's established enforcement activity in the financial sector — €890,000 in fines against Spanish banks for AI-related data misuse under GDPR. See our dedicated guide: EU AI Act for the Financial Sector in Spain.

HR and Recruitment AI

Spanish employers using CV screening tools, candidate ranking systems, or performance evaluation software are high-risk deployers under Annex III. For employers who are public bodies or provide public employment services, a FRIA is mandatory. For private employers using these tools, a FRIA is not strictly required under Article 27 but the underlying rights analysis should form part of governance practice.

The FRIA for an HR AI system must address:

• Non-discrimination (Article 21): Does the system systematically disadvantage candidates with certain names, addresses, educational backgrounds, or career gaps that correlate with protected characteristics?
• Rights of workers (Article 31): For performance evaluation AI used on existing employees, does the system respect fair and just working conditions?
• Right to effective remedy (Article 47): Can rejected candidates understand why they were not selected? Is there a human review mechanism?

See our guide to EU AI Act obligations for Spanish employers: EU AI Act and HR in Spain.

Public Administration AI

Spanish municipal councils, regional governments, and national agencies using AI for welfare eligibility, housing allocation, or citizen services are among the most clearly in-scope deployers for Article 27. The affected populations are often the most vulnerable: individuals seeking housing support, welfare benefits, or essential public services. The FRIA for a welfare eligibility AI must give particular attention to:

• Rights of access to social security (Article 34): Does the system create barriers that effectively prevent eligible individuals from accessing support?
• Non-discrimination (Article 21): Are there systematic disparities in outcomes across demographic groups that the system serves?
• Human dignity (Article 1): Does the system treat applicants as individuals whose circumstances deserve genuine assessment, or as data points to be filtered?

The Five Most Common FRIA Mistakes

Mistake 1: Conducting the FRIA After Deployment

Article 27 is explicit: the FRIA must be completed before the system is put into service. A retrospective FRIA — completing the assessment after the system is already running — does not satisfy the legal obligation. The purpose of a pre-deployment assessment is to identify risks before they materialise and affect people. An organisation that conducts its FRIA after deployment has already failed to meet the standard the law sets.

Mistake 2: Treating the FRIA as an Expanded DPIA

A FRIA is not a DPIA with extra fields. A DPIA focuses on data. A FRIA focuses on people and their fundamental rights — including rights that are implicated even when no personal data is processed in a conventional sense. Compliance teams that assign FRIA completion to their data protection function without expanding the scope of the analysis frequently produce assessments that satisfy GDPR requirements but miss the fundamental rights obligations at the heart of Article 27.

Mistake 3: Not Involving Affected Stakeholders

The FRIA should not be completed in isolation by a compliance team that has never spoken to the people the AI system affects. Consulting with representatives of affected groups — trade union representatives for employment AI, patient advocacy groups for healthcare AI, consumer representatives for credit scoring AI — strengthens the quality of the risk analysis and demonstrates to AESIA that the assessment reflects genuine engagement with rights impacts, not a template exercise.

Mistake 4: Ignoring Indirect Risks

A social housing allocation algorithm affects the fundamental rights of people who never interact with the software directly — family members, neighbours, communities. A credit scoring model affects people who will never know their application was filtered. The FRIA must account for indirect impacts on affected groups, not only those who have direct contact with the system.

Mistake 5: Not Updating When the System Changes

Machine learning systems change — through retraining, parameter updates, changes to input data, or changes to deployment context. A FRIA completed for version 1.0 of a credit model does not remain valid when that model has been significantly retrained. Build FRIA review into your AI system change management process, and treat it as a living document.

Start Your FRIA Before the Deadline

The FRIA is the EU AI Act obligation that most organisations are not yet taking seriously enough. It is the assessment that requires you to look past the data and ask whether the people affected by your AI system have their fundamental rights genuinely protected. That is not a technical question. It is a governance question — and it requires people with the knowledge and tools to answer it properly.

The Compliance with the EU AI Act and Ethics in AI certification from the Spanish Compliance Institute covers everything you need:

• A dedicated FRIA module — Article 27 requirements in full, step-by-step completion framework, ready-to-use templates
• Rights analysis methodology — how to work through the EU Charter systematically for your specific deployment context
• Integration with DPIA — how to build an efficient integrated FRIA-DPIA assessment
• AESIA notification guidance — what to submit and how
• 15 hours of on-demand expert training across all 7 EU AI Act compliance modules
• Verified digital certificate recognised across Europe

€79.99 €49.99 — Join 89+ compliance professionals already certified.

Enrol Now and Get Certified →

Continue Reading: Related Guides in This Series

• Ethical AI and EU AI Act Compliance: The Professional's Complete Guide for Spain
• AESIA: Spain's AI Regulator Explained — What It Means for Your Business
• EU AI Act vs GDPR in Spain: What Your Business Must Do to Comply With Both
• EU AI Act and HR in Spain: What Employers Must Do Now
• EU AI Act for the Financial Sector in Spain: What Banks, Fintechs and Insurers Must Prepare
• What to Expect From an EU AI Act Audit: A Step-by-Step Walkthrough for Spanish Organisations