Human in the loop AI is a design in which the system cannot complete an action until a person approves, edits or rejects it; the human is a required step, not an observer. It sits between "human on the loop", where the system acts on its own while a person monitors and can step in, and "human out of the loop", where no one is involved once it starts. The hard part is not adding an approve button. It is deciding which actions need one, and designing the review so the person actually checks instead of clicking yes.

What does human in the loop mean?

The terms come from autonomous weapons debates, where the question was how much human involvement a machine needs before it uses force. Human Rights Watch's 2012 report Losing Humanity set out the three categories that most AI writing still uses: machines that act "only with a human command", machines that act "under the oversight of a human operator who can override the robots' actions", and machines that act "without any human input or interaction".

Translated into business systems:

Mode What the human does Does the system wait? Typical use
Human in the loop Approves, edits or rejects each output before it takes effect Yes Payments, refunds, contract terms, messages to customers in a new process
Human on the loop Watches dashboards and samples, intervenes when something looks wrong No High volume, low risk work such as tagging and routing
Human out of the loop Nothing per case; reviews performance periodically No Reversible, internal, well tested steps

Most real systems mix all three. An invoice pipeline might extract fields with no human involvement, route exceptions to a person on the loop, and put every payment above a threshold in front of a person in the loop. Our article on invoice processing automation shows that layering in one process.

Where should approval gates go in an AI system?

Put a gate wherever a mistake is expensive to undo. Four kinds of action qualify almost every time:

  1. Irreversible actions. Deleting records, cancelling orders, sending a message that cannot be recalled.
  2. External actions. Anything a customer, supplier, regulator or the public will see.
  3. Financial actions. Payments, refunds, credits, price changes.
  4. Legal actions. Accepting terms, signing, making commitments on the company's behalf.

The model vendors' own guidance draws the same line. OpenAI's guide to building agents names two triggers for human intervention: exceeding failure thresholds, where you should "set limits on agent retries or actions", and high-risk actions: "Actions that are sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent's reliability grows." Its examples are cancelling user orders, authorizing large refunds and making payments. The same guide recommends rating every tool low, medium or high on read-only vs. write access, reversibility, required account permissions, and financial impact and using the rating to decide when to pause.

Anthropic's framework for trustworthy agents makes the same point with an example: an agent managing expenses spots overspending on software subscriptions, and "Before it starts cancelling subscriptions or downgrading service tiers, the company would likely want a human to give approval."

Gates also limit damage from attacks. An agent that reads emails or web pages can be manipulated by text planted in them, which is why approval gates are one of the defenses we cover in prompt injection attacks: a manipulated agent that cannot pay without a human cannot pay an attacker either.

Why do human reviewers rubber-stamp AI output?

Because people over-trust automated advice, especially when it is usually right. Researchers call this automation bias. A systematic review in the Journal of the American Medical Informatics Association defines it as "the tendency to over-rely on automation" and screened 13,821 papers down to 74 that met its criteria. It describes two error types: errors of commission (following incorrect advice) and omission (failing to act because of not being prompted to do so).

The numbers are uncomfortable. In four pooled healthcare studies, when the decision support was wrong it increased the risk of an incorrect decision being made by 26% compared with no support. In comparable studies, the share of cases where a clinician switched from a correct answer to the system's wrong one ranged from 6% to 11%. These were trained professionals, and the review found that workload, task complexity, and time constraint made it worse.

So a human in the loop is not a safeguard by default. A tired person approving 300 drafts an hour is a stamp, and the EU AI Act names the problem explicitly, as the section on the law below shows.

How do you design a review queue people actually use?

