AI risk management: how to identify, assess and control AI risk

The short answer: AI risk management is how you identify, assess, treat and monitor the risks created by AI systems you build, fine-tune or simply buy: biased outputs, leaked data, hallucinated answers, model drift and suppliers you cannot audit. It runs on the same machinery as any other risk discipline. A register, agreed criteria, named owners, controls and evidence. The certifiable standard for doing it properly is ISO/IEC 42001, which requires an AI risk assessment, an AI risk treatment process and an impact assessment for every AI system in scope.

Most organisations did not decide to adopt AI. It arrived. Marketing bought a copywriting tool on a card, engineering wired an LLM API into a support flow, and someone in finance is pasting management accounts into a chatbot. By the time a customer's security questionnaire asks which AI systems process their data, the honest answer is usually a shrug. That gap is the risk, and an ISO 27001 certificate on its own no longer closes it.

{{snapshot}}

AI risk management at a glance

• Scope covers build and buy. A model you trained and a SaaS tool with AI bolted on both belong on the register. Most of your exposure is bought, not built.
• ISO/IEC 42001 is the certifiable standard. Published in December 2023, it defines an AI management system (AIMS) with 38 Annex A controls across 9 control objectives.
• NIST AI RMF is voluntary guidance. Govern, Map, Measure, Manage gives you a shared vocabulary and no certificate at the end of it.
• The EU AI Act is law, and it is tiered. Prohibited, high-risk, limited or transparency-only, and minimal risk, with obligations phased in from 2025.
• The UK has no single AI act. Existing regulators apply existing law, so the ICO, FCA and MHRA are your practical rule-setters.

{{/snapshot}}

What actually counts as an AI risk?

An AI risk is anything that can go wrong because a system produces probabilistic output rather than deterministic output, or because of the data that shaped it. The spread is wider than most security teams expect.

• Model and output risk: hallucination, confidently wrong answers, and performance that decays as the world moves on from the training data.
• Data and privacy risk: training or prompt data you had no right to use, personal data pasted into a public tool, and no clear lawful basis or answer on automated decision-making under UK GDPR.
• Bias and fairness: outcomes that differ by protected characteristic in recruitment, credit, triage or pricing. In the UK that is Equality Act 2010 exposure before it is an AI story.
• Security: prompt injection, jailbreaks, model and data extraction, poisoned training sets, and agents holding more access than anyone signed off.
• Safety and harm: physical or clinical consequences wherever AI touches a patient, a vehicle or a vulnerable person.
• IP and copyright: who owns generated output, and whether generated code has quietly contaminated your repository.
• Transparency: whether you can explain a decision to a customer, an auditor or an employment tribunal.
• Third-party and concentration risk: your provider swaps the model under you, deprecates a version or has an outage. You inherit their risk without their controls.
• Operational and legal: shadow AI, unmanaged spend, and contractual promises about AI you cannot evidence.

Several of these are not new. Bias, privacy and supplier risk have sat on registers for years. What changed is how fast adoption outpaces sign-off. One API key can put six of those categories into production on a Tuesday afternoon, and no risk owner.

Why AI risk is not IT risk with a new label

Classic information security risk assumes a system does the same thing every time. You test it, sign it off, review it annually. AI breaks four of those assumptions at once.

Output is probabilistic. The same prompt can return a different answer tomorrow, so testing gives you a distribution rather than a pass mark. The controls have to be statistical: sampling, accuracy thresholds, human review where being wrong costs most.

Performance decays quietly. Nothing alerts when a model trained on last year's behaviour starts getting worse. Drift monitoring is a control with an owner and a cadence, not an engineering hobby.

Your supplier is opaque. You will not audit the training data of a frontier model, and asking politely will not change that. Assurance becomes contractual and evidential instead: model documentation, terms of use, region of processing, and deprecation notices.

Tooling sprawls faster than governance. Anyone with a company card can onboard an AI vendor before lunch. Shadow AI is the default state, which is why an accurate inventory beats a well-written policy.

ISO 42001, NIST AI RMF and the EU AI Act do different jobs

These three get bundled together in every board deck and should not be. One is a certifiable management system, one is voluntary guidance, one is law.

ISO 42001 turns intent into an auditable process. Clause 6.1 asks you to define AI risk criteria, assess risks against them and produce a treatment plan. Separately, the standard requires an AI system impact assessment, which looks outward at consequences for individuals and groups rather than inward at consequences for you. That distinction catches people out. ISO/IEC 23894 is the companion guidance, and our comparison of ISO 42001 and NIST AI RMF covers the overlap.

The NIST AI Risk Management Framework is free, readable and strong on the part standards tend to skip: how you actually measure whether an AI system is behaving. Use it for the Measure step, then hang the results on your ISO 42001 register.

