How to Run an AI Risk Assessment: Template and Process

Contents

Figure 1: How to Run an AI Risk Assessment: Template and Process — the eight steps, the register columns, and the arithmetic that quietly loses the rare severe risk

Someone in your company just shipped a chatbot that talks to customers. Nobody wrote down what could go wrong. Congratulations, you now have an unmanaged risk with a friendly interface.

An AI risk assessment fixes that. It is a structured way to find what could go wrong with an AI system, judge how bad it would be, and decide what to do. Below you will find the frameworks that matter, an eight-step process, a template you can copy, and the scoring traps I found when I tested the usual methods. I am not a lawyer, so check legal obligations with one.

What "Risk" Means Here

The NIST AI Risk Management Framework defines risk as a composite of an event's probability and the magnitude of its consequences. It also says harm can fall on individuals, groups, communities, organisations, society, the environment and the planet. A good assessment therefore looks beyond your own company, which is the part most internal-only exercises skip.

The EU AI Act takes a tiered view. The summary I read describes four levels:

Tier	What it means	Examples
Unacceptable risk	Prohibited outright	Social scoring, manipulative AI
High risk	Heavily regulated, with obligations across the lifecycle	Hiring, credit, education, critical infrastructure, law enforcement
Limited risk	Transparency duties	Telling people they are talking to an AI
Minimal risk	Unregulated	Most ordinary applications

The tier decides how much process you owe, so classification belongs near the start of the assessment rather than at the end of it.

The Frameworks, in Plain Terms

NIST AI RMF 1.0

Released on 26 January 2023, voluntary, and organised into four functions:

Function	What it does in an assessment	Artifact it leaves
Govern	Builds a risk culture, policies and accountability	Named owners, policy, written risk tolerance
Map	Sets the context: intended purposes, settings, affected parties	System card, context memo
Measure	Assesses and tracks risks using quantitative, qualitative or mixed methods	Test reports, monitoring results
Manage	Allocates resources to the risks you found and plans responses	Treatment plan, release gates

The document says systems should be tested before their deployment and regularly while in operation, which is the sentence to quote when someone proposes a one-off assessment.

The Generative AI Profile

NIST published the Generative AI Profile, NIST AI 600-1, on 26 July 2024. Its page also notes that AI RMF 1.0 is being revised as part of the White House AI Action Plan. That matters for your template: pin the version you assessed against, or your register will quietly reference a superseded document.

ISO/IEC 42001

Published on 18 December 2023, ISO/IEC 42001 specifies requirements for an AI management system, and its page says it covers risk assessment through to effective treatment of those risks. A companion standard, ISO/IEC 23894, provides guidance on AI-related risk management. The practical difference is certification: the AI RMF gives you structure, while ISO/IEC 42001 gives you something an auditor can certify against.

The EU AI Act Timeline

The dates are staggered, and they moved:

Obligation	Date
GPAI model obligations	2 August 2025
Article 50 transparency	2 August 2026
Annex III high-risk systems	2 December 2027
Annex I high-risk systems (AI in regulated products)	2 August 2028

Those high-risk dates are the ones that moved. The Digital Omnibus on AI, Regulation (EU) 2026/1744, postponed them, and one source reports it entered into force on 27 July 2026. A law-firm analysis from May confirms the agreed dates. High-risk providers must run a risk management system across the system's lifecycle, among other duties, so the deadline is not the date you start writing the assessment, it is the date by which the process must already be running.

The Eight-Step Process

Step 1: Inventory Your AI

List every system, including vendor tools and the ones teams adopted without asking. You cannot assess what you have not found, and the shadow systems are usually the ones with the worst answers.

Step 2: Map the Context

For each system, write down its purpose, who uses it, who it affects, and where it should not be used. The out-of-scope list is the part that saves you in an incident review.

Step 3: Classify Against the Law

