AI risk management is the repeating process of identifying what could go wrong with an AI system, working out how bad it would be and how often it could happen, deciding what to do about it, and checking afterwards whether the decision held. It is the same discipline as any other risk management. What changes is the failure modes, the evidence you need, and the speed at which a system that was fine last quarter stops being fine.
This article covers the three things people usually need at once: which framework to work to, a checklist you can run against, and the mistakes that come up often enough to be worth naming in advance.
Choose one framework and stay in it
Three reference points dominate, and the common mistake is running all three at once. They do different jobs.
The NIST AI Risk Management Framework, published in January 2023 with a Generative AI Profile added in July 2024, is free, voluntary and organised around four functions. Govern sets the culture, accountability and policy that everything else runs inside. Map establishes context: what the system is for, who it affects, what assumptions sit underneath it. Measure works out how you will test performance, bias, security and drift, and what a failing result looks like. Manage decides what to do about the findings and in what order. NIST also publishes a Playbook of suggested actions against each function, which saves a lot of blank-page time.
ISO/IEC 23894 is the method rather than the structure. It maps onto ISO 31000, so it slots into an organisation that already runs enterprise risk that way: identify, analyse, evaluate, treat, monitor, review. It is not certifiable and it is best used as the engine inside a wider system.
ISO/IEC 42001 is the management system standard, published on 18 December 2023, and it is the one enterprise buyers ask about because it can be certified. Its Annex A controls give you a checklist of the organisational things a governed AI operation is expected to have in place.
A workable combination for most UK organisations is 42001 as the management system, 23894 as the risk method inside it, and the NIST Playbook borrowed for practical prompts. Pick that stack, or pick another one, and write down which you chose. Half-implementing two frameworks produces a programme that satisfies neither auditor.
The four lenses
Whatever framework you use, every AI system needs looking at through four lenses, and teams tend to be strong on one and blind on the others.
Performance asks whether the system does what it claims on data that looks like your data, not on the vendor’s benchmark. Security asks what an attacker can do with it, including the AI-specific routes such as prompt injection and data poisoning. Legal and rights asks whether the use is lawful, fair and explicable, and whether an affected person can challenge the outcome. Operational asks what happens when it is unavailable, wrong, or quietly degrading, and whether anyone would notice.
Security teams tend to score the second lens well and skip the third. Compliance teams do the reverse. An assessment signed off by only one function is usually missing half its findings.
Scoring AI risk without lying to yourself
Most organisations reach for the five-by-five likelihood and impact matrix they already use, and it produces a page of amber. That happens because likelihood is the wrong first question for AI.
Start with consequence instead. What is the worst realistic outcome of a wrong output, who bears it, and can they tell it happened? A tool that drafts internal summaries has a low ceiling. A tool that ranks applicants has a high one, and the person affected will usually never know the system was involved.
Then look at volume rather than probability. A model that is wrong 2% of the time is a curiosity at fifty decisions a month and a serious exposure at fifty thousand. Frequency of use turns a modest error rate into a pattern, and patterns are what regulators and claimants find.
Third, ask about reversibility. A wrong answer a human catches before it leaves the building is a different risk from one that has been sent, published or acted on. Where a system sits in a workflow changes its rating more than the model behind it does.
Score those three, consequence, volume and reversibility, and the tiering usually falls out on its own. Keep a note of the reasoning behind each rating. In six months nobody will remember why a system was rated medium, and the reasoning is the part an auditor asks for.
DPIAs, FRIAs and how they fit together
Two formal impact assessments sit alongside AI risk management, and they are not interchangeable.
A data protection impact assessment is required under UK GDPR where processing is likely to result in a high risk to individuals. It covers the data protection questions: lawful basis, necessity, proportionality, rights and safeguards.
A fundamental rights impact assessment is an EU AI Act obligation under Article 27, and it applies to a narrower group: deployers that are bodies governed by public law, private entities providing public services, and deployers of Annex III systems used for creditworthiness assessment or for risk assessment and pricing in life and health insurance. Where it applies, it must be completed before first use, updated if the picture changes, and its results notified to the market surveillance authority. It follows the high-risk timeline, which the Digital Omnibus moved to 2 December 2027.
Article 27(4) lets a deployer who has already carried out a DPIA use it as the base, with the FRIA completing it. That is worth planning for, because the two are usually run as one exercise. The scopes still differ: a DPIA looks at data protection, while a FRIA looks at rights a DPIA was never written to cover, including non-discrimination and access to justice, and it can be required even where no personal data is involved.
Neither replaces AI risk management. Both are outputs of it, triggered by what the classification step finds.
Treating the risk: four options, one rule
Treatment options are the familiar four. Avoid the risk by not doing it, or by doing it without AI. Reduce it with controls: narrower scope, human review, better data, tighter permissions, output filtering. Transfer part of it through contract terms and insurance, remembering that a contractual indemnity moves the cost and not the regulatory accountability. Or accept it.
The one rule is that acceptance needs a name and a date. An accepted risk with no named accepter is an unmanaged risk with better paperwork, and it is the first thing that unravels when something goes wrong. Give it a review date too, because acceptance was a judgement made against a set of facts that will change.
What to monitor after go-live
Assessment before deployment is the easy half. AI risk management is mostly what happens afterwards, and this is where most programmes quietly stop.
Track output quality against a sample checked by a person, at a frequency set by the risk tier. Track the rate at which human reviewers override the system, because a rate near zero usually means the review is not real and a rising rate is an early warning. Log supplier model updates, since your system can change without you deploying anything. Watch complaint and appeal volumes for the process the AI sits in. Record incidents, including near misses that a human caught.
Set a reassessment trigger in writing: a new system, a material model change, a new purpose for an existing tool, a relevant regulatory change, or an incident. Without triggers, review happens when somebody remembers.
An AI risk management checklist
Run this against any system before it goes live, and against your existing estate as a catch-up exercise.
- The system is on the inventory, with a named business owner and your role recorded as provider or deployer.
- The purpose is written down, along with the purposes it is not approved for.
- The data it processes is documented, with the lawful basis where personal data is involved.
- A DPIA has been completed where the processing warrants one, and a FRIA where Article 27 applies.
- The risk rating is recorded, with the consequence, volume and reversibility reasoning behind it.
- Performance has been tested on representative data, with a threshold agreed in advance.
- Bias testing has been carried out where the system affects people, or the reason it was not is documented.
- Security testing covers the AI-specific routes, including prompt injection where the system reads untrusted content.
- Human oversight is designed with a realistic workload and a route for the reviewer to disagree.
- Logging captures inputs, outputs and overrides in a form that would let you reconstruct a disputed decision.
- Supplier terms cover training use of inputs, retention, model change notification, audit rights and indemnities.
- Monitoring metrics, review frequency, reassessment triggers and a rollback plan are all agreed and owned.
Eight pitfalls that come up repeatedly
Scoring the tool instead of the use case. The same model summarising internal notes and screening tenants are two entries in the register, not one. Organisations that assess at tool level end up with a rating that is wrong in both directions at once.
Treating supplier assurance as evidence. A marketing page claiming responsible AI is not test evidence. Ask for the results, the method and the date, and record what you were given rather than what you were told.
A matrix that turns everything amber. If nothing in the register is red and nothing is green, the scoring method has stopped discriminating and the register has stopped being useful for prioritising anything.
Risk appetite left unwritten. Without an agreed statement of what the organisation will and will not accept, every case is argued from scratch, decisions vary by whoever is in the room, and there is nothing to point at when someone wants an exception.
Treating the DPIA as the whole assessment. The DPIA covers data protection. It was never designed to cover accuracy, safety, intellectual property, supplier lifecycle or the operational question of what happens when the system is unavailable.
Assessing the model rather than the human-plus-model system. Most real-world outcomes come from how a person uses the output under time pressure. A model that performs well in testing can still produce poor decisions if the interface encourages acceptance and the reviewer has ninety seconds.
No baseline. If you never measured the error rate of the process before the AI arrived, you cannot show the system made things better, and you cannot show it made things worse either. That cuts both ways, and the second one matters in a dispute.
Reading a deferral as an exemption. The Digital Omnibus moved the high-risk obligations to December 2027 and changed none of the substance. Conformity assessment, technical documentation and human oversight design all still have to be built, and the queue for people who can do that work will be longer in late 2027 than it is now.
Frequently asked questions
What is an AI risk management framework?
A structured method for identifying, analysing, treating and monitoring AI risks consistently across an organisation. The main reference points are the NIST AI Risk Management Framework, ISO/IEC 23894 for method, and ISO/IEC 42001 for the surrounding management system. A framework gives you repeatability, which is what turns a one-off assessment into something you can evidence.
How do you score AI risk?
Start with the consequence of a wrong output and who bears it, then factor in how many decisions the system touches and whether an error can be caught and reversed before it has effect. Likelihood alone tends to produce a page of amber ratings, because error rates for AI systems are rarely known precisely enough to separate one system from another.
What goes in an AI risk register?
One row per system and use case, with the owner, the purpose, the data involved, the risk rating and the reasoning behind it, the controls in place, the residual rating, the treatment decision and who made it, and a review date. Keep the reasoning field, because it is the part that gets asked about and the part nobody can reconstruct later.
Who is responsible for AI risk management?
Accountability sits with the business owner of each system, supported by risk, data protection and security, with a single executive accountable across the estate. Treating it as a technology function’s problem is the arrangement that fails most often, because the decisions that create the risk are commercial ones.
How often should the AI risk register be reviewed?
Set a routine cycle appropriate to the risk tier, with high-tier systems reviewed more frequently, and define the events that trigger a review regardless of the cycle: a new system, a material model change, a new purpose, an incident or a regulatory change. Reviews that depend on someone remembering do not happen.
Where to start this week
Take the AI system in your business with the highest consequence attached and score it on the three questions above: what a wrong output does, how many decisions it touches, and whether anyone would catch it. Write the reasoning down in a paragraph.
That paragraph is the first entry in your risk register, and it will tell you more about the state of your AI risk management than a template ever will, because the gaps show up in what you cannot answer.
Cybercy Group’s AI Governance and Enablement service covers AI strategy, use case identification, ethical AI framework development and performance monitoring. For a faster read on where you stand across cybersecurity, data protection and AI, the Cybercy+ Check gives you a scored assessment and a prioritised report.
