FAI Risk Assessment Under the EU AI Act: Classification, FRIA, Scoring

Article 9 of the EU AI Act mandates that providers of high-risk AI systems establish, implement, document, and maintain a risk management system as a continuous, iterative process throughout the entire system lifecycle. The system must comprise four interlocking activities: identification and analysis of known and reasonably foreseeable risks, estimation and evaluation of risks arising from both intended use and reasonably foreseeable misuse, adoption of appropriate and targeted risk management measures, and evaluation of whether residual risk is acceptable after those measures are applied.

The obligation extends beyond a single point-in-time assessment. Article 9(2) specifies that the risk management system must be updated throughout the entire lifecycle, which includes design, development, testing, deployment, and post-market monitoring phases. This means the risk assessment produced before initial deployment is only the first iteration. Each subsequent review must incorporate new evidence from operational data, deployer feedback, incident reports, and external developments such as new harmonised standards or enforcement guidance from the AI Office.

Risk assessment feeds directly into AISDP Module 6, the risk management system documentation that forms a central pillar of the conformity assessment case. A weak risk assessment produces a weak AISDP, which in turn produces a weak conformity assessment. The assessment must be substantive and evidence-based. A checkbox exercise, one that merely lists generic risks without system-specific analysis, will not survive regulatory scrutiny from a notified body or competent authority.

The risk management system must also interface with several other EU AI Act obligations. Article 9(5) requires that risks to persons under 18 and other vulnerable groups receive specific attention. Article 9(6) mandates that testing procedures are suitable for the system's intended purpose. Article 9(7) requires that the testing regime covers operation within real-world conditions. These sub-obligations mean the risk management system is not an isolated document but a connecting tissue that links data governance (Article 10), human oversight (Article 14), accuracy and robustness (Article 15), and post-market monitoring (Article 72). For the full regulatory context, timeline, and compliance architecture, see EU AI Act Overview.

The practical consequence is that organisations must allocate ongoing resources to risk management. A one-time consulting engagement that produces a risk register at deployment is insufficient. The register must be maintained by personnel with the authority, expertise, and access to operational data needed to keep it current. The AI Governance Lead owns the register's integrity, the Technical SME provides engineering-level risk analysis, and the Legal and Regulatory Advisor ensures the methodology satisfies the regulatory standard. Without this tripartite ownership, the risk management system will decay into a compliance artefact that no longer reflects the system's actual risk profile.

The EU AI Act establishes a four-tier risk classification framework that determines the obligations attaching to each AI system. Where a system falls within this framework is the precondition for every subsequent risk assessment activity, and a classification error cascades into every downstream compliance decision.

Article 27 requires deployers of high-risk AI systems to conduct a fria before putting the system into service. The FRIA examines the system from the perspective of affected persons, providing a rights-based lens that complements the provider's engineering-focused risk assessment under Article 9.

The FRIA addresses questions distinct from the provider's technical risk analysis. It examines the deployer's specific operational processes in which the system will operate, the categories of natural persons and groups likely to be affected, the specific risks of harm to those categories, the human oversight measures in the deployment context, and the measures to be taken if risks materialise. For organisations that serve as both provider and deployer, the FRIA obligation creates a dual assessment requirement, with the engineering risk assessment and the rights impact assessment conducted in parallel and cross-referenced at completion.

The scope must cover all fundamental rights recognised under the EU Charter that could plausibly be affected. For a recruitment screening system, this includes non-discrimination (Charter Article 21), freedom to choose an occupation (Charter Article 15), protection of personal data (Charter Article 8), the right to an effective remedy (Charter Article 47), and the right to good administration (Charter Article 41). For a credit scoring system, the right to property (Charter Article 17) and the prohibition of discrimination in access to services become relevant. The assessment must be tailored to the specific system and deployment context. Template exercises that list generic rights without system-specific analysis will not satisfy the obligation.

The FRA's 2023 methodology template provides the most directly applicable framework for conducting an Article 27 assessment. It structures the FRIA around six steps: describe the AI system and its context of use, identify the fundamental rights at stake, assess the risks to those rights, evaluate existing safeguards, assess proportionality and necessity, and identify additional mitigation measures. Each step produces documentation that feeds into AISDP Module 11.

