Chaining risk factors into a risk scenario

The problem with a risk register entry like “hallucination”

Most AI risk registers have a line that reads something like “AI hallucination,” rated amber. I understand why. It is a real concern, and everyone knows what the label means.

But what are you supposed to do with that line?

You can't estimate how often it happens, because it doesn't describe an event. You can't assign a single owner, because hallucinations can affect customer service, legal, finance, engineering, and just about anywhere else AI is used. And when someone proposes a control, you have no clear way to tell whether the risk has changed.

The same problem shows up when the AI Risk Map is used as a risk register. A factor describes a condition that contributes to risk. It is not, by itself, a risk scenario you can analyze or measure.

Take AIRM-052:

“Fluent but incorrect output (hallucination), or summaries and transformations that change what the source said, accepted as reliable.”

That is a condition worth worrying about. It still leaves some basic questions unanswered: What is the system doing? Who relies on its output? What happens when the output is wrong? And what loss follows?

The Map now includes a condition type to help with the next step. Here's how to use it.

Three roles a risk factor can play

Each factor on the Map has a condition type. The type describes how the factor enters a scenario.

Cause

The first thing that goes wrong. If you fix it, the loss never starts.

Safeguard gap

A missing or weak control. The first failure can still happen, but a later step is stopped or the loss is reduced if the gap is fixed.

Amplifier

Makes losses happen more often, spread further, or land harder, without causing them.

These distinctions matter when you scope a scenario. “No guardrails on our chatbot” is not a scenario on its own. It is a condition that could allow a chatbot to do something harmful. You still need to say what the chatbot might do and what the resulting loss would be.

An amplifier plays a different role. It changes how often or how badly a loss happens, not whether the event can happen in the first place. Keep it in view for analysis, but don't make it a required link in the causal chain.

A few factors on the Map use a fourth type, outcome. Those factors name a loss event rather than a condition. One appears in the second example below. In most cases, the Map stops at the conditions on purpose. You name the outcome when you scope your scenario.

A five-step technique

Start with a cause and follow it to a specific loss. The chain should explain how the event could happen, not become a list of every control you can think of.

1. Start with a cause. Filter the workbook or CSV for cause in the Condition type column. Choose a factor that concerns you, then name the source: which system, used by whom?
2. Follow the output. Where does the failure land? That determines who owns the scenario and what kind of loss you're considering. One cause may lead to several scenarios.
3. Name the outcome in plain words. Describe an event you could count and estimate. If you need another “because” to explain it, you may have added another cause rather than named the outcome.
4. Add the safeguard gaps. Check the cause's see-also pointers. Then filter for safeguard gap in the domain that owns the outcome. Keep the one or two gaps that would actually change how often the event happens or how much it costs. The Map isn't a control catalog, and your scenario shouldn't turn into one.
5. Note any amplifier and write the sentence. Keep one outcome per scenario. If you find yourself joining two outcomes with “and,” you probably have two scenarios.

A statement template you can reuse

There is a risk that [source] will cause [outcome],
via [cause],
where [missing or weak safeguard],
resulting in [impact].

Amplifier: [factor]. Changes how often or how badly, not whether.

If you know FAIR, the structure will look familiar: asset, threat, and effect, with the reasons attached. The source is who or what acts. The outcome says what happened to what. The cause and safeguard gap explain why it could happen. Those are the details you'll need when someone asks what might reduce the risk.

Worked example: the chatbot that speaks for us

According to the tribunal's decision, in November 2022 Jake Moffatt asked Air Canada's website chatbot about bereavement fares after his grandmother died. The chatbot told him he could book at the regular fare and apply for the bereavement discount within 90 days. The airline's actual policy did not allow claims after travel. When Air Canada refused the refund, Moffatt took the matter to British Columbia's Civil Resolution Tribunal.

Air Canada argued, in part, that it could not be held liable for what its chatbot said. The tribunal disagreed. The chatbot was part of Air Canada's website, and the airline had not taken reasonable care to ensure the information was accurate. Air Canada was ordered to pay C$812.02 in damages, interest, and fees.¹

These damages may be modest, but the case gives us a concrete outcome to work backward from.

Public reporting tells us what the chatbot said. It does not tell us exactly why it said it or which safeguards were in place. That is normal for a public incident. We can still use the event to build a hypothetical scenario, but the cause and safeguard gaps below are my hypotheses, not findings about Air Canada's systems.

The chatbot chain, factor by factor

There are two judgment calls here.

First, the cause could instead be stale grounding data (AIRM-035): perhaps a policy page changed after the chatbot's sources were refreshed. That points to a different fix and changes how often you might expect the event. If both explanations seem plausible, write and estimate separate scenarios rather than combining them.

