AI programme management
AI project risk register: turn concerns into controls
Build an AI project risk register around failure scenarios, owners and tested controls. Use a worked example to review residual risk before release.
“Hallucinations”, “privacy” and “vendor dependency” are concerns. They become useful entries in an AI project risk register when you explain how they could affect a particular workflow, who would be affected and which control the team can test. A list of frightening words cannot tell a release owner what to do next.
A risk register should connect a possible failure with a decision. This guide shows how to write scenarios, distinguish controls from promises and keep residual risks visible. It sits within the wider AI programme management approach, with accountability addressed in the AI governance guide.
Describe a chain from cause to consequence
Use a sentence with three parts: because of a condition, an event may happen, leading to a consequence. For example: because two approved documents contain different service terms, an assistant may select an obsolete statement, leading an account manager to give a customer incorrect information.
This wording makes the risk discussable. The team can inspect conflicting documents, test whether the assistant retrieves the obsolete statement and assess the consequence for the customer. “The AI might be wrong” provides none of those handles.
Write risks at the workflow level. A wrong draft that a trained reviewer corrects has a different exposure from the same statement sent automatically. Record the relevant permissions and the point where an output becomes an action. Do not treat the model as the entire system.
The NIST Generative AI Profile includes confidently incorrect content among generative AI risks. Its terminology can help you find scenarios; your own workflow determines the applicable consequences. The register proposed here is an editorial working tool, not a complete risk assessment for every use.
Distinguish a risk, an issue and a dependency
A risk is an uncertain future event. An issue has already happened. A dependency is something another activity must provide. The three belong in connected records, but treating them as interchangeable hides what kind of decision the team needs.
If a supplier might change behaviour after an update, that is a risk. If yesterday's update broke source attribution, that is an issue. If an evaluation environment is required before the team can test the update, that is a dependency. Each needs a different action and a clear link to the others.
An existing issue can expose additional risks. After repairing a broken source citation, ask whether similar failures could affect other answers and whether monitoring would detect them. Closing the incident does not automatically close those prospective scenarios.
Dependencies belong on the AI roadmap as well as in the register. A missing document owner may block a release. Calling it a low-probability risk does not make the missing owner less real. Keep the delivery decision and the risk record consistent.
Keep the record specific enough to test
A practical entry needs more than probability and impact. It needs a scenario, evidence, an owner, controls, a way to check those controls and a decision about what remains. Use identifiers so incidents, evaluations and changes can refer to the same entry.
Swipe or use the arrow keys to see every column.
| Field | Example content | Review question |
|---|---|---|
| Scenario | Obsolete service terms enter a customer answer | Under what conditions can this happen? |
| Affected people and process | Customer and account-management team | Who bears the consequence? |
| Existing evidence | Conflicting documents found in a source review | Observation, assumption or external evidence? |
| Exposure | Reviewed draft; sending remains manual | Which permissions affect the consequence? |
| Control | Retire old source, show provenance, review terms | Prevention, detection or recovery? |
| Verification | Test a known conflict and inspect the answer | What would prove the control failed? |
| Owner and action | Content owner resolves the source conflict | Who has authority and capacity? |
| Residual risk | Unidentified outdated documents may remain | Who accepts it, for which scope? |
| Review trigger | New source collection or failed test | When must the decision reopen? |
Do not require a numerical probability when the team lacks a defensible basis. Qualitative categories can be useful if their meaning is explicit. Include uncertainty and evidence strength separately. Otherwise “unlikely” can mean anything from a well-tested rare event to something nobody has investigated.
If you use a ranking score, keep severe consequences visible independently. Multiplying two ordinal labels creates a convenient ordering, not a measured expected loss. A low overall number should not erase a consequence that requires specialist attention or a release restriction.
Separate prevention, detection and recovery
A preventive control reduces the chance of the event. A detective control helps identify it. A recovery control limits consequences after it occurs. These functions complement one another, and each can fail in a different way.
For an outdated source, prevention could mean a governed source catalogue with explicit retirement. Detection could mean evaluation questions that target known source conflicts and alerts for stale documents. Recovery could mean pausing the assistant, identifying affected outputs and returning the task to the approved manual process.
“Human review” is not a sufficiently specified control. What must the reviewer inspect? Can they access the source? How long is available? What happens when they are unsure? The human-in-the-loop workflow guide turns that general phrase into an operational design.
Likewise, “the prompt tells the model not to do it” does not establish a security boundary. The OWASP guidance on excessive agency links harmful actions to excessive functionality, permissions or autonomy. In the register, identify permission controls outside the text-generation instruction and verify their behaviour.
Hypothetical example: a document assistant acquires tools
Consider a hypothetical internal document assistant. It reads approved files and prepares summaries. The team proposes allowing it to create tasks in a shared work-management system. This example illustrates a method; it does not report a client deployment or measured outcome.
The first scenario concerns wrong task content. An ambiguous source may cause an incorrect assignment, creating avoidable work. The control could require a preview showing the proposed title, assignee, date and source before the person confirms. Evaluation checks both the generated fields and what happens when confirmation is refused.
A second scenario concerns permissions. A tool connection may allow changes outside the intended project. The team tests the allowed project boundary independently of the prompt. An attempted out-of-scope action should fail at the permission layer, with enough information for investigation.
A third scenario concerns availability. If the work-management service is unavailable, a user may believe a task exists when it does not. The workflow needs a clear result state and recovery route. A polished sentence saying “done” cannot substitute for a verified creation record.
The release decision can permit reviewed task creation for one workspace while leaving other actions disabled. The register records what was tested, what remains uncertain and the event that would require review. It explains a specific operating scope rather than declaring the assistant broadly safe.
Test controls through deliberate failure cases
For each important scenario, construct a case that should trigger the control. Use authorised synthetic or appropriately handled data. A stale-document control needs an outdated document in the test; an access control needs an attempted forbidden action. Happy-path examples cannot demonstrate that a control catches failure.
Keep these challenge cases distinct from ordinary task samples. Routine samples estimate performance on expected work. Challenge cases examine a particular boundary. Passing an adversarial case does not establish the frequency of that event in production, while a good average does not establish that a boundary works.
Record configuration, expected behaviour, observed behaviour and the decision. Repeat relevant checks when permissions, sources or models change. The AI output evaluation guide explains how to preserve comparability without using the same examples as endless prompt-tuning material.
Also test recovery. If the pause mechanism works but a queued action still executes, the control is incomplete. Check how the manual process resumes and which outputs need review. Ask someone who did not build the system to follow the recovery instructions.
Make residual-risk decisions visible
Controls rarely remove every uncertainty. Residual risk is the risk that remains after the defined measures, for the defined scope. Write that scope explicitly. Acceptance for an internal reviewed draft cannot silently extend to autonomous customer communication.
The accountable owner needs enough evidence to understand what they are accepting. Show failed checks and unresolved limitations alongside successful checks. A register that displays only reassuring outcomes becomes a presentation aid rather than a decision record.
Set review triggers around changes, incidents and new evidence. A calendar review can still help, but a source update or permission expansion may require attention immediately. Record who receives the trigger and who can reopen the decision. An unattended notification is not a functioning control.
Specialist questions should stay with the appropriate specialists. This worksheet does not determine legal compliance, classify regulated uses or replace assessment for high-consequence settings. It helps a team preserve operational evidence and identify where its own judgement is insufficient.
Watch for registers that become ceremonial
A risk register is failing when every entry says “monitor”, every owner is the programme manager and no decision changes after a failed test. It is also failing when entries are copied across unrelated workflows without checking the input, users and actions.
Another warning sign is stale acceptance. A workflow evolves, but the same approval survives because nobody linked the change to the original scenario. Make a register review part of material changes, with enough focus to examine affected entries rather than rereading every row mechanically.
Measure usefulness through action: overdue controls, unverified assumptions, recurring incidents, time to detect and time to restore. Interpret trends carefully; more reported incidents can reflect better reporting rather than deteriorating quality. Avoid rewarding low reporting as proof of safety.
Start with the three scenarios that could most affect your intended workflow. Write the failure chain, identify a testable control and ask who can accept what remains. For marketing-specific applications, connect the work with the AI marketing guide. To review the register within your programme, tell me about the project.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
AI governance: assign responsibility before release
Make AI governance operational with clear decision rights, release gates and incident ownership. Use a charter that your team can apply to real work.
AI roadmap prioritisation: choose what to build first
Prioritise an AI roadmap around evidence, dependencies and measurable value. Use a practical decision sheet to choose the next project with confidence.
Evaluating AI output: a practical quality scorecard
Evaluate AI output with task-specific criteria, representative cases and independent review. Build a scorecard that informs a clear release decision.