Defining residual risk acceptance criteria for EU AI Act risk management

What Article 9 requires and what it leaves to the provider

Article 9(1) requires a risk management system to be established, implemented, documented and maintained for high-risk AI systems. Article 9(2) describes it as a continuous iterative process run throughout the lifecycle, with regular systematic review and updating. Article 9(5) sets the acceptance test: the relevant residual risk associated with each hazard, and the overall residual risk of the system, must be judged acceptable.

The Act defines risk as the combination of the probability of an occurrence of harm and the severity of that harm. That definition gives you two dimensions for criteria. Article 9 also limits its scope to risks that can be reasonably mitigated or eliminated through development or design, or addressed by providing adequate technical information. Criteria should be scoped to that boundary.

Article 9 does not prescribe numeric thresholds or a method for setting them. It also does not say who approves residual risk or how decisions escalate. Those are organizational judgments, and they need to be made explicitly and written down. ISO/IEC 23894:2023 offers guidance on AI risk management for organizations that develop, produce, deploy or use AI, including integrating risk management into AI-related activities. It can serve as a reference for your internal method, but the choice of method remains yours.

Writing criteria as measurable, testable conditions

A criterion that cannot be tested is a policy statement. For each hazard, record the affected interest (health, safety or a specific fundamental right), the condition of use it applies to (intended purpose or a named misuse scenario), the residual probability and severity estimate, the acceptance condition, and how the condition is measured. Keeping the intended purpose and misuse scenario beside each criterion matters because Article 9(2)(a) and (b) are framed around them.

Probability-based criteria suit hazards where occasional failure is tolerable at a stated level, for example the rate at which outputs in a defined category fail a defined test set. High-severity hazards often call for absolute conditions instead, such as a class of action that is never taken without human review. Recital 73 says high-risk systems should be designed so that natural persons can oversee them, so human oversight can be named directly in a criterion as a required condition.

Article 9(5) also requires a judgment on overall residual risk. Document how you combine per-hazard results, including cases where several individually acceptable hazards interact. The Act gives no aggregation method, so the reasoning you choose has to be stated and defensible on its own terms.

Decision ownership, escalation and documentation

Recital 65 expects justification and documentation of significant decisions and actions taken under the Regulation. For residual risk, that means each acceptance decision is recorded with the approver, date, criteria version, the estimates relied on, and the rationale. A signature on a policy document is not enough on its own.

Define escalation before it is needed. Reasonable triggers include a criterion breach, a change to the intended purpose, a newly identified misuse scenario, and signals from post-market monitoring. Article 9(2)(c) ties risk evaluation to data gathered through the monitoring system referred to in Article 72, so operational data is a formal input to revising criteria.

Keep a version history. A reviewer should be able to see what the criteria were at a given time, who approved them, and what changed on each review. As of November 2026, the Commission's Digital Omnibus on AI proposal could shift application timing for high-risk rules, so confirm its status before fixing a compliance timeline. The Article 9 logic itself does not depend on it.