AI Risk Register: Build and Maintain One Under Article 9
Article 9 EU AI Act requires a living risk register. Recommended fields, update cadence, and a worked example for providers and deployers. Dec 2027.
Article 9 of the EU AI Act (Regulation (EU) 2024/1689) requires every provider of a high-risk AI system to run a continuous risk management system throughout the system's lifecycle — and to document it. The risk register is the operational form that documentation takes: a structured, living record of every identified risk, its lifecycle, and what you are doing about it.
The Act does not use the phrase "risk register." What Article 9 calls for is a risk management system with defined phases — identification, estimation, evaluation, mitigation, and post-market monitoring. The register is how you execute and evidence those phases. Regulators and notified bodies reviewing your Article 11 technical file will reach straight for it.
What Article 9 actually requires
Article 9 sets four obligations that the register operationalises:
- Identify and analyse known and reasonably foreseeable risks — both intended use and foreseeable misuse.
- Estimate and evaluate risks that may emerge from use in realistic conditions, including from interactions with other systems or across diverse user populations.
- Adopt suitable mitigation measures, document them, and assign ownership.
- Test the effectiveness of those measures before placing the system on the market, and continue testing post-deployment.
The register is the single artifact that ties these four phases together. An entry that records only the initial assessment but no mitigation status or review date cannot satisfy Article 9's continuous-monitoring requirement. The word "continuous" matters — Article 9(3) explicitly requires the risk management system to be updated in light of post-market monitoring data gathered under Article 72.
The register in the broader compliance architecture
The risk register does not stand alone. It plugs into three other obligations:
Article 11 / Annex IV technical documentation. Your technical file must include a description of the risk management system and its results. The register is that description. An auditor or notified body reviewing the Article 11 package will check whether risks identified in design are reflected in the register, and whether the register shows evidence of ongoing updates.
Article 72 post-market monitoring. Providers must operate a post-market monitoring system and feed its data back into the risk management system. Practically, that means creating a feedback loop: monitoring data generates new register entries or revises existing risk scores. A register that has not been touched since the day of market placement is evidence of non-compliance with Article 72.
Article 26 deployer monitoring. Deployers of high-risk AI systems have their own monitoring duties and must inform providers of risks and incidents discovered in use. Where a deployer is also required to implement parts of the risk management system — which can happen when the provider expressly builds that into the instructions for use — the deployer should maintain a parallel register section covering deployment-context risks. Deployers of credit-scoring or public-service AI systems must also assess fundamental-rights implications under Article 27.
Recommended fields for each register entry
The Act specifies what the risk management system must capture but does not dictate column headers. The following fields satisfy Articles 9, 11, and 72 and give an auditor everything needed to verify the record:
| Field | Purpose |
|---|---|
| Risk ID | Unique reference (e.g. RSK-004) for traceability across documents and audit logs |
| AI system | Which registered system this entry relates to |
| Risk description | Specific statement of the potential harm, mechanism, and affected persons |
| Category | Bias / robustness / security / privacy / transparency / drift — or a combination |
| Affected persons / groups | Who could be harmed (e.g. job applicants over 50, patients, customers in lower-income brackets) |
| Likelihood | 1–5 scale, with defined thresholds; anchor to evidence, not intuition |
| Severity | Independent of likelihood; magnitude if the risk materialises |
| Inherent risk level | Likelihood × severity before any controls |
| Mitigations + owner | Specific, measurable actions; named person or team accountable |
| Residual risk level | Likelihood × severity after controls; if still unacceptable, escalate |
| Acceptability decision + sign-off | Explicit decision that residual risk is acceptable (or not), with named sign-off |
| Linked Article / control | e.g. Art 9(2)(a), Art 10(3), Art 14(4), Art 15(1) |
| Review date | Next scheduled review; mandatory when monitoring data arrives |
| Status | Open / In Progress / Mitigated / Accepted / Closed |
Two fields new compliance teams routinely omit: the acceptability decision (accepting a residual risk without documenting the rationale is not a valid compliance strategy) and the linked Article/control (without it, the register cannot be read against the legal requirements it purports to satisfy).
Risk categories worth mapping explicitly
Article 9 requires risks to be analysed across use-as-intended and reasonably foreseeable misuse. In practice, five categories cover the ground for most high-risk systems:
Bias and discrimination. The most litigated category. A recruitment-screening model trained on historical hiring data will reflect historical patterns. The register entry must name the affected demographic, quantify the disparity where possible, and specify the test that will verify the mitigation worked.
Robustness and performance drift. Models degrade when the real-world data distribution shifts from the training distribution. A credit-scoring model trained on pre-2022 economic data behaves differently in a high-interest-rate environment. Article 15 requires accuracy, robustness, and cybersecurity to be maintained throughout the lifecycle — the register links performance-monitoring thresholds to that obligation.
Security and adversarial inputs. Article 15 also covers cybersecurity. AI systems can be vulnerable to data poisoning (training-time) or adversarial examples (inference-time). Register the known attack vectors, the controls, and the residual exposure.
Privacy. Where the system processes personal data, register the privacy risks alongside the GDPR risk analysis. The two frameworks are complementary — a DPIA (GDPR Article 35) does not substitute for the Article 9 risk register, but the findings should cross-reference each other.
Transparency and explainability. Article 13 requires providers to give deployers enough information about the system's functioning. If the model is not interpretable, that creates a risk: deployers cannot comply with Article 14 human-oversight requirements if they cannot understand what the system is doing. Register it and specify the mitigation (e.g., explanation output, confidence score, override capability).
How to build the register: a practical sequence
Start before development ends. The risks you can identify during design — at the point when you still have control over architecture and training data — are the cheapest to mitigate. A register opened only at pre-deployment testing will miss design-stage decisions.
Cross-functional ownership from the start. Risk identification requires input from data scientists (who know the training data), product managers (who know the use cases and user populations), legal/compliance (who map the obligations), and, for deployer-facing tools, the sales or implementation team (who have seen how customers actually use the system). A register maintained by compliance in isolation is a compliance document. A register owned by the whole team is an operational one.
Anchor likelihood estimates to evidence. "High likelihood" is meaningless without a definition. Define your scale before you start populating it: likelihood 4 means "has occurred in similar systems or in your own testing; frequency > once per 1,000 transactions." Otherwise the register becomes a collection of subjective guesses that will not withstand scrutiny.
Set a review cadence and honour it. Article 9 is continuous; quarterly review is a reasonable minimum for most high-risk systems, with triggered reviews whenever monitoring data reveals a new pattern, an incident occurs, or a substantial modification is made under Article 3(23). A modification that is substantial enough to re-trigger the conformity assessment under Article 43 should generate a full register re-evaluation.
Distinguish acceptance from avoidance. Some residual risks will be acceptable; some will not. Document both. If the risk is accepted, name the person who made that decision and the rationale. If it is not acceptable and cannot be reduced further, that is a go/no-go signal for market placement.
Worked example: a 40-person HR-tech company
Assume a company builds a CV-screening tool classified as high-risk under Annex III point 4(a) (recruitment — selecting persons for employment). Their register opens with the following entry:
RSK-001 | CV Screener v2 | Disparate impact on age
- Risk description: Model assigns lower relevance scores to CVs from applicants over 55 due to underrepresentation in training data; could constitute indirect discrimination under Art 21 of the EU Charter.
- Category: Bias
- Affected persons: Job applicants aged 55+
- Likelihood: 4 (confirmed in pre-deployment testing: 14% lower pass-rate for 55+ cohort)
- Severity: 4 (denial of employment opportunity; fundamental-rights impact)
- Inherent risk: High
- Mitigations: (1) Retrain with age-balanced dataset by Q3 2027; (2) Add age-group fairness constraint to model objective; (3) Human reviewer must approve all rejections before candidates are notified — Art 14(5)
- Owner: Head of Engineering (retraining); Compliance Officer (human-review process)
- Residual risk: Medium (retraining reduces but does not eliminate; human review provides catch)
- Acceptability decision: Accepted pending Q3 retraining; CEO sign-off 2026-05-28
- Linked Article: Art 9(2)(a); Art 14(4); Art 26(7) [worker-rep notification if deployed by the customer]
- Review date: 2027-01-15 (or earlier if monitoring data triggers)
- Status: In Progress
This entry is auditable. An assessor can trace the risk back to evidence (pre-deployment testing), forward to specific controls, and across to the relevant Articles.
Maintaining the register over time
At market placement. Confirm all high-severity risks are at an acceptable residual level. Close any pre-market risks that were fully mitigated. Set the first post-market review date.
Post-market cycle. Article 72 requires providers to actively collect and analyse data from deployed systems. When monitoring data arrives — incident reports, user complaints, accuracy metrics, bias-audit results — update the affected register entries. If the data reveals a new risk, open a new entry. If it confirms a mitigation is working, record that evidence in the status field.
Serious incidents. Article 73 requires providers to report serious incidents to the market-surveillance authority of the member state where the incident occurred — within 15 days of first becoming aware, or 2 days for widespread or critical-infrastructure incidents, or 10 days where a person has died (Article 73(2)–(4)). The incident should also generate or update a register entry immediately; the register becomes part of the evidence trail the authority will review.
Substantial modifications. If a change to the system is substantial within the meaning of Article 3(23), treat the modified system as a new compliance cycle: re-evaluate existing risks, assess whether new ones arise, and update the technical file under Article 11. The register date-stamps this reassessment.
System decommissioning. Close all entries with documented closure rationale. Retain the complete register as part of the Article 11 technical documentation for 10 years after market withdrawal (Article 18).
How Confir helps
Confir maintains an organisation-wide risk register linked directly to the compliance controls and Articles its entries map to. When you register and classify an AI system — Confir derives your role (provider or deployer under Art 16/26) and risk tier via rule-based, deterministic logic — the register is pre-seeded with the risk categories relevant to that system's Annex III classification. Controls fire against specific Articles (Art 9, 10, 14, 15, 72), and each update is recorded in an immutable audit log. The same register feeds the Article 11 / Annex IV technical documentation pack at export time, so you are not maintaining two separate documents that can drift apart.
Frequently Asked Questions
Is the risk register a statutory requirement, or just good practice?
The term "risk register" does not appear in the EU AI Act, but the substance is mandatory. Article 9 requires a documented, continuous risk management system with identified risks, estimated severity, mitigation measures, and post-market monitoring. The register is the operational form of that system. Calling it something else — risk log, risk tracker — does not change the obligation. For high-risk AI systems, the output of that system is a core component of the Article 11 technical file that notified bodies and market-surveillance authorities will inspect.
Does a deployer need a risk register, or is that only the provider's job?
Providers bear the primary Article 9 obligation, but deployers have monitoring duties under Article 26 and must inform providers of risks and incidents discovered during use. Where a provider has structured the instructions for use to assign risk management tasks to the deployer, those tasks should be documented — a deployer-side risk log is the natural form. Additionally, deployers in certain sectors (creditworthiness, public services) must conduct an Article 27 Fundamental Rights Impact Assessment, which documents risks from a deployer perspective. The two records — provider register and deployer FRIA — are complementary.
What risk categories should every high-risk AI register cover?
At minimum: bias and discrimination (Article 9(2)(a) explicitly calls out fundamental rights); robustness and accuracy degradation (Article 15); security and adversarial inputs (Article 15); privacy (particularly where personal data is processed under GDPR); and transparency failures that undermine human oversight (Article 14). A system processing sensitive categories of personal data under GDPR Article 9 should have dedicated privacy entries cross-referencing the DPIA.
How often does the register need to be updated?
Article 9 says "continuously," which in practice means event-driven plus scheduled. Triggered updates: whenever post-market monitoring data reveals a new pattern, whenever an incident occurs, whenever a substantial modification is made (Article 3(23)), and whenever the intended use changes. Scheduled: most organisations run quarterly or semi-annual reviews. The review date field in each entry makes this enforceable — if the date passes without an update, that is a compliance gap.
Can a spreadsheet satisfy Article 9, or does software matter?
A spreadsheet can satisfy the legal requirement if it is version-controlled, backed up, and stores a full edit history. The risk is practical: a spreadsheet with no audit trail cannot prove that a risk was identified on a given date, not backdated. For systems subject to regulatory scrutiny, timestamped, immutable records are materially safer. EU data-residency considerations apply to wherever the register is stored — confirm your hosting location.
How does the risk register relate to the Article 11 technical file?
The technical file required under Article 11 and Annex IV must include "a description of the risk management system and its results." The register is that description. Practically, this means the register (or a formatted export of it) is submitted as a section of the Annex IV documentation package. A stale or incomplete register will cause the technical file to fail review. Keeping the register and the technical file in sync — rather than maintaining them separately — avoids the most common audit failure.
What happens if a risk materialises after market placement?
Add a new entry immediately with the discovery date, initial severity assessment, and interim mitigation. If the incident meets the definition in Article 3(49), Article 73 reporting obligations may be triggered — notify the relevant market-surveillance authority within the applicable window (15, 10, or 2 days depending on severity). Update the Article 11 technical file to reflect the new risk and any system changes made in response. Document everything with timestamps; regulators assessing a post-incident technical file will look at whether the risk was foreseeable, when it was first identified, and how quickly you responded.
Related guides
- Article 9 risk management requirements
- compare risk management tools
- EU AI Act overview
- AI system inventory software
- risk classification levels guide
- Article 6 high-risk classification
Manage your EU AI Act compliance in one place
Confir automates risk classification, technical documentation, and audit trails for any company. No consultants. No 6-month projects. 7-day free trial.
Start free trial →