Risk Management System

The risk management system is the spine of high-risk AI compliance. Under EU AI Act Article 9, providers of high-risk AI systems must establish, implement, document and maintain a risk management system that runs as a continuous, iterative process across the entire lifecycle of the system. The system has to be regularly and systematically reviewed and updated.

This is the article that auditors open first. If your risk management system is undocumented, the rest of your technical file collapses because every other obligation (data governance, transparency, human oversight, post-market monitoring) connects back to risks identified here.

The same logic appears in NIST AI RMF 1.0 under the MANAGE function and in ISO/IEC 42001:2023 under Clause 6.1. Different vocabulary, same concept.

Most AI governance platforms in our directory ship a risk register module: a structured store for identified risks, severity scores, treatment plans, owners, and review dates. The good ones tie each risk back to the AI system, the regulation, and the mitigating control so an auditor can trace a single risk from identification to closure.

Look for these capabilities:

• A risk taxonomy aligned to EU AI Act Annex III high-risk use cases and to NIST AI RMF risk categories.
• Configurable severity and likelihood matrices, with audit trails when scores change.
• Risk-to-control mapping so each risk has at least one mitigating control documented.
• A scheduled review cadence with reminders, because the law requires continuous review.
• Export to the technical file format an auditor or notified body will request.

• [ ] Identify all high-risk AI systems your organization provides or deploys.
• [ ] Document foreseeable risks for each, including risks to health, safety, and fundamental rights.
• [ ] Score each risk on severity and likelihood with a documented methodology.
• [ ] Assign an owner to every risk with a clear treatment plan.
• [ ] Tie each risk to one or more mitigating controls and verify the control works.
• [ ] Re-run the risk assessment after every material change to the AI system, including model retraining.
• [ ] Keep version history so an auditor can see how the risk picture changed over time.
• [ ] Test residual risk against the acceptable-risk threshold defined by your organization's policy.

Three patterns we see repeatedly in vendor and operator audits.

First, the risk register exists but is static. Risks were entered on day one and never updated. The Act explicitly requires a continuous process. A risk register frozen at month zero is evidence of non-compliance, not compliance.

Second, risk identification stops at obvious technical risks (model drift, data quality) and never reaches fundamental rights, discrimination, or societal harm. Article 9(2)(a) requires identification of risks to health, safety, and fundamental rights. These are not optional categories.

Third, residual risk is documented but never tested against the acceptable-risk threshold. Article 9(5) requires that residual risks be judged acceptable. If you never wrote down what acceptable means, you cannot prove the residual risk meets the bar.

Primary sources:

• EU AI Act Article 9: Risk Management System — the binding text.
• Annex IV: Technical Documentation — what the risk management documentation must include in the technical file.
• NIST AI RMF 1.0 - MANAGE function — the US counterpart, useful for cross-jurisdiction operators.
• ISO/IEC 42001:2023 Clause 6.1 — the management-system standard certified bodies audit against.
• European Commission AI Office — the body issuing interpretive guidance ahead of August 2026 enforcement.