The same review lists what reduced automation bias: training and emphasizing user accountability, and design choices such as the position of advice on the screen, updated confidence levels attached to DSS output, and the provision of information versus recommendation. Turned into rules for an AI review queue:

  1. Show the evidence, not just the answer. Put the source document, the extracted field and the place it came from side by side, so checking takes seconds.
  2. Show uncertainty per case. Flag low confidence and unusual cases individually instead of one overall accuracy figure for the system.
  3. Ask for a decision, not a click. Make the reviewer choose approve, edit or reject with a reason code. A reason code is also your best source of new test cases.
  4. Name the owner. Every approval carries the reviewer's name. The review found accountability improved vigilance.
  5. Send fewer, better cases. Only route the cases the gate exists for. If everything needs approval, nothing gets reviewed.
  6. Measure the override rate. If reviewers change almost nothing for months, either the system is ready for the next level of autonomy or nobody is reading. Seed known errors occasionally to find out which.
  7. Budget the time. Volume times minutes per case is a staffing number. Plan it before launch, not after the queue backs up.

How do AI agent frameworks implement human in the loop?

As a pause, a decision and a resume. OpenAI's Agents SDK documents a human-in-the-loop flow that will "pause agent execution until a person approves or rejects sensitive tool calls". A tool is marked with needs_approval, either always or through a function that decides per call. Paused runs surface the pending calls as interruptions, and the state can be serialized, so an approval can wait hours in a queue and the run resumes after the decision. When a reviewer rejects a call, a rejection message is returned into the run instead of the tool result.

Anthropic describes the same pattern in Claude Code: its framework says Claude Code has read-only permissions by default and must ask for human approval before taking any actions that modify code or systems, while users can grant persistent permissions for routine tasks they trust it with. That last part is the graduation path: approvals start per action and become standing permissions as trust is earned.

The design lesson is to put the gate in the tool layer, enforced by code, rather than in the prompt. A model told "always ask first" can be talked out of it. A tool that cannot execute without a stored approval cannot.

What does the EU AI Act say about human oversight?

Article 14 of the EU AI Act sets the rule for high-risk AI systems, such as those used in employment, education or critical infrastructure. They "shall be designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use."

The people assigned to oversight must be enabled, among other things, to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias), to disregard, override or reverse the output, and to interrupt the system through "a 'stop' button or a similar procedure". Companies that use such systems have their own duty under Article 26: they "shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support."

Check the dates before you plan around them. The AI Omnibus, which the European Commission says entered into force on 27 July 2026, moved the high-risk rules. Article 113 now says they apply from 2 December 2027 for high-risk systems listed in Annex III and 2 August 2028 for those under Annex I. Annex III lists uses such as filtering job applications and evaluating creditworthiness; drafting replies, extracting invoice fields and routing tickets are not on that list. Even so, Article 14 is the clearest written standard for what effective oversight means. This is general information, not legal advice.

When can you take the human out of the loop?

When the numbers say so, one action type at a time. Run the gate, log every decision, and watch three figures: the override rate, the error rate found in sampled reviews of auto-approved cases, and the cost of the worst error you saw. When overrides stay rare and the worst error is cheap to reverse, move that action from in the loop to on the loop, keep sampling, and leave irreversible, financial and legal actions behind a gate for good. If you want this built into a system from the start, Qubba designs AI systems with review points at the actions that need them, and the same rules belong in your staff AI acceptable use policy for the AI tools people use directly.

Frequently asked questions

Is human in the loop required by law?

Not in general.
The EU AI Act requires human oversight for high-risk systems under Article 14, on the dates above.
For other systems it is a design choice, though a sensible one wherever an error would be costly.
Sector rules and data protection law can add requirements of their own, so check those for your industry.

Does human in the loop slow everything down?

Only for the cases that pass through a gate.
Designed well, the model handles the routine volume, and people see the minority of cases that are risky or uncertain.
The slowdown that hurts is a gate on everything, which also produces the rubber-stamping described above.

Who should be the human in the loop?

Someone who could do the task without the AI and has the authority to say no.
Article 26 of the EU AI Act asks for competence, training and authority for exactly this reason.
A junior reviewer who cannot reject the system's output in practice is not oversight.

What is the difference between human in the loop and human on the loop?

In the loop, the system waits for a person before acting.
On the loop, the system acts and a person supervises with the power to override, the distinction Human Rights Watch drew in 2012.
On the loop suits high volume, reversible work; in the loop suits actions you cannot take back.