How to manage risks on an AI project

Start with a project risk, not an AI label

"AI risk" is too broad to manage. Describe the cause, the uncertain event and the effect on people, the service or the project objective. The structure makes the risk easier to challenge and gives the owner something specific to act on.

Example: because the evaluation data does not represent several important operating conditions, the capability may perform poorly in those situations, leading to incorrect service decisions and a loss of user trust.

This example is not a universal risk. Its credibility, likelihood, impact and owner depend on the use case, affected people, technical design and operating process.

Risk patterns worth testing

Use categories to prompt discussion, then write risks that are credible for the project. Do not paste a standard list into the live register.

Benefit and scope

The work is framed as using AI rather than improving a defined and measurable outcome.

Data suitability

Data may be incomplete, unrepresentative, poorly governed, inaccessible or not permitted for the intended use.

Output quality

Incorrect, fabricated or unstable output may look plausible enough to be accepted.

Uneven outcomes

Performance or impact may differ materially across people, contexts, languages or edge cases.

Privacy

Personal, sensitive or confidential information may enter prompts, logs, evaluation data or supplier systems.

Security and misuse

The capability may be manipulated, over-permissioned or used to access, disclose or change information outside its purpose.

Evaluation

Approval may rely on a demonstration, an unrepresentative test set or measures chosen after the result is known.

Supplier and model dependency

Changes to models, services, hosting, price, terms or data use may alter risk after approval.

Traceability

Insufficient records may prevent the organisation reconstructing a material output, test, limitation or decision.

Human oversight

A reviewer may lack the time, authority, competence or information needed to detect and act on a problem.

Operational integration

Roles, workload, training, support and exceptions may not be redesigned around the capability.

Monitoring and exit

Performance or context may change without an owner, threshold, fallback, incident route or decommissioning plan.

Connect the risk register to evaluation evidence

Evaluation is not a separate technical exercise that happens beside the project. Test evidence should support the acceptance decision and the current risk assessment. Agree measures, tolerances, test cases, affected groups, failure conditions and approval owners before the result is known.

Ask whether the tests represent live conditions and consequences. A high average result can still conceal a severe failure in an important group or edge case. The service owner and relevant specialists should explain what the evidence supports, where it is weak and which use is prohibited or conditional.

Separate controls, mitigation and contingency

Record what already controls the current exposure. Then add mitigation actions that will change the likelihood or impact, rather than general statements such as "monitor closely" or "use human review".

• Current controls: measures already operating and supported by evidence.
• Mitigation: owned work intended to reduce likelihood or impact before the risk occurs.
• Residual risk: the expected exposure after the mitigation is complete and effective.
• Contingency: the action to take if the event happens or a trigger is reached.
• Fallback: a credible alternative process or service when the capability is restricted, unavailable or withdrawn.

Do not lower a residual score merely because an action appears in the register. Record the evidence needed to show that the action is working and the date on which the assumption will be reviewed.

For the underlying approach to likelihood, impact, current risk, residual risk and ownership, see the general PMZ project risk guide.

Do not close the risk work at go-live

Project closure should transfer live risk ownership, monitoring, budget and competence to a named service or operational owner. Record indicators and thresholds for performance, errors, impact, usage, incidents and control effectiveness.

Define which changes to data, model, supplier, process, users or applicable requirements trigger investigation, re-evaluation, re-approval, rollback or suspension. A previous approval may not support a materially changed capability.

These are example project-risk prompts, not legal advice, technical assurance, certification or a complete risk library. Apply your organisation's risk policy, governance and specialist review.