Describe the harm first

Two teams assess the same AI system, an agent that answers customer support calls. The first records “Impact: medium. Likelihood: low.” The second writes a few paragraphs. It describes a caller given confident but wrong troubleshooting steps, an older caller who can’t get past the agent to a person, and a distressed caller whose urgency the agent doesn’t recognise. Both have done an impact assessment. Only one of them will be useful.

ISO 42001 requires an AI system impact assessment (clause 6.1.4). It sits in the body of the standard, so unlike an Annex A control, you can’t exclude it. Most discussion is about how much is enough. I think that’s the wrong question.

Most assessments start from the rating, because the instinct is “we need to manage any high risks”. So the work becomes sorting: high, medium, low. That skips the reality of what could happen to someone and jumps straight to categorising abstract ideas. Description beats categorisation. A description of potential harm, saying who could be affected and how, is the evidence a rating should rest on, and it’s what everyone downstream can work with. The categories come after.

An assessment designed to minimise work won’t stack up for long. The risk register keeps accumulating, management reviews keep happening, and the system’s reach grows. An assessment that said “negligible” three years running while the system doubled its users will sit awkwardly next to all of it, and consistency across cycles is exactly what surveillance audits look at.

The bigger cost is the lost opportunity. A thoughtful assessment shapes the work. Each harm you describe suggests a design choice: a quick route to a person, a confidence threshold below which the agent hands over, a check for urgency. Controls get designed for a reason rather than picked from a list, and they tend to be implemented well, because the team knows what they’re for.

It also tells you what to monitor. If you’ve written down that the agent might miss a caller’s urgency, you know to measure missed escalations, not just call volume and handling time. Anyone who has built a system that makes judgements about people knows this. The validation that matters is designed around the harm you’re trying to prevent, and a single accuracy figure tells you very little.

This is where governance stops being paperwork and starts paying for itself. Done early, the impact assessment is a design tool. Done late and thin, it’s a liability that grows with every audit cycle.

A readiness assessment looks at whether your impact assessment is doing that work, and how to make it do more.