AI risk identification template: the risk canvas

Risks to people

Health, safety and fundamental rights. Inspired by prEN 18228 and ISO 14971.

Working draft · 3 Oct 2026

Download PDF · A4, two sides

Risks to your organisation’s objectives

Concerned about business objectives rather than harm to people? Inspired by ISO/IEC 23894.

Working draft · 3 Oct 2026

Download PDF · A4, two sides

No form or email address required.

Licensed under CC BY-NC-SA 4.0: use and adapt it with credit to Venturalítica, for non-commercial purposes, and share adaptations under the same licence.

The canvases are working drafts: we improve them with each session. The latest version is always at venturalitica.ai/canvas, and every PDF carries its date.

The technique: the bow tie

The canvas uses a bow tie to find, recognise and describe risks in a diagram. An event sits at the centre: something that should not happen. On the left, what could cause it. On the right, what happens next, through to harm.

Between them, record the existing controls: preventive controls on the causes side, mitigating controls on the consequences side. Under each control, “Fails if” captures the escalation factor: the vulnerability that could make it fail. Record evidence needed for later analysis in I; take ideas for new measures to J.

In an AI system, the central event is an output failure: a wrong prediction, classification or recommendation. Start there, because your system’s risks arise from what your model does. In the people version, each chain is read as a hazardous situation in ISO 14971: cause, failure, hazardous situation, harm and who is affected.

We add a distinction to the bow tie. ◐ Random failures are baseline model errors with no identified pattern. ● Systematic failures follow a pattern linked to a condition or a group of people: look for what causes them.

The format: a cooperative “what if?” session

Work as a team to uncover gaps in the system. Assume it has already failed, then ask questions in both directions: what if it excludes a suitable applicant? What happens to that person? What if the input data is wrong?

Each participant speaks for an affected party, so someone at the table always asks, “What happens to me?” You need people who understand the system’s inner workings and people who know those affected by its output.

Use the canvas when identifying risks, before the organisation analyses and evaluates them; revisit it when the system or its use changes. Keep the completed canvas and chain record sheets in the organisation’s risk management records, and take them to the owner named in J. This is an internal working record for that process.

Step by step

Fill in the top row: A, B and C. Intended use, foreseeable misuse and affected parties. Each participant speaks for an affected party.
Start at the centre: F. Write down an output failure and mark its type: ◐ random, the baseline error present in any model, or ● systematic, a failure that follows a pattern.
◐ expands to the right, G and H: the consequence, the harm and the existing control; record in I what data would show how often it happens. Keep the branch open until someone asks, “Is it concentrated in any group?”
● expands to the left, D and E: the condition or cause and the existing preventive control. Below each control, write what makes it fail.
Finish when no failure at the centre has an open branch. Then record in I what you do not know and take the canvas to J. Put each completed chain on a record sheet.

A risk identification session: CV screening

The back of the canvas sets the challenge with two chains already started. Here is how they look when completed. The system is fictional.

Working draft · 1 Oct 2026. The validation data in I is fictional.

The failure in chain 1 is a recognised concern: 88 % of employers using automated CV screening believe it excludes candidates capable of doing the job (Fuller, Raman et al., Hidden Workers: Untapped Talent, Harvard Business School and Accenture, 2021). This is what employers believe, not a measured failure rate.

A · Intended use

Ranks CVs for each vacancy and suggests the top twenty to Recruitment. A person decides whom to interview.

B · Foreseeable misuse

Recruitment only looks at the top twenty and discards the rest unread: the suggestion is used as the decision.

C · Affected parties

Applicants · people with career gaps due to caring or sick leave · the recruiter.

D · Causes◐ expands to the right

E · Existing controls (preventive)—

F · Output failure◐ random · chain 1Leaves a suitable applicant out of the top twenty.Is it concentrated in any group? Yes → chain 2

