Your Risk Register Is Already Dead. Here's the 15-Minute AI Workflow That Keeps It Alive.

Building the register was never the hard part. Keeping it describing the project you're actually running is.

Everyone builds the register. Almost nobody maintains it. The second problem is the one that gets you.

Six weeks into a payments migration project, I opened our risk register to prep for a steering meeting and realized I was reading fiction.

Top risk on the list: a third-party API dependency we'd fully resolved in week three. Likelihood: High. Status: Open. Meanwhile, the actual biggest threat to the project — our client's compliance lead had resigned, taking every approval relationship with her — appeared nowhere. The register had twenty-two rows, color-coded, properly owned, genuinely good work. On the day I built it.

It just described a project that no longer existed.

Nobody had touched it since. Not because we were lazy — because updating a risk register is the kind of task that never wins a fight for calendar space. It's important, never urgent, and it loses to whatever is on fire that morning. Every morning.

Here's the uncomfortable arithmetic: a register you built carefully and then froze isn't neutral. It's worse than nothing, because it looks authoritative. A steering committee reads twenty-two color-coded rows and concludes risk is handled. An empty template at least admits it doesn't know.

Building the register was never the hard part. Keeping it true is. And it turns out that's the part AI is genuinely built for — not because it understands your project, but because comparing two documents and flagging what doesn't match is exactly the kind of tedious, mechanical diff work a model does without getting bored in week four the way I do.

The workflow takes about fifteen minutes a week. Here's the whole thing.

Why registers die, specifically

It's worth being precise about the failure, because the fix follows from it.

A register doesn't die from neglect in general. It dies from three specific kinds of drift, and they compound quietly:

Stale risks. Things that were true in week one and got resolved, mitigated, or overtaken. They sit there at High/High, hogging attention, training everyone who reads the register to trust it a little less.

Missing risks. The project changed — a departure, a scope decision, a slipped dependency — and the register didn't hear about it. This is the dangerous one. The risk that actually lands is almost never one you rated wrong. It's one you never wrote down.

Risks that already happened. A risk that has occurred isn't a risk anymore — it's an issue, and it needs a response plan, not a likelihood score. Most registers I inherit have two or three of these: things everyone is actively firefighting that are still filed under "might happen." That's not a register, that's a time capsule.

Notice what all three have in common: none of them require judgment to detect. They require comparing what the register says against what the project is actually doing this week. Detection is a diff. Judgment comes after.

So let the model run the diff.

The workflow: the weekly register review

Tool: Claude or ChatGPT — anything that can read two documents side by side. I use Claude because it holds longer context without dropping rows. Takes: 15 minutes, once a week. I run it before the weekly status meeting, for reasons that will be obvious. Output: A short list of proposed register changes — you accept or reject each one.

Step 1 — Feed it the register and this week's reality

Two inputs. First, the current risk register — the actual table, pasted or attached. Second, whatever honestly describes this week: your status report, the standup notes, the decision log, even five candid sentences typed from memory. The messier and more current, the better.

One non-negotiable: if it's a real client project, strip names and figures before you paste. Public AI tools log what you give them.

Step 2 — Ask for a diff, not an opinion

This is where most people go wrong. They paste the register and ask "is this still accurate?" — and the model, eager to be useful, rewrites the whole thing, re-rates everything, and hands back a register you no longer recognize. Now you have to review every row, which is the exact task you were avoiding. You've automated nothing.

Ask for changes only. Here's the prompt I run:

``` You are a project risk specialist reviewing a live risk register against current project status.

Below are two documents: (1) the current risk register, (2) this week's project status notes.

Compare them and report ONLY the deltas, in four lists:

1. STALE — register risks that appear resolved, overtaken, or materially

less likely based on the status notes. Cite the line in the notes that suggests it.

1. ESCALATED — register risks that appear MORE likely or higher impact

than currently rated. Cite your evidence.

1. OCCURRED — register risks that have already happened and should be

reclassified as issues with a response owner.

1. NEW — risks implied by the status notes that are absent from the

register. For each: description (specific to this project), category, proposed likelihood and impact with one-line rationale.

Do not rewrite the register. Do not re-rate risks you have no evidence about. If the status notes don't mention something, say "no signal" — do not infer.

REGISTER: [paste] STATUS NOTES: [paste] ```

Watch-for: the model will occasionally flag a risk as stale just because the status notes don't mention it. Silence is not resolution. That's what the "no signal" instruction is for — but check anyway. The one risk nobody has mentioned in three weeks is sometimes the one quietly getting worse.

Step 3 — Rule on each delta yourself

The model proposes; you dispose. This is a five-minute pass, and it's the part that can't be delegated — not because the AI isn't capable, but because accepting a register change is a decision, and decisions need someone whose name is on them.

For each delta: accept, reject, or investigate. Anything you accept goes into the register with a date and your initials on the change. Anything filed under "investigate" becomes a question in that week's status meeting — which is why I run this workflow right before it. The diff hands me my agenda.

Step 4 — Once a month, run the adversarial pass

The weekly diff catches drift. It doesn't catch blind spots — things missing from both the register and the status notes, because nobody's writing them down anywhere. Once a month, I add one more question:

`` Based on everything you've seen about this project, what's one risk that appears in neither document — the kind of sponsor, political, or people risk that nobody puts in writing but that could quietly sink the project? ``

The model has no career riding on staying quiet, which makes it strangely good at this question. The compliance-lead resignation I mentioned at the start? A monthly pass like this one flagged "key-person dependency on client-side approvers" two projects later, and that time I had a succession conversation before the departure instead of after. Same category of risk. Very different Tuesday.

What changes when the register is alive

The fifteen minutes buys you something specific: a register that agrees with reality closely enough that people start using it again.

That sounds small. It isn't. On the project where I finally ran this properly, the register went from a document I opened before steering meetings to the document the steering meeting was run from. Stale risks came off, so the live ones got real attention. Two risks got caught escalating early enough to act. And when a risk finally did land, it was already reclassified as an issue with a named owner — so the meeting was about the response, not about why the register said "Medium likelihood" on something that had already happened.

None of that came from better risk analysis. It came from the register being current, which is a maintenance property, not an intelligence property. The AI didn't make me smarter about risk. It made the boring weekly comparison cheap enough that it actually happened.

The part you still own

Every row is still yours. The model detects drift; it doesn't decide what's true. It will propose deltas that are wrong — usually the "stale by silence" ones — and part of the fifteen minutes is catching those. If you find yourself accepting every proposed change without reading it, you haven't automated register maintenance. You've automated the fiction, faster.

But run honestly, the loop is simple: the model does the comparison you'll never make time for, and you do the judging you were always supposed to do. The register stays true. The steering committee reads something real.

Which — same as building the thing in the first place — is the entire job.

If you'd rather not build the first one yourself

I take a small number of these directly. You send me your project — a description or your charter, names and figures redacted — and in three business days you get back a populated register (15–25 risks scored and owner-assigned), a full RAID log, and a one-page "Top 5 to Watch." After that, the weekly loop above is yours to run. Details here.

This article originally appeared in AI in Plain English on Medium — read the original there, or follow new pieces on Substack.