How to manage programme risks with AI

Define risk ownership and cadence

Set programme objectives, risk categories, appetite or tolerance language, escalation rules, review cadence, and decision rights. HM Treasury’s Orange Book establishes risk-management principles for UK government organizations. Its core discipline is useful elsewhere: risk management should connect to objectives, governance, assurance, and decisions.

Rewrite vague risks as scenarios

Use: “Because [cause], [uncertain event] may occur, leading to [impact on objective].” “Poor adoption” is a label; “Because manager support and scheduled practice are not in place, participants may not apply the new workflow, limiting the programme’s evidence objective” is testable.

Worked synthetic risk register

| Risk | Trigger | Existing control evidence | Action | Owner | Residual view | | --- | --- | --- | --- | --- | --- | | Scenario materials may miss approval because source owners are unavailable, delaying pilot start | Two source reviews overdue by five days | Weekly review log | Add alternate approver by 15 Sep | Programme lead | Medium, low confidence | | Assessment guidance may imply an employment decision, creating product-boundary risk | Prohibited phrase found in review | Automated claim check plus human review | Correct copy and test corpus | Content owner | Low if controls operate |

The risks, dates, and ratings are synthetic. The second control’s existence does not prove every future draft is safe.

Separate controls, actions, and evidence

An existing control operates now. A mitigation action changes likelihood or impact later. An assurance activity checks whether either is true. Store the evidence artifact and review date for each. “Team monitors risk” is not a control unless monitoring has a defined signal and response.

Use triggers and aging

Every material risk needs an observable trigger or leading indicator. Track action due dates, overdue age, last evidence date, and next decision. Ask AI to flag risks with no owner, circular wording, expired evidence, permanently unchanged ratings, or actions that merely restate the risk.

Review residual risk honestly

Assess exposure after evidenced controls, not after planned work. State confidence and dependencies. If control operation is unknown, the residual rating should reflect that uncertainty rather than assuming success.

Run a monthly challenge

Invite delivery, finance, security, operations, and affected users as relevant. Review changes in objectives, emerging dependencies, near misses, closed risks, and risks that should be merged or split. Test whether the current owner can authorize the response.

Verification checklist

Confirm each risk affects an objective; cause, event, and impact are distinct; triggers are observable; owners have authority; actions have dates; control evidence is current; residual ratings exclude unfinished actions; overdue work escalates; closed risks retain closure evidence; and programme decisions cite the register.

Review cadence should follow exposure and trigger timing, not a uniform calendar ritual. A rapidly approaching dependency deserves different monitoring from a stable, low-exposure uncertainty. When a trigger fires, preserve the prior assessment, record the decision taken, and update linked milestones. This provides a usable history of how the programme responded instead of overwriting yesterday’s view with today’s rating. Link any changed exposure to the decision record.

Sources and claim map

The programme, risks, controls, and ratings are synthetic. This resource does not assert risk elimination, control effectiveness, or successful programme delivery.

• HM Treasury, Orange Book: supports objective-linked risk-management principles, governance, and assurance in UK government organizations.
• Infrastructure and Projects Authority, Project Routemap: supports early examination of project capability, governance, risk, and delivery gaps for its intended project context.

Sources: [1] [2]