How to Build a Project Risk Register With AI in 20 Minutes

What used to take me hours the night before a steering meeting — and how I do it now.

M. Mohammad · June 13, 2026

Hub-original. This article was published only on Substack. It has never appeared on Medium. On the hub it is canonical, with no "read the original" link.

Slug: /blog/how-to-build-a-project-risk-register-with-ai-in-20-minutes/ Meta description: A step-by-step workflow for building a project risk register with AI in about 20 minutes — including the prompts and the one move most people skip. Sitemap priority: 0.9

It was 11pm the night before a steering committee, and I was looking at an empty risk register.

You know the one. Eight columns, no rows, a cursor blinking at you like it knows you've been avoiding it. The project was a payments migration — twelve weeks, four teams, a regulator watching every move. And somewhere along the way, "we'll do the risk assessment properly later" had quietly turned into "later is tonight, and it's late."

For years I did these by hand. Stare at the template, dig through memory for risks, then lie awake wondering which obvious one I'd forgotten — the one that surfaces in week six and makes you look like you weren't paying attention. It took hours. And the register was only ever as good as whatever I happened to remember at 11pm, which, at 11pm, isn't much.

These days the same task takes about twenty minutes. The strange part is that the register comes out better — not because the AI understands my project, but because it never gets tired, and it never skips the category I always skip when I do.

Here's how I do it now.

First, a warning, because most people do this badly

If you open Claude or ChatGPT and type "give me a risk register for a software project," you'll get fifteen risks that apply to every project ever run. Scope creep. Resource constraints. Technical debt. All true. All useless. That's not a risk register — it's a fortune cookie.

The thing that makes the difference is boring and it's this: context, then structure. Tell the AI exactly what your project is — the real one, with the specific mess in it — and then make it reason through risk by category instead of free-associating. That's the whole game. Everything below is just those two ideas, applied.

Set the role, then hand over the real project

Before I ask for anything, I tell the AI who it's supposed to be. One short paragraph: a senior PM, fifteen years in regulated software and migration work, the kind who thinks about risk by category and doesn't pad a list with filler. It sounds almost too simple to matter. It matters more than anything else I do.

Then I give it the actual project — and I mean the actual one. Not "a software migration." This: moving a fintech client's payments platform off on-premise hardware onto the cloud, twelve weeks, with a backend team, QA, infrastructure, and a client-side compliance team I don't control. A regulator who has to sign off before go-live. A system that can't go dark during business hours. Nine people, two of them new this quarter.

Read that back. The risks are in those details — the dependency I don't own, the regulator, the two people still finding their feet. A generic prompt never sees any of it, because you never told it. So tell it.

Make it work category by category

This is the move that separates a sharp register from a list, so don't skip it. I don't ask for "risks." I ask it to walk through the categories one at a time — technical, schedule, people, external dependencies, compliance, operational — and for each one, find the risks specific to this project. Risk statement, likelihood, impact, a real mitigation. As a table. And explicitly: nothing generic, nothing that isn't tied to the details I just gave you.

The categories are the engine. They're what stops the thing from handing me three versions of "scope creep" while quietly forgetting that my compliance team reports to someone who isn't me.

Then argue with it

The first draft is where most people stop. It's the worst place to stop.

So I push back. Which three risks did you under-rate? And — this is the one that earns its keep — what's a risk nobody on this project would say out loud in a meeting, but that could sink the whole thing?

Because the risks that actually kill projects are rarely technical. They're the sponsor who's privately checked out. The lead who's three interviews into leaving. The things everyone senses and nobody writes down. A well-aimed AI will name them precisely because it has no career riding on staying quiet. That's not a small advantage.

The prompts, if you want to skip straight to them

Two prompts. The first builds the register; the second is the one that earns its keep.

Tool: both are written for Claude — it reads your project and reasons through risk better than anything else I use. Swap everything in [brackets] for your real project. If it's a real client, replace names and figures before you paste — public AI tools log what you give them.

Prompt 1 — Build the register

Paste your real project documents into the placeholder at the end — charter, requirements summary, project plan. No documents handy? Drop in a few honest sentences describing the project instead. The more specific the input, the sharper the register.

You are a risk management specialist with experience in [SaaS / MedTech /
enterprise software / data platform] projects.

I'm going to provide my project documentation. Read it carefully, then
identify all material risks across exactly these eight categories:
Technical, Resource, Stakeholder, Schedule, Budget, Compliance, External,
and Data/Security.

For each risk, provide: Risk ID (RM-01, RM-02, etc.), Description (two
sentences — specific to this project, not generic), Category, Likelihood
(High/Med/Low with one sentence rationale), Impact (High/Med/Low with one
sentence rationale), Risk Score (multiply Likelihood × Impact using H=3,
M=2, L=1), Recommended Owner (by role), Initial Mitigation Action
(specific, not "monitor closely").

Format as a table. Do not generate generic risks — every risk must be
specific to the documentation I'm providing.

Here is the project documentation: [paste charter, requirements summary,
project plan]

Watch for: Claude sometimes generates risks that are already being mitigated by plans you've described in the documentation. Review each risk against your existing mitigation actions before adding to the live register.

Prompt 2 — Run this on the register from Prompt 1

The first draft is where most people stop. It's the worst place to stop. Run this on the register Prompt 1 gave you.

Now pressure-test your own register.

1. Which three risks did you under-rate on likelihood or impact, and why?
2. What's one risk nobody on this project would say out loud in a meeting
   — a sponsor, political, or people risk — that could quietly sink the
   whole thing?

Re-rate or add accordingly, then tell me the single risk you'd watch most
closely in the first two weeks.

Then do the part the AI can't: read every row, delete whatever isn't true for your project, and put a name and a review date next to each risk you keep. A register without owners isn't a register — it's a diary with good formatting.

You still own every row

Here's the part the twenty-minute version doesn't replace: judgment. The AI drafts. You decide. I read every line and ask the only question that matters — is this true for my project, and does each live risk have a name next to it and a date to review it?

That night, twenty minutes after the blank template, I had around twenty real risks — categorized, owned, and including two I'd genuinely missed. I walked into the steering meeting able to say "here's what could go wrong, and here's what we're doing about each one."

Which, when you strip away the job title, is the entire job.

The AI didn't think for me. It just made sure I didn't skip a category at 11pm, half-asleep, hoping for the best. After enough 11pms, that turns out to be worth a lot.