CéntrikaGovernance·Risk·Compliance
◎ ENEspañol
Let's talk
Professional examining the possible effects of an AI system on people and fundamental rights

AI ACT · FUNDAMENTAL RIGHTS

Fundamental Rights Impact Assessment: understanding the AI Act FRIA

Published: 25 September 2026 · 11 min read

Before deploying certain high-risk AI systems, an organisation needs to consider what their use may mean for the people affected.

A fundamental rights impact assessment makes that question concrete: the setting, the people, the risks, human oversight and a plan to respond.

Article 27 does not impose this duty on every business using AI. Its scope and the current timetable both matter. This guide explains how to check them and prepare the assessment.

What is a FRIA?

A fundamental rights impact assessment (FRIA) examines how the actual use of a high-risk AI system may affect people. Article 27 of the EU AI Act requires certain deployers to undertake it before first use. It concerns the organisation's process, affected groups and safeguards in context; a supplier's technical assessment cannot simply stand in for it.

When does Article 27 apply?

Start by classifying the AI system. Article 27 covers high-risk systems under Article 6(2) and Annex III, except those intended for the area in point 2 of that annex. It does not automatically cover product-related systems classified under Article 6(1) and Annex I.

Timing as at September 2026: Regulation (EU) 2026/1744 moved the application date for the relevant Annex III high-risk rules to 2 December 2027. The earlier 2 August 2026 date should not be presented as the applicable deadline. Organisations may prepare earlier without describing the future duty as already applicable.

Who must carry it out?

The duty concerns deployers that are bodies governed by public law, private entities providing public services, and deployers of systems in points 5(b) and 5(c) of Annex III: creditworthiness assessment or credit scoring (subject to the stated financial fraud exception), and risk assessment and pricing for life and health insurance.

Being a private business does not automatically exclude an organisation; nor does using AI automatically include it. Determine the deployer's role and the system's precise purpose. Providers should supply information, but the deployer must assess its own use.

What must the assessment cover?

Article 27(1) asks for:

  • the deployer's processes and the system's intended purpose
  • the expected period and frequency of use
  • categories of people and groups likely to be affected
  • specific risks of harm to them, informed by the provider's Article 13 information
  • implementation of human oversight in accordance with instructions
  • measures if risks materialise, including internal governance and complaint mechanisms.

A risk matrix can support this work, but cannot replace a description of the real-world use.

How to prepare a FRIA

Establish scope

Record the system in the AI inventory, its classification, the deployer and why Article 27 does or does not apply.

Map the decision

Describe where the tool enters the workflow, who receives its output and how it influences decisions.

Examine effects

Identify affected groups, plausible harms and the context that could make errors or unfair outcomes more serious. Use the provider's information and the AI risk assessment.

Set controls

Assign authority to intervene, escalation triggers, complaint routes, evidence owners and review dates.

Team reviewing risks, oversight and safeguards for an AI system

Practical example: access to credit

A lender uses a high-risk system to assess creditworthiness. The use may fall under point 5(b) of Annex III; its precise function and the financial fraud exception must be checked.

The FRIA should explain the role of the score in lending decisions, who may be adversely affected, how unfair outcomes can be detected, who can challenge a recommendation and how complaints will be handled. Meaningful human oversight requires authority to change the outcome, not a ceremonial approval click.

How it relates to a GDPR DPIA

A data protection impact assessment (DPIA) under Article 35 GDPR addresses high-risk processing of personal data where required. A FRIA considers fundamental rights in the deployment of the AI system. The two may overlap, but their legal triggers and scopes differ.

The amended Article 27(4) allows the deployer to cross-reference relevant DPIA sections or include relevant parts when they cover FRIA obligations. Remaining gaps must still be addressed. A DPIA is not automatic proof of a completed FRIA.

Classification and risk management

A broader AI impact assessment may help even where Article 27 does not impose a FRIA. Classification identifies the Annex III use; risk management identifies scenarios and controls; the FRIA documents the particular deployer's assessment where required.

ISO/IEC 42001 can help assign owners, maintain controls and record evidence within a management system; adopting it does not automatically fulfil Article 27. A FRIA also differs from a provider's conformity assessment. A useful working sequence is classification → applicability → impact → controls → evidence.

Owners, oversight and consultation

The process owner describes the use. Legal and Compliance check scope; Data Protection reviews personal data; Risk and technical teams contribute evidence; human reviewers explain what they can actually override.

Consulting affected people or their representatives can improve the assessment where appropriate. It is good practice in many contexts, rather than a universal express requirement of Article 27.

Records and notification to the authority

Keep a dated assessment with scope, sources, risks, controls, decisions and owners. Article 27 also provides for a template developed by the AI Office and notification of the assessment results to the market surveillance authority, using that template. Annex III point 2 is outside the scope of the FRIA duty itself.

Check the available template and national process when the obligation becomes applicable. Link documented evidence to controls that work in practice.

When to review the assessment

The obligation applies to first use. If relevant elements change, update the assessment: purpose, affected groups, data, supplier, operational scope or system behaviour. Connect review to AI change management.

Common mistakes

Assuming every high-risk system needs a FRIA

Check Article 6(2), Annex III, the point 2 exclusion and the deployer's role.

Copying the provider's assessment

The provider may not know the local workflow or the people it affects.

Treating a DPIA as an automatic substitute

Relevant parts may be reused; remaining FRIA requirements still need attention.

Using an outdated deadline

As of September 2026, the relevant Annex III date is December 2027.

Frequently asked questions

Can a private company be required to carry out a FRIA?

Yes, where it provides public services or deploys specified systems under points 5(b) or 5(c) of Annex III.

Is it a certification?

No. It is an assessment of the impact of a particular deployment by an in-scope deployer.

Is naming a risk enough?

No. The assessment must explain whom it may harm, how oversight works and what happens if the risk materialises.

Documenting the decision before use

A useful FRIA makes an operational decision possible: whether the planned deployment is appropriate, under which conditions, and who acts if something goes wrong. It connects people's rights to evidence and accountable action.

Does your AI system need a FRIA?

Begin with the system's classification, your organisation's role and its actual use. Then identify affected people, controls and evidence.

Start the diagnostic →
Céntrika's diagnostic can help organise that starting point.