G · Existing controls (mitigating)For each vacancy, Recruitment opens ten randomly selected CVs from outside the shortlist.⚡ Fails if, under time pressure, the sample goes unread and the shortlist is trusted.

H · Consequences → harmThe applicant’s CV goes unread and they do not reach the interview.They miss out on a job they were suited to.

D · CausesThe model was trained on five years of hiring decisions, in which almost everyone hired had an uninterrupted career. Months out of work count against applicants.

E · Existing controls (preventive)No preventive control was identified in this session. The proposal to remove the variable goes to J.

F · Output failure● systematic · chain 2Downgrades applicants with a career gap of more than a year.

G · Existing controls (mitigating)The same random sample as in chain 1.⚡ Fails if the sample includes no CVs with career gaps.

H · Consequences → harmThe applicant drops off the shortlist because they took time out to care for someone.Unequal access to employment, affecting women in particular.

I · What we do not know

Known validation result: 7 % of suitable applicants are excluded. The 7 % rate is fictional, for this example. We still need to know how these cases are distributed by sex and career gaps, and which applicants appear in the sample Recruitment opens. This requires disaggregated validation data and a record of the sample for each vacancy.

J · Next steps

This session identifies risks. The organisation sets criteria, analyses, evaluates and treats risks through its risk management process.

Take to: the head of People · Date: ____

Analysis and evaluation take place there, using the evidence missing in I. Removing the career-gap variable is one treatment idea to take forward; consider whether other variables, such as the end date of the last job, reintroduce it.

Templates for these steps: venturalitica.ai/canvas.

Chain record sheets · one per hazardous situation.

Chain 1 · ◐ the suitable applicant left out

Hazardous situation: A suitable applicant is left off the shortlist and Recruitment does not open their CV.
Harm · to whom: Missing out on a job they were suited to · the applicant.
Existing control: A random sample of ten CVs for each vacancy.
Fails if: Time pressure means the sample goes unread.
What we do not know: The sample record for each vacancy is missing, so we do not know which CVs are opened.
Version: System v2 · session date.
Record revision: 1 · 1 Oct 2026

Chain 2 · ● the career gap

Hazardous situation: An applicant with a career gap of more than a year is ranked lower because of that gap.
Harm · to whom: Unequal access to employment · people who have cared for someone, particularly women.
Existing control: A random sample of ten CVs for each vacancy. No preventive control has been identified.
Fails if: The sample contains no CVs with career gaps, or goes unread.
What we do not know: Validation data by sex and career gaps, and the composition of the sample, are missing.
Version: System v2 · session date.
Record revision: 1 · 1 Oct 2026

A risk identification session: when to ask for a code at online checkout

This is the “Your organisation’s objectives” version of the canvas, used at a fictional payment processor. For each card purchase at an online shop, the system decides whether to require strong authentication from the cardholder or grant an exemption. Two people from the processor sit down, each speaking for an interested party.

Working draft · 2 Oct 2026. The company, system, people and cases are fictional. The exemption thresholds come from payment regulation (PSD2).

Marta · risk managementSpeaks for issuers. Handles fraud and the relationship with the supervisor; thinks in rates.

Iker · customer supportSpeaks for cardholders. Handles their complaints every day; thinks in cases.

Marta and Iker put themselves in the interested parties’ shoes. Those parties also speak: a cardholder, an online merchant and an issuer are consulted during the session. The session prepares for that consultation; it does not replace it.

A · Intended useScores the risk of each online payment and decides whether to exempt the cardholder from strong authentication or require it: two of three factors (something you know, have or are). Only while fraud remains below the thresholds: 0.13 % up to €100, 0.06 % up to €250, 0.01 % up to €500.

B · Foreseeable misuseThe threshold is raised to meet a business target, rather than on the basis of measured risk. The score is used for something other than authentication: rejecting a payment without allowing authentication, or blocking cards.

C · Interested partiesIssuers · cardholders · online merchants · the payment processor itself · the supervisor and card schemes.

Chain 1 ◐ random · expands to the right

