Ivara Labs
"Human in the loop" has become the phrase people reach for when they want an automation to sound safe. It is said in demos, written into decks, and very rarely designed.
The tell is simple. Ask who the human is, what they see, how long they spend, and what proportion of items they reject. In most systems the honest answers are: whoever is available, a summary, four seconds, and almost none. That is not oversight. That is a person laundering the automation's decision, carrying the accountability without the ability to disagree.
Getting this right is a design problem with a small number of real choices. Here they are.
The human can sit in three places
Most discussion collapses into a single idea — a person approves things. There are actually three distinct placements, and they behave completely differently.
Human in the loop
The system stops and waits. Nothing happens without a decision.
Use for: irreversible or expensive actions. Sending money, publishing, deleting, anything a client sees. Cost: it is a bottleneck by design, so it does not survive high volume.
Human on the loop
The system acts. A person watches and can intervene.
Use for: reversible actions with fast, reliable detection. Drafting, classifying, routing, scheduling. Cost: worthless if nothing surfaces the errors quickly.
Human over the loop
A person sets the rules and reviews patterns, never individual cases.
Use for: high volume, low stakes, individually trivial. Tagging, deduplication, first-pass triage. Cost: systematic errors can run a long way before anyone notices.
Choosing the wrong placement is the most common design failure, in both directions.
Put a blocking human on a workflow running two hundred times a day and you have built something slower than the manual process you replaced, plus a queue that becomes somebody's whole job. Put an over-the-loop human on an irreversible action and you have automated a decision nobody agreed to.
Choosing the placement
Three properties decide it. They are the same properties that determine whether a workflow is a good automation candidate at all, which we cover in what to automate first.
| If the action is | And errors are | At volume | Put the human |
|---|---|---|---|
| Irreversible | Costly | Any | IN the loop |
| Reversible | Detected fast | Moderate to high | ON the loop |
| Reversible | Trivial | Very high | OVER the loop |
| Reversible | Detected slowly | Any | IN the loop |
That last row is the one people get wrong. Reversibility is not sufficient on its own. An error you could undo but will not notice for six weeks is functionally irreversible, because by the time you find it the damage is downstream. Detectability decides more than reversibility does.
Regulated publishing is the clearest case for a blocking gate. In veterinary marketing, advertising rules differ by state and province, so nothing should go live until it has cleared the rules of that exact jurisdiction — a decision no amount of monitoring after the fact can undo.
An automation that fails loudly is a nuisance. One that fails quietly is worse than the manual process it replaced.
How to tell if your approval is theatre
If you already have a human in the loop, these are the signs it is not doing the work you think it is.
Rubber stamp diagnostics
- Approval rate above ~97%. Either the automation is genuinely excellent, or nobody is really reading. Check which by sampling rejected-in-hindsight items.
- Median review time below the time it takes to read the item. A four second decision on a two paragraph draft is a click, not a review.
- The approver cannot describe what would make them reject. If there is no articulated threshold, there is no judgement being applied.
- Rejecting is harder than approving. If approve is one click and reject opens a form, the design has an opinion and people will follow it.
- The queue is somebody's overflow work. Oversight assigned to whoever has capacity is oversight nobody owns.
- Nothing records why. Without captured reasons, you cannot improve the automation or defend the decision later.
Designing an approval that means something
Four changes do most of the work.
Show the evidence, not just the answer. People over-trust confident machine output — a well documented effect in human factors research, usually called automation bias. If the screen leads with the recommendation, the human's job silently becomes agreeing with it. Lead with what the system found, then what it concluded.
Make rejection as cheap as approval. One click either way. Capture the reason with a short pick list rather than free text, so reasons become data you can act on.
Separate the easy from the hard. Batch approve the high confidence items in one action, and give the uncertain ones a full screen each. Reviewing two hundred identical cards guarantees the twelve that mattered get the same four seconds as the rest.
Surface uncertainty honestly. If the system is unsure, say so prominently. An automation that presents every output with equal confidence has thrown away the most useful thing it knows.
The exception queue is the product
Most teams build the automation and treat exceptions as leftovers — a spillover list nobody designed. That is backwards. The automated path handles the cases where judgement adds nothing. The exception queue is precisely where human judgement concentrates, which makes it the part most worth designing well.
A good exception queue has an owner by name, a target response time, the full context needed to decide without opening three other systems, and a route back into the automation so recurring exceptions become handled cases over time. If exceptions only ever accumulate, the automation is not learning and someone is slowly acquiring a second job.
What should stay human regardless
Some decisions are not automation candidates at any confidence level, and not because the model would get them wrong.
Keep these with people
- Decisions where a person deserves a person. Bad news, refusals, anything about someone's employment or their animal's health. Efficiency is not the value being optimised.
- Judgement that depends on context the system cannot see. A pricing exception for a client having a hard year is a relationship decision wearing a pricing decision's clothes.
- Anything where the reason matters as much as the outcome. If you would have to explain the decision to a regulator, a client or a court, a person should have made it.
- Novel situations. Automation is pattern matching. The first time something happens, there is no pattern, and confident output is exactly the wrong response.
This is also a reason to decline work. If the only way to make a workflow economical is to remove judgement that should have stayed human, the honest answer is that it should not be built.
How we build this
Every automation we ship carries an exception queue and an audit trail, and a human approval wherever a mistake would cost real money. In our own operation nothing publishes, sends or spends without a green light from a person.
AI carries the repetition — intake, triage, drafting, reporting. Decisions stay with your team. That is one of our standards, and during mapping we tell you plainly what AI should carry and what it should not, because an automation that guesses wrong costs more than the manual work it replaced.
If you are weighing where the line sits in your own operation, that conversation is what we build, and it starts with the map.
Frequently asked questions
- What does human in the loop actually mean?
- A design where the system stops and waits for a person's decision before it acts. It is distinct from human on the loop, where the system acts and a person monitors, and human over the loop, where a person sets policy and reviews patterns rather than individual cases.
- When should AI require human approval?
- When the action is irreversible or expensive, or when errors would be detected slowly. Slow detection matters more than reversibility: a mistake you could undo but will not notice for weeks behaves like one you cannot undo at all.
- How do I know if my approval step is just a rubber stamp?
- Check the approval rate, the median review time, and whether the approver can articulate what would make them reject. Approval rates above about 97%, review times shorter than the time needed to read the item, and no captured reasons all point to theatre rather than oversight.
- What is automation bias?
- The documented tendency for people to over-trust automated recommendations and under-scrutinise them. It is why approval screens should show the underlying evidence before the system's conclusion, rather than leading with the answer.
- What should never be automated?
- Decisions where a person deserves a person, judgement that depends on context the system cannot see, anything where the reasoning must be explained to a regulator or client, and novel situations with no established pattern.