The EU AI Act reaches UK organisations that place AI systems on the EU market or whose system output is used there. Obligations arrive in stages: bans on prohibited practices applied from February 2025, general-purpose AI model duties from August 2025, and most high-risk obligations from August 2026. Work out your tier early, because high-risk classification changes the size of the job considerably. We go deeper in how the EU AI Act and ISO 42001 fit together, and the free ISO 42001 vs EU AI Act tool gives you the side-by-side.

The UK took a different route. Rather than one AI statute, the pro-innovation approach hands supervision to existing regulators applying existing law, under principles covering safety, transparency, fairness, accountability and contestability. In practice, ICO guidance on AI and data protection sets the tone, sector regulators fill in the rest, and ISO 42001 is the cleanest way to show a buyer or a regulator that you run a real process.

An operating model that survives contact with reality

Framework choice matters less than whether the process actually runs. Six parts, in order.

1. Build the AI inventory first. Every model, tool, feature and vendor, with purpose, data used, owner and whether a human reviews the output. Expect the first pass to surface tools nobody in IT knew about.
2. Set AI risk criteria. Extend your likelihood and impact scales to cover harm to individuals, fairness and explainability. Without this, every AI risk scores as catastrophic or trivial depending on who is in the room.
3. Assess each system. Score the risks, and run the AI system impact assessment for anything touching people, money, health or employment. Our guide to running an AI risk assessment covers the mechanics.
4. Treat and assign. Pick controls from ISO 42001 Annex A, map them to risks, and give each a named owner and a date. Unowned controls are decoration.
5. Monitor. Drift, accuracy, incident volume, complaint themes, supplier change notices, with review frequency set by risk tier rather than calendar convenience.
6. Keep the evidence. Decisions, assessment records, approvals, test results, review dates. An auditor checks whether the process ran, not whether your policy reads well.

Wrap that in the governance layer described in our AI governance framework guide: policy, roles, an approval route for new AI use, and a way for staff to register a tool without feeling they are confessing to something.

You already own most of this if you run an ISMS

Organisations with ISO 27001 certification are further along than they think. ISO 42001 shares the same structure, clause numbering and appetite for documented decisions. Leadership, competence, internal audit, management review and corrective action all transfer. So does the risk methodology.

The practical move is one register, not two. Add AI systems as assets, extend the impact criteria to cover fairness and harm to individuals, add the AI-specific threats, and tag the AI rows so you can report on them separately. Running AI risk as a parallel process is how you end up with two registers that disagree about the same supplier.

That is the design behind Hicomply's risk management module. The register auto-populates risks from your assets, so adding an AI system pulls in the relevant risks instead of leaving someone to invent them from a blank row. Use the guided likelihood and impact assessment or your own methodology, then keep everything in one central register with audit-ready records.

HealthBoxHR, an HR and payroll SaaS holding sensitive employee data, started with nothing in place and reached ISO/IEC 27001:2022 certification in 12 weeks, with policy templates linked to controls and a dashboard showing status. The same discipline applied to AI turns good intentions into something an auditor can follow.

Where first attempts usually go wrong

Three failures show up repeatedly, and all are avoidable.

Registering models instead of use cases. The same model is low risk in a marketing draft and high risk in a shortlisting decision. Assess the use case.

Treating vendor AI as out of scope. If a supplier's AI feature processes your customer data, the risk is yours regardless of who trained the model. Your customers certainly see it that way.

Writing an AI policy and stopping. A policy nobody can map to a control or an owner is a document, not a control environment. Auditors want evidence.

For a structured start, the guide to ISO 42001 certification explains what the audit involves. Organisations already holding security certifications, including those on the route in ISO 27001 for managed service providers, find the extension easier because the habits exist.

{{snapshot}}

Hicomply's take

We have watched a lot of teams open their first AI risk workshop with a debate about frameworks. Wrong starting point. Spend two weeks building an honest inventory instead, because you cannot assess what you have not found, and the discovery exercise usually changes the shape of the programme. The mistake we see most often is running AI risk as a separate project with its own register and its own spreadsheet. Extend the ISMS you already have. One methodology, one register, AI systems tagged. That survives both audit and staff turnover.

{{/snapshot}}

Get your AI risk under control before a customer asks for the register

AI risk management stops being theoretical the moment a prospect's security team sends a questionnaire with an AI section, or a regulator asks how an automated decision was reached. The organisations that answer well have an inventory, a scored register and evidence that the process ran.

Start with the ISO 42001 checklist to see how much of the standard you already meet, then book a demo and we will show you how the register, impact assessments and evidence trail work on one platform. Bring your messiest AI use case. Those are the interesting ones.