How to run an AI risk assessment

An AI risk assessment works out what could go wrong with one AI system in your setting, how likely and serious each risk is, and which controls it needs before and while it runs. This guide gives you a method that works on paper and scales in software. It follows the shape the standards describe. ISO/IEC 23894 sets out AI risk management as identify, analyse, evaluate and treat. The NIST AI Risk Management Framework calls the same work Map, Measure and Manage, under a Govern function that sets tolerance and ownership.

Before you start: set your scale and tolerance

Agree two things once, for the whole organisation, before the first assessment. The first is the rating scale, meaning the likelihood and consequence levels and the matrix that turns them into a rating such as Low, Moderate, High or Critical. The second is risk tolerance, meaning the rating above which a risk must be treated and the person who may accept a risk that stays above it. Without these, every assessment invents its own scale and nothing can be compared across systems.

Step 1: Scope from the AI register

Start from the system’s record in your AI register, not a blank page. Write down what the system is, who provides it, what data it uses, what decision it makes or supports, who owns it and where the humans sit. If you cannot write those down, you are not ready to assess and the register work comes first. The scope statement is two or three sentences covering what is being assessed, in which setting and as at which version.

Step 2: Work the harm dimensions

Walk the system through the dimensions where AI goes wrong, and write down what failure looks like in your setting for each of them.

• Accuracy and reliability. What happens when the output is wrong, and how would anyone notice?
• Fairness. Which groups could be treated differently, and is the difference defensible?
• Privacy. What personal information flows through, and does the use match what was disclosed?
• Transparency. Can the people affected, and your own staff, understand what the system did?
• Security and misuse. Who could game it, poison it, inject instructions into it or use it beyond its purpose?
• Human oversight. Where does a person sit, and can they actually change the outcome?
• Dependence. What breaks when the vendor changes the model, the data drifts or the service goes down?

For generative systems, the NIST Generative AI Profile (NIST AI 600-1) adds risks worth checking explicitly, including confabulation (confident output that is made up), information security, data privacy and harmful content.

Not every dimension bites for every system. Write down the ones that do not apply and why, because the reasoning is part of the record.

Step 3: Rate what remains

For each live risk, rate likelihood and consequence squarely and resist the temptation to average everything to medium. The useful output is not the rating itself but the sentence beside it, explaining why this rating, in this setting, at this volume. A fraud model blocking transactions at peak volume carries a different consequence profile from the same model in a pilot, and the assessment should say so.

Step 4: Derive the controls

Every risk rated above your tolerance gets a control, and every control gets an owner and a status. Controls are specific. Examples are a score range where cases go to a person for review, with its outcomes reviewed quarterly, a decline review within a defined period, or a vendor validation report obtained and read each cycle. “Ongoing monitoring” is not a control. It is a hope. The controls belong in your risk register, worked alongside everything else the organisation manages. The AI risk register template shows the fields to record them in.

Step 5: Record the result and the dissent

The completed assessment records what was found, what was rated, what was disputed and what was accepted. Disagreement is part of a genuine assessment, because an owner who pushes back on a rating, with reasons, is producing exactly the record a reviewer wants to see. Record who accepted any risk that stays above tolerance. Lock the assessment when it is done, so what was decided and by whom does not blur later.

Step 6: Reassess on change, not on calendar

The assessment describes the system as at a version. When the system changes, the vendor updates the model, the data shifts or the setting moves, the assessment is due again. A calendar review is the backstop, not the trigger.

What a completed assessment looks like

A finished assessment reads as a story a stranger can follow. This system, in this setting, carries these risks, rated for these reasons, controlled by these measures with these owners, reviewed on these triggers, and here is who stood behind it. If your document cannot be read that way, it is a form, not an assessment. Whether your organisation’s assessment practice as a whole is ad hoc, defined or managed is a different question, and a maturity assessment answers it alongside the six other areas of governance.

How this runs in Aicura

On Essentials and above, registering a system in Aicura starts its first risk assessment, and a material change re-runs it against a fixed version of the system’s register record, so what was read is what was assessed. Each run drafts Steps 2 to 4 for you, with an overall rating and its rationale, the oversight that rating calls for, and risk items by domain, each with a written rationale and suggested controls. Every run is kept in the system’s assessment history, and at Pro your people can record signed statements against it.

A system with no completed assessment shows as not assessed, never as low. The draft is guidance for your judgement. Your owner still decides what the rating means in your setting and who accepts what remains.

A note on this page

This is a practitioner’s method, not legal advice or a regulatory template. Where a framework your organisation works against prescribes its own assessment structure, the framework is the primary source and this method fills the judgement inside it. The sources are ISO/IEC 23894:2023 (AI risk management guidance), ISO/IEC 42001:2023 clauses 6.1.2 and 6.1.3 (AI risk assessment and treatment), and the NIST AI RMF 1.0 with its Generative AI Profile.