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

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.

`mermaid flowchart TD A["AI System<br/>Identified"] --> B{"Listed under<br/>Article 5?"} B -->|Yes| C["PROHIBITED<br/>Cease operation"] B -->|No| D{"Annex III domain<br/>or Annex I safety<br/>component?"} D -->|No| E{"Triggers Article 50<br/>transparency<br/>obligations?"} D -->|Yes| F{"Article 6(3)<br/>exception<br/>applies?"} F -->|"Both criteria<br/>satisfied"| G["LIMITED / MINIMAL<br/>Standard or Baseline AISDP"] F -->|"One or neither<br/>criterion met"| H["HIGH-RISK<br/>Full AISDP required"] E -->|Yes| I["LIMITED RISK<br/>Standard AISDP"] E -->|No| J["MINIMAL RISK<br/>Baseline AISDP"] `

Tier 1: Prohibited practices under Article 5 include subliminal manipulation, exploitation of vulnerabilities, social scoring by public authorities, untargeted facial recognition scraping, workplace and educational emotion recognition (outside narrow medical and safety exceptions), criminal risk profiling based solely on profiling, and real-time remote biometric identification in publicly accessible spaces (outside narrow law enforcement exceptions). These systems cannot proceed through the AISDP process. Their existence triggers immediate escalation and cessation, not a risk assessment.

Tier 2: High-risk systems fall within the eight Annex III domains: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and border control, and administration of justice. Systems constituting safety components of products governed by Annex I harmonisation legislation (machinery, medical devices, vehicles) also qualify. These require the full AISDP with all 12 modules, a conformity assessment, CE marking, and EU database registration. The risk assessment for Tier 2 systems must satisfy every element of Article 9.

Tier 3: Limited-risk systems trigger Article 50 transparency obligations. This includes chatbots (which must disclose their non-human nature), emotion recognition and biometric categorisation systems (which must inform affected persons), and systems generating or manipulating synthetic content (which must label outputs as artificially generated). Tier 4: Minimal-risk systems require only a Baseline AISDP confirming the classification rationale and documenting the reasoning that none of the higher tiers apply.

The Article 6(3) exception allows certain systems that would otherwise be classified as high-risk to be treated as lower risk, but only if two conditions are both satisfied. The system must perform narrow procedural tasks, improve previously completed human activities, or detect decision-making patterns without replacing human assessment. In addition, the system must not pose significant risk to health, safety, or fundamental rights. Both the functional criterion and the risk criterion must be met simultaneously; satisfying one alone is insufficient. The risk assessment should treat this exception as a hypothesis to be tested against evidence, not as a convenient exit from compliance obligations. Both the Legal and Regulatory Advisor and the AI Governance Lead must review and approve any reliance on this exception. For the detailed classification methodology with worked examples, see Risk Classification.

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 FRIA must assess intersectional vulnerability, where multiple factors such as age, disability, economic situation, and ethnic origin compound in the same individuals or groups. A system performing adequately for each protected characteristic in isolation may still produce discriminatory outcomes for persons belonging to multiple disadvantaged groups simultaneously. The assessment must document the methodology used to identify intersectional effects, the data available to test for them, and the compensating controls applied where data limitations prevent comprehensive analysis.

Article 27 implicitly requires meaningful stakeholder engagement. The FRIA must document which stakeholders were consulted, how input was gathered, what concerns were raised, and how those concerns were addressed. Generic statements are insufficient. Article 27(4) requires deployers to notify the relevant market surveillance authority of the FRIA results, with procedures and timelines tested before the system goes live. The AI System Assessor integrates FRIA findings with the provider's risk register in Module 6, and any risks identified through the FRIA that were not captured in the provider's analysis are added. For the full FRIA methodology, see Fundamental Rights Impact Assessment.

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.

The FRIA should proceed in parallel with the Article 9 risk assessment, with a structured cross-reference step at completion. The AI Governance Lead reviews the completed FRIA for completeness before signing off, verifying that the rights analysis is tailored to the specific system, intersectional cell sizes are reported honestly, stakeholder consultation produced traceable outcomes, and every FRIA finding has a corresponding risk register entry or a documented rationale for exclusion. The completed FRIA feeds into both AISDP Module 11 and the market surveillance authority notification required by Article 27(4).

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.

FMEA (Failure Mode and Effects Analysis) is the workhorse of AI risk identification. For each system component (data pipeline, feature engineering, model inference, post-processing, user interface), the team enumerates the ways the component can fail, the effects of each failure, and the severity of those effects. In an AI context, failure modes extend beyond traditional software failures to include data drift, concept drift, adversarial manipulation, distributional shift in input data, label noise propagation, and emergent biases that only surface under specific input distributions. Each failure mode is assigned a Risk Priority Number calculated as Severity (1-10) multiplied by Occurrence (1-10) multiplied by Detectability (1-10). RPNs above the defined threshold (often 100 on a 1,000-point scale) trigger mandatory mitigation. The IEC 60812 standard provides the formal framework, extended with AI-specific failure modes covering the full ML pipeline.

Stakeholder consultation surfaces risks invisible from within the engineering team. Structured engagement with deployers, affected persons, civil society representatives, domain experts, and legal advisors reveals experiential risks that technical analysis alone will miss. Consultations must be scheduled at multiple points in the development lifecycle, not confined to a single pre-deployment review.

Regulatory gap analysis systematically maps the system's characteristics against every obligation in Articles 9 through 15 and the Annex IV documentation requirements, identifying areas where current design, testing, or operational practice falls short. Each gap becomes a risk entry. The Master Compliance Questionnaire provides a structured walkthrough for comprehensive coverage.

