How to Prompt AI to Write a Risk Register That Isn't Generic
A bare 'write a risk register' prompt produces generic filler. Here is how to feed AI project specifics and a scoring rubric so it produces one you can actually act on.
A risk register is only useful if someone can act on it: what could go wrong, how likely, how bad, and what you do about it. Ask AI to "write a risk register for my project" with nothing else and you get a list of risks so generic they would fit any project ever started: scope creep, budget overrun, key person leaves. True, and useless.
The fix is the same one that works for every structured business document: give the model the specifics of your actual project, and force a consistent scoring method instead of letting it eyeball severity.
Start With the Project, Not the Template
Give the model: what the project delivers and by when, the team involved and any known gaps (a contractor who has not worked with you before, a dependency on another team's roadmap), the budget or resource constraints, and anything that has already gone slightly wrong or nearly gone wrong. That last one matters more than people expect: near-misses are the highest-signal input for a risk register, because they are risks that have already partly materialized.
Force a Consistent Scoring Method
Left alone, a model will describe severity in prose ("this could be quite damaging") which cannot be sorted or compared. Specify the scoring method up front: likelihood and impact each on a 1-5 scale, multiplied for a risk score, with a one-line definition of what each number means so the model applies it consistently across every row rather than drifting.
Score | Likelihood meaning | Impact meaning |
|---|---|---|
1 | Rare, would be surprised if it happened | Negligible, absorbed without changing the plan |
3 | Plausible, has happened on similar projects | Moderate, causes a delay or budget adjustment |
5 | Expected without intervention | Severe, threatens the project's viability |
Paste a table like this into your prompt and require every risk to cite a likelihood and impact number against these definitions, not just a verbal severity. This is what turns the output into something you can actually sort and prioritize.
Require a Named Owner and a Real Mitigation, Not a Platitude
"Monitor closely" is not a mitigation, it is the absence of one. Instruct the model: every mitigation must be a specific action with a trigger condition, for example "if the contractor misses the week 3 milestone, escalate to the backup vendor already identified" rather than "communicate regularly with the contractor". If it cannot produce a specific action for a risk, that is useful information too, it means the risk needs a person to think about it further, not an AI-generated placeholder.
A Prompt Structure That Produces a Usable Register
Project summary: deliverable, deadline, team, budget, in 2-3 sentences.
Known weak points: anything already slightly wrong, any inexperienced team member, dependency, or vendor.
Scoring rubric: paste the likelihood/impact table above.
Instruction: list 8-12 risks specific to this project (not generic project risks), score each on likelihood x impact using the rubric, and give each a named mitigation with a trigger condition, not a general statement.
Review the Output for Two Failure Modes
Duplicate risks wearing different words: "key person unavailable" and "team member illness" are the same risk twice. Merge them and keep the sharper phrasing.
Risks that are really just restated project goals: "we might not finish on time" is a symptom, not a risk. Push the model to identify the cause behind it (an underspecified dependency, an untested integration) instead.
A good AI-assisted risk register still needs ten minutes of human review. What the prompting method above buys you is a first draft that already has real numbers, real specifics from your project, and mitigations you could actually execute, instead of a template you would have written faster yourself.
Keep It Alive, Not Just Written Once
A risk register written once at kickoff and never revisited is a compliance artifact, not a management tool. Re-run the same prompt structure with an updated "what has changed" section every few weeks: new near-misses, resolved risks, and shifted timelines. Ask the model explicitly to flag which previous risks have increased or decreased in score given the update, rather than just regenerating the list from scratch.
a framework for prompts that actually workprompting AI for a real SWOT analysisnegotiating a contract with an AI vendor
FAQ
What is the difference between a risk register and a general project plan?
A project plan describes what should happen. A risk register describes what could go wrong instead, how bad that would be, and what you would do about it. They are complementary documents, not substitutes for each other.
How many risks should a good risk register have?
Enough to cover the real exposure without becoming noise. Eight to fifteen well-specified risks with real mitigations are more useful than forty generic ones nobody will read past the first page.
Can AI assign realistic likelihood scores on its own?
Not reliably without your input. The model has no visibility into your team's actual track record. Give it context (has this kind of risk happened before, how often) and treat its likelihood scores as a starting point for discussion, not a final answer.
Should the risk register be shared with the client or kept internal?
That depends on your contract and relationship, but a version with sensitive internal risks removed (staffing concerns, budget pressure) shared with the client for the risks that affect their timeline is common practice, and asking the model to produce both an internal and client-facing version from the same source list is a reasonable follow-up prompt.
How did this land?
About the author
Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.
