A completed box is not a decision
Use each question to record a named owner, the current answer, the evidence or decision location, any conditions and the next review date. "Considered" or "discussed" is not enough when the project cannot show the outcome or accountable decision-maker.
The suggested roles are starting points. Follow local decision rights and governance. A project manager coordinates the work but does not personally approve security, decide data lawfulness, interpret legislation or validate a model unless formally authorised and competent to do so.
Decide whether to explore or approve
The first decision needs a defined problem, accountable owner and a proportionate reason for using AI before technology choices harden the scope.
- What business problem, user need or service outcome is being addressed?
- Why is an AI-enabled approach appropriate compared with a simpler option?
- Who is accountable for the outcome, affected people and accepted residual risk?
- Who may be affected, including people outside the immediate user group?
- Which legal, privacy, security, procurement or sector specialists need to be involved, and when?
- What baseline, benefit, costs, constraints and stop conditions support the decision?
Prepare to build or procure
Turn the proposed capability into a visible system of data, models, suppliers, integrations, people and manual work.
- What data will be used for development, evaluation and live operation, and who owns it?
- What is inside the system boundary, including suppliers, models, integrations and manual steps?
- What may the capability access, produce, recommend or change?
- Which supplier terms, data-use arrangements, hosting locations, model changes and exit needs require review?
- What records are needed for traceability, challenge, support and incidents?
- How will limitations, prohibited uses and user responsibilities be documented?
- What changes are required to roles, workload, skills, process and support?
Test and decide whether to go live
A go-live decision should be based on representative evidence, explicit limitations, recorded specialist decisions and workable operational controls.
- Were evaluation measures, tolerances and representative test cases agreed before the result was known?
- Does testing cover credible errors, edge cases, affected groups, misuse and real operating conditions?
- Can the project reconstruct the source, version, test result, limitation and decision behind the evidence?
- Is human review designed with enough time, authority, competence, information, escalation and override?
- Have required legal, privacy, security, procurement and organisational approvals been recorded?
- Are support, incident response, communications, fallback and stop arrangements tested and owned?
- Who makes the go-live decision, what residual risks are accepted and what review conditions apply?
Operate, monitor and change
Project closure should transfer continuing accountability, monitoring, competence and a funded fallback to the live service.
- Who owns the live capability, its outcomes and its continuing suitability?
- Which performance, error, impact, usage and control indicators will be monitored, by whom and how often?
- What thresholds trigger investigation, human intervention, rollback, suspension or re-approval?
- Which changes to data, model, supplier, process, users or requirements require re-evaluation?
- How can users and affected people raise errors, challenge outcomes or obtain a human route?
- Is there a funded fallback, exit and decommissioning plan, including records and supplier dependencies?
Review AI-assisted project work before relying on it
The same accountability applies when AI is used inside ordinary project work. A polished plan, status report, risk summary or stakeholder communication can contain unsupported statements, invented detail or missing uncertainty.
- Confirm the source and permitted use.Use authoritative, current material and check that the chosen service is approved for the information involved.
- Check facts against the source.Verify figures, dates, quotations, claims and named decisions in the underlying records.
- Expose assumptions and omissions.Make uncertainty, conflicting evidence, missing views and important exclusions visible.
- Check project mechanics.Verify calculations, dependencies, owners, dates, status claims and RAID entries.
- Review information before sharing.Remove confidential, personal or security-sensitive content that should not be distributed.
- Obtain accountable human approval.The named owner remains responsible for the final artefact and the decision to rely on it.
Human review reduces some risks only when the reviewer can detect and correct the problem. It does not make an AI-generated output reliable by default.
Free editable Excel resource
Use the 32-question working checklist
The workbook provides project-response, evidence, owner, status and review-date fields across all five stages. It also includes a blank AI project risk register and separate illustrative risks.
Related PMZ resource
Identify gaps before the next governance decision
This is a project working checklist, not legal advice, an audit, certification, technical assurance or a replacement for local governance and specialist approval.