Fundamental Rights Impact Assessment for AI: How to Decide Whether It Applies and What to Document

Scope and caution: an assessment to inform decisions before use

The fundamental rights impact assessment under Article 27 of the Artificial Intelligence Regulation, known as the AI Act, is a prior analysis that certain deployers must carry out before using specified high-risk AI systems. In practical terms, its purpose is to examine how the intended use could affect people or groups in a particular context, and to establish what measures, responsibilities and response mechanisms are needed before that use is authorised.

It is not a system certification, a guarantee that no harm will occur, or a general assessment of every activity carried out by an organisation. Nor does it automatically replace a data protection impact assessment (DPIA). This guide has a narrower purpose: to help determine whether the obligation applies to a case and to organise the work needed to make the deployment decision traceable.

The applicable legislation may change. The official sources provided include a 2026 amendment affecting, among other things, the handling of DPIA elements and the questionnaire to be prepared by the AI Office. Before applying this guide, therefore, check the current consolidated text, official forms and applicable timeline. This guide structures the analysis; it is not legal advice.

Applicability decision tree: who must assess, and what use to check

The Article 27 obligation does not apply indiscriminately to every organisation that uses AI. In general, you need to check whether the system falls within the relevant high-risk category and whether the deployer belongs to one of the categories specified by the law. Article 27 covers, among others, bodies governed by public law, private entities providing public services, and deployers of certain high-risk systems in the areas of credit and life or health insurance.

The assessment is linked to the actual intended use, not merely to a product’s commercial name or the provider’s general classification. Identify the purpose, the functions enabled, the organisational process in which the system is used, and the people affected. If a tool has several uses, assess each use case separately: both the obligation and the risks may differ from one use to another.

Article 27 excludes from this specific obligation the high-risk systems referred to in point 2 of Annex III. Do not extend that exclusion to any system that appears to involve limited risk; nor does the exclusion, by itself, resolve other obligations under the AI Act, data protection law or sector-specific rules. If the classification depends on an exception, a change in use or an interpretation of the purpose, document the basis for that conclusion and obtain legal review.

The decision can be summarised with four questions: Is the organisation an included deployer? Do the system and use case fall within the relevant scope? Does an exception apply? Is any existing assessment still valid for this use? If information is missing, the responsible conclusion is not to assume that the obligation does not apply. Instead, identify the outstanding information, who is responsible for obtaining it and what condition prevents approval from being finalised.

Timing, responsibilities and communication with the authority

The assessment must be completed before the relevant deployment, not after harm has occurred or routine operations have begun. In practice, the decision gate should come before users are given access, the system is integrated into a decision-making process, or its outputs are allowed to influence decisions about people.

Organisational responsibility should be explicitly assigned. The team proposing the use case provides a description of the process and the decisions the system will support. Compliance, privacy, fundamental rights, security and operations functions review the areas within their remit. An adequately empowered decision-making body determines whether the use can be approved, must be changed or should be stopped. Collaboration should not obscure who is accountable for completing and maintaining the assessment.

The law provides for communicating the assessment to the competent market surveillance authority once it has been carried out. Determining which authority is competent, and what channel and format apply, requires checking the jurisdiction, the national institutional arrangements and current official instructions. Do not invent a recipient or procedure based on an internal template.

You should also define when the assessment will be updated. A change to the purpose, affected population, input data, frequency of use, degree of automation, human oversight measures or operating conditions may alter the analysis. Record which changes require the decision to be reopened, who detects them and who can suspend use while the assessment is reviewed.

What to document: from purpose to affected people

Article 27 establishes a core set of information that connects the system with its context of use. The assessment must describe the processes in which the system will be used in line with its intended purpose; the period and frequency of use; the categories of people and groups likely to be affected; the specific risks of harm in that context, taking account of relevant information from the provider; how human oversight measures will be applied; and the measures to be taken if risks materialise, including internal governance arrangements and complaint mechanisms.

To make these sections useful for decision-making, avoid vague statements such as “there may be bias” or “human oversight will be maintained”. Explain who could be harmed, through which step in the process, what consequence is plausible and what evidence could detect it. If an impact depends on facts that are not known—for example, the size of an affected group or the quality of particular data—record the uncertainty instead of turning it into an assertion.

Information provided by the system provider may help explain the system’s capabilities, limitations and known risks, but it does not replace the deployer’s analysis. The same system can have different consequences depending on eligibility criteria, how staff interpret its outputs, whether data can be corrected and whether people have a way to challenge a decision. The assessment must reflect these specific conditions.

Consulting affected people, their representatives or specialists can provide information that does not appear in technical documentation. Distinguish legal requirements from good editorial or organisational practice: where the law does not prescribe a particular consultation method, record consultation as a measure chosen to improve the analysis, not as a textual requirement attributed to the Article.

From risks to decisions: measures, evidence and limits

A list of risks is not enough. Each relevant risk should be linked to a verifiable measure, an owner, a deadline and evidence that can show whether the measure works. If a measure depends on another team, a feature that has not yet been implemented or validation that is still pending, do not describe it as operational. Treat it as a condition that must be met before deployment.

Measures may include limiting the purpose or the people eligible, reducing the frequency of use, improving data quality, setting review thresholds, testing outputs for relevant differences, requiring human review before an adverse decision, enabling corrections and complaints, or stopping the system when signs of harm emerge. These are options that must be justified in context; they are not an exhaustive list and do not, by themselves, guarantee compliance.

Human oversight must be specific and workable. State who reviews, what information they receive, what training they need, how much discretion they have to depart from the output and how they record their decision. A person who merely confirms outputs automatically, without the time, information or authority to intervene, does not become an effective safeguard simply because a procedure says so.