The description step requires more than a technical summary. The assessor must capture the operational context: who interacts with the system, what decisions it influences, what alternatives exist if the system is unavailable, and what power asymmetry exists between the system operator and the affected persons. A recruitment system screening thousands of applications per week creates a fundamentally different rights impact from one screening fifty, even if the underlying model is identical.

For intersectional analysis, Fairlearn's MetricFrame supports multi-dimensional evaluation directly. Define the sensitive features (for example, gender and age group), and MetricFrame computes metrics for every combination of those features. Aequitas provides similar capability with automated report generation that visualises disparities across intersectional groups. The AI System Assessor defines the intersectional groups before running the analysis, based on the deployment population's demographic composition. Minimum cell size thresholds must be set. Subgroups below the threshold are flagged as inconclusive, not omitted, because omission conceals the very risks the FRIA is designed to surface.

Stakeholder consultation must produce traceable outcomes. Each consultation session should be documented with attendees, the questions posed, the responses received, and the specific risk register entries or mitigation measures that resulted. Where a stakeholder raises a concern that the organisation decides not to act upon, the rationale for inaction must be recorded and reviewed by the AI Governance Lead. Civil society organisations, disability advocacy groups, and trade unions are particularly valuable consultees because they represent perspectives that internal teams rarely possess.

Risk identification for AI systems requires a multi-method approach because no single technique captures every class of risk. Five complementary methods together provide the coverage that Article 9 demands.

Reputational risk sits outside the EU AI Act's explicit scope, yet it materialises faster and more destructively than regulatory enforcement. A single well-publicised AI incident can trigger consequences that dwarf any administrative fine, making reputational risk assessment an essential complement to the Article 9 obligations.

Customer reputational risk arises when deployers discover that an AI system produced unfair, biased, or opaque outcomes. Customer attrition in AI-dependent services tends to be abrupt. A recruitment platform whose deployer organisations discover demographic bias will face mass contract termination, not gradual churn. The risk register should model customer concentration risk and the contractual remedies available to deployers.

Market reputational risk reflects the disproportionate media attention that AI fairness and safety incidents attract. The combination of complex technology, potential discrimination, and power asymmetry between AI systems and affected individuals creates narratives that resonate with journalists, advocates, and policymakers. Organisations operating in regulated sectors such as financial services, healthcare, and public administration face amplified market reputational risk because their regulators and industry bodies are already monitoring AI Act compliance closely.

Regulatory reputational risk is heightened during the Act's early enforcement phase. National competent authorities are building supervisory capabilities, and early enforcement actions will set precedents. An organisation among the first to receive an enforcement notice or fine under the AI Act will face disproportionate harm because the novelty magnifies media interest. Even a modest fine can carry reputational costs that far exceed the direct financial penalty.

Risks are scored using a 5x5 likelihood-impact matrix that assesses impact against four dimensions: health and safety, fundamental rights, operational integrity, and reputational exposure. The composite score is the product of likelihood and the highest impact rating across all four dimensions. This worst-case dimension approach prevents dilution of severe single-dimension impacts through averaging.

The likelihood scale runs from Rare (failure mode not observed in comparable systems, requiring a highly improbable confluence of conditions) through Almost Certain (failure mode observed repeatedly in operation, expected to recur without additional mitigation). Each level has defined criteria anchored to observable evidence, not subjective impressions.

Each impact dimension requires a calibrated rubric to ensure consistency across assessors and across the organisation's AI system portfolio. The health and safety dimension ranges from Negligible (no measurable consequence) to Catastrophic (irreversible harm to life, health, or safety, or serious harm affecting a large and vulnerable population). The fundamental rights dimension ranges from no discernible effect on any Charter right to large-scale or irreversible infringement affecting rights of particular sensitivity such as human dignity and non-discrimination. The operational integrity dimension covers system availability and accuracy, from no effect through total system failure or compromise. The reputational exposure dimension ranges from internal awareness only to sustained public attention, political scrutiny, and regulatory enforcement proceedings.

