Reviewing AI output after launch: reduce review only with evidence

Sampling only works if reviewers apply consistent criteria. Anthropic's guide to defining success criteria recommends criteria that are specific and measurable, and reminds teams to consider edge cases. For a document extraction workflow, that might mean each required field matches the source document exactly. For a drafting workflow, it might mean the draft contains no statement unsupported by the provided sources.

Write the criteria down and give reviewers examples of pass, fail and borderline cases. Record reviewer decisions in a structured form, not in free-text comments, so they can be counted.

Before reducing review, check that reviewers agree with each other. Have two reviewers independently check the same set of outputs for a period and compare. If they disagree often, the criteria are unclear, and sampling on unclear criteria produces numbers that mean little.

Disagreements are useful. They show where the criteria need examples or where the workflow produces genuinely ambiguous output that should be routed differently.

Not all outputs carry the same consequence. I would group them by risk: outputs that affect money, legal obligations, client communications or safety in one group; routine internal outputs in another. Some categories should always receive full review, regardless of how well the workflow performs on average.

Inside each group, sampling can be considered once there is evidence. A good average across all outputs can hide a poor rate in a rare but important category, so track results per group, not only overall.

Agree in advance what evidence is needed to move from full review to sampling: a minimum number of reviewed outputs in the group, an error rate below an agreed threshold, and no unresolved serious errors. When the evidence is met, move to a higher sampling rate first, not straight to a low one.

The NIST AI Risk Management Framework core includes measures for tracking identified risks over time and for establishing feedback processes so end users can report problems and appeal outcomes. In practice, that means sampling continues indefinitely at some level, and there is a clear way for anyone affected by an output to flag it.

The evidence for reduced review applies to the workflow as it was measured. When the model version, prompt, retrieval sources, input formats or business rules change, the earlier evidence may no longer hold. I would make a return to full review for the affected group part of the change procedure, at least until a fresh sample shows performance is unchanged.

The same applies when an error escapes review and is found downstream. Investigate it, decide whether it reveals a pattern, and increase review for the affected group until the cause is understood.

Reviewing outputs that are almost always correct is tedious, and tired reviewers approve things without reading. Show reviewers the source material next to the output, keep review sessions short, and occasionally include known-error examples to check that reviews remain attentive, with reviewers aware this practice exists.

Do not measure reviewers by speed alone. A reviewer who catches errors slowly is more valuable than one who approves everything quickly.

A short regular report helps the team decide: outputs reviewed per group, error rate per group, serious errors and their causes, current sampling rate, and any changes that triggered a return to full review. The business owner of the workflow should read it and approve changes to review levels.

The acceptance condition I would agree before reducing review: written criteria with examples, measured reviewer agreement, per-group error rates with enough reviewed outputs to be meaningful, defined always-review categories, and a documented trigger for returning to full review.

Bring the workflow, its current review process and examples of outputs reviewers have rejected.