Check whether the use is prohibited, or falls in a high-risk area. The EU summary lists examples such as hiring and worker management, credit and insurance pricing, education, critical infrastructure and law enforcement. Record "unsure" as its own answer rather than guessing, because an unsure classification is a legal question with an owner.

Step 4: Identify Risks

Write each risk as cause, then event, then consequence. Prompt the team with NIST's seven trustworthiness characteristics: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. NIST also names three bias categories, systemic, computational and statistical, and human-cognitive, which are useful headings when a team insists its model is unbiased.

Step 5: Score the Risks

Use likelihood and impact, but read the next section first. The arithmetic is the weakest part of most assessments, and it is the part people trust most.

Step 6: Gather Evidence

Test before launch and keep testing. A red-team report beats a hunch, and the model monitoring guide covers the production half of that sentence. If you are assessing a generative system, the LLM interpretability guide explains why a model's own explanation is not evidence.

Step 7: Treat and Assign Owners

Pick avoid, mitigate, transfer or accept, a standard menu in risk practice, and put one named person on each risk. A treatment without a name and a date is a wish, and the register should make that obvious.

Step 8: Monitor and Review

Reassess when the model, the data, the use or the law changes. The law clause is the new one, and the EU timeline above shows why: a schedule change can reclassify work you already shipped.

Govern runs through all eight steps. Without clear accountability the other steps become paperwork, which is the failure mode the NIST framework guide covers in more depth.

The Template

Here is the register I use, with the columns that actually carry weight:

Column	What goes in it
ID, system	R-001, the AI system or use case
Risk description	Cause, event, consequence
Who could be harmed	People, groups, the organisation
Likelihood, impact (1 to 5)	Your scores, with the scale defined in a legend
Inherent score	Likelihood times impact, before controls
Existing controls	What already reduces the risk
Residual likelihood, impact, score	After controls
Owner	A named person, not a team
Treatment, action, due date	What you will do and when
NIST function	Govern, Map, Measure or Manage
Possible EU high-risk use?	Yes, no or unsure
Evidence	Test result or report

The file has 21 columns and two clearly labelled example rows. Replace them.

id,system,use_case,risk_description,harmed_parties,likelihood,impact,inherent_score,score_legend,existing_controls,residual_likelihood,residual_impact,residual_score,owner,treatment,action,due_date,nist_function,eu_high_risk,evidence,last_reviewed
R-001,support-assistant,customer Q&A,Confabulated policy detail answers a billing question wrongly; customer overpays,Customers; support staff,3,4,12,L1 rare / L5 almost certain; I1 minor / I5 critical,Retrieval grounding; low-confidence handoff to human,2,4,8,[email protected],mitigate,Add faithfulness gate at 0.90 and weekly regression run,2026-11-15,Measure,unsure,faithfulness_eval 0.93 on 2026-10-18 suite,2026-10-21
R-002,scoring-api,credit pre-screen,Proxy feature encodes postcode; denies applicants from one district without review,Applicants; compliance,2,5,10,L1 rare / L5 almost certain; I1 minor / I5 critical,Manual review above threshold,1,5,5,[email protected],avoid,Remove postcode proxy and retrain before next release,2026-11-01,Map,yes,disparity audit per district,2026-10-21

Twenty-one columns sounds heavy until you notice eleven of them are one-liners, and the register is the artifact that turns an assessment into something an auditor can follow.

Where Likelihood × Impact Misleads You

I tested the standard scoring method on synthetic registers. The numeric mappings and assessor error rates below are my illustrative assumptions, not standards.

The Matrix Hides Information

A 5×5 grid has 25 cells but produces only 14 distinct scores, and 21 of the 25 cells share a score with another. A rare, severe risk at likelihood 1 and impact 4 scores the same as a frequent trivial one at likelihood 4 and impact 1. Multiplication cannot tell them apart, and the person reading the register will.

The moment this became personal: the first time I ran two scoring passes over the same twelve-risk list, they disagreed about which single risk came first, and in both passes the winner was the row with the scarier name rather than the higher expected loss. That is what the reliability numbers below look like in a real spreadsheet.

