AI Risk Management

AI Risk Management: A Practical Framework for Getting Started

How to structure an AI risk management program from scratch — identification, assessment, treatment and monitoring — with a working risk register template.

Jasper Claes

July 3, 2026 · 11 min read

AI Risk Management

Most AI risk registers start as a copy-paste of a generic IT risk template with “AI” added to the title. That approach misses almost everything that actually goes wrong with AI systems — model drift, biased training data, hallucinated outputs, and automation bias in the humans supposed to be overseeing them. This is a framework built for how AI systems actually fail, with a risk register structure you can start using today.

TL;DR

AI risk management is a continuous loop — identify, assess, treat, monitor — not a document you write once and file away.
AI-specific risk categories that generic IT risk registers miss: model drift, training data bias, hallucination/factual inaccuracy, automation bias, and third-party/vendor model risk.
Assess each risk on likelihood × impact, but define impact across multiple dimensions — legal, safety, financial and reputational — since AI harms rarely fit one category cleanly.
Treatment options are the same as any risk discipline: mitigate, transfer, avoid or accept — the difference is what mitigation actually looks like for an AI system.
Monitoring has to be ongoing because AI risk profiles change as models are retrained, data drifts, or the system is used in ways it wasn't originally designed for.

Why Generic IT Risk Templates Miss AI-Specific Risk

A generic IT risk register is built around infrastructure failure, data breaches and access control — real risks, but not the ones that get an AI system flagged by a regulator or an angry customer. AI systems fail in ways that are probabilistic and behavioral rather than binary: a model doesn’t crash, it quietly gets worse at its job, or confidently produces a wrong answer, or is used by staff who trust its output more than they should.

AI-Specific Risk Categories to Track

Risk category	What it looks like in practice
Model drift	Performance degrades over time as real-world data diverges from training data
Training data bias	Unequal outcomes across demographic groups baked into historical data
Hallucination / factual inaccuracy	Confident, plausible-sounding outputs that are simply wrong
Automation bias	Human reviewers over-trust AI output and stop applying real scrutiny
Third-party / vendor model risk	You inherit risk from a model you didn't build and can't fully inspect
Security & adversarial risk	Prompt injection, data poisoning, or model extraction attacks
Regulatory misclassification	Treating a system as lower-risk than its actual legal classification

The Risk Management Cycle

AI risk management is a loop, not a one-time project — each system cycles through it continuously.

Identify — inventory every AI system in use, including shadow AI adopted by teams without formal sign-off.
Assess — score each identified risk on likelihood and impact, using AI-specific criteria, not generic severity scales.
Treat — decide, per risk, whether to mitigate, transfer, avoid or accept it, and assign an owner and deadline.
Monitor — re-assess on a schedule and whenever the system, its data, or its use case materially changes.

Building a Risk Register That Actually Gets Used

A working AI risk register needs, at minimum, these fields per risk:

AI system affected
Risk category (from the table above)
Likelihood and impact scores, with impact broken out by dimension (legal, safety, financial, reputational)
Current controls in place
Treatment decision and owner
Residual risk after treatment
Next review date

The field most registers skip is next review date — without it, the register becomes a one-time snapshot instead of a living record, and that's exactly the gap an auditor or regulator will find first.

Scoring Risk: A Practical Likelihood × Impact Approach

Score each identified risk on a simple 1–5 scale for both likelihood and impact, then multiply them for a rough severity score. The value isn’t the precision of the number — it’s forcing a consistent comparison across very different risks, so a rare-but-catastrophic risk doesn’t get silently deprioritized against a frequent-but-minor one.

A simple 5×5 likelihood × impact matrix — the same structure works for AI risk once the underlying categories are AI-specific.

For AI systems specifically, define impact across at least four dimensions — legal, safety, financial and reputational — and score against the worst dimension, not an average. A hiring algorithm with low financial impact but high legal/discrimination impact should be treated as high severity, not middling.

Third-Party and Vendor Model Risk: A Closer Look

Third-party AI risk deserves its own process because you can’t inspect a vendor’s training data or model internals the way you can your own system. Assessment has to rely on different evidence.

What to request from the vendor	Why it matters
Model card or system documentation	Baseline understanding of intended use and known limitations
Bias/fairness testing results	Evidence they've tested for the failure modes you're most exposed to
Security and data handling practices	Determines what risk you inherit around your own data passing through their system
Incident notification commitments	Whether you'll be told promptly if something goes wrong on their end
Contractual indemnification terms	Whether financial risk can be transferred, not just technical risk mitigated

