Human-in-the-loop systems: how to design review that holds up in production

A human-in-the-loop system lets AI process most of the work on its own and sends the cases it's unsure about, or that carry too much risk, to a person who checks, corrects or approves them. In document processing, the AI extracts each field with a confidence score, low-confidence fields and rule failures go to a review queue, and every correction is logged and fed back into the system.

This guide covers when to use one, how it works, and how to design the thresholds, queue, reviewer screen and feedback loop.

What is a human-in-the-loop system?#

Human-in-the-loop (HITL) means people are part of the system's design, not a fallback for when the AI breaks. Google Cloud describes it as integrating human input and expertise into the machine learning lifecycle. In practice, the AI handles volume and speed, and people handle judgment calls, edge cases and the decisions someone has to own. Article 14 of the EU AI Act points the same way: high-risk AI systems must be designed so people can effectively oversee them while they're in use.

There are three ways to split the work:

• Full automation

  AI runs the whole workflow with no one checking. Fine when an error costs little and is easy to fix later.

• Human-in-the-loop

  AI handles the documents it's confident about and sends the rest to a person. The default for documents that drive payments, claims or credit decisions.

• Full manual review

  People check everything. Accurate but slow and expensive, and only workable at low volume.

When human-in-the-loop review is worth it#

HITL costs more than full automation: reviewer time, a review screen, monitoring and retraining. It pays off when an error is expensive, when someone has to be accountable for the decision, or when you want the system to learn from its mistakes.

It also needs ground truth and people: reviewers who can't tell right from wrong add noise, and a review step nobody staffs becomes a backlog.

How a human-in-the-loop system works#

The loop is the same for every document type:

1. Extract and scoreEvery field comes back with a confidence score.
2. Check with rulesRules test what confidence can't: totals, bank details, approval limits.
3. RouteFields that clear their threshold and pass every rule go straight through; the rest go to a queue, ordered by risk and age.
4. ReviewA person sees the flagged value next to its source on the page and approves, corrects or rejects it.
5. Log and learnEvery action is logged, and checked corrections train the next model version.

Setting confidence thresholds#

A confidence threshold is the cutoff below which a field goes to a person. Too loose and errors slip through; too strict and the queue fills with correct values that reviewers learn to approve without looking. Where it goes depends on your accuracy target, the cost of an error and reviewer capacity: a team that can check 500 documents a day, out of 2,000 processed, can take at most 25% of them.

Set thresholds per field, not per document: stricter on fields that move money, looser on fields that are easy to fix later.

Start with a guess, then adjust weekly from the escalation rate and the errors that still get through: documents change and models drift.

Add business rules for errors the model is confident about

Some costly errors come back with high confidence: a year read as 2024 instead of 2023, or a total that doesn't match its line items. Add rules that flag a document whatever its score:

• The vendor's bank details differ from the vendor master or the last invoice.
• The amount is above an approval limit, or unusual for this vendor.
• Line items don't add up to the total.
• A required field or signature is missing.

These flags join the same queue as low-confidence fields. See exception handling for how to structure them.

Designing the review queue#

A queue needs a size your team can clear, an order that puts risk first, and a view that shows when it's falling behind.

• Size it for the peak

  Keep the backlog within 2 to 3 days of what reviewers clear, and staff for month-end, not the average day.

• Prioritize by risk and age

  A high-value payment comes before an uncertain phone number, and older items move up.

• Make it visible

  Put queue depth, the oldest item and escalation rate by document type on a dashboard.

To size the team, enter your monthly volume, the documents a person touches and the minutes each takes, then add month-end headroom to the hours it returns.

Designing the reviewer screen#

The screen decides whether review works: too little on it and reviewers guess, too much and they skim. Test each version with real reviewers, timing their decisions and checking their accuracy.

• The source next to the valueShow the region of the page the value came from, so the reviewer checks the document, not their memory.
• Confidence and the reason for the flagShow the score and which rule fired.
• ContextThe document type, when it arrived, and earlier decisions on the same vendor or customer.
• Keyboard shortcuts and batch actionsApprove, edit or reject without the mouse, and confirm a set of clean fields at once.
• A second check on high-risk changesA changed bank account shouldn't go through until someone has checked it against the source or a second person has approved it.

Turning corrections into training data#

Every correction is a labeled example. Captured well, corrections bring the escalation rate down; captured badly, they teach the model one reviewer's habits.

• Log every correctionWho, when, the old and new values, and why it was flagged. The log is also your audit trail: proof a person checked the decision.
• Audit a sample of each reviewer's workIf someone is consistently wrong, downweight their corrections and give them more training.
• Retrain from a versioned snapshotKeep corrections in a separate dataset and retrain weekly or monthly from a snapshot, so test data doesn't leak into training.
• Measure before and afterCheck accuracy on a held-out test set before and after retraining, and don't ship a model that didn't improve.

As the model improves, the escalation rate should fall, so people spend their time only on the cases that need them.

Metrics that tell you it's working#

Track these from day one to tune thresholds, size the team and show the review step is worth its cost.

Common human-in-the-loop design mistakes#

Say a team sends everything below 90% confidence to review, and in week one 40% of invoices land in the queue. Swamped reviewers start approving without reading. The model wasn't the problem; nobody designed the review.

How Docsumo handles human review#

Docsumo is an intelligent document processing (IDP) platform that extracts fields and tables from documents such as invoices and bank statements, handwritten text included. Any field below the confidence threshold you set for it goes to a reviewer, who clicks the field to see its source line highlighted, and reviewer corrections improve the model. Clean data goes to your systems through the API and webhooks; audit logging is on the Business plan, and cross-document validation and case management are on the Enterprise plan.

What it doesn't do: it's software, not a managed review service, so it doesn't supply reviewers; your own team decides the exceptions.

• 99%99%field-level accuracy across 250+ document types
• 95%+95%+of documents processed straight through, without manual review

For review inside a full workflow, see accounts payable automation and IDP for lending, or straight-through processing for the other side of the same design.

The bottom line#

Human-in-the-loop is part of the design, not a feature added later. Set a threshold for each field, add rules for the errors the model is sure about, size the queue for your busiest day, show reviewers the source and feed their corrections back. Then tune from escalation rate, reviewer accuracy and end-to-end accuracy.

Book a demo with a batch of your own documents, or start a free trial.

Frequently asked questions#