
A generative AI draft can be useful and still contain a serious mistake. Fluent wording is not evidence that a quotation exists, a calculation is correct or a recommendation fits the situation. The person sharing or acting on the output needs a review process suited to the task.
This guide focuses on checking an individual output. Organisations deploying AI systems also need ownership, testing, incident handling and ongoing monitoring; those broader controls are covered in our responsible AI governance guide.
1. Decide what happens if the answer is wrong
A brainstorming list needs a different review from a customer message, financial summary or security instruction. Identify who will receive the result and what they might do because of it.
For tasks affecting health, rights, employment, money or safety, involve an appropriately qualified reviewer and follow the relevant process. A disclaimer attached to an unverified answer does not make the answer suitable for a consequential decision.
2. Check whether the input belongs in the tool
Confirm the organisation’s rules, the provider’s data handling and the permissions for the material. Remove unnecessary personal details. Do not upload confidential records merely because a tool can accept a document.
For practice, use fictional or public information. In a real workflow, keep a record of the permitted sources and the scope of the task. This makes it easier to investigate an output that includes something unexpected.
3. Verify factual claims against independent sources
Highlight names, dates, numbers, quotations and references. Open the underlying sources and confirm that they support the specific claim. A plausible-looking title or citation is not enough.
Check whether the source is current for the question and whether the draft has changed its scope. A statistic about one country, reporting period or sample should not become a worldwide claim. If a source cannot be verified, remove or qualify the claim.
Recalculate important totals outside the generated text. Compare a summary with the original document, looking for omitted conditions and exceptions. Ask what a reader would misunderstand if they saw only the summary.
4. Review treatment of people
Look for unsupported assumptions about groups, dismissive descriptions and unequal treatment. Check whether the wording introduces characteristics irrelevant to the task or treats limited evidence as representative of everyone.
Changing a few offensive words is not a complete bias evaluation. If an output is part of a repeated decision process, the organisation needs testing across relevant cases and groups, plus a way for affected people to raise concerns.
5. Separate suggestions from authorised actions
A drafted email and a sent email have different consequences. So do suggested code and code run against production data. Review the recipient, data, permissions and reversibility before allowing a connected tool to act.
Text inside a retrieved page or document may attempt to redirect the assistant. Treat that material as evidence to examine rather than authority to send files, reveal secrets or change the task. A model’s confident recommendation should not replace the human approval required by the workflow.
6. Label the result and preserve context
Make clear when the result is a draft, a hypothetical example or an estimate. Do not describe invented interviews, testing or cases as events that actually happened. Keep limitations near the claim they affect.
For a public document, verify attribution and permission for included material. Ensure the final author or owner accepts responsibility for it. Transparency should help the reader judge the content rather than serve as a substitute for checking it.
A practice review
Use a fictional meeting note and ask an approved tool for a short action list. Compare each owner and deadline with the original. Mark any task that was inferred rather than stated. Remove invented commitments and restore important conditions.
This is a suggested exercise, not a claim that a particular model has been tested. Repeat it with an incomplete note to see whether the tool guesses missing information. The useful outcome is a review habit you can reproduce.
When to stop and escalate
Do not share the output if you cannot verify a material claim, if sensitive information appears unexpectedly, or if the task needs expertise you do not have. Seek the appropriate reviewer or use a conventional workflow.
NIST’s generative AI risk profile describes risks including confabulation, privacy and harmful bias. No single prompt or content filter eliminates these risks. Practical review, controlled permissions and clear accountability work together.
Sources and further reading
NIST: Generative AI Risk Management Profile
NIST: AI Risk Management Framework
Related guides: AI governance for organisations · Prompt injection and connected tools · AI literacy.
Written and prepared by Kshitij Gupta.



