What does EU AI Act Article 9 require?

Article 9 requires providers of high-risk AI systems to establish a documented risk management system that is an iterative process running throughout the entire AI system lifecycle. It must identify known and foreseeable risks across all phases, estimate and evaluate each risk, adopt suitable mitigation measures, test measures against predefined metrics with representative data, and document residual risks. Article 9 is not a pre-deployment checklist — it runs continuously from development through decommissioning.

Is Article 9 a one-time risk assessment or an ongoing process?

Article 9(1) is explicit: the risk management system shall be an iterative process throughout the AI system's entire lifecycle. This means the risk analysis must be updated when material changes occur: model provider updates, deployment context changes, new use cases, and newly published research that makes a previously unrecognized risk foreseeable. Organizations that treat Article 9 as a project gate create compliance exposure every time a model is updated without re-triggering the risk management process.

What counts as a foreseeable risk under Article 9?

Article 9(2) requires identification of risks from intended use and reasonably foreseeable misuse. Foreseeable risks are those predictable from the deployment context and the potential for misuse — they do not need to have actually occurred to require documentation. For AI agent systems, foreseeable risks include model drift after provider updates causing systematic errors, scope creep into use cases beyond documented intended purpose, adversarial inputs in retrieved content, and automation bias causing over-reliance. Risks that are foreseeable but not documented create Article 9 exposure regardless of whether they materialize.

What testing does Article 9 require before deployment?

Article 9(5) requires testing to verify that risk management measures are adequate and effective, against predefined metrics and probability thresholds appropriate to the intended purpose. Article 9(6) requires testing with data representative of the intended geographic, contextual, and functional deployment context. Standard ML benchmarks often do not satisfy the representative data requirement for domain-specific deployments. Testing must also recur after material changes — model updates, prompt changes, and deployment context changes — because Article 9 is a lifecycle process, not a one-time gate.

Does Article 9 apply to deployers or only to providers?

Article 9 is a provider obligation — it applies to developers who place high-risk AI systems on the market. Deployers have separate obligations under Article 26, including implementing technical and organizational measures consistent with the provider's documentation. However, deployers who make substantial modifications to a high-risk AI system take on provider-equivalent obligations including Article 9 risk management for the modified system. Fine-tuning a foundation model for a new use case, for example, may constitute a substantial modification requiring the organization to conduct full Article 9 risk management as a provider.

How does Article 9 relate to Article 12 logging requirements?

Article 9 requires identification and mitigation of risks; Article 12 requires automatic logging capabilities enabling post-hoc reconstruction of AI system operation. The connection: Article 12 logging is the technical control that satisfies many Article 9 monitoring requirements. A complete Article 9 risk management system should document which risks are monitored via Article 12 logging controls, what thresholds trigger escalation, and how the logging capability is tested for adequacy. Without this link, organizations may have both Article 9 documentation and Article 12 logs that are not operationally connected.

How does EU AI Act Article 9 compare to ISO 42001?

Both require risk management systems for AI but differ in mechanism. Article 9 is a legal requirement for EU high-risk AI — non-compliance risks market prohibition and penalties up to 3% of global revenue. ISO 42001 Clause 6.1.2 is a certifiable management system standard — certification demonstrates a functioning risk management system to customers and auditors without a legal mandate. They are substantially aligned on requirements: iterative processes, risk identification, control measures, and ongoing monitoring. ISO 42001 certification substantially satisfies Article 9, but Article 9 has additional specificity (Art.9(5) predefined metrics, Art.9(6) representative data) that requires explicit implementation.

What are the most common Article 9 compliance failures for AI agent teams?

Four patterns appear consistently: treating Article 9 as a pre-deployment checklist with no lifecycle update mechanism; documenting intended use risks but not foreseeable misuse scenarios; testing on generic benchmarks rather than representative deployment data; and maintaining risk management documentation that is decoupled from actual operations — risk registers that list monitoring as a control, but with no evidence that monitoring is running. The fourth pattern is the most dangerous because it creates documented exposure: the organization's own risk management records show a control that evidence would reveal is not operational.

EU AI Act Article 9: What the Risk Management System Requirement Actually Means

EU AI Act Article 9 requires providers of high-risk AI systems to establish a documented risk management system that is an iterative process running throughout the entire AI system lifecycle. It is not a pre-deployment risk register — it requires identification of known and foreseeable risks including misuse scenarios, estimation and evaluation of each risk, adoption of risk management measures, testing against predefined metrics with representative data (Art.9(5) and 9(6)), and documentation of residual risks. This guide maps each Article 9 sub-clause to the technical controls required for AI agent systems.

Article 9 Core Requirements

Article 9(1) requires a documented risk management system that is explicitly an iterative process throughout the entire high-risk AI system lifecycle — not a one-time pre-deployment assessment. Article 9(2) requires identification of risks across development and production phases, from intended use and reasonably foreseeable misuse. Article 9(5) requires testing against predefined metrics and probability thresholds to verify that risk management measures are adequate and effective. Article 9(6) adds that testing must include data representative of the intended geographic, contextual, and functional purpose. Article 9(7) requires documentation of residual risks in user instructions.

Iterative Lifecycle Process, Not a Risk Register

The most commonly misunderstood aspect of Article 9 is its lifecycle scope. The risk management system must continue operating after deployment: when model providers issue updates (even minor versions), the risk profile may change and risk analysis must be re-evaluated; when deployment context expands, the foreseeable misuse scope changes; when new research or regulatory guidance makes a risk foreseeable that was not previously identified, the risk analysis must be updated. Organizations that treat Article 9 as a project gate create compliance exposure every time a model is updated without re-triggering the risk management process.

Risk Identification for AI Agent Systems

Article 9 requires identification of risks from intended use and reasonably foreseeable misuse. For AI agents, this extends beyond generic ML risks to agent-specific failure modes: model drift causing systematic errors after provider updates, tool call scope expansion beyond authorized domain, multi-agent cascade failures, context poisoning via adversarial retrieved content, automation bias causing over-reliance by human oversight persons, and training data memorization exposing sensitive information. Article 9(2)(b) explicitly requires identifying risks affecting fundamental rights — for credit, healthcare, and employment AI, this connects Article 9 to ECOA/GDPR Article 22 non-discrimination requirements.

Article 9 Testing Obligations (Art.9(5) and 9(6))

Article 9(5) requires that risk management measure testing be against predefined metrics and probability thresholds appropriate to the AI system's intended purpose. This means documenting at deployment what metrics will be used and what values constitute adequate performance — then testing against those thresholds, not evaluating in a vacuum. Article 9(6) requires testing with data representative of the intended geographic, contextual, and functional purpose. Standard ML benchmarks do not satisfy this for domain-specific deployments. Post-update re-testing is also required: since Article 9 is a lifecycle process, testing must recur after model updates, prompt changes, and deployment context changes.

Article 9 vs ISO 42001 vs NIST AI RMF

EU AI Act Article 9 is a legal requirement for high-risk AI systems — non-compliance risks market prohibition and penalties up to 3% of global revenue. ISO 42001 Clause 6.1.2 is a certifiable standard with risk management as one component — certification demonstrates a functioning risk management system to customers and auditors. NIST AI RMF MAP function is voluntary guidance with the most operationally detailed implementation guidance. The three are complementary: Article 9 as the legal floor, ISO 42001 as the certification mechanism, NIST AI RMF MAP as the implementation guide. A functioning ISO 42001 Clause 6.1.2 program substantially satisfies Article 9 requirements, but Article 9 has additional specificity (representative data testing, misuse documentation) that requires explicit implementation.