KPIs Worth Tracking Across Your Risk Register

Metric	Why it's useful
% of AI systems with a current risk assessment	Direct measure of register coverage and staleness
Average time from risk identification to treatment decision	Shows whether the register drives action or just documents inaction
Number of risks past their review date	Leading indicator of a register going stale before it's too late
% of high-severity risks with residual risk sign-off	Confirms accepted risk was a deliberate decision, not an oversight

Escalation: When a Risk Needs to Go Above the Register

Not every risk decision belongs with the team that owns the AI system. Define a threshold — for example, any risk scoring in the top band of your matrix, or any risk with potential regulatory exposure — that automatically escalates to a governance committee or executive sponsor rather than being closed out at the team level. Without this threshold, the people most incentivized to ship quickly are also the ones deciding whether a risk is acceptable.

Risk Treatment: What Mitigation Actually Means for AI

Treatment	Example for an AI system
Mitigate	Add human review for high-stakes outputs; retrain on rebalanced data; add guardrails against known failure modes
Transfer	Contractual indemnification from a vendor; insurance covering AI-related liability
Avoid	Decide not to deploy the system for a specific high-risk use case
Accept	Formally document and sign off on a residual risk that falls within tolerance

How This Connects to Formal Frameworks

This cycle isn’t a Unorma invention — it’s the same underlying logic behind the NIST AI RMF’s Map, Measure and Manage functions, the EU AI Act’s risk management system requirement under Article 9, and ISO 42001’s clause 6 risk treatment process. Building one solid internal risk register pays off across all three, since the assessment work is what those frameworks actually ask you to evidence.

Primary Sources

NIST — AI Risk Management Framework
EUR-Lex — Regulation (EU) 2024/1689

Keeping the Register Alive Instead of Static

Where software helps

Unorma’s gap analysis and oversight modules turn the identify-assess-treat-monitor cycle into scheduled reviews with owners and due dates, instead of a spreadsheet that goes stale the month after it's created. If you're just getting started, read our guide to what AI compliance software does end to end.

Frequently asked questions

How is AI risk management different from general IT risk management?

AI systems fail in probabilistic, behavioral ways — model drift, bias, hallucination, automation bias — rather than the binary failure modes (outages, breaches) generic IT risk registers are built around. AI risk management needs its own categories and assessment criteria.

How often should an AI risk register be reviewed?

At minimum on a set schedule (commonly quarterly for high-risk systems), and immediately whenever a system, its training data, or its use case materially changes. A 'next review date' field per risk is what keeps this from lapsing.

Who should own AI risk management inside an organization?

Ownership is typically shared: a central compliance or governance function sets the framework and reviews the register, while the product or engineering team that owns each AI system owns day-to-day risk treatment for it.

Does a good AI risk register satisfy the EU AI Act, ISO 42001 and NIST AI RMF at once?

A well-built one gets you most of the way for all three, since each expects some form of risk identification, assessment and treatment. You'll still need framework-specific documentation on top of it, but the underlying risk work doesn't need to be duplicated three times.

How should we score AI risk severity?

A simple 1-5 likelihood × impact matrix works well, as long as impact is assessed across multiple dimensions — legal, safety, financial and reputational — scored against the worst dimension rather than an average across them.

How do we assess risk from third-party AI vendors we can't inspect directly?

Request their model documentation, bias/fairness testing results, security practices, incident notification commitments and contractual indemnification terms — you're assessing evidence and contractual protection rather than the model internals directly.

What metrics show whether an AI risk register is actually working?

Track the percentage of systems with a current assessment, average time from identification to treatment decision, the number of risks past their review date, and whether high-severity residual risks have explicit sign-off.

When should a risk be escalated beyond the team that owns the AI system?

Set a defined threshold in advance — for example, any risk in your matrix's top severity band, or any risk with regulatory exposure — so escalation isn't left to the judgment of the team most incentivized to ship quickly.

Key terms in this article

About the author

Jasper Claes

Compliance Manager & AI Governance Consultant

Compliance Manager and consultant specializing in AI governance for high-scale technology companies operating in regulated markets.

View full profile

Keep reading