Checklist
AI-assisted change review checklist
Review generated code and AI workflow changes using independent expectations, explicit permissions, failure handling and a named human decision owner.
Download editable MarkdownHow to use this
Useful for: Teams using AI in software delivery, product features or internal workflows.
Define the task, permitted inputs and expected behaviour before asking an assistant to implement it. Preserve the human requirement so generated tests do not merely repeat generated assumptions.
Review permissions and data paths as part of the change. A useful suggestion does not authorise a tool to deploy software, write to a customer system or send a message.
Use independent checks for high-impact output. Add realistic failure examples and document what happens when the model is uncertain, a provider is unavailable or retrieved material is stale.
Measure the total workflow, including review and rework. Keep a manual fallback and a stop condition rather than assuming faster generation means a cheaper or more reliable process.
Scope and limitations: This checklist helps organise review. It does not guarantee model accuracy, certify an AI system or replace legal, security or domain-specific assessment.
Document preview
# AI-assisted change review ## Task and authority - Intended user outcome and human-written acceptance criteria: - Model / provider / version or configuration: - Permitted data and approved retention arrangements: - Tools and permissions available to the assistant: - Actions requiring human approval: - Change owner and reviewer: ## Independent evidence - [ ] A reviewer understands the implementation and can maintain it. - [ ] Tests compare behaviour with requirements, not only generated output. - [ ] Negative cases, boundaries and failure paths have independent expectations. - [ ] Dependencies, licences and configuration changes have been reviewed. - [ ] Secrets, personal data and customer material are handled under agreed rules. - [ ] External or retrieved content cannot silently grant the assistant new authority. - [ ] Tool output and generated instructions are treated as untrusted input. - [ ] High-impact writes, deployments and communications have enforceable approval boundaries. Record evidence, reviewer and remaining questions next to each check. ## For an AI feature or workflow - Representative evaluation examples and expected outcomes: - Uncertain answers, refusal and escalation behaviour: - Provider outage and stale-document handling: - Cost and latency observations under realistic load: - Manual fallback, monitoring owner and stop conditions: - Change triggers requiring a fresh evaluation: ## Decision and operation - Accepted limitations and approving owner: - Required fixes before wider use: - Pilot scope and observation period: - Handover, support and rollback reference: Example — fictional: a document assistant may draft an answer from approved internal material but may not send that answer to a customer. Review the citation against the source and keep the send action with an authorised person. A correct answer in one demonstration does not establish reliability across the document collection. Treat model configuration, source documents and tool permissions as part of the deployed system. Re-evaluate when any of those change; keeping the same prompt does not mean the behaviour stayed the same.