Adapting your risk assessment for AI systems

Your risk methodology assumes systems fail in ways you can detect. AI systems degrade quietly, behave differently on inputs you never tested, and can cause harm while operating exactly as designed. That does not require a separate methodology - but it does require extending the one you have.

Three things that genuinely change

1. Who bears the impact

Traditional security risk assesses harm to the organisation - downtime, breach cost, penalties. AI governance asks about harm to individuals and society: someone wrongly refused credit, a candidate screened out unfairly, incorrect advice acted upon. ISO 42001 makes this explicit through AI system impact assessment, and the EU AI Act builds obligations around it.

Practically, add an impact dimension covering effects on people, alongside your existing organisational impact scale.

2. Failure is probabilistic, not binary

A server is up or down. A model is right most of the time, in ways that vary by input. "Availability" is the wrong frame; accuracy, consistency and degradation are the right ones. Risk statements need to reflect rates rather than events.

3. The system changes without you changing it

Model drift, provider upgrades and shifting input distributions mean today's assessment may not describe next quarter's behaviour. AI risks need shorter review cycles than most infrastructure risks - and a trigger on provider model changes.

Risk categories to add

• Accuracy and reliability - wrong output relied upon.
• Bias and fairness - systematically worse outcomes for a group.
• Transparency - inability to explain a decision that affects someone.
• Data provenance - training or grounding data you lacked rights to use.
• Privacy - personal data in prompts, outputs or training sets.
• Security of the model itself - prompt injection, data exfiltration through outputs, model or supply-chain compromise.
• Over-reliance - humans rubber-stamping AI output, which is the most common failure of "human in the loop" controls.
• Drift - performance decaying silently over time.
• Vendor and model dependency - concentration on a provider that can change or withdraw the model.

Scoring: keep your scale, add a dimension

Do not invent a parallel scoring system - it fragments your register and confuses governance. Keep likelihood and impact as they are, and add:

• Impact on individuals (1-5), scored alongside organisational impact, taking the higher of the two to drive treatment.
• Autonomy - is output advisory, human-approved, or acted on automatically? This multiplies everything else.
• Reversibility - can a wrong outcome be undone, and how quickly?

Autonomy is the dimension people underweight. The same model recommending an action and taking it are entirely different risks, even though the model is identical.

Triage by use case, not by technology

Not every AI system needs deep assessment. A practical tiering:

• Low - internal productivity on non-sensitive data, output always reviewed. Light-touch.
• Medium - customer-facing or handling confidential data, human-reviewed. Standard assessment.
• High - influences decisions about people, or acts autonomously. Full impact assessment, documented human oversight, monitoring and periodic testing.

Controls that actually mitigate

• Grounding output in retrieved evidence with citations.
• Meaningful human review - with authority and time to disagree, not a checkbox.
• Monitoring accuracy in production and alerting on degradation.
• Input and output filtering for sensitive data.
• Model version pinning and change notification.
• Documented fallback when the AI is unavailable or untrusted.
• Logging of model, prompt, sources and approver for anything that becomes a record.

Key takeaways

• Add impact on individuals to your existing impact scale.
• Autonomy and reversibility change the risk more than the model does.
• Tier by use case; not every AI system needs deep assessment.
• Keep AI risks in one register with everything else.