Describe the event and consequence, not only “AI risk”.

Connect the risk to a use

Identify the workflow, decision, information and systems involved. A general concern about inaccurate output becomes useful when tied to a consequence, such as a customer receiving incorrect service information.

Keep the scenario specific enough to assign ownership and test a control.

Examine the path to harm

What would cause the event? Would a person detect it? How far could it spread before intervention? Can the outcome be corrected?

Likelihood and severity need evidence and context. Record uncertainty rather than applying precise numbers to weak information.

Ask what each control does

A policy may define permitted use. An access restriction may limit exposure. Evaluation may identify a failure pattern. Human review may prevent an incorrect action, provided it is meaningful.

These controls address different parts of the scenario. A list of controls is not proof that all risks are managed.

Consider dependencies

Vendors, information sources, internal experts and integrations can become critical to operation. Establish how the business would continue if one became unavailable or unsuitable.

A fallback needs capacity and knowledge, not only a document saying “manual process”.

Distinguish treatment and acceptance

Management may remove the use, reduce the exposure, improve controls or accept a residual risk through authorised governance. Some requirements cannot be waived by risk appetite.

Qualified specialists should assess applicable obligations and technical questions.

Report the decision required

Show the scenario, evidence, current controls, remaining uncertainty, owner and proposed action. Escalate material incidents or changes through the appropriate process rather than waiting for a routine reporting date.

Use the AI risk register template and read board governance.