What Belongs in an AI-Drafted Project Risk Register?
Last Updated: October 2026
An AI risk register is a project risk list that a tool drafts first and a person fixes later. It holds the same columns a handwritten one holds: the risk, the cause, the owner, and your planned response. The draft lands in seconds, and it reads well. It also tends to name the risks that each project of this type carries, which is the part worth catching before you send it out.
AI Smart Ventures has guided growing businesses through AI adoption on live project work, where the register is often the first thing someone hands to a model. AI Smart Ventures observes that these drafts come back complete and oddly familiar, naming scope creep and vendor delay on a job whose real risk was one key person and a date set by a trade event.
A register full of risks you manage anyway is worse than none. It passes review, it goes in the kickoff pack, and the team feels covered while the thing that will really derail the work sits nowhere on the page. That is what a common draft costs you.
Key Takeaways
- Ask for the odd ones, not a list: a format request pushes a model to its most common answer, so ask what differs from your last five jobs.
- Cut each row you manage anyway: if a standing process handles the risk, it belongs there, not in a weekly review.
- A row needs a trigger you would notice: name something you can see, with a date or a number.
- One named person owns each row: the owner watches the trigger and calls the response; a team name means no one.
All four come down to one swap. A model is strong at recall and weak at knowing which project is odd, and a register earns its slot only where it records the odd part. Treat the draft as a rough start, then spend your time on the four or five rows no one else would write.
Why does an AI risk register come back generic?
Because you asked for a table, and a fixed format pulls a model toward its most common answer. A 2026 study by Tapan Parikh, Structured Output Collapses Answer Diversity Across 44 Language Models, ran 31 open prompts. Telling a model to reply in JSON raised the top answer from 41 percent of replies to 64 percent. Distinct answers fell from 52 to 36. A risk register request is just that kind of request.
So you get the middle of the range back: scope creep, people not being free, vendor delay, vague scope. Those risks are real, and they are the ones your process was built to absorb. A Riskonnect survey of more than 200 risk and compliance leaders found 20 percent use AI to create risk registers, and 21 percent use it to surface risks no one had considered. The second use is the one the table format works against.
What should you cut from the first AI draft?
Cut each row your team would handle the same way whether or not it appeared on the page. A register is not a list of all that could go wrong, only a short list of what you would forget to watch. Common rows survive because deleting them feels careless, and they are why no one opens the file by week four. Keep a row only if it could change a decision this month.
The test is not whether the risk is real, because nearly all of them are. The test is whether the row does work: does it send someone to look at something they would miss? Four questions clear a draft fast, and they often strip out half of it. What is left is short enough that people read each line. That is the only state in which a register has any effect.
- Would you notice it without the row: if the risk shows up in numbers you read weekly, the numbers are the control.
- Does a process cover it now: a standing change-request route handles scope creep, so the row adds nothing.
- Can you name who sees it first: if no single person would spot it first, the row has no trigger.
- Is a decision attached this month: a risk with no near-term decision belongs on a parked list.
Which risks are unusual about this project?
Four kinds, and a model cannot know any of them. A client you have never worked for, which leaves your guesses about review speed untested. Work that runs through one person. Tech nobody on the team has used. A date set by someone outside the project, such as a conference, a board meeting or a client launch. Your real risk sits in those four, and all four belong to this job alone.
Pulling them out takes a different prompt. Work by Yuting Deng, Melanie Brucks and Olivier Toubia, Examining and Addressing Barriers to Diversity in LLM-Generated Ideas, published in February 2026, found that ideas from two groups of people vary more than ideas from two runs of a model. One cause is fixation: the model sticks to its own first answers. Their fix was better prompting, not a better tool. So tell it what is new here, then ask what that changes.
| What is odd here | What to ask | The row you want |
|---|---|---|
| First job for this client | How do they approve work? | Review runs long on unknown routes |
| One person holds a skill | What stops if they are out? | A single dependency, no backup |
| Tech new to the team | Where would a first-timer lose days? | Setup runs past the estimate |
| Date set from outside | Who set it, and what if we slip? | A deadline we cannot move |
What makes a risk register row worth keeping?
Five parts, and the trigger is the one an AI draft writes worst. The Association for Project Management advises describing risk events clearly, keeping causes, which are facts now, apart from events, which may happen, and from effects on the project. Add the two fields that make a row act: a trigger you would notice, and a named owner. A register, in APM’s words, documents risks, analysis and responses, and assigns clear ownership of actions.
Watch what a model puts in the trigger column. It writes “monitor closely” or “review weekly”, which asks no one to act on a set day. A real trigger is something you can see: the client has not returned the data file by the 14th, or the second test run still fails. The owner is a person, not a team, and the job is watching that trigger rather than doing the work. Agree the response before the trigger fires.
| Row field | What the draft says | What you write instead |
|---|---|---|
| Cause | “Project complexity” | A fact true today about this job |
| Risk event | “Delays may occur” | What might happen, and to what |
| Trigger | “Monitor closely” | An event with a date on it |
| Owner | “Project team” | One person who checks the trigger |
| Response | “Mitigate as needed” | The step that runs when it fires |
Rewriting triggers and owners takes about half an hour, and it is the half that changes behavior. AI Training works on the registers your team keeps now, so AI literacy grows on live projects rather than a sample file.
How do you keep the register alive, not filed?
Give it a standing slot and three questions: what fired, what closed, what is new. Ten minutes inside a meeting you already hold beats a separate review no one protects. Most registers die because they were written for the kickoff pack, where a full page reads as care. Kaplan and Mikes argued in Harvard Business Review that risk management is too often treated as a compliance issue, solved by drawing up rules. A filed register is that failure on one page.
Keep it small enough to read out loud. Eight to twelve live rows suits most projects, and past that people skim. Closing a row counts as much as adding one, because a list that only grows stops being a decision tool. Generic AI consultants will offer you a bigger template here. The better move is a shorter register and more time on triggers, which is where change management and capability building quietly happen.
- Attach it to a meeting you never miss: a review with its own invite gets moved; one inside the weekly call does not.
- Close rows out loud: name the risk that has gone and why, so the list shrinks as the project settles.
- Re-ask the odd question monthly: what is new since last month, then draft only rows that answer it.
- Keep one owner per row: when the owner changes, say so, because an unwatched trigger is no row.
Frequently Asked Questions
Is there a best AI tool for drafting a risk list?
No single tool wins; the draft matters less than where the register lives. A general assistant writes a usable first pass from your notes. Risk tools add workflow and history. The same Riskonnect survey found 53 percent of risk leaders rely only or mostly on spreadsheets, while just 21 percent strongly trust their own risk data. Pick the place your team opens each week.
How much of a register should AI actually write?
Treat it as most of the typing and none of the judgment. People quote a 30 percent rule for AI work, but no fixed split survives a real project: the share depends on how odd the job is. A model gives you the common rows. You supply the odd ones, each trigger and each owner. If more than a third of the draft survives untouched, you kept common rows.
Are project risks the same as the risks of using AI?
No, and merging them weakens both. MIT’s AI Risk Repository reached over 1,700 coded risks from 74 frameworks in its version 4, released in December 2025. That is a list of harms AI systems can cause. A project risk register names what could stop this project. If the project is an AI rollout you may need both, kept apart.
What does a 20-minute risk review look like?
Three questions, in order, with the register open. Which triggers fired since last time, and what did the owner do? Which rows can close today? What is new about the project that is not on the page yet? Owners answer for their own rows, so no one writes a report. Ten to twelve rows fit easily into twenty minutes, the real reason to keep it short.
How many rows belong on a project risk register?
Fewer than a draft gives you. Eight to twelve live rows suits a project of a few months, because that is about what a group can discuss in one sitting without skimming. A 40-row register is a filing job: no one reads to the bottom, and the rows that matter sit beside rows that never will. Park the real but distant risks on a second list.
Can AI invent a risk that is not really there?
Yes, and it reads just like the real rows beside it. A model fills gaps with likely detail in the same steady tone, so an invented link or a vendor limit no one mentioned slides into your table. Check each row against a fact somebody can point to: an email, a contract clause, a named person, a system you use. Delete anything you cannot trace.
What do you do about a risk nobody can control?
Put it on the register anyway, then write a response you can control. A date set by an outside party is the common case, and the honest row does not say “escalate”. It names what you will cut, reorder or hand off if the date holds and the work slips. Risks you cannot control still need an owner, because someone must say when the trigger fires.
How do we get started with an AI risk register?
Take the register on your current project and run two passes. First delete each row your process handles now. Then add rows for whatever is odd about this project, each with a trigger and an owner. Most teams finish both passes in under an hour and lose half the draft. Schedule a consultation to build that edit pass into how your team runs projects.
Executive Summary
An AI risk register is a project risk list drafted by a tool and corrected by a person. It comes back common because a format request pushes a model to its most likely answer: in one 2026 study of 44 models the top answer rose from 41 to 64 percent of replies. So the work is editing, not writing. Delete the risks your process absorbs anyway, add the four odd conditions a model cannot know, and give each kept row a trigger and an owner.
What Should You Do Next?
Open the risk register on your current project this week. Delete each row a standing process covers, then add rows for what is unique here: a first-time client, a one-person gap, new tech, a date you cannot move. Give each kept row a dated trigger and an owner, then book a ten-minute review inside a meeting that already exists.
AI Smart Ventures offers AI Training for growing businesses that want AI upskilling to land in the project documents their teams keep. Schedule a consultation to turn an AI-drafted register into one your project really uses.
People Also Read
- AI Head of Innovation Owner-Operated Bets: 2026 Guide
- AI Owner-Operator Pricing Decisions Trust Override: 2026 Guide
About the Author
Nicole A. Donnelly is the Founder of AI Smart Ventures and an AI Adoption Specialist with 20 years of experience as a founder and CEO and over a decade leading AI adoption initiatives. She helps businesses integrate artificial intelligence with clarity and confidence, driving innovation and sustainable growth. Nicole has trained over 20,217 professionals in Applied AI, delivered 624 workshops, and worked with close to 1,000 organizations across diverse industries.
Expertise: AI Transformation, AI Strategy, AI Implementation, AI Adoption, Applied AI, Marketing, Business Operations
Disclaimer: This content is for informational purposes only and does not constitute professional business or technology advice. Results vary based on industry, existing systems and implementation commitment. Contact AI Smart Ventures for a consultation regarding your specific situation.
