Create a Project Risk Register with AI: Example and Prompt

Create a project risk register with AI by describing the project context and asking for cause–event–impact statements. Review each proposed risk with the team, assign an owner and define a trigger or next action. Keep probability and impact ratings tied to your own scale rather than accepting invented percentages.

AI is useful for prompting overlooked questions. It cannot know a supplier's reliability, a team's capacity or the likelihood of a specific delay unless you provide relevant evidence. Treat its initial list as a set of hypotheses to review.

Distinguish a risk from an issue#

A risk is an uncertain event that could affect the objective. An issue has already occurred. “The approval owner may be unavailable next week” is a risk. “The approval owner is unavailable and the review is blocked” is a current issue.

Use the distinction to choose the next step. A risk may need prevention or contingency planning. An issue needs an active resolution plan. Do not leave an event in the risk register unchanged after it has happened.

Write cause, event and impact#

“Supplier risk” is too vague. A stronger statement is: “Because the integration depends on an external test account that has not been confirmed, access may arrive after the planned test window, delaying acceptance.” The cause, uncertain event and project effect are visible.

The following fictional register illustrates useful fields. Ratings would need your team's defined scale and evidence.

Copy this risk-register prompt#

Help create a project risk register from the context below.
Objective, deliverables and exclusions: [paste].
Milestones, dependencies, capacity and known constraints: [paste].
Existing risks/issues and rating scale: [paste].
Propose distinct cause-event-impact statements. For each, identify
supporting evidence or assumptions, owner role, early trigger,
preventive action, contingency and information needed to rate it.
Do not invent probabilities, costs, dates or assigned commitments.
Separate risks from issues and merge duplicates with an explanation.

Ask for a manageable set connected to the actual project. A hundred generic risks can make a register harder to use and obscure the few uncertainties that threaten the objective.

Rate risks with a defined scale#

If you use qualitative ratings, define what Low, Medium and High mean in your context. A delay that is minor for an internal improvement may be critical for an event with a fixed date. Use the project's objectives to interpret impact.

Avoid treating a model's numerical probability as measured evidence. If you have historical data or an expert assessment, record its source and limitations. If you do not, preserve the uncertainty and identify what would improve the estimate.

Make mitigation different from monitoring#

“Watch closely” does not reduce a risk by itself. A preventive action changes the cause or exposure, such as requesting access earlier or reducing dependence on one reviewer. A contingency describes what the team will do if the event occurs.

Monitoring still matters. Define an observable trigger that tells the owner when to act. “Access is unconfirmed at the agreed preparation checkpoint” is more actionable than “Supplier seems slow.” Use an actual checkpoint agreed by the team rather than an AI-generated date.

Avoid duplicate and disconnected risks#

Several entries may describe the same chain: late content, delayed design and delayed launch. Decide whether to track one underlying risk with several effects or separate risks with clear relationships. Do not add their impacts as though they were independent events.

Conversely, similar impacts can have different causes and owners. A review delay caused by missing evidence differs from one caused by unavailable decision authority. Keep the cause visible so the action addresses the right problem.

Review the register during delivery#

At each review, ask what changed, whether the trigger occurred and whether the action worked. Close risks that no longer apply with a reason. Promote materialized events to the issue process and update their effect on the forecast.

Use a short stakeholder summary for the most important changes. The full register can remain detailed, while the weekly report explains what the decision-maker needs to know or do.

Keep ownership explicit#

An owner is responsible for following the risk, not automatically for accepting every consequence. Confirm who can approve a contingency, spend additional resources or change the scope. AI can suggest roles, but actual responsibilities need agreement.

Use the project status report template to communicate material changes and the scope-of-work template to evaluate scope-related uncertainty. For a decision discussion, prepare a focused meeting agenda.

Common questions#

Can AI estimate the probability of a project delay?#

It can suggest factors to investigate, but a numerical estimate needs relevant data or an explicit expert assessment. Do not present a generated percentage as measured likelihood.

How many risks should the register contain?#

Track distinct uncertainties that could materially affect the objective. A concise register with owners and actions is usually more usable than a long generic list.

When should a risk become an issue?#

When the uncertain event has occurred, manage the resulting problem as an issue. Preserve the link to the original risk and update the forecast and response plan.

Download the working files#

Download the copyable prompt and download the illustrative worksheet (CSV). Replace example data with your own verified inputs; the worksheet is a planning aid.

Browse the English AI workflow guides for related tasks.