Human in the loop automation: where to keep a person

A firm automates its invoicing. A job is marked complete, the software assembles the invoice, and it sends. Six weeks later a client rings about a bill for work that was scoped differently, and nobody at the firm saw the invoice before the client did.

The problem was not the automation. It was that nobody decided where a person still needed to look.

That decision has a name. Human in the loop automation means designing a workflow so the software handles the repeatable steps and a person stays at the points where judgement actually matters.

IBM defines it as keeping human oversight inside an automated system rather than around it. Most of the writing on it treats it as an artificial intelligence problem. It is not. It is a workflow design decision, and it applies whether or not there is any AI in your systems.

The short version:

You are probably already doing this

Here is the thing most guides on this topic miss. A human in the loop is not something you add when you buy AI. It is the review step you already rely on.

When we build a billing workflow, the sequence is deliberately not "job complete, invoice sent." It is trigger, draft, review, send. The software assembles the invoice from data that already exists. It creates it as a draft. A person approves anything unusual. Then it goes.

There is no AI anywhere in that workflow. It is still human in the loop automation, because the design keeps a person at the one point where a mistake reaches a client and costs money to unwind.

That reframe matters, because it changes the question you are asking. The question is not "do we need a human in the loop?" You already have humans in loops all over your business, most of them undesigned and some of them pointless. The useful question is which ones to keep, which to remove, and where you are missing one.

Where the checkpoint belongs

Four tests. If a step fails two or more, keep a person on it.

Can you undo it? Sending an email to a client, issuing an invoice, filing a document with a regulator, and paying a supplier are all hard to take back. Creating a draft, assigning a task, or updating an internal record are not. Irreversibility is the strongest single argument for a checkpoint.

What does being wrong cost? Not the cost of the error itself, the cost of the client seeing it. A wrong internal task assignment costs someone five minutes. A wrong fee estimate in a client email costs a conversation you did not want to have, and sometimes the client.

How much do you trust the input? Automation is only as good as what it reads. Data arriving from a structured form your team controls is reliable. Data extracted from a client's emailed PDF, a scanned document, or free text is not, at least not consistently. The messier the input, the more valuable a set of human eyes on the output.

Is this a judgement or a rule? If you can write the decision down as a rule your team agrees on, automate it. If two experienced people would reasonably disagree about the answer, that is judgement, and judgement stays human. This is the same test we use when deciding what not to automate at all.

An Australian financial advice firm offers an example of review in practice. In Marloo's case study, Everest Wealth describes generating a draft statement of advice and spending time amending and customising it. The vendor account does not establish how every output is reviewed or whether a checkpoint can be bypassed. For consequential advice, define who reviews the draft and what must be checked before it reaches a client.

Where AI changes the calculation

AI is worth adding when there is a real classification problem: reading a PDF, sorting inbound email by topic, extracting fields from an unstructured document. Using it to "improve" a plain text email is usually not worth the cost or the latency.

The reason AI raises the stakes on checkpoints is that rule-based automation fails loudly and AI fails quietly. A broken rule throws an error. A language model returns a confident, well-formatted, entirely wrong answer, and it looks exactly like a correct one. That is a difference in failure mode, not just accuracy.

So the practical rule: where AI makes a judgement that reaches a client or a regulator, keep a person between the output and the outside world. Where it does internal sorting or drafting that a person will pick up anyway, you usually do not need a separate review step. For more on where AI earns its place at all, see AI business process automation.

Too many checkpoints is its own failure

This is the part that gets left out. A checkpoint is not free. It costs a person's attention and it adds delay. Put one on every step and you have rebuilt the manual process with more clicks, then paid for the automation as well.

Two ways this goes wrong:

Latency. A workflow with four approvals in it runs at the speed of the slowest approver. If your intake now takes three days because three people have to click through it, the automation has made the client experience worse, not better.

Rubber-stamping. This is the more dangerous one. When a review step fires a hundred times a week and the answer is almost always "approve," the reviewer stops reading. The checkpoint still exists on the process map. It is no longer doing anything, except manufacturing confidence that someone is checking. A review nobody genuinely performs is worse than no review, because it stops anyone else from looking.

The fix for both is the same: make checkpoints rare and make them meaningful. Route the exceptions to a person, not the whole volume. If a workflow runs 200 times a week and 190 are unremarkable, the design should surface the 10.

Which means you have to define what counts as an exception, and that is the work most teams skip. In practice it comes down to a short list of conditions the workflow can test. Examples are a value over a threshold, a new client or one with no agreed rate, a field the automation could not populate, or a variance from the last comparable job.

Where AI is involved, add a confidence score below a set level. Everything that trips one of those goes to a person. Everything else proceeds. Write the list down with the team, because if you cannot state the exception rule, you do not yet have a workflow to automate.

Monitoring is not a checkpoint

One more failure worth naming, because it catches people who think they have covered this.

A documented pattern in DIY automation: a reporting workflow ran for three weeks sending client reports that were technically successful and completely empty. Every run showed as a success. Nobody had built anything that checked whether the output was sensible, only whether the process completed.

A human checkpoint asks "is this right?" Monitoring asks "did it finish?" You need both, and they are not substitutes. If your only oversight is a green tick in a dashboard, you will find out about failures from a client. Any workflow that can produce a plausible but wrong output needs someone or something checking the content, not just the status.

When not to bother

Do not add a review step if any of these are true:

• The action is trivially reversible and internal. Nobody needs to approve a task being created.
• Nobody owns the review. An approval step assigned to "the team" is an approval step that will not happen. If you cannot name the person, do not build the checkpoint.
• The volume makes it impossible. If a step runs 500 times a week, a human review is not a checkpoint, it is a full-time job. Fix the input data or narrow the rule instead.
• You are using it to avoid agreeing on the process. A review step is sometimes added because the team cannot agree what the rule should be, so a person decides case by case forever. That is unresolved process debt wearing a checkpoint costume. Agree the rule.

If you are unsure which of your workflows even needs one yet, a Workflow Audit maps the current state and identifies where the risk actually sits before anything is built.