Iker
What if we exempt a purchase that turns out to be fraud?
Marta
The issuer has let it through. Fraud insurance covers it, but it goes into the report to the supervisor. That is when the questions start.
Iker
The cardholder sees a charge they do not recognise. They complain, their card is cancelled and they get their money back. A refund does not restore their confidence in shopping online.
Cardholder
consulted
I was charged €249 by a website I had never heard of. Yes, I got it back. Since then, I only buy online when I have to.
Marta
That is one case. What worries me is the rate: if a band exceeds its threshold for two consecutive quarters, we lose the exemption for that band. Across all our issuers.
Issuer
consulted
If the exemption goes, our customers will be asked for a code on every purchase. You can explain that to them.
Iker
What control do we have today?
Marta
We monitor the trend using confirmed fraud: complaints and chargebacks. That is already in place; put it in G.
Iker
And those arrive when they arrive. Some people check their statement once a month, and a chargeback takes months.
Marta
If fraud is confirmed after the charge, the loss has already happened. In I, record what is still awaiting confirmation and how long it takes.

D · Causes◐: start on the right.

E · Existing controls (preventive)—

F · Output failureExempts a fraudulent payment.

G · Existing controls (mitigating)Trend monitoring using confirmed fraud.⚡ Fails if fraud is confirmed after the loss has occurred.

H · Effect on objectivesLosses and reporting to the supervisor. If the threshold is exceeded, the exemption is lost for all issuers.

Is it concentrated in any group… or category?

Iker
If it were just bad luck, it would be spread around. Is it?
Marta
No. It clusters at €99, €249 and €499, and at gift-card and electronics shops. They know the cut-offs and split the payments.
Iker
Then we have a pattern. Another chain, and this one opens towards the cause.

Chain 2 ● systematic · expands to the left

Marta
The underlying problem is that the cut-offs are fixed. They are in the regulation for anyone to read.
Iker
We cannot move those cut-offs. What about only exempting payments below our own changing limit, and asking a small random sample to authenticate? An idea for J.
Marta
Write it down for treatment. In E, we have not yet identified a preventive control against that pattern.
Iker
And take the merchants’ objection with it: asking for authentication can cost a sale. If we explore that idea, we also need to consider business pressure to raise the limit and shrink the sample.
Online merchant
consulted
When the code prompt appears, some baskets never come back. More so at Christmas. If you are going to ask at random, tell me how often.
Marta
What if the attack is already under way?
Iker
Another idea for J: look for runs at the same merchant, amounts just below the cut-off and cards in the same number range, and examine when to withdraw the exemption. What we have today is monitoring of confirmed fraud.
Marta
What if the attack is slow and spread across shops? There may be no run to spot. Record that limitation alongside the idea.
Iker
We are missing exempted payments and confirmed fraud by band, including cases still awaiting confirmation. That goes in I.
Marta
And H holds the consequence: if a band exceeds its threshold, we could lose the exemption for all issuers. We will analyse frequency later, once we have those data.

D · CausesThe cut-offs are fixed and public: payments are split to stay below them.

E · Existing controls (preventive)No preventive control against this pattern has been identified. A variable limit and random authentication checks go to J as ideas.

F · Output failureExempts a run of fraudulent payments split just below the thresholds.

G · Existing controls (mitigating)Trend monitoring using confirmed fraud.⚡ Fails if fraud is confirmed after the loss has occurred.

H · Effect on objectivesLosses and reporting to the supervisor. If the band exceeds its threshold, the exemption is lost for all issuers.

Chain 3 ● systematic · expands to the left

