Template
EU AI Act Article 9 - Risk Management System Template
Article 9 is where the dossier shows how your team identifies risks, tracks controls, updates the register after changes, and decides what residual risk is still acceptable.
Who supplies what
What Article 9 expects, what the toolkit can add, and what your team still owns
Without connecting your agent, the toolkit can only draft the register from the EU package you already generated. After adapter integration, it can also add entries from real runs, linked article outputs, and monitoring history.
| Article 9 expects | Toolkit with bundle only | Toolkit after adapter integration | Still written and approved by your team |
|---|---|---|---|
| A maintained risk register | Creates a draft risk-register file and basic placeholders from the EU bundle. | Adds evidence-linked entries from runs, linked article outputs, and monitoring history. | Add domain risks the toolkit cannot observe and decide which ones belong in the final register. |
| A record of concrete risks | Can flag missing evidence and degraded execution already visible in the bundle. | Can add entries from failed cases, blocked actions, security constats, drift, and monitoring gaps. | Describe the harm, affected users or process, and why that risk matters in your deployment. |
| Controls and follow-up | Can point to unresolved gaps already present in the package. | Can link a risk entry to monitoring signals, scanner constats, and follow-up actions. | Write the control, the control owner, the review date, and the next action. |
| Residual-risk decision | Shows open items but does not decide whether they are acceptable. | Still does not accept, reject, or sign off residual risk for you. | Set likelihood and severity rationale, then accept, block, or escalate with a named approver. |
Manual fields
What your team adds manually today, and when
These fields are not filled by the toolkit automatically and are not written back into the generated draft today. Add them in your Article 9 document or governance workflow while you review the register.
| What you add | When you add it | Practical format to use |
|---|---|---|
| Domain-specific risk not visible in runs | When you first prepare the Article 9 section, and again after major product or deployment changes. | One short risk statement naming the failure or harm and the affected users, process, or business area. |
| Affected users and business harm | When you review each open risk entry generated by the toolkit or added by the team. | One or two sentences explaining who can be harmed and what that harm looks like in your deployment. |
| Likelihood and severity rationale | Before the Article 9 section is approved or relied on in provider governance. | Short text or your internal scale explaining why the risk is low, medium, or high and how likely it is. |
| Control owner and target review date | As soon as a risk stays open and needs follow-up after review. | Named owner plus a concrete review date in the Article 9 section, tracker, or governance tool. |
| Residual-risk acceptance and sign-off | At provider or governance review, after the open risks and controls have been reviewed. | Accepted, blocked, or escalate, plus the approver name and any required next step. |
How this fits into the full package
Article 9 is one section inside the full EU dossier
There is one full EU dossier. The Article 9 draft is one file inside that package, alongside the oversight and monitoring outputs it depends on. The JSON layout shown here is the toolkit's structured format for those requirements, not an EU-mandated form.
| File in the package | Why it matters for Article 9 | Open file |
|---|---|---|
| Article 9 draft risk register - article-9-risk-register.json | Starting draft for the Article 9 risk section. | Open file |
| Annex IV dossier - eu-ai-act-annex-iv.json | Wider technical package that links Article 9 to the other dossier sections. | Open file |
| Human oversight summary - human-oversight-summary.json | Used when an open risk depends on human review, blocking, or escalation controls. | Open file |
| Post-market monitoring - post-market-monitoring.json | Used when Article 9 is updated because drift or recurring failures appear during monitoring. | Open file |
FAQ
Frequently asked questions
Can Article 9 be documented without technical evidence?
You can write the narrative, but that is weaker than a package that links to recent test evidence and review records.
What should evidence look like?
It should be machine-readable, timestamped, and linked to real cases, not a manual spreadsheet summary.
Does this replace legal review?
No. It gives legal and compliance teams a stronger technical basis.