Full automation is a sales pitch. Keep a human where it counts.

The pitch is always the same. Straight-through processing. Zero touch. The invoice arrives, the system reads it, approves it, pays it, files it, and no human ever gets involved. Sounds like progress.

Then it pays a duplicate invoice for eleven grand, because the supplier sent it twice with a slightly different reference, and nobody was watching. Being unwatched was the whole point.

That’s the trap in “full automation.” Taking the person out of the loop doesn’t take the judgement out of the work. The judgement was doing something. It was catching the odd case, the thing that passed every rule and was still obviously wrong to anyone who glanced at it. Remove the glance and you don’t get a cleaner process. You get the same mistakes, made faster, found later, at scale.

Most workflows are three jobs wearing one coat

Pull any business process apart and you’ll find three kinds of step tangled together. The mistake is treating them the same.

Some steps are pure mechanics. Copy this field into that system, send the reminder, create the record, attach the file. There’s no decision in it, and a person doing it by hand is a person being wasted. Automate it outright and don’t look back.

Some steps are rules. If the amount is under the threshold, route it here. If the customer’s on the approved list, skip the check. These can be encoded, but log every one, so that six months later you can prove why the system did what it did instead of shrugging at an auditor.

And some steps are judgement. Approve the exception. Decide whether the evidence is good enough. Weigh a risk the rules never anticipated. This is the slow step everyone wants to automate, and it’s the exact one to be most careful about handing to a machine. Automate the mechanics, encode the rules, keep a person on the judgement. Blur the three together and you either automate nothing or you automate the wrong thing.

AI is brilliant at the prep and shaky at the call

Here’s where AI actually pulls its weight, and it isn’t where the hype puts it. AI is good at the messy front end of a decision. Reading a document, summarising a long and boring history, pulling the relevant records out of a system nobody can navigate, drafting a reply, sorting an incoming request onto the right desk. That’s the legwork, and it’s tedious for a person to do.

Take a supplier approval. The AI reads the certificate of currency, pulls the coverage dates, checks them against what your contract requires, flags that the public liability lapsed last month, and puts the whole thing in front of a person with the problem already circled. The person makes the call. The AI decided nothing. It just meant thirty seconds on a clear decision instead of ten minutes digging for the facts.

That’s the pattern that works, and it’s the shape of most of the applied AI work that survives contact with production. AI does the reading and the fetching. The human does the deciding. The moment you let the AI make the call unsupervised on anything that carries money, safety, legal weight or a customer’s trust, you’ve swapped a slow reliable process for a fast one that’s confidently wrong every so often. “Every so often, at scale” is a bad way to find out.

Decide the review point on purpose

“We’ll keep a human in the loop” is a line people say in the kickoff meeting and never pin down. So in practice the human ends up reviewing everything, and nothing gets faster, or reviewing nothing, and the whole thing runs unsupervised. Neither is what anyone wanted.

The review point is a design decision, and it should be explicit in version one. Maybe a person reviews every item while the system is young and you’re learning where it’s reliable. Maybe only the cases the AI itself flags as low-confidence. Maybe only transactions over a dollar figure, only messages going to external parties, only anything with a legal or safety edge. Those rules can and should move as you learn what the system gets right. But the first version needs a clear answer to “which cases does a human see, and why those?”

Make it concrete. An accounts team at a civil contractor handles about 400 supplier invoices a month. A sensible first design: anything under a thousand dollars from a known supplier with a matching purchase order goes straight through, which clears roughly two-thirds of the volume on day one. Everything else queues for a person, with the reason it queued highlighted. New suppliers always queue. Anything the extraction was unsure about always queues. Any invoice matching another by supplier and amount inside sixty days always queues, and that’s the rule that catches the eleven-grand duplicate from the top of this article. Nothing in that design is exotic. It’s just someone deciding, on purpose, which cases deserve eyes.

And the review screen has to actually help. If checking an AI-prepared task means opening five tabs to hunt down the source document, the extracted fields and the related history, people won’t review, they’ll rubber-stamp. Put the evidence in front of them: the source, what the AI pulled out, how confident it was, which rule checks passed, what the last few related records looked like. That screen is where a person decides whether to trust the system or quietly go back to doing it by hand, and a bad one guarantees the second outcome.

The loop rots if nobody watches it

A review point isn’t something you set at go-live and forget. Two failure modes creep in over the following months, and they pull in opposite directions.

The first is rubber-stamping. The queue grows, Friday afternoon arrives, and someone approves forty items in six minutes because the system is usually right. You can see it coming in the data: when the average review takes eight seconds, nobody is reviewing, they’re clicking. The fix is rarely a stern email about diligence. It’s volume. If the queue is clogged with cases that never needed judgement, tighten the rules so fewer items reach a person, and the ones that do will actually get looked at.

The second is the loop seizing when the person disappears. If one officer owns the queue and she takes two weeks of leave, the human in the loop becomes a two-week bottleneck, the backlog builds, and the pressure to just switch review off for a while gets loud. That’s how a carefully designed control quietly dies. Every review point needs a named backup and an escalation path before launch, not after the first pile-up.

And track one number from day one: how often the reviewer changes or rejects what the system prepared. That override rate is your evidence for loosening the leash. When a category of work has run for three months at ninety-something per cent agreement, widen the auto-approve rules for that category and spend the human attention where the overrides actually cluster. Loosening on numbers rather than vibes gets you most of the speed the zero-touch pitch promised, without giving up the person who catches the case the rules never met.

This isn’t the timid option

There’s a lingering idea that human-in-the-loop is a compromise, the thing you settle for until the technology’s good enough to cut the person out. That’s backwards. Keeping a person on the decisions that matter is how automation reaches production at all, because it’s how you keep a clear answer to the question that gets asked the day something goes wrong: who was responsible?

Auto-approve the lot and the answer is “the system,” which is another way of saying nobody, which is not an answer your insurer, your regulator or your customer will accept. The strongest workflow systems we build lean on more AI over time, not less, and they stay legible to the people who own the outcomes. The person spends their day on the fifteen cases that need a brain instead of the four hundred that don’t. That’s not a smaller job. It’s a better one.

If you’re trying to work out which parts of a process to automate outright and which to keep a person on, tell us the workflow and where it currently bites. The AI readiness assessment is a decent place to start mapping it.