Iker
Now my concern. What if we always ask people who rarely shop online to authenticate?
Marta
Why would that happen?
Iker
Because the model has learnt that unusual means risky: a new phone, little history, an amount that card rarely pays. Someone who shops twice a year always looks unusual.
Marta
I want to know whether it happens to very frequent shoppers too. We are missing data at both ends; put that in I.
Iker
This is the situation I want on record: people with little history are asked to authenticate again and again, and may abandon the purchase.
Marta
To analyse it later, we need authentication requests and confirmed fraud by group. That goes in I.
Iker
How do you know the fraud rate for someone you always ask to authenticate?
Marta
Abandonment alone cannot tell us. We need to distinguish the reasons.
Iker
For example, not being able to find the code on their phone. I want to record what the cardholder tells us.
Cardholder
consulted
The code comes to my phone, but by the time I find it, it has expired. In the end I ask my daughter to buy things for me.
Marta
What about a reminder to try again? My bank sent me one yesterday. Let’s take it to J as a treatment idea.
Iker
Record the reminder’s own risk too: “Your payment did not go through, click here” is the first thing a fraudster would copy. Take the idea of a reminder without a payment link to J.

D · CausesThe model has learnt that unusual means risky.

E · Existing controls (preventive)No preventive control for this situation has been identified.

F · Output failurePossible failure: repeatedly asks people with little history to authenticate because of that condition.

G · Existing controls (mitigating)No mitigating control for abandonment has been identified. A reminder to try again goes to J as an idea.

H · Effect on objectivesAbandoned purchases, lost sales, complaints to issuers and customers switching cards.

Chain record sheets · one per chain.

Chain 1 · ◐ the exempted fraud

Situation: A fraudulent payment is exempted and the card is charged.
Effect · on which objective: Losses covered by insurance, reporting to the supervisor and, if the band exceeds its threshold, the exemption for all issuers.
Existing control: Monitoring confirmed fraud trends by band.
Fails if: Fraud is confirmed after the loss has occurred.
What we do not know: Exempted payments and fraud by band, cases awaiting confirmation and confirmation delays are missing.
Version: System v3 · session date.
Record revision: 1 · 2 Oct 2026

Chain 2 · ● the run below the cut-off

Situation: A run of fraudulent payments split just below a cut-off is exempted.
Effect · on which objective: If the band exceeds its threshold, the exemption is lost for all issuers.
Existing control: Monitoring confirmed fraud. No preventive control against the pattern has been identified.
Fails if: Fraud is confirmed after the loss has occurred.
What we do not know: Records by amount, merchant and payment time, and cases awaiting confirmation as fraud, are missing.
Version: System v3 · session date.
Record revision: 1 · 2 Oct 2026

Chain 3 · ● the group always asked to authenticate

Situation: People who rarely shop online are repeatedly asked to authenticate and may abandon the purchase.
Effect · on which objective: Abandoned purchases, lost sales, complaints to issuers and customers switching cards.
Existing control: No control for this situation has been identified; the reminder is an idea for J.
Fails if: A control’s vulnerability cannot be described until the control has been identified. That information is missing.
What we do not know: Authentication requests, code-entry errors, abandonments and their reasons by group are missing; abandonment alone does not distinguish fraud from difficulty authenticating.
Version: System v3 · session date.
Record revision: 1 · 2 Oct 2026

I · What we do not know

Exempted payments and fraud by band, cases awaiting confirmation and confirmation delays are missing. These are needed for later frequency analysis.
Records by amount, merchant and payment time are missing. These are needed to describe runs and distributed attacks.
Authentication requests, code-entry errors, abandonments and their reasons by group are missing. Abandonment alone does not distinguish fraud from difficulty authenticating. Existing controls for this situation also need to be identified.

J · Next steps

This session identifies risks. The organisation sets criteria, analyses, evaluates and treats risks through its risk management process.

Take to: the processor’s head of risk · Date: ____

Marta and Iker take the canvas and what the cardholder, merchant and issuer said. Analysis and evaluation take place there, using the evidence missing in I.

Treatment ideas: a variable internal limit and random authentication checks, with the merchant’s business objection; detecting runs, allowing for slow, distributed attacks; and a reminder to try again, considering the risk of impersonation. These are proposals to examine, not controls already in place.