Approval can be conditional. For example, a restricted pilot could be permitted only after tests have been completed, the complaint channel has been validated and review resources have been assigned. The decision should include criteria for suspending or changing the use, such as errors exceeding a previously defined threshold, complaints indicating a pattern, unapproved changes to the system, or an inability to carry out the promised oversight. Specific thresholds must be derived from the assessment; they should not be invented as universal values.

Relationship with the DPIA: coordinate without conflating

A DPIA, or data protection impact assessment, is carried out under data protection law when the proposed processing is likely to result in a high risk to people’s rights and freedoms. Its focus is the processing of personal data and data protection obligations. The Article 27 assessment focuses on the impacts on fundamental rights of using an AI system within the scope of the AI Act. The two can overlap, but their objectives and scope are not identical.

Article 27 addresses the relationship with data protection assessments. In addition, the official sources provided indicate that a 2026 amendment affects the reuse of DPIA elements and the questionnaire to be prepared by the AI Office. Therefore, do not automatically apply earlier wording about whether the assessment must supplement, reuse or cross-reference a DPIA. Check the current consolidated text and official instructions to establish the conditions that apply now.

As a working method, keep a correspondence map. Identify which DPIA analyses also inform the assessment of relevant people, data or risks; which elements require additional analysis; and which issues are not covered by an assessment conducted for the other purpose. Cross-references reduce duplication, but must allow a reviewer to find the evidence and understand why it is relevant to the corresponding point.

If a DPIA is not required in a particular case, that does not establish that the Article 27 assessment is also unnecessary. And if a DPIA exists, its mere existence does not show that risks beyond the processing of personal data have been covered. The organisation should document the conclusion for the case, the applicable legislation on which it relies and any gaps that remain to be addressed.

Worked example: assessing credit applications

Suppose an organisation uses a high-risk system to support the assessment of credit applications. This is a hypothetical example: it does not claim that a particular system exists, that a specific organisation is obliged to conduct an assessment, or that harm has occurred. Before applying it, the organisation would have to confirm the classification, its role, the intended use and the legal conditions of the case.

Start by mapping the process: what information the system receives, what output it produces, who reviews that output, and whether it recommends, ranks or determines a decision. Also describe the frequency and period of use. An analysis that says only “the model assesses credit” does not clarify whether staff can depart from its recommendation, whether the output causes an automatic refusal, or whether there is a second review.

Next, identify the people affected—for example, applicants and people whose data indirectly influence the assessment—and formulate hypotheses of harm for the organisation to validate. It could examine the possibility of adverse decisions associated with incomplete data, disproportionate effects on particular groups, errors that are difficult to correct, or barriers to understanding and challenging a decision. These are not conclusions about a real model; they require data, testing and context.

Measures should address the hypotheses. The organisation might verify the source and quality of the data, test outputs and relevant differences, prevent a score from being the sole basis for adverse decisions where the analysis indicates that review is needed, train staff, record reasons for departing from a recommendation, and provide an accessible way to correct information or complain. It must specify who carries out each control and what result would mean that the control is insufficient.

Before approval, the responsible decision-making body should check that the measures exist and that oversight has effective authority. If test results are missing, no complaint channel is operational, or the information supporting a decision cannot be explained, a cautious response may be to defer, restrict or refuse deployment until the issue is resolved. The organisation must reach that conclusion based on its own evidence; this example is not a substitute for its analysis.

Checklist before approving use

A checklist is useful if it leads to a decision rather than becoming a box-ticking exercise. Each answer should have a source, an owner and, where appropriate, a follow-up action. Keep legal requirements identified in the current text separate from the internal practices the organisation adds to make the analysis more robust.

Before closing the assessment, check that the document precisely identifies the system, its version, purpose, affected processes, period and frequency of use. Confirm that affected people and groups are described in sufficiently specific terms, each risk is linked to possible harm in that context, and relevant limitations and information from the provider have been considered.

Also confirm that human oversight exists in practice, measures have owners and evidence, and residual risks are known. Review the arrangements for detecting problems, receiving complaints and responding to incidents. If affected people or specialists were consulted, record what the consultation contributed and which decisions it influenced. If no consultation took place, state whether that limits the analysis.

Finally, check communication with the competent authority, any cross-references to the DPIA where relevant, the review date and the conditions that require the assessment to be reopened. Approval should state which version of the documentation was reviewed, which conditions apply to use and who has the authority to stop it.

What to verify before using this guide

The assessment should be based on the consolidated version of the AI Act in force at the relevant time, not solely on summaries, drafts or earlier texts. The sources provided identify a 2026 legislative amendment and a consolidation dated July 2026; they also indicate that the European Commission updated its FAQs in August 2026. Since rules and dates may change, confirm that these versions apply to the time and use case being assessed.

Check the official text for the precise scope of the deployers covered, the system categories included, the exception, the required sections, communication to the authority and the effect of amendments on the DPIA. Also check whether definitive official forms have been published and how notification must be made in the relevant Member State. An FAQ can help with orientation, but it does not prevail over the legislative act.

Check the implementation timeline separately: the relevant date depends on the provisions in force and the specific system category. Do not infer a general date from a news item or an earlier version of the Regulation. If there is uncertainty about scope, the competent authority or interaction with other laws, seek legal advice before authorising use.

For a broader analysis, connect this assessment with the organisation’s internal security and risk management processes, its system comparison process and its evaluation of alternatives before selecting a solution. Those reviews can complement the decision, but they do not replace the legal assessment when it is required.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.