How to Review AI-Generated Work Before You Use It

How to Review AI Output Before It Enters Real Work

AI output should enter real work only after a named reviewer verifies the authorized input, consequential claims, sources, calculations, required elements, permissions, uncertainty, and downstream effect. The reviewer must have the competence, time, evidence, and authority to accept, revise, reject, or escalate.

A glance at fluent prose is not review.

flowchart TD
    A["AI-generated draft"] --> B["Identify task, consequence, and approved boundary"]
    B --> C["Verify source support and calculations"]
    C --> D["Check completeness, uncertainty, and permissions"]
    D --> E["Test downstream fit and harmful failure"]
    E --> F{"Acceptance decision"}
    F --> G["Accept with named owner"]
    F --> H["Revise and record material correction"]
    F --> I["Reject"]
    F --> J["Escalate to qualified authority"]

Identify what the output can change

Begin with consequence, not grammar.

Ask who will receive the output, where it will be stored, which decision or action it can influence, and what happens if it is wrong. A private brainstorm, internal draft, customer message, personnel record, code change, payment instruction, legal interpretation, and safety procedure need different review depths.

Name the accepted use. If the system was approved to draft an internal update, do not review the same output as if it were also authorized for a customer notice. Adjacent use is a new decision.

If the output can affect employment, rights, health, safety, money, security, contractual obligations, or a regulated record, a general reviewer may not be sufficient. Route it to the qualified owner required by the context.

Confirm the input was authorized

Review can discover that the work should never have entered the system.

Identify the account, application, tenant, connector, source, data class, and purpose. Confirm that the worker had authority to use the material in that exact path.

Check whether the prompt or attachment contained personal information, customer records, confidential business data, credentials, licensed content, employee data, security details, or another restricted class. Verify the output destination as well.

[[How to Set a Workplace AI Data Boundary]] provides the full data-flow decision. If the input was not authorized, stop the ordinary review, contain the material, and follow the incident process.

Break the output into consequential claims

Do not read only for overall plausibility. Mark each statement that can change a decision, obligation, number, owner, deadline, status, fact, or action.

For each consequential claim, identify the controlling evidence. Open the source. Confirm that it is authoritative, current enough, in scope, and actually supports the claim.

A real citation can still be wrong. It may point to a stale policy, unrelated passage, vendor marketing claim, draft document, or source that describes intended behavior without proving observed performance.

Episode 35's [[How to Verify an AI Answer Against Its Citations]] provides a deeper support test. Episode 49's [[How to Build a Human Review Gate for AI Research]] covers multi-source research work.

If the output has no citations, reconstruct the evidence from the approved source set. If that is impossible, reject or qualify the claim.

Reproduce calculations and transformations

Verify numbers from the original data and formula. Do not accept a total because the surrounding prose sounds careful.

Check units, dates, currencies, signs, denominators, exclusions, rounding, time zones, version, and sample. Recompute material values with a trusted method. For code or spreadsheet work, inspect the actual logic and test representative and boundary cases.

The AI may produce the right number for the wrong reason. Preserve the calculation path required by the business record.

If the transformation changes format, confirm that no required field, condition, dissent, exception, or provenance was lost.

Look for missing information

Review what is absent.

Compare the output with the acceptance standard and source set. Check required sections, unresolved questions, conflicting evidence, caveats, ownership, dates, accessibility needs, and next actions.

Summaries often compress uncertainty into confidence. "The team discussed a Friday target" can become "The team committed to Friday." "No issue was found" can become "There is no issue."

Restore conditions, alternatives, and dissent when they matter. If evidence is missing, say what is unknown and who can resolve it.

Check permission and representation

The output can misuse material even when its factual claims are accurate.

Confirm copyright, license, confidentiality, consent, attribution, records, and brand requirements for the intended use. Check whether the output imitates a person, discloses AI assistance where required, or presents a vendor claim as independent fact.

Review personal and employment impact. The EEOC's employment-practice guidance records federal anti-discrimination duties across hiring, assignments, promotion, pay, discipline, and other employment actions. Human approval does not make a discriminatory process acceptable.

The EEOC and Department of Justice have also warned about disability discrimination from AI and software tools, including screening and accommodation issues.

These sources identify review boundaries. They are not individual legal advice.

Test the downstream system

An output can be correct in isolation and wrong for the destination.

Check the schema, required fields, formatting, audience, ownership, retention, version control, and system of record. Confirm that the output does not duplicate an existing task, reopen a closed decision, overwrite a source record, or trigger an action beyond its approval.

For customer or public content, verify claims, links, dates, accessibility, disclosure, canonical source, and approval. For code, run tests, security review, dependency checks, and deployment controls required by the repository.

Episode 37's [[How to Review AI Generated Code Before Accepting It]] and Episode 107's [[How to Review an AI-Generated Pull Request]] handle code-specific evidence.

Record material corrections

Do not silently repair every defect and then report that the system worked.

Record the original material error, category, correction, time, source, reviewer, and downstream consequence. Repeated corrections reveal task mismatch, source problems, training needs, or a system that is not ready.

Minor style changes can be summarized. Changes to facts, calculations, owners, deadlines, permissions, decisions, or required conditions should remain traceable.

Correction evidence belongs in productivity measurement. The output is not "95 percent complete" if the missing five percent required expert reconstruction or prevented harm.

Choose one decision state

Accept only when the output meets the standard and the reviewer owns the decision.

Revise when a bounded correction can produce an acceptable result without changing the task's authority. Reject when the answer is unsupported, unusable, outside scope, or too costly to repair. Escalate when a qualified expert, data owner, legal function, security team, records owner, manager, or another authority must decide.

The acceptance record should preserve the task, system, date, data class, sources, checks, material corrections, decision, reviewer, escalation, destination, and retention path.

The NIST Generative AI Profile identifies confabulation, information integrity, privacy, bias, intellectual property, and overreliance among the risks that may need management. The review method must translate those categories into the exact work.

The central rule is simple: the reviewer accepts accountability for the result. If no one can do that responsibly, the output does not enter real work.

This guide was developed with AI assistance from the preserved E019 transcript, the linked acceptance protocol, and current NIST and EEOC sources. Dalton Anderson remains the author. It is not legal, employment, medical, safety, financial, privacy, security, copyright, or professional advice. Domain, records, rights, privacy, security, accessibility, legal, policy, source, and founder review may be required. Publication is not authorized.