Scoring must be accompanied by explicit rationale. Stating "medium likelihood" is insufficient. The assessor must explain the reasoning, citing evidence such as the frequency of a particular failure mode observed during testing, the exposure of the affected population, or comparable incidents in similar systems. Risks scoring above the organisational threshold (typically 12 on a 25-point scale) require specific, documented mitigation. Those below the threshold are accepted, with the acceptance recorded and signed by the AI Governance Lead.

Systems incorporating gpai models present a distinctive compliance challenge: the downstream provider bears full Article 25 responsibility for the high-risk system, yet has limited visibility into the GPAI model's training data, architecture, and behavioural characteristics. This information asymmetry is the central risk assessment problem for any system built on a third-party foundation model.

The risk assessment must identify three categories of inherited risk. Training data risks include bias embedded in the pre-training corpus, personal data processed without consent, and copyrighted material in the training data. Behavioural risks encompass hallucination, output instability, sensitivity to prompt phrasing, and emergent capabilities that were not anticipated by the model provider. Supply chain risks arise when the GPAI provider discontinues the model, changes its behaviour through updates, or restricts access under changed commercial terms.

Where the GPAI provider's disclosures are insufficient for a complete risk assessment, the organisation must implement compensating controls. These include systematic behavioural testing against a sentinel dataset that exercises the risk dimensions the training data disclosures do not address. They also include output filtering and validation layers that constrain the model's outputs to the acceptable range for the system's intended purpose, and continuous monitoring of the model's behaviour for drift with automated alerting when output distributions shift beyond defined tolerances.

Article 9(4) requires that risks be eliminated or reduced "as far as possible through adequate design and development." This standard does not require zero residual risk. It requires evidence that the organisation has pursued risk reduction to the point where further reduction would be disproportionate, technically infeasible, or counterproductive.

Operationalising this standard requires a structured process for each risk above the acceptance threshold. The assessor documents the mitigations already implemented, the residual risk rating after those mitigations, the alternative mitigations that were considered and rejected, and the rationale for rejection. That rationale must address cost, technical feasibility, and any adverse effects the alternative mitigation would introduce. Specificity is essential. "Too expensive" is insufficient; the organisation must explain the cost relative to the system's economic value and the severity of the risk. "Not technically feasible" requires the Technical SME to provide supporting evidence that the alternative was genuinely investigated, not merely dismissed. "Would degrade performance" must quantify the degradation and explain why the current performance level is necessary for the intended purpose.

The AI Governance Lead reviews this documentation and determines whether the residual risk is acceptable. Each acceptance is recorded as a formal governance decision, signed by the AI Governance Lead, and retained in the AISDP evidence pack. This sign-off confirms that the residual risk is proportionate to the system's benefits and that no reasonably practicable further mitigation remains available.

Residual risk must be communicated to deployers through the Instructions for Use (AISDP Module 8). The communication must be specific: stating that "the system has residual fairness risk" is inadequate. The deployer must know which subgroups are affected, the magnitude of the risk, the conditions under which the risk is most likely to materialise, and the compensating controls the deployer should implement in their operational context.

Article 9 requires continuous iteration of the risk management system, not a single assessment filed at deployment and left to gather dust. The risk register must demonstrate evolution over time. A static register that looks the same at the end of its first year as it did at the beginning suggests the organisation is not learning from its own monitoring data.

The AI System Assessor reviews the risk register quarterly, after every substantial modification, whenever post-market monitoring data reveals new risk indicators, and whenever external factors change. The quarterly review is a governance event convened by the AI Governance Lead with the Technical SME, Legal and Regulatory Advisor, and relevant stakeholders. The structured agenda covers new risks identified since the last review (from PMM data, deployer feedback, horizon scanning, or internal testing), changes to existing risk ratings with supporting evidence, the status of mitigation actions (on track, delayed, or blocked), reassessment of residual risk acceptability in light of any changes, and external developments that affect the risk profile.

Trigger-based reassessment fires immediately and without waiting for the next quarterly cycle. Triggers include serious incidents meeting Article 73 criteria, substantial modification determinations, competent authority inquiries or enforcement actions, publication of new harmonised standards or AI Office guidance, and significant deployment context changes such as new deployer populations or new jurisdictions. Every person in the organisation who might observe a trigger event must know the trigger mechanism and how to activate it. The AI Governance Lead documents these triggers in the quality management system and communicates them to all relevant stakeholders.