Human in the Loop AI: What It Is and How to Design It

Put simply, human in the loop is an approval step. It sits between what an AI system proposes and what happens in the world.

The system drafts, sorts or suggests. A named person reads the draft, with its evidence beside it. Then they approve it, edit it or reject it. Only then does the message send or the record change.

That costs reading time. So it belongs where a wrong output is costly or hard to undo. For the rest, a lighter design often fits better. In it, a person watches, checks samples and can stop the system. Most working systems mix all three designs, action by action.

Human in the loop, on the loop and out of the loop

The labels matter less than the question they force. For this action, what happens if the output is wrong? And who would notice?

Gartner is a research firm. It predicts over 40% of agentic AI projects will be canceled by the end of 2027. Agentic AI means AI that takes actions by itself. Gartner cites rising costs, unclear business value or weak risk controls. An approval step is a risk control you can point to.

Where should the human sit in an AI workflow?

Before the effect, not after it. A system can read freely. Approval belongs at the moment it acts.

That is when a message leaves, a record changes or money moves. It is when access is granted or taken away. And it is when a choice is made about a person.

We call the strict version the Approval Rule. Take an action on that list. Nothing takes effect until a named person approves it. "Someone could look at the output if they wanted to" is watching. It is not approval.

The rule can live inside a system that does plenty on its own. Take a build for a property manager. The agent chases late rent by itself. But blocking a late tenant's portal waits for a person to confirm.

Or take the phone system we are building for a medical practice. It has more than one site. Nothing is written to a patient's records until the caller confirms it. And anything off the script goes to staff.

Each system runs mostly on its own. Each has a gate right where the harm would be.

What should send an output to a person?

Five triggers cover most systems:

1. A topic flag. Some subjects always go to a person, no matter what the model thinks of its draft. In the coaching build, an injury mention stops the draft. So does a sensitive input. The flags run on 5 topic groups, 3 risk levels and 80+ trigger phrases.
2. Low confidence, measured. Don't ask the model how sure it is. Score it. An HR assistant we built scores each answer on three weighted parts. How well the sources it found match the question counts for 80%. How varied those sources are counts for 10%. How complete the answer is counts for the last 10%. A low score sends the question to a senior consultant.
3. An action that can't be undone. Payments, deletions, account blocks and things sent to a regulator.
4. Something new. Say a request falls outside what the system was tested on. No one knows its error rate there.
5. A person who isn't verified. Say a voice or chat agent hasn't confirmed who it is talking to. Then it should show nothing.

How the handoff happens matters as much as when. When the engine is unsure, the coach writes that reply in full. They don't edit a weak draft.

A bad draft, filled in up front, anchors the person to it. A blank one makes them think. A system that always gives an answer gives confident wrong ones. So let it say "not this one."

How do you stop reviewers rubber-stamping?

The risk has a name: automation bias. It is the habit of trusting a machine's output because it is right most of the time.

The EU AI Act writes it into law for high-risk systems. Article 14 says how they must be designed. The people in charge of them must be able to do three things:

• Stay aware of "automatically relying or over-relying on the output."
• Decide to "disregard, override or reverse the output."
• "Interrupt the system through a 'stop' button or a similar procedure."

In practice, five habits keep a review real:

• Put the evidence beside the draft. Show the input it answers, the sources it used and the flags it raised. Approval should be a check, not a feeling.
• Keep the volume readable. Take drafts per day, times the seconds each takes to review well. If that is more than the reviewer's day, the step will be stamped.
• Put a name on each approval. Record it with the model call. Then a bad output can be traced. You can see its inputs and the person who approved it.
• Audit a sample. A high approval rate is good news only when someone else checks a sample and agrees.
• Give the reviewer a real override and a stop. Make sure they know they are allowed to use them.

1234

1. 1In the coach’s voice. The draft comes in that coach’s own words.
2. 2Sensitivity and cycle. The engine takes the client’s cycle into account. It checks the wording before the coach sees it.
3. 3An injury flag. An injury mention stops the draft.
4. 4Nothing sends on its own. The coach approves it.

Say a reviewer approves more drafts in an hour than they can read. That is not a reviewer. That is a stamp. And a stamp is worse than no step at all. It looks like control.

Does human in the loop make AI slower?

It moves the work from writing to reading. And reading is faster.

Body Smart Fitness is the clearest case we have. Its 14 coaches each spent 15 hours a week writing client check-ins by hand. Each had 60 to 70 clients.

Now a drafting engine writes the first draft. It has a voice profile for each coach. Each profile is built from that coach's own past replies. The coach approves every message. Weekly writing fell to 10 minutes per coach. In the pilot, 90%+ of drafts were approved with no edit. Then the engine went to all 14 coaches.

The client counts the week another way. Its own public video puts the gain at about 8 hours back per coach per week. That is after every coach has read and approved every draft.

Both numbers are true. One counts the writing. The other counts the week.

That gap is the cost of the loop. Budget for it, and don't hide it. Count your own the same way. Take drafts a week, times the minutes it takes to read one well.

Human oversight and the law

The EU AI Act calls some systems high-risk. For those, Article 14 makes human oversight a design rule. A line in a policy is not enough. The people in charge of the system must be able to:

• Understand what it can and can't do.
• Monitor it.
• Read its output correctly.
• Override or reverse it.
• Stop it.

Take remote biometric identification, such as matching faces from a distance. There, no action may be taken on the result alone. It must first be "separately verified and confirmed by at least two natural persons."

Which rules apply to you depends on your field and where you do business. That reading belongs to your lawyer. Either way, the approval step belongs in your AI governance policy. List the actions that need it by name.

When not to put a human in the loop

The volume is more than anyone can read. Then the gate is theater. Shrink the volume. Or move the work on the loop, with sampling and a stop. Or don't automate it.

The output is low-stakes and easy to undo. A receipt does not need a reviewer. Use a template and keep the money.

No one qualified will review it. Medical advice and legal notices need a qualified person to write them. A tired one approving them is not enough. Use AI around that work, not inside it.

The plan is to quietly remove the person later. Then you are building a new kind of system, with a new risk. Design for it in the open from the start. Build in sampling, audit and a stop.