Hello Hello,
Before we ask AI to score a risk, we need to ask a more basic question:
Do we have a clear risk to score in the first place?
Most risk registers do not start with poor judgement. They start with poor raw material.
An incident review sits in one place. A vulnerability trend sits in another. A policy exception is in a ticket. An audit observation is in a spreadsheet. A project team has noticed a concern but does not yet have the language to explain it as a business risk.
By the time all of this reaches the risk register, the story can be incomplete, overly technical, or too vague for anyone to act on.
That is where the first useful AI use case in Risk Management begins.
Not with an automated score.
With risk identification and framing.
THE ONE THING TO TAKE AWAY
AI can help bring scattered evidence into a clear candidate risk story. It should not decide whether the organisation accepts the risk, how it is scored, or what action is taken.
THE KEY POINTS
Start with evidence, not a score. A score without a well-framed risk statement can create false certainty.
Use AI to find the thread. It can group related signals, surface recurring themes, and turn technical detail into a first draft that a risk owner can challenge.
Make unknowns visible. The most useful output is not only a draft. It is also the questions that still need human answers.
Keep the decision with the practitioner. A candidate risk is a starting point for assessment, not a decision or a register entry by default.
FROM SCATTERED SIGNALS TO A CLEAR RISK NARRATIVE
A risk is rarely handed to GRC in a neat, ready-to-assess format.
It might start with an incident. Or a run of similar vulnerabilities. Or a recurring policy exception. Or an audit finding that keeps resurfacing. On their own, those things may look like separate operational issues.
The job is to understand whether they are evidence of the same underlying exposure.
That is a human judgement. But it does not have to start from a blank page every time.
An AI-enabled workflow can take approved inputs and produce a risk narrative in a structure such as:
Risk Narrative: Because [condition or control weakness], there is a risk that [threat or failure event] could lead to [business impact / [Threat] impacts [Asset] via [Method], causing [Effect].
Evidence considered: [Relevant incidents, audit observations, vulnerability themes, policy exception, control weakness, tickets, or other source material.]
What is still unknown: [the questions the risk owner or subject-matter expert needs to answer].
Suggested next step: [validate, assess, combine with an existing risk, or close as a local issue].
Notice what the workflow is not doing.
It is not deciding the likelihood. It is not assigning an impact rating. It is not accepting a risk. It is not creating a register record without review.
It is helping the practitioner get to the right conversation faster.
Another useful way to make a risk narrative consistent is the FAIR TAME methodology.
TAME gives practitioners a simple grammar for framing a complete risk scenario:
Threat impacts Asset via Method, causing Effect.
Threat: Who or what could cause harm? For example, cybercriminals, insiders, third parties, or an environmental event.
Asset: What business-critical data, service, system, capability, or resource could be affected?
Method: How could the harm occur? For example, phishing, a vulnerability exploit, a process failure, or a supply-chain compromise.
Effect: What is the business consequence? For example, productivity loss, response costs, regulatory exposure, reputational damage, or loss of competitive advantage.
If one of these components is missing, that does not mean there is no risk. It means the scenario is not fully framed yet.
That is where AI can help.
WHY THIS SHOULD COME BEFORE RISK SCORING
It is tempting to begin with AI risk scoring because a score looks measurable and easy to automate.
But a score is only as useful as the story and evidence underneath it.
If the input is vague, the output will be a precise-looking number with very little meaning. If the input is incomplete, the model may fill gaps with assumptions. And if the risk statement does not explain the business consequence, senior stakeholders cannot make a useful decision from the rating alone.
This is why the first AI capability should be to improve the quality of the starting point.
If you read my earlier issue, The Extreme Sport of Risk Management, you will recognise this as the storytelling problem. A risk only becomes useful when the reader understands what could happen, why it matters, and what decision is needed.
And if you read Before the Use Case: How to Build AI Workflows That Actually Work in GRC, this is what the operating framework looks like in a real Risk Management workflow.
IN PRACTICE
Here is how I would design a narrow risk-identification and framing workflow.
Context: Your risk taxonomy, risk statement format, risk appetite, assessment methodology, existing risk register, and the language your organisation uses for business impact.
Connections: Only the approved sources where relevant evidence lives, such as incident reviews, vulnerability trends, audit findings, policy exceptions, change tickets, or project updates.
Capability: Group related signals, draft a candidate risk narrative, cite the evidence considered, identify missing information, and prepare focused questions for the risk owner.
Cadence: Run it on demand before an assessment workshop, during a major change review, or when a GRC practitioner is investigating a recurring theme. A human reviews the output before it moves anywhere else.
The key is to keep the job narrow.
You are not building a tool to manage risk. You are building a tool to help you frame a potential risk well.
A STARTING PROMPT
You can use this in an approved ChatGPT, Claude, or enterprise AI environment after adapting it to your organisation's risk methodology and data boundaries.
You are supporting a GRC practitioner with early-stage risk identification and framing.
Use only the material provided or the approved connected sources. Do not assume facts that are not evidenced.
Review the inputs and identify any themes that may indicate a candidate risk. For each candidate risk, provide:
A concise risk statement in this format: [Threat] impacts [Asset] via [Method], causing [Effect].
The evidence that supports the statement, including the source name.
Information that is missing or uncertain.
Up to five plain-English questions for the risk owner.
A suggested next step: validate, assess, combine with an existing risk, or treat as a local issue.
Do not assign a final risk score, recommend risk acceptance, or present conclusions as definitive. This is a draft for human review.
KEY QUESTIONS
Before trying this, ask:
Is the existing risk methodology documented clearly enough for the AI to follow?
Are the source materials approved for use in the chosen AI environment?
Can the workflow show the evidence behind each candidate risk, rather than giving a conclusion with no trail?
Who is responsible for deciding whether the candidate risk enters the register?
What should happen when the output identifies uncertainty rather than a clear risk?
ONE IMPORTANT POINT BEFORE YOU BUILD
The aim is not to create a faster path from raw notes to a number in a risk matrix.
The aim is to create a better path from evidence to understanding.
A strong workflow should make it easier to see what is known, what is not known, and what decision is actually being asked of the business.
AI can help with the first draft. The GRC practitioner, risk owner, and decision-maker still own the risk story.
NEXT IN THE SERIES
Next, I will share a real case study: I Built a Security Risk Assessment Toolkit. Here Is Exactly How.
It shows what happens when a narrow framing capability is connected to a complete, human-reviewed assessment workflow, from Jira intake to reassessment.
Until next time,
Princess David Okoro, CISM
Author, The AI GRC Desk
Find me on LinkedIn: Princess David Okoro
Sign up to the AI GRC Desk Newsletter: https://aigrcdesk.com/subscribe
