Annex IV §4 — Risk Management System Description (EU AI Act)

What Annex IV §4 actually requires

Annex IV §4 of Regulation (EU) 2024/1689 requires the technical documentation to include:

"A detailed description of the risk management system in accordance with Article 9."

That's it — one line. The work sits behind it: the Article 9 system itself, which is a continuous, iterative process running across the system's lifecycle.

The Annex IV §4 entry is a description of the system, not the full risk register. The register is a referenced artefact that a competent authority can request under Article 21. But the description in the technical file must be detailed enough that a market surveillance officer can understand the methodology, the cadence, the ownership and the integration with other Article 11 sections without leaving Annex IV §4.

Who is covered

Annex IV §4 applies to providers of high-risk AI systems. Deployers under Article 25 (substantial modification, brand-on-it, intended-purpose change) inherit the obligation for the modified variant.

SMEs filing under Article 11(1) second subparagraph (simplified form) still owe an Annex IV §4 description, but compressed. The simplified-form template is a Commission draft as of mid-2026; until it lands, SMEs should target one well-structured page covering the methodology, the cadence and the ownership.

What to include in Annex IV §4

A defensible Annex IV §4 description, in our experience, has six paragraphs:

1. Methodology. What risk-assessment framework you use (qualitative, quantitative, hybrid; ISO/IEC 23894 alignment; severity × likelihood matrix or another scheme). Two paragraphs maximum.
2. Risk identification scope. The categories you cover: health and safety risks, fundamental-rights risks, discrimination risks, foreseeable-misuse risks, vulnerable-group risks (Article 9(9)). Reference the actual risk taxonomy you maintain.
3. Mitigation hierarchy. State explicitly: design fix → guardrail → operational control → instructions for use. This signals you've internalised Article 9(5).
4. Review cadence. Who reviews, how often, with what trigger. Real cadences: quarterly for high-priority risks, annual for low-priority, ad-hoc on incident under Article 79. Name the accountable person or role.
5. Integration points. How Article 9 feeds into and is fed by:

- Annex IV §3 (human oversight) — risks identified here drive oversight measures. - Annex IV §8 / Article 72 (post-market monitoring) — operational data updates the register. - Article 79 (serious incidents) — incidents trigger register updates and possible re-classification. - Annex IV §5 (lifecycle changes) — material changes trigger re-assessment.

1. Reference to the live register. State where the register lives, the version-control identifier, and how a regulator can access it on request.

A worked paragraph

For a Dutch logistics company deploying a driver-scoring high-risk system:

"Risk management runs as a continuous process under our internal procedure RMS-2026 v1.4, anchored on a 5×5 likelihood-severity matrix and aligned with ISO/IEC 23894:2023. The Article 9 register currently holds 41 active risks across four categories: safety (driver and third-party harm), fundamental rights (employment effects, especially Article 9(9) for under-25 drivers as a vulnerable group), discrimination (sex, age, regional), and foreseeable misuse (the model being used for dismissal decisions despite the intended-purpose exclusion in §1 of this file). Mitigation follows the Article 9(5) hierarchy: design fix first (e.g., model retraining with re-balanced data), guardrails second (e.g., score capping), operational controls third (e.g., dual-reviewer for borderline scores), instructions for use last. The register is reviewed monthly by the Head of Driver Operations and quarterly by the AI Governance Committee (CTO + Compliance Director + safety officer); ad-hoc reviews are triggered by any Article 79 serious-incident report. The current register lives in our internal GRC system at GRC-RMS-DriverScore-v2.4 and is available to a competent authority on 14 days' notice under Article 21."

That paragraph, plus the cross-references to other Annex IV sections, is what Annex IV §4 should look like. It's specific. It names tools, frameworks, people and cadences. It does not paraphrase Article 9.

What regulators look at first

A market surveillance officer opening Annex IV §4 looks for:

1. Whether the description is generic or system-specific. Generic is a red flag; the file gets de-prioritised toward "looks back-filled."
2. Whether the cadence is realistic. "Quarterly" with no entries from the last quarter in the linked register is a non-conformity.
3. Whether vulnerable groups are addressed. Article 9(9) requires it where applicable.
4. Whether the integration with Article 72 is explicit. Article 9(2)(c) requires the post-market loop.
5. Whether Article 79 incidents update the register. Show the link.

Inline crosswalk to ISO 42001 and NIST AI RMF

• ISO/IEC 42001:2023 Clause 6.1.2 — AI risk assessment.
• ISO/IEC 42001:2023 Clause 6.1.3 — AI risk treatment.
• NIST AI RMF GOVERN 1.1 — Legal and regulatory requirements involving AI are understood, managed, and documented.
• NIST AI RMF MANAGE 1.3 — Responses to the AI risks deemed high priority are developed, planned, and documented.

A team running ISO/IEC 23894:2023 already produces 80% of the Annex IV §4 substance. The remaining 20% is the AI-Act-specific scaffolding: the Article 9(5) mitigation hierarchy, the vulnerable-groups paragraph (Article 9(9)), and the explicit integration with Annex IV §3, §5, §8 and Article 79.

What to do

1. Maintain the live register. Annex IV §4 is the abstract; without the live register it is fiction.
2. Adopt a documented methodology. ISO/IEC 23894 is the cleanest reference; CEN-CENELEC JTC 21 harmonised standards are emerging in 2026.
3. Bind documentation events to engineering events. Every retrain, every architectural change, every incident updates the register.
4. Quarterly review minimum for high-priority risks. Document attendees and decisions.
5. Cross-reference the FRIA (where applicable under Article 27) — same risks, deployer perspective.

Common mistakes

1. Static description with no live register. Annex IV §4 is a description of a process; if the process doesn't run, the description is false.
2. Paraphrasing Article 9 instead of describing your system. Regulators have read Article 9. They want to see your implementation.
3. No vulnerable-groups paragraph where Article 9(9) applies.
4. Generic mitigation hierarchy — "we will mitigate risks." State the hierarchy explicitly.
5. No link to Article 72 / Article 79 — both are required integration points.

Generate Article 11 documentation with AI

Governancer Pro includes an LLM-assisted Article 11 drafting tool that pre-fills the Annex IV §4 description based on your system characteristics and risk-register snapshot. The output is a defensible v0.1 paragraph; you fill in the system-specific details.

---

Disclaimer. This page is a reference summary of EU AI Act Annex IV §4. It is not legal advice. Verify with qualified counsel before relying on it for compliance decisions. Reg text from Regulation (EU) 2024/1689.