The Reading of the Scale Matters

I took random registers of 10 risks and compared linear likelihood times impact against two reasonable expected-loss readings of the same labels:

Compared with L × I	Median rank agreement (Kendall tau)	Top-3 overlap	Same #1 risk
Impact grows 10× per step	0.81	2.37 of 3	76%
Impact grows 3× per step	0.95	2.78 of 3	88%

The readings mostly agree, but not always. One caveat: in 28% of registers the top likelihood times impact score was tied, so "the number one risk" depended partly on my tie-break.

People Disagree

I simulated two assessors scoring the same 12 risks, each slipping by one point with probability e:

Slip rate	Rank agreement (Spearman)	Same #1 risk	Same low/medium/high band
0.0	1.000	100%	100%
0.2	0.886	69%	82%
0.4	0.797	55%	71%

Modest slips cost agreement, especially on which single risk comes first. So record the evidence behind each score, and have two people score your top risks independently.

LEGEND = {
    1: "rare / minor",
    2: "unlikely / moderate",
    3: "possible / serious",
    4: "likely / severe",
    5: "almost certain / critical",
}

def residual_score(likelihood, impact):
    """Residual risk after controls. Same arithmetic, different inputs."""
    return likelihood * impact

def top_risk(register):
    """Return the leader and any ties, so a tie never silently picks a winner."""
    scored = [(r["id"], r["likelihood"] * r["impact"]) for r in register]
    best = max(score for _, score in scored)
    leaders = [rid for rid, score in scored if score == best]
    return best, leaders

best, leaders = top_risk(register)
print(f"top score {best}, tied between {leaders or 'no one'}")

The tie list is the most useful line in that snippet, because it forces the conversation the arithmetic wanted to skip.

Common Pitfalls

1. Assessing once, then filing it. Risks change with every model update, so treat the register as a living document with a review date.
2. Scoring without a legend. Define what "likelihood 3" and "impact 4" mean, in numbers where you can, or two assessors will read the same scale differently.
3. Treating the score as the answer. It is a conversation starter. Look at the rare, severe risks yourself.
4. Owner equals "the team". No name, no action, and no one to page at 2 a.m.
5. Ignoring vendors. Third-party AI is still your risk, because your users see your product, not your supply chain.
6. Confusing inherent and residual scores. A risk that looks fine only after controls still needs the control written down and tested.
7. Letting the classification slip. "Unsure" on the EU high-risk question is a legal task with a due date, not a column you leave blank.

Before you consider the assessment done:
[ ] every AI system, including vendor APIs, is in the inventory
[ ] purpose, users, affected parties and out-of-scope use are written down
[ ] the EU high-risk question is answered yes, no or unsure for each use
[ ] every risk reads as cause, event, consequence
[ ] likelihood and impact have a written legend, with numbers where possible
[ ] inherent and residual scores are both recorded
[ ] each risk has one named owner, a treatment and a due date
[ ] every score cites evidence, and the top risks were scored twice
[ ] a review date exists, and the law is rechecked on it

Check the edition date before you buy. The governance landscape has moved quickly, so pair any book with the current NIST and EU documents rather than treating it as the last word.

Unlock AI That Actually Works

Get lifetime access to GPT-6 Astra, Claude Fable 5.1, Gemini 3.5, Grok 4.5, and more — all in one platform. Build websites, apps, videos, content, and digital products from a single command. No monthly fees. No tool-hopping.

Click here to get GPTAstra Max now — one-time payment, lifetime access.

Frequently Asked Questions

What is an AI risk assessment?

It is a structured way to find what could go wrong with an AI system, judge how bad each outcome would be, and decide what to do about it. A good one covers the system's purpose, the people it affects, the legal classification of its use, the risks written as cause then event then consequence, the evidence behind each score, and a named owner for every risk. It is short, specific and repeated rather than filed once, because risks change with every model update, data change and shift in the surrounding law.