Adversarial red-teaming using the MITRE ATLAS threat taxonomy subjects the system to deliberate misuse scenarios, input manipulation, data poisoning attempts, and social engineering of the human oversight layer. Microsoft's PyRIT (Python Risk Identification Toolkit) automates portions for LLM-based systems, generating adversarial prompts and testing for jailbreak vulnerabilities. Red-team exercises should be conducted by personnel who were not involved in the system's development, ensuring independence and reduced confirmation bias.

Horizon scanning draws on three curated sources: the OECD AI Policy Observatory for regulatory developments, the Stanford HAI tracker for policy and research trends, and the AI Incident Database (maintained by the Responsible AI Collaborative) for real-world incident scenarios in comparable systems. This method identifies risks that the organisation might not have encountered internally. For the detailed methodology of each method with tooling recommendations, see Risk Identification Methodology.

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.

Investor reputational risk reflects the growing incorporation of AI governance into ESG assessment frameworks by institutional investors. A material AI compliance failure can affect an organisation's ESG rating, its attractiveness to responsible investors, and its cost of capital. Employee reputational risk operates through recruitment and retention. Organisations associated with bias, opacity, or regulatory non-compliance face challenges in competitive labour markets, particularly among engineering, data science, and ethics professionals.

The AI System Assessor assesses reputational risk for each identified technical risk across five factors: probability of public discovery, narrative severity, affected stakeholder sensitivity, containment ability, and likely duration of the reputational effect. Mitigations include proactive transparency measures such as publishing model cards and fairness reports, crisis communication planning, deployer and affected-person notification procedures, and engagement with civil society and academic reviewers. These mitigations are documented in the AISDP alongside the technical risk mitigations, ensuring a complete picture of the organisation's risk exposure.

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.

Calibration workshops should precede each assessment cycle. Assessors score standardised reference scenarios (drawn from published enforcement actions, the AI Incident Database, or internal near-miss events) independently, then compare results. Systematic divergences are addressed through shared reference cases. For high-uncertainty risks where the team genuinely cannot determine whether a failure mode is likely or unlikely, semi-quantitative Bayesian scoring provides probability distributions across the five likelihood levels rather than point estimates, making uncertainty visible rather than concealing it behind a single number. Where the organisation has multiple high-risk systems, cross-system calibration ensures that a "Significant" rating carries the same meaning across the portfolio, enabling meaningful risk reporting to executive leadership. For the full scoring rubric across all dimensions, see Risk Scoring and Calibration.

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 25(3) entitles downstream providers to request specific information from GPAI providers. The information request should cover five categories: training data governance (sources, methodology, geographic and demographic coverage, known biases, copyright compliance), model architecture and behaviour (architecture family, known failure modes, alignment approach, output constraints), versioning and change policy (deprecation policy, change notification commitments, scope of within-version updates), data handling practices (inference data retention, sub-processor disclosure, data residency), and safety and security (red-teaming results, vulnerability disclosure policy, incident response).

The AI Office Code of Practice for GPAI providers, finalised under Article 56, defines specific transparency and documentation commitments that participating providers have agreed to meet. The AI System Assessor should cross-reference these commitments against the information actually received, attributing gaps to either provider non-compliance with the Code (which may be raised with the AI Office) or limitations in the Code's scope (which the downstream provider must fill through its own controls). Where providers refuse disclosure, the refusal itself becomes a risk factor influencing Model Selection decisions. For the complete GPAI integration framework, see GPAI Integration.

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.

Residual risk acceptability changes over time and must be reassessed at each quarterly review. A risk acceptable at deployment may become unacceptable if the deployment scale increases (exposing more affected persons), if the affected population changes (new jurisdiction with different demographic composition), if new academic research identifies a previously unanticipated failure mode, or if the regulatory standard tightens through new AI Office guidance. The quarterly review must re-assess residual risk acceptability against current conditions, not merely confirm that the original assessment remains on file. For residual risk thresholds and communication templates, see Residual Risk Thresholds.

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.

Every change to the risk register creates a new version with timestamp, author, and rationale. The version history becomes the narrative of the organisation's risk management journey. An assessor reviewing the register should be able to trace from version to version and see the organisation responding to events: a post-market monitoring alert triggered a risk rating increase, a new mitigation reduced a residual risk score, a horizon scanning exercise added a risk that had not previously been considered.

Three implementation patterns are common. Dedicated GRC platforms (OneTrust, ServiceNow, Archer) provide structured workflows, automated reminders, and audit trails. Adapted project management tools (Jira, Azure DevOps) keep risk management visible alongside development work through custom issue types. Git-based registers with PR-driven changes provide the strongest version history at the lightest weight, though they lack workflow automation. AI-specific platforms (Credo AI, Holistic AI) offer tighter ML workflow integration. The NIST AI RMF and ISO/IEC 23894:2023 provide the methodological foundation, with NIST offering broad principles and ISO 23894 providing prescriptive integration points with the development lifecycle.

All findings feed into AISDP Module 6, which must contain the methodology description, risk register with version history, residual risk acceptance decisions, and cross-references to the AISDP modules where mitigations are documented. The evidence pack includes FMEA worksheets, stakeholder consultation records, red-teaming reports, horizon scanning summaries, scoring calibration records, and quarterly review minutes. For compensating controls and implementation patterns, see Iterative Risk Management. For the complete Data Governance implications of risk assessment findings, see the data governance pillar.