Dieser Artikel ist derzeit auf Englisch verfügbar.
AI Risk Register: How to Build and Maintain One (With Template)
An AI risk register is the operational heart of AI governance — the living document that tracks what risks your AI systems create, how they are being managed, and who is accountable. How to build one that actually works.
Key Takeaways
An AI risk register has six fields that matter: the AI system, the risk (specific and concrete), the likelihood, the potential impact, the current controls, and the accountable owner. Everything else is decoration.
The most common risk register failure is recording risks at the wrong level of abstraction — 'AI may produce biased outputs' is not a registerable risk; 'our credit scoring model may produce loan denial rates that differ by 15% across demographic groups in ways that constitute indirect discrimination' is.
Risk registers must be reviewed at a set frequency — quarterly for high-risk AI, semi-annually for medium risk — and must be updated when AI systems change, when incidents occur, or when the regulatory environment materially changes.
The risk register is the primary evidence document for AI governance maturity in regulatory examinations, due diligence processes, and ISO 42001 audits. A risk register that is current, specific, and evidences active management is worth more than any amount of policy documentation.
For EU AI Act compliance, the risk register for high-risk AI must document: identified risks, their likelihood and severity, the measures taken to address them, and the residual risk after controls. This maps directly to the technical documentation requirement.
"Nur zu Informationszwecken. Dieser Artikel stellt keine rechtliche, regulatorische, finanzielle oder professionelle Beratung dar. Konsultieren Sie einen qualifizierten Spezialisten für spezifische Beratung."
What a functional AI risk register looks like
An AI risk register is not a list of things that could go wrong with AI in general. It is a specific, current, actively maintained record of the risks created by the specific AI systems your organisation operates, with specific controls assigned to specific owners. The difference between a functional risk register and a compliance document is whether anyone reads it, updates it, and acts on it.
The minimum viable risk register entry has six fields. The system: the specific AI system this risk relates to, identified precisely enough that it is unambiguous. The risk: a specific statement of what could go wrong, concrete enough that someone who read it would know whether the risk had materialised. The likelihood: a considered assessment of how probable the risk is, not a box-ticking exercise. The impact: what the harm would be if the risk materialised — to customers, to the organisation, to third parties. The control: the specific measures in place to prevent the risk from materialising or to reduce its impact if it does. The owner: the named person accountable for ensuring the control is operating effectively.
Writing risks at the right level of specificity
The hardest part of building a risk register is writing risks at the right level of specificity. Too abstract ('AI may produce incorrect outputs') and the risk cannot be assessed, controlled, or monitored. Too granular ('specific edge case in training data batch 7') and the register becomes unmanageable. The right level is: specific enough to be actionable, general enough to cover a meaningful class of events.
Examples of correctly specified AI risks: 'Our automated customer communication system may generate responses that contain incorrect information about product features or pricing, leading to customer complaints and potential consumer law exposure.' 'Our CV screening AI may produce shortlisting rates that differ systematically by gender or ethnicity due to biases in historical hiring data used for training, creating indirect discrimination liability.' 'Our fraud detection AI may flag legitimate transactions from customers in certain geographic regions at higher rates due to underrepresentation in training data, creating customer service burden and potential discrimination claims.' Each is specific, identifies a concrete harm, and points to a specific risk cause that can be addressed by specific controls.