An AI risk assessment scores impact, and the open question is whose. The score can reflect what the organization stands to lose, such as money, regulatory standing or reputation. It can also say nothing about the people the system scores, ranks or decides about.
The EU AI Act takes the second view for a defined group of deployers. Before they first use certain high-risk AI systems, they must carry out a fundamental rights impact assessment. That assessment describes the categories of people likely to be affected, the specific risks of harm to them and what the deployer will do if those risks materialize. The NIST AI Risk Management Framework, which is voluntary, points in the same direction for any AI system.
Note: statements attributed to a named source come from that source. Everything else, including passages marked “Interpretation,” is the author’s interpretation. The article does not describe any real organization or system.
Impact on whom?
The NIST AI Risk Management Framework (AI RMF 1.0) has a category on impacts in its MAP function. MAP 5 reads: “Impacts to individuals, groups, communities, organizations, and society are characterized.” The organization is one entry in that list of five.
Interpretation: a review that scores only organizational impact covers one of the five. The other four are where a system’s errors land first. A wrong credit decision or an unfair insurance price affects a person first. Any cost to the organization comes later, if it comes at all.
Who must carry out a fundamental rights impact assessment
Article 27 of the EU AI Act sets the duty, and it falls on deployers. Article 3(4) defines a deployer as a person or body “using an AI system under its authority,” except for personal non-professional use.
Article 27(1) applies to high-risk AI systems referred to in Article 6(2), which are systems listed in Annex III. Article 6(3) treats some Annex III systems as not high-risk, for example one that only performs a narrow procedural task, unless it profiles natural persons. Article 27(1) also excludes systems intended for use in the area listed in point 2 of Annex III, critical infrastructure. Within that scope, three groups of deployers must carry out the assessment:
- bodies governed by public law;
- private entities providing public services;
- deployers of the systems in points 5(b) and 5(c) of Annex III.
Annex III point 5(b) covers AI systems intended “to evaluate the creditworthiness of natural persons or establish their credit score,” with an exception for systems used to detect financial fraud. Point 5(c) covers AI systems intended “for risk assessment and pricing in relation to natural persons in the case of life and health insurance.”
Recital 96 explains the reasoning. It names “banking or insurance entities” as examples of deployers of the listed systems. It describes private entities providing public services as linked to tasks in the public interest, “such as in the areas of education, healthcare, social services, housing, administration of justice.”
Under Article 113(c)(i), as amended by the Digital Omnibus on AI, Chapter III Sections 1 to 3 apply from December 2, 2027, for systems classified as high-risk under Article 6(2) and Annex III. Article 27 sits in Section 3.
Interpretation: whether a given organization is a body governed by public law or a private entity providing public services, and whether a given system falls under Annex III, are legal questions. The checks in the last section of this article do not depend on the answer.
What the assessment must contain
Article 27(1) lists six elements. The assessment must describe:
- the deployer’s processes in which the system will be used in line with its intended purpose;
- the period of time within which, and the frequency with which, the system is intended to be used;
- the categories of natural persons and groups likely to be affected by its use in the specific context;
- the specific risks of harm likely to have an impact on those persons or groups, taking into account the information the provider gives under Article 13;
- the implementation of human oversight measures, according to the instructions for use;
- the measures to take if those risks materialize, including the arrangements for internal governance and complaint mechanisms.
The first two elements describe the use. The next two describe the people and the harm they could face. The last two describe the controls and the response.
Recital 93 explains why the duty sits with the deployer. It says deployers “are best placed to understand how the high-risk AI system will be used concretely.” It adds that they can identify risks “not foreseen in the development phase,” because they know the context of use and the persons or groups likely to be affected, “including vulnerable groups.”
Interpretation: the same model can carry different risks in two deployments. A credit model used for small consumer loans and the same model used for housing finance affect different people in different ways. The provider’s documentation is an input. Under Article 27(1)(d) it does not replace the deployer’s own view of its context.
Before first use, and after
Article 27(2) says the obligation applies to the first use of the high-risk AI system. In similar cases, the deployer may rely on earlier fundamental rights impact assessments or on existing impact assessments carried out by the provider. If, during use, the deployer considers that any of the listed elements has changed or is no longer up to date, it must take the necessary steps to update the information.
Article 27(3) requires the deployer to notify the market surveillance authority of the results once the assessment is done, submitting the filled-out template as part of the notification. In the case referred to in Article 46(1), deployers may be exempt from notifying. Article 46(1) covers the market surveillance authority’s authorization of specific high-risk systems for exceptional reasons, such as public security or the protection of life and health of persons. That authorization is for a limited period while the conformity assessment procedures are carried out.
Article 27(4) and 27(5) are among the passages the Service Desk marks as amended by the Digital Omnibus on AI. Article 27(4) covers overlap with data protection impact assessments under Article 35 of the GDPR (Regulation (EU) 2016/679) or Article 27 of Directive (EU) 2016/680. Where such an assessment already meets an obligation in Article 27, the deployer may cross-reference the relevant sections or include relevant parts of it. Article 27(5) requires the AI Office to develop a questionnaire template, including through an automated tool, to help deployers comply in a simplified manner.
Recital 96 adds a practical point. Where appropriate, and in particular in the public sector, deployers “could involve relevant stakeholders,” including representatives of groups likely to be affected, independent experts and civil society organizations, both in carrying out the assessment and in designing the response measures.
Interpretation: the assessment is a record that must stay current once the system is in use. A deployer that changes the process, the frequency of use or the population a system covers has reason to look at it again.
What NIST’s MAP 5.1 adds
NIST’s framework is voluntary. AI 100-1 describes it as “voluntary, rights-preserving, non-sector-specific, and use-case agnostic.” It does not depend on Annex III or on the type of deployer.
MAP 5.1 calls for organizations to identify and document the likelihood and magnitude of each identified impact, both potentially beneficial and harmful. The listed bases are expected use, past uses of AI systems in similar contexts, public incident reports, feedback from people outside the team that developed or deployed the system, or other data.
The NIST AI RMF Playbook, the framework’s companion resource, offers suggested actions for MAP 5.1. One is to establish assessment scales for AI system impact and apply them uniformly across the organization’s AI portfolio. Among the questions it suggests organizations document is a direct one: “Which population(s) does the AI system impact?”
Interpretation: Article 27 asks a narrow set of deployers to describe who is affected. MAP 5.1 asks how likely and how serious each impact is, and it points to outside feedback as a source. A deployer can use both. An organization outside Article 27 can still use the NIST approach for any system.
Checks for any AI risk assessment
The following checks are interpretation, offered as a starting point rather than a complete program.
- Name the people. List the categories of people and groups the system makes or supports decisions about, in the specific context of use.
- Describe harm from their side. For each group, write down what a wrong or unfair output would mean for them, not only for the organization.
- Use the provider’s information, then go beyond it. Read the instructions for use and the provider’s stated limits, then add what only the deployer knows about its own context.
- Name the oversight. Record who reviews outputs and how. Check that the review has not turned into rubber-stamp oversight.
- Plan the response before it is needed. Decide what happens if a harm occurs, who is told, and how an affected person can complain.
- Score likelihood and magnitude on one scale. Use the same scale across systems so that impacts on people can be compared.
- Ask people outside the team. Feedback from those affected, or from people who represent them, can surface risks the team does not see.
- Record when to look again. Note what kind of change to the process, the frequency of use or the affected groups would trigger a fresh review, and link the assessment to the system’s entry in the AI inventory.
Conclusion
The EU AI Act requires certain deployers of high-risk AI systems to carry out a fundamental rights impact assessment before first use. These deployers are bodies governed by public law, private entities providing public services, and deployers of AI used for credit scoring or for life and health insurance risk assessment and pricing. The assessment describes the use, the people likely to be affected, the specific risks of harm to them, the human oversight measures and the measures to take if those risks materialize. For Annex III systems, these rules apply from December 2, 2027. NIST’s MAP 5.1 asks any organization to document the likelihood and magnitude of each impact, using sources that include feedback from outside the team.
If an AI risk assessment cannot say who is affected and what harm would look like for them, it describes the risk to the organization and nothing more.
This article reflects the author’s personal views, not those of any employer, and interpretation of publicly available materials from NIST and the European Commission’s EU AI Act Service Desk, as available on October 25, 2026. It is not affiliated with or endorsed by either body and does not reproduce their full requirements. It is general information, not legal, compliance or certification advice, and reading it does not create any advisory relationship. Laws, guidance and application dates change. Refer to the official texts, including the EU AI Act as published in EUR-Lex, and get qualified advice before acting on how they apply to your organization.
Sources: NIST, AI Risk Management Framework (AI RMF 1.0), NIST AI 100-1, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf; NIST AI RMF Playbook, Map, https://airc.nist.gov/airmf-resources/playbook/map/; European Commission AI Act Service Desk, Article 3, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-3; Article 6, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-6; Article 27, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-27; Article 46, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-46; Article 113, https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-113; Annex III, https://ai-act-service-desk.ec.europa.eu/en/ai-act/annex-3; Recital 93, https://ai-act-service-desk.ec.europa.eu/en/ai-act/recital-93; Recital 96, https://ai-act-service-desk.ec.europa.eu/en/ai-act/recital-96.
