EU AI Act Article 9 risk management system — the template.
Article 9 requires a documented, continuous risk management system — not a one-time assessment. This template gives you the structure: what sections the record must contain, what each field should capture, and what sign-off pattern satisfies an auditor asking for evidence.
When is Article 9 required?
Article 9 applies to providers and deployers of high-risk AI systems as defined in Annex III (biometric identification, critical infrastructure, employment, credit, education, law enforcement, migration, justice). Not sure if your system qualifies? Use the EU AI Act risk tier classifier →
What Article 9 actually requires
Article 9 defines risk management as a continuous, iterative process, not a document. The six substantive requirements are: (1) establish and maintain a risk management system; (2) identify and analyze known and reasonably foreseeable risks; (3) evaluate risks; (4) implement mitigation measures; (5) test the system against intended purpose and foreseeable misuse; and (6) monitor the system post-deployment. Each step requires a record.
What most organizations get wrong: they treat Article 9 as a form to fill in once, rather than as an ongoing process with version-controlled records. An auditor asking for the Article 9 evidence record expects to see: a system policy document, a risk register with rationale, a control plan with implementation status, test records with defined pass/fail criteria, and a monitoring plan. Not a one-page summary.
The template below gives you the structure. It is not a legal form — it is a starting point that must be adapted to your specific system, deployment context, and applicable sectoral regulation. The goal is to have a record that answers the auditor's questions before they ask them.
The Article 9 risk management system template
The template below shows the structure. Download the free XLSX version to use it directly, or use it as a reference when building your own documentation.
Section 1
System identification
System name
e.g. Recruitment screening assistant
System version
e.g. v2.1.0
Intended purpose
Describe the specific function and context of use as documented by the provider
Annex III category
e.g. Employment and worker management — screening of candidates
Provider
Organization name and role (provider / deployer / both)
Deployment context
Which teams, locations, and subject groups will interact with this system
Date of assessment
YYYY-MM-DD
Next review due
YYYY-MM-DD — review triggered by: model change, data change, scope expansion, or scheduled annual review
Document owner
Name and title of the responsible party for this record
Approved by
Name and title of the person accepting the residual risk profile
Section 2
Risk identification and analysis
Enumerate known and reasonably foreseeable risks — including biased or discriminatory outputs, privacy leakage, misuse by end users, failure under edge conditions, adversarial manipulation, and risks to fundamental rights. Article 9(2) requires considering risks to health, safety, and fundamental rights. Consider both harms to the persons subject to the system and third-party harms.
Risk 1
Risk description
Describe the foreseeable risk to health, safety, or fundamental rights
Risk source
e.g. model bias, input data quality, misuse scenario, adversarial input
Affected persons
e.g. applicants, employees, customers, vulnerable groups
Likelihood (before mitigation)
Remote / Possible / Probable / Near-certain
Severity (before mitigation)
Negligible / Limited / Significant / Serious
Mitigation measures
Controls, design changes, process safeguards, human oversight measures in place
Residual risk
Describe the risk after mitigation and the basis for accepting it
Risk owner
Name/role of the person who accepted the residual risk
Residual likelihood
Remote / Possible / Probable
Risk 2
Risk description
Describe the foreseeable risk to health, safety, or fundamental rights
Risk source
e.g. model bias, input data quality, misuse scenario, adversarial input
Affected persons
e.g. applicants, employees, customers, vulnerable groups
Likelihood (before mitigation)
Remote / Possible / Probable / Near-certain
Severity (before mitigation)
Negligible / Limited / Significant / Serious
Mitigation measures
Controls, design changes, process safeguards, human oversight measures in place
Residual risk
Describe the risk after mitigation and the basis for accepting it
Risk owner
Name/role of the person who accepted the residual risk
Residual likelihood
Remote / Possible / Probable
Risk 3
Risk description
Describe the foreseeable risk to health, safety, or fundamental rights
Risk source
e.g. model bias, input data quality, misuse scenario, adversarial input
Affected persons
e.g. applicants, employees, customers, vulnerable groups
Likelihood (before mitigation)
Remote / Possible / Probable / Near-certain
Severity (before mitigation)
Negligible / Limited / Significant / Serious
Mitigation measures
Controls, design changes, process safeguards, human oversight measures in place
Residual risk
Describe the risk after mitigation and the basis for accepting it
Risk owner
Name/role of the person who accepted the residual risk
Residual likelihood
Remote / Possible / Probable
Section 3
Testing records
Article 9(5) requires testing against intended purpose and against probable misuse. Testing must occur before deployment and when the system changes in a way that could affect its risk profile. Signed test records with defined pass/fail criteria are required — not a summary statement that testing occurred.
Test scope
Describe what was tested — include accuracy, fairness, robustness, adversarial inputs, edge cases
Test methodology
How tests were performed — automated evaluation, red-teaming, human review panel, etc.
Pass/fail criteria
What specific criteria define a pass — accuracy thresholds, fairness metrics, no prohibited outputs in adversarial set, etc.
Test results
Summary of results against each criterion
Issues found
Any issues identified during testing — include severity and whether resolved before deployment
Test date
YYYY-MM-DD
Tested by
Name/team and role
Test sign-off
Name, title, and date of the person who approved the test results as sufficient for deployment
Section 4
Human oversight measures
Article 14 requires high-risk AI systems to support effective human oversight. Document what oversight measures are in place, how they were implemented, and who is responsible for maintaining them.
Oversight mechanism
Describe how humans can monitor the system's operation — dashboards, alert thresholds, review queues
Intervention capability
How a human can pause, override, or stop the system — and under what conditions they would do so
Competence of oversight persons
What training or qualifications are required of the persons who exercise oversight — and who provides that training
Oversight accountable party
Name and title of the person responsible for maintaining oversight effectiveness
Oversight last reviewed
YYYY-MM-DD
Section 5
Post-deployment monitoring plan
Post-deployment monitoring is not a requirement for continuous technical monitoring of every inference. It is a requirement for a defined process that can detect and respond to risks that emerge after deployment. This is what Article 9(4) requires: a monitoring plan with defined triggers, review cadence, and escalation path.
Monitoring triggers
What events trigger an unscheduled review — incident reports, accuracy degradation, complaints, regulatory guidance, data distribution shift, model update
Monitoring metrics
What is measured — false positive rate, demographic parity, complaint rate, human override rate, accuracy on spot-check sample
Review cadence
How often is the risk management record reviewed even without a trigger — e.g. quarterly, annually, or after any significant system change
Incident escalation path
Who is notified if a risk event occurs — internal responsible party, provider, national market surveillance authority, DPA
Monitoring owner
Name and title of the person responsible for the monitoring process
Last monitoring review
YYYY-MM-DD and brief summary of outcome
Section 6
Version history and sign-off
Free download
EU AI Act AI System Inventory Template (includes Article 9 risk management)
The XLSX template includes the Article 9 risk management record above, a system inventory sheet with five worked examples, and an Article 9 risk cycle log. Free download — no account required.
Worked example: HR recruitment screening tool
To illustrate how the template is used, here is a worked example for a hypothetical AI system that screens job applications and ranks candidates for human review.
Section 1 — System identification. System name: Recruitment screening assistant v2.1. Intended purpose: Rank inbound job applications based on matching criteria defined by the hiring manager. Annex III category: Employment and worker management — recruitment and selection of natural persons. Deployment context: HR team, all open roles at the company, applied to all inbound applications before human review. Provider and deployer: both (company that built and uses the system internally).
Section 2 — Risk identification (excerpt). Risk 1: Biased ranking against protected characteristic groups. Source: Training data reflects historical hiring patterns which may encode demographic bias. Affected persons: job applicants. Likelihood before mitigation: Possible. Severity: Significant (affects access to employment). Mitigation: Demographic parity testing on candidate ranking scores; quarterly disparity monitoring; human review of bottom-ranked candidates for any high-volume role. Residual risk: Possible for under-represented groups in roles where historical data is sparse — accepted by Head of HR with requirement for quarterly monitoring review.
Section 3 — Testing records.Test scope: Accuracy on held-out evaluation set; demographic parity by gender, age, ethnicity (where data available); adversarial inputs (CV padding, keyword injection). Pass criteria: Demographic parity gap < 0.05 (selection rate ratio); no prohibited terms in ranking explanation outputs; no high-confidence ranking from adversarial inputs. Results: Pass on all criteria. Issues: One edge case in adversarial test — fixed before deployment. Test date: 2026-04-15. Signed off by: CISO + Head of HR.
Section 5 — Monitoring plan.Triggers: Adverse selection rate by demographic group > 0.05 gap on any quarterly check; formal complaint from applicant alleging discrimination; change to scoring model. Metrics: Demographic parity (gender, age); human override rate (percent of AI rankings reversed by HR team); complaint rate. Review cadence: Quarterly demographic audit; annual full Article 9 review. Incident path: Head of HR → DPO → external legal counsel → national DPA if formal complaint triggers DPIA review.
How Drel produces the Article 9 record
The Article 9 risk management record above is what Drel produces as part of an AI Security Review Case. The Drel assessment output maps directly to the six Article 9 requirements: risk identification from the system architecture and threat model; risk evaluation with likelihood and severity ratings; a control plan mapping each risk to required controls; pre-deployment testing verification; human oversight requirements; and re-assessment triggers that define the post-deployment monitoring conditions.
The output is the AI Security Review Case — a structured, version-controlled record that can be exported as a PDF and used as the Article 9 evidence record in the technical documentation file. It is not a legal certification. It is the type of documented process record that Article 9 requires from a risk management system, produced through structured assessment rather than freeform documentation.
One case, one system. The record covers one assessed system per case. If you have ten high-risk AI systems in deployment, you need ten cases. The inventory template above covers the multi-system overview; each individual system requires its own Article 9 record.
Frequently asked questions
- Is Article 9 required for all AI systems?
- No. Article 9 applies specifically to high-risk AI systems as defined in Annex III and Article 6. Most enterprise AI tools — internal chatbots, document summarizers, coding assistants — do not fall within Annex III. The key question is whether the system is used for decisions in the Annex III categories: employment, credit, education, law enforcement, biometric identification, critical infrastructure, migration, or justice.
- Does a deployer need their own Article 9 record or can they rely on the provider's?
- Deployers have their own Article 9 obligations that the provider's compliance does not satisfy. A deployer must document their own deployment context — the specific way they use the system, the population it affects, the oversight measures they implement — even if they rely on a third-party model. The provider's documentation covers the model; the deployer's record covers the application layer.
- How detailed does the risk identification need to be?
- Detailed enough that a regulator reviewing the record can see that the organization identified the risks specific to this system and context — not generic risks that would apply to any AI system. The record should name specific failure modes: what happens if the model's predictions are biased against a particular demographic group in the specific context of your deployment? What happens under adversarial conditions in your specific use case?
- What counts as a 'reasonably foreseeable' risk?
- Reasonably foreseeable risks include misuse (using the system in ways the provider did not intend), edge-case failure modes (inputs or conditions outside the system's tested operating range), and risks that arise from the deployment context rather than the model itself. 'Reasonably foreseeable' does not require predicting every possible misuse — it requires applying professional judgment to identify the plausible failure modes for this system in this context.
- How often must the Article 9 record be updated?
- Whenever the system changes (model update, data change, scope expansion), when a risk event occurs, and in any case on a defined periodic schedule (typically annually). The Article 9 requirement is for a continuous, iterative process — not a static document. Version history and an audit trail of updates are evidence of continuity.
- What is the relationship between Article 9 and a DPIA?
- They are separate but overlapping. A DPIA is required under GDPR Article 35 when processing is likely to result in a high risk to natural persons. An Article 9 risk management record is required under the EU AI Act for high-risk AI systems. Both may be required for the same system. The DPIA focuses on data protection risks; the Article 9 record focuses on safety, accuracy, and fundamental rights risks from the AI system's operation.