How to run an AI risk assessment
A practical method for assessing the risks of an AI system: scope from the register, work the harm dimensions, rate what remains, derive controls and record the result.
How do you run an AI risk assessment?
An AI risk assessment answers a plain question: what could this system do to people, to the organisation and to the decision it serves, and what are we doing about it? It is different from an impact assessment, which starts from the people affected and works inward; the risk assessment starts from the system and works outward. Done properly it takes a competent owner a few focused hours per system, and it is the piece of governance work that most changes what an organisation actually does, because controls fall out of it.
This guide gives you a method that works on paper and scales in software.
Step 1: Scope from the register entry
Start from the system’s register entry, not a blank page. 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: what is being assessed, in which setting, 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 or use it beyond its purpose?
- Dependence. What breaks when the vendor changes the model, the data drifts or the service goes down?
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 pension-day 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 state. Controls are specific, meaning a referral band 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.
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. 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 the free AI governance maturity assessment answers it alongside the six other areas of governance.
How this runs in Aicura
Aicura generates the risk assessment from the register data when a system is registered and again as it changes, works through the dimensions with framework-specific reasoning, and drafts the ratings and suggested controls for the accountable owner to refine, dispute and lock. The risks and controls flow to the Risk Register with owners and states, and the locked assessment is sealed in the Evidence Vault so it can be proven unchanged from the moment it was created. The judgement stays with your people, and the drafting, the structure and the record-keeping are carried for them.
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.
Related guides
Do this work in Aicura
Aicura is your AI Register, and Essentials runs the risk assessments, the risk register, the derived controls and the governance policies on top of it, with the privacy disclosure work included. It is guidance to help you do the work, not certification or legal advice.