How Much AI Output Should a Human Review?

Review a fixed number of AI outputs per period, not a percentage of volume. The confidence a sample buys you depends on how many items you check, not on what share of the total they represent, so "spot check 10 percent" means something completely different at 400 items a month than at 40,000. Check 59 consecutive outputs, find zero errors, and you can say the true error rate is under 5 percent at 95 percent confidence. That holds at either volume.

Why "review 10 percent" is the wrong unit

Almost every piece of advice on human review of AI output lands on a percentage. Ten percent daily, more after a prompt change, less for internal work. The risk-tiering part of that advice is right. The unit is wrong, and it fails in both directions.

Take a small operation running 400 AI-drafted replies a month. Ten percent is 40 reviewed items. If all 40 are clean, the most you can honestly claim is that the error rate is under about 7 percent. That is not a quality program, that is a feeling. Now take the same rule at 40,000 items a month. Ten percent is 4,000 reviews, roughly a full-time job, to learn what 299 items would have told you.

The reason is that the width of a confidence bound on an error rate is driven by the absolute number of observations. Population size only enters through a finite population correction, which is negligible whenever you are sampling a small slice of the whole. The NIST handbook's sample size formulas for a proportion contain no population term at all.

Manufacturing settled this decades ago. Under the ANSI/ASQ Z1.4 attribute sampling tables, a lot of 300 units at general inspection level II gets a sample of 50 units, about 17 percent. A lot of 10,001 to 35,000 units gets 315, roughly 1 percent. The lot grew by a factor of 100 and the sample grew by a factor of six. A percentage rule would have demanded 5,000.

How many outputs do you actually need to check?

The arithmetic is one line. If you check n items and find zero errors, the upper 95 percent bound on the true error rate is approximately 3/n. This is the rule of three, published by Hanley and Lippman-Hand in JAMA in 1983 under the title "If nothing goes wrong, is everything all right?" It is a good approximation above about 30 samples.

Error rate you want to rule out	Clean items you must check	What you can then say
10 percent	29	Fine for a reversible internal step
5 percent	59	The default for most operator automations
2 percent	149	Justified when a bad output reaches a customer
1 percent	299	Only worth it for money or compliance

The word doing the work in that table is "clean." Any error you find resets the arithmetic, and the honest bound gets worse than people expect. Two errors in 100 checked items does not mean a 2 percent error rate. It means the true rate could be as high as 6.2 percent at 95 percent confidence, which is a weaker claim than 59 spotless items would have given you. That asymmetry is the whole reason to front-load review instead of spreading it thin.

Most steps do not need the 1 percent row. A misfiled ticket category costs a few seconds of someone's attention. Pick the target from what a wrong output actually costs, then look up the count. This is the same logic as testing an AI step before you trust it, applied after launch instead of before it.

Burn-in, drip, trigger

Once review is a count rather than a percentage, the schedule falls out of it.

Burn-in. Review 100 percent of output, consecutively, until you hit your clean count. At 400 items a month, 59 items is about four working days of full attention. That is a real cost, and it is finite, which is what makes it payable. Spreading the same 59 reviews across four months buys you the same statistical claim four months late.

Drip. After the burn-in, drop to a fixed count per week. Fifteen to twenty-five items is a reasonable band. Be honest about what that buys: 20 items a week only catches gross failure, an error rate that has climbed into double digits. It is a tripwire, not a measurement. Anyone who tells you a weekly spot check proves an automation is 98 percent accurate is doing arithmetic they have not checked.

Trigger. Re-run the full burn-in when any input to the step changes: the prompt, the model version, the upstream data source, or the customer segment flowing through it. A silent provider-side model update is the most common one and the easiest to miss, which is the argument for pinning the model version so the change is at least yours to schedule.

Stratify by consequence, not at random

Random sampling spends your review budget in proportion to volume, which means most of it lands on the easy middle. Sample 60 tickets at random from a queue of 5,000 and you will mostly see 60 versions of the same routine ticket. Split the volume by what the output does instead.

What the output does	Example	Review policy
Irreversible and external	Issuing a refund, deleting a record, emailing a full list	Approval gate, not sampling
Reversible and external	A drafted reply a rep sends, a quote line item	Burn in 59 clean, then 20 a week
Internal and easy to correct	Lead tags, ticket categories, meeting summaries	Burn in 29 clean, then 10 a week

The top row is not a sampling problem at all. When a single wrong output cannot be walked back, no sample size makes unattended operation acceptable, and the decision belongs to reversibility and blast radius rather than to accuracy statistics.

Inside the rows that do get sampled, oversample the tails on purpose. Pull the longest inputs, the ones from a source that started feeding the step last month, the runs that took a fallback branch, and the runs where a validator passed by a hair. Those are where the error rate lives. A pure random draw will underrepresent every one of them, which is exactly why the first production surprise so often looks nothing like anything in the sample.

The 100 percent sample you already have

The cheapest quality signal in most AI automations is already being generated and thrown away: the correction rate. If the AI drafts and a person sends, log whether the sent text differs from the drafted text. That is a census, every single item, at zero review labor. The same trick works on any step with a human downstream. Compare the AI's proposed field values against what was in the record a day later. Count reopened tickets, corrected invoices, second-touch rates, refunds issued after an AI-set price.

Here is the distinction that most teams miss. A sample measures the level. A census proxy measures the change. They are not substitutes.

Correction rate cannot tell you the automation is 96 percent right, because a rep editing for tone is counted the same as a rep fixing a wrong price. But if it sits at 12 percent for six weeks and jumps to 30 percent on a Tuesday, something changed on that Tuesday, and you know within a day rather than at the next monthly sample. Run both: a sized burn-in to establish the level, a cheap census proxy to catch the moment it moves. Trying to make one mechanism do both jobs is how teams end up with a review process that is expensive and still slow to notice failures.

Wire the correction rate into the same run record as everything else you log, so a change in it is visible next to the prompt version and model ID that were in play when it moved.

What to do next

Pick your single highest-volume AI step. Write down, in one sentence, the error rate you would actually accept for it, then look up the clean count in the table above and schedule the burn-in as a block of work with an end date. Four days of concentrated review will tell you more than a year of ten percent spot checks, and unlike the spot checks it finishes.

Then instrument the correction rate, because that is the number that tells you when the burn-in has expired. If you want a second read on where the gates belong in an existing stack, our workflow automation work starts with exactly that inventory, and you can tell us what you are running to start the conversation.