Second, AIRM-201 matters because the loss could grow with every customer who receives the same wrong answer before someone disables the feature. A tested fallback might not prevent the first incorrect answer, but it could limit the number of customers affected.

The scoped scenario

There is a risk that our customer-service chatbot will make unauthorized commitments to customers, via incorrect answers accepted as reliable (AIRM-052), where nothing constrains what it can say on our behalf (AIRM-199) and there is no tested way to shut it off quickly (AIRM-201), resulting in refunds, claims, and customer remediation.

Amplifier: AIRM-160. The same mistake made by a person on the phone might draw far less attention.

The statement gives the scenario an owner: the person responsible for the customer-service channel. It also points toward the data you'd need to estimate it, such as conversation volume, the frequency of incorrect answers, and the number of customers affected before the feature is disabled.

Same cause, different landing: the report we put our name on

In 2025, Deloitte Australia delivered an A$440,000 review to the Australian Department of Employment and Workplace Relations. University of Sydney researcher Chris Rudge found that the report cited papers that did not exist and quoted a Federal Court judgment that did not say what the report claimed. A corrected version disclosed the use of a generative AI tool. The department said the substance and recommendations were unchanged, and Deloitte agreed to repay the final installment of the contract. Deloitte said the matter had been resolved with the client and did not confirm whether AI caused the errors.²

Again, the public record doesn't establish the root cause. The scenario below is a hypothesis, but it describes a situation that could arise in a consulting firm, legal team, or internal audit function: AI drafts part of a work product, people review it, and the organization signs its name to the result (think of a SOC 2 report, for example).

The report chain, factor by factor

The difference from the chatbot example is where the output lands. It does not go directly to a customer. Our people review it first, so the safeguard that matters is not a guardrail on a live service. It is whether the review process still works when AI drafting outpaces it.

That changes the owner, too. This scenario belongs with whoever runs quality review on client deliverables, not the person who runs a customer-service channel. Automation bias (AIRM-099) can amplify the loss: polished prose and tidy footnotes may receive less scrutiny than a rough draft.

There is also an outcome-type factor that could be relevant: AIRM-091, “Harmful, misleading, or defamatory output driving decisions,” is the other half of a split pair with AIRM-052. If the department had acted on a misquoted judgment, that could be a separate scenario on the client's side. Our scenario ends when we issue the flawed deliverable with our name on it.

The scoped scenario

There is a risk that our AI-assisted drafting process will issue client deliverables with fabricated or misstated sources, via AI-drafted content accepted as reliable (AIRM-052), where human review cannot keep pace with what AI produces (AIRM-102), resulting in rework, fee refunds, and damage to client relationships.

Amplifiers: AIRM-099 and AIRM-160.

The two scenarios start with the same cause. They don't share the same owner, safeguard, or estimate. A single “hallucination” line on a register would hide those differences.

Where the chain branches

The cause can change, too. In December 2023, a user reported that he told a Chevrolet dealership's ChatGPT-powered website chatbot to agree with everything a customer said and end each answer by calling it a legally binding offer. The user then asked for a new Tahoe for $1. The chatbot agreed.³

That is an attempt to produce a similar kind of unauthorized commitment, but the cause is different. The AI Risk Map connects AIRM-199, the safeguard gap involving customer-facing content guardrails, with direct prompt injection (AIRM-071).

How often someone tries to manipulate a chatbot is a different question from how often it gives an incorrect answer on its own. The outcome was different as well. Reporting found no binding sale, and the dealership took the chatbot down.

I would keep these as separate scenarios that share a safeguard. Assessing them together would make it harder to estimate the frequency of either one.

Three scoping mistakes to watch for

• Scoring the safeguard gap. “No guardrails on customer-facing AI” is a condition that affects the scenarios those guardrails protect. Evaluate the scenarios, not the gap in the abstract.
• Skipping a step. Link a cause only to outcomes it can produce directly. If the chain requires another event in the middle, include that event in the scenario.
• Combining outcomes. “Resulting in a wrong refund and a data leak” is probably two scenarios. Each outcome may have a different owner and require different estimates.

From chain to sentence

The technique is useful because it gives you a repeatable way to move from a broad AI concern to a scenario that can be discussed and analyzed. Before condition types were on the Map, I was sorting causes from control gaps in my head each time I did this. Now I can use the type as a filter and spend more time on the judgment calls.

The same steps work with other causes on the Map. Start with the condition, follow the output, and scope one outcome at a time.

For a practical treatment of scenario scoping, I recommend Tony Martin-Vegue's From Heatmaps to Histograms: A Practical Guide to Cyber Risk Quantification (Apress, 2026), particularly Chapter 7, “Scoping Your Risk Assessment.” One useful test for a finished scenario is whether another person could picture the same event from your description.