Phase 2: Risk Assessment & FRIA — Owner & Outputs

Phase 2 runs during Weeks 2 to 6. The Technical SME and AI System Assessor jointly own this phase.

The objective is to conduct the comprehensive risk assessment that informs all subsequent design and development decisions. Article 9(2)(a) requires the risk management system to identify and analyse the known and the reasonably foreseeable risks that the high-risk AI system can pose to health, safety, or fundamental rights, including risks arising from the system’s intended use and conditions of reasonably foreseeable misuse. The team applies the five-method risk identification approach: Failure Mode and Effects Analysis (FMEA), stakeholder consultation, regulatory gap analysis, adversarial red-teaming, and horizon scanning. The risk register is established, and each risk is scored across four dimensions: health and safety, fundamental rights, operational integrity, and reputational exposure.

Residual risk acceptability is assessed against Article 9(4)'s standard, which requires elimination or reduction of risks “as far as possible through adequate design and development,” with any remaining residual risk judged acceptable in relation to the system’s intended purpose and the persons or groups of persons on whom it is intended to be used. 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.

For deployers of high-risk systems that fall within the categories specified in Article 27(1) (bodies governed by public law, private entities providing public services, and deployers conducting creditworthiness evaluation or insurance risk pricing), the Fundamental Rights Impact Assessment under Article 27 is conducted in parallel. Article 27 places the FRIA obligation on these deployer categories specifically; where the organisation is both provider and deployer, the FRIA is nonetheless a deployer-capacity activity, and the assessment should reflect the deployer’s knowledge of the deployment context rather than the provider’s design assumptions alone. The FRIA examines the impact on all potentially affected EU Charter rights, with particular attention to intersectional effects where multiple vulnerability factors compound in the same individuals. The reputational risk framework is also applied, assessing customer, market, regulatory, shareholder, and employee dimensions for each technical risk. provide detailed guidance on FRIA methodology and documentation requirements.

Key outputs

• Risk register (populates AISDP Module 6)
• FRIA report (populates AISDP Module 11)
• Reputational risk assessment
• Risk mitigation plan with assigned owners and timelines

Phase 2: Governance Gate (Residual Risk Acceptance)

Phase 2 concludes with a governance gate: the AI Governance Lead reviews the risk register and formally accepts the residual risk profile before development proceeds.

This is a governance decision, not a technical one. For each risk above the acceptance threshold, the Assessor must document 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 relative to the system’s economic value and the severity of the risk. Claims of technical infeasibility require supporting evidence from the Technical SME. Claims that an alternative mitigation would degrade performance must quantify the degradation and explain why the current performance level is necessary for the intended purpose.

Each acceptance is signed by the AI Governance Lead. These sign-offs are retained as part of the AISDP evidence pack for the full ten-year retention period. Residual risk is communicated to deployers through the Instructions for Use (Module 8), specifying which subgroups are affected, the magnitude of the risk, the conditions under which it may materialise, and the compensating controls that deployers should apply.

Residual risk acceptability is not a one-time determination. The quarterly risk register review must re-assess acceptability in light of changes to deployment scale, affected population, new evidence, or tightened regulatory standards.

Key outputs

• Signed residual risk acceptance decisions
• Deployer risk communication documentation

Phase 2: Identification Methods & Scoring

Risk identification for AI systems requires a multi-method approach because no single technique captures every class of risk. The recommended methodology combines five complementary methods.

Failure Mode and Effects Analysis (FMEA) is the workhorse. For each system component, the team enumerates failure modes (including data drift, concept drift, adversarial manipulation, distributional shift, label noise propagation, and emergent biases), the effects of each failure, and the severity of those effects. Each failure mode receives a Risk Priority Number (RPN) based on severity, occurrence probability, and detectability, scored on scales of 1 to 10. RPNs above a defined threshold trigger mandatory mitigation. A threshold of 100 on the 1,000-point scale is a common starting point, but the threshold must be calibrated per system: a safety-critical system in healthcare may warrant a lower threshold (e.g., 80), while an internal analytics tool may accept a higher one (e.g., 150). The chosen threshold, the calibration rationale, and the individuals involved in setting it should be documented in the risk register and reviewed at each annual calibration workshop.

Stakeholder consultation surfaces experiential risks invisible to the engineering team. Structured consultation with deployers, affected persons, civil society representatives, and domain experts produces documented and actionable insights. Regulatory gap analysis maps the system against every obligation in Articles 9 through 15 to identify shortfalls. Adversarial red-teaming subjects the system to deliberate misuse scenarios, with the MITRE ATLAS threat taxonomy as the reference framework and tools such as Microsoft PyRIT for LLM-based systems. Horizon scanning reviews incidents and enforcement actions from comparable systems, drawing on the OECD AI Policy Observatory, Stanford HAI, and the AI Incident Database.

Risk scoring uses four impact dimensions: health and safety, fundamental rights, operational integrity, and reputational exposure. Annual calibration workshops ensure scoring consistency across assessors. High-uncertainty risks may employ semi-quantitative Bayesian scoring to make uncertainty visible rather than concealing it behind point estimates.

Key outputs

• Populated risk register with RPNs and four-dimension scoring
• FMEA analysis documentation
• Red-team exercise reports
• Stakeholder consultation records
• Calibration workshop records