What are the eight steps of an AI risk assessment?

Inventory every AI system including vendor tools, map the context for each one, classify the use against the law, identify risks as cause to event to consequence, score likelihood and impact, gather evidence from tests, treat each risk with avoid, mitigate, transfer or accept and assign a named owner, then monitor and review. Govern runs through all eight, because without clear accountability the other steps become paperwork. The whole sequence is designed to fit one system into a single week for a first pass.

How do I score AI risks?

Use likelihood and impact from one to five, but define both scales in a written legend first, because the label means nothing without it. Score inherent risk before controls and residual risk after, and record the evidence behind every number. Then distrust the arithmetic: a five by five grid produces only fourteen distinct scores, so a rare severe risk can tie with a frequent trivial one. Read every top score yourself, have two people score the top risks independently, and never let a tie decide your priority.

What are the EU AI Act deadlines?

As currently in force, general-purpose AI model obligations applied from 2 August 2025, Article 50 transparency duties from 2 August 2026, Annex III high-risk systems from 2 December 2027, and Annex I high-risk systems embedded in regulated products from 2 August 2028. The high-risk dates moved: the Digital Omnibus on AI, Regulation (EU) 2026/1744, postponed them and one source reports it entered into force on 27 July 2026. Verify the current dates before you commit a roadmap to them, and check with legal counsel rather than relying on a summary.

Is the NIST AI RMF mandatory?

No, NIST AI RMF 1.0 is voluntary guidance, published as NIST AI 100-1 on 26 January 2023. It certifies nothing and imposes no legal duty, but it gives you four functions, Govern, Map, Measure and Manage, plus seven trustworthiness characteristics that make an assessment structured and auditable. Many teams adopt it because their customers and auditors already recognise the vocabulary. NIST's own page notes that the framework is being revised as part of the White House AI Action Plan, so check for the current version before you build a process around it.

What should an AI risk register contain?

At minimum an identifier, the system and use case, the risk written as cause to event to consequence, who could be harmed, likelihood and impact scores with the legend that defines them, the inherent score, existing controls, residual scores, a named owner, the chosen treatment with an action and due date, the NIST function it maps to, whether the use might be EU high-risk, and the evidence behind the score. Twenty-one columns covers all of it. Replace the example rows with your own and version the file alongside your code.

Sources

• NIST AI Risk Management Framework — the programme page.
• NIST AI 100-1 — the core framework, released 26 January 2023.
• NIST AI 600-1 — the Generative AI Profile, released 26 July 2024.
• European Commission: AI Act regulatory framework — the high-level summary and the four risk tiers.
• Regulation (EU) 2024/1689 — the AI Act itself.
• Regulation (EU) 2026/1744 — the Digital Omnibus on AI, in force 27 July 2026.
• ISO/IEC 42001 and ISO/IEC 23894 — the AI management-system standard and the risk-management guidance.
• Gibson Dunn: EU AI Act Omnibus Agreement — the May analysis of the agreed dates.
• Usercentrics: EU AI Act Deal, Digital Omnibus Now in Force — reporting on the 27 July 2026 entry into force.

Links checked on 21 October 2026.

Wrapping Up

A good AI risk assessment is short, specific and repeated. Inventory your systems, map their context, classify them against the law, write risks as cause, event, consequence, score them skeptically, test them, and give every risk an owner.

Frameworks such as NIST's give you the structure, and the EU AI Act sets deadlines you cannot ignore. Pick one AI system this week and run steps one through four on it. You will find something, and finding it on your own terms is much cheaper than finding it in an incident review.

Which system in your inventory would you assess first, and can you name its owner without checking?

Related Articles

• NIST AI Risk Management Framework Explained for ML Teams
• AI Ethics Principles: Fairness, Accountability and Transparency
• Interpretability vs Explainability in Machine Learning: What's the Difference?
• Model Monitoring in Production: How to Detect Problems Early
• Best Explainable AI and Model Interpretability Tools