The sizing rule most teams get backwards
Human review usually gets sized by confidence. The team feels shaky about the model, so everything goes to a reviewer. Six weeks later the reviewers are rubber stamping at nine seconds an item and the workflow has a compliance theatre problem on top of an accuracy problem. Size review by the cost of a silent error instead. An error that gets caught downstream anyway needs sampling. An error that ships to a customer, moves money, or enters a regulatory filing needs a gate. Confidence and consequence are unrelated variables, and mixing them up is why review budgets go to the wrong steps.
Step 1. List the actions, not the models
Write down every action the workflow can take in the world: sends an email, updates a record, approves a payment, closes a ticket, files a document, calls another system. Reading and drafting aren't actions in this sense. Actions are the things you can't take back with a refresh. Output: a flat list, usually between four and fifteen items. If your list has one entry called processes the request, decompose it. The review design lives at this granularity or nowhere.
Step 2. Price a silent error for each action
For each action, answer one question: if the AI gets this wrong and nobody notices for a month, what does it cost? Put a number or a band on it. A wrongly categorised internal ticket is tens. A wrongly closed complaint in a regulated firm is a reportable breach plus remediation. A wrong payee on a transfer is the amount plus the recovery effort. Include the detection lag explicitly. Two errors of equal size are not equal risks if one surfaces the same day and the other surfaces at year end audit. Output: your action list with a cost band and a typical detection lag against each row.
Step 3. Assign a review mode per action
Four modes, and each action gets exactly one. Gate: a human approves before the action happens. Reserve it for the high cost, slow detection rows. It's the most expensive mode you have, so spend it deliberately. Sample: the action proceeds, a percentage gets reviewed after the fact, and the rate is set by the error cost rather than by convention. Most rows land here. Reverse: the action proceeds with an automatic undo path and an alert. Good where the action is cheap to unwind and the volume makes gating impossible. None: the action proceeds unreviewed because a downstream control already catches the failure. Write down which control, by name. If you can't name it, this row isn't a none. Output: one mode per action, with the reason recorded next to it. That column is what an auditor reads, and it's also what stops the design drifting when a new person joins.
Step 4. Set sampling rates from the error cost, then move them
Start sampled rows at a rate that catches a problem before it becomes expensive rather than at a round number that sounded prudent. If a category runs 500 items a month and an undetected error costs 2,000, reviewing 10 percent means an average of 25 items pass between reviews of a bad one, so your exposure per incident is around 50,000 before anyone looks. If that's too much, the rate is too low. Do that arithmetic per row. Then let the rate move on evidence. Rows with clean review results for three consecutive months earn a lower rate. Rows with a miss go back up immediately. Publish the rule in advance so the reduction isn't a negotiation each quarter. Output: a rate per sampled action plus the written rule for changing it.
Step 5. Make review fast enough that people actually do it
A reviewer needs the model's output, the inputs it used, the specific claim to check, and one click each way. If the reviewer has to open three systems to verify one item, review quality collapses within a fortnight and you'll never see it in a dashboard. Budget the review time honestly in the business case. Thirty seconds an item at 4,000 items a month is 33 hours, which is real money and belongs in the cost per completed outcome. One design choice worth arguing for: show the reviewer the two or three items where the model was least certain first, but never let certainty decide whether an item is reviewed at all. Ordering by confidence is useful. Filtering by confidence recreates the mistake from the top of this page.
Step 6. Instrument the reviewers as well as the model
Track approval rate, time per item, and disagreement between reviewers on the same item. A reviewer approving 99.6 percent of items in eleven seconds is not providing oversight, and that pattern is visible in the data long before it's visible in an incident. This is also where the regulatory ask lands. EU AI Act Article 14 requires human oversight that a person can genuinely exercise, including the ability to understand the system's output, override it, and stop it. A gate that nobody has the time or information to use doesn't meet that bar, whatever the process document says. Article 12 requires the events to be recorded automatically over the system's lifetime, which for review means capturing the decision, the reviewer, and the timestamp alongside the outcome. Output: a monthly view of reviewer behaviour that a risk committee can read in one page.
Step 7. Design the exit before you need it
Review is scaffolding. Decide up front what evidence would let you take a gate down: a sustained agreement rate, a volume threshold, a downstream control that got built. Write it in the original design. Teams that skip this keep every gate forever, which is how a workflow that saved 40 percent of handling time gives it all back in approvals. The gate that made sense at launch is often the thing blocking the second workflow eighteen months later. One closing opinion. Human in the loop is not a safety feature you add to a risky system. It's a place where you decided to spend money instead of accepting a loss, and it should be argued for in those terms in front of the people paying for it. Difinity partners with regulated teams to build AI into production that delivers real value, with the control and evidence to scale it past the first workflow.