Human in the Loop vs Human on the Loop: Which Do Your AI Agents, Automations and Applications Need?

Human in the loop vs human on the loop comes down to one question: does a person approve the action before it happens, or watch and step in after it has started? Human in the loop (HITL) puts a person’s decision inside the process, so nothing happens until they say yes. Human on the loop (HOTL) lets the system act on its own while a person monitors it and can stop, override or reverse it.

For AI agents, automations and applications that act on real systems, you will almost always need both. The useful question is not which model to pick for the whole system. It is which model to apply to each action it can take.

At a glance

• Human in the loop (HITL): a person approves each decision before it takes effect. Slow, but nothing irreversible happens without a named human.
• Human on the loop (HOTL): the system acts; a person supervises, gets alerts, and can intervene or stop it. Fast, but harm can happen before anyone looks.
• Human out of the loop: no routine human involvement. Fine for low-stakes, reversible, well-tested tasks.
• Decide per action, not per system. Whether the action comes from an AI agent, an automation or an application, reading a ticket and wiring money should not share an oversight model.
• The law cares about effectiveness, not labels. Article 14 of the EU AI Act asks that overseers can understand, override and stop a high-risk system, and that they stay aware of automation bias. For standalone high-risk (Annex III) systems this applies from 2 December 2027 after the Digital Omnibus delay.
• A gate nobody reads is not oversight. If 99% of approvals are clicked through in seconds, you have a rubber stamp, not a control.

What do human in the loop and human on the loop actually mean?

The terms come from military and control-systems engineering, and the European Commission’s High-Level Expert Group on AI gave them their most cited governance definitions in its Ethics Guidelines for Trustworthy AI (April 2019). That document describes three levels: human in the loop, human on the loop, and human in command.

Human in the loop means a person takes part in every decision cycle. The AI proposes; the human disposes. A loan officer who sees a model’s recommendation and then signs the decision is in the loop. So is a security analyst who must approve each firewall change an agent suggests.

Human on the loop means a person oversees the system while it runs and can intervene. They design the boundaries, watch dashboards and alerts, review samples, and hold the authority to pause or reverse. A fraud team watching an automated transaction-blocking system, and stepping in when the false-positive rate jumps, is on the loop.

Human in command sits above both. It is the ability to decide whether, when and how an AI system is used at all, including the decision to switch it off. Most competitor guides skip this level, yet it is the one boards and regulators ask about first: who can turn this thing off, and have they ever tested that they can?

How are they different in practice?

	Human in the loop	Human on the loop	Human out of the loop
When the human acts	Before each decision takes effect	During or after, by exception	Only at design and audit
Speed	Limited by human response time	Machine speed	Machine speed
Who carries the decision	The approving person	The system, with a supervisor accountable	The system owner
Main failure mode	Rubber-stamping, queue backlogs	Harm happens before anyone notices	Silent drift, no one watching
Evidence you get	A signed approval per action	Monitoring logs, alerts, interventions	Test results, periodic reviews
Typical actions	Payments, deletions, access changes, messages to customers or regulators	Drafting, triage, routing, internal updates	Summarising, tagging, search

The difference that matters most for a CISO is timing. HITL stops a bad action before it lands. HOTL limits how long a bad action runs. With a traditional predictive model, a delay of a few minutes before a human notices is often acceptable. With an AI agent that can call 40 tools in a minute, or an automation that runs 10,000 times overnight, a few minutes is a long time.

The second difference is evidence. A HITL gate produces a record per decision: who approved, what they saw, when. HOTL produces aggregate evidence: what was monitored, which thresholds fired, who intervened. Auditors working against ISO/IEC 42001 or the EU AI Act will ask for both kinds, so plan your logging before you plan your dashboards.

Why does this matter more for agents, automations and applications than for models?

A classifier produces an output and stops. An agent plans, calls tools, reads the results and acts again. Automations and applications act too: a workflow fires on every new record, and an application writes to a live database whenever someone presses a button. Each step can change data, spend money or send a message. That changes the oversight question from “is this output correct?” to “should this action be allowed to happen at all?”

Agents also chain actions. An agent asked to “clean up stale customer records” might query a CRM, decide which records are stale, export them, then delete them. A human on the loop who reviews a daily summary sees the deletion the next morning. A human in the loop gate on the delete step alone would have caught it, while letting the query and export run at full speed.

This is why “per action, not per system” is the rule that holds up. You keep the speed on the 90% of steps that are harmless and put a person in front of the few that are not. In @Human, every instance runs its own MCP server, and a live instance exposes 296 tools to agents. Zero of those tools can sign an approval gate. Only an accountable human can.

What does the EU AI Act require for human oversight?

Article 14 of Regulation (EU) 2024/1689, the EU AI Act, requires that high-risk AI systems are designed so that natural persons can oversee them effectively while they are in use. It does not say “use HITL” or “use HOTL”. It lists what the overseer must be able to do. In plain terms, the people assigned to oversight must be able to:

• understand the system’s capabilities and limits, and spot anomalies or unexpected behaviour;
• stay aware of automation bias, the tendency to over-trust the system’s output;
• interpret the output correctly;
• decide not to use the output, or override or reverse it;
• intervene, or stop the system through a “stop” button or a similar procedure.

For certain remote biometric identification systems, Article 14 goes further: no action may be taken on an identification unless at least two people have separately verified it. That is a HITL requirement with two humans, written into law.

Article 26 then puts duties on deployers, the organisations using the system: assign oversight to people who have the competence, training and authority to do it. Authority is the word to underline. A reviewer who cannot actually block an action is decoration.

On timing: the Digital Omnibus on AI, Regulation (EU) 2026/1744, entered into force on 27 July 2026. It moved the high-risk obligations for standalone Annex III systems from 2 August 2026 to 2 December 2027, and for AI embedded in Annex I regulated products to 2 August 2028. The transparency rules in Article 50 kept their August 2026 date. Penalties under Article 99 still reach up to €35m or 7% of worldwide annual turnover for prohibited practices, and up to €15m or 3% for most other breaches. Fifteen months sounds like a lot of runway until you count procurement, design, testing and staff training.

Outside the EU, the NIST AI Risk Management Framework asks organisations, under its Govern function, to define roles and responsibilities for human-AI configurations and oversight. ISO/IEC 42001 expects you to define, resource and evidence the oversight you claim. Different wording, same test: can you show who oversees what, and prove they could step in?

How do you choose? A five-question test for each action

Run every action an AI agent, automation or application can take through these five questions. If any answer is “yes”, put a human in the loop for that action.

1. Is it hard to reverse? Deleting data, sending external messages, moving money, publishing content, changing access rights. Reversible actions can usually be supervised on the loop.
2. Does it touch people’s rights or safety? Decisions about credit, employment, benefits, healthcare or education fall into the EU AI Act’s high-risk areas for good reason.
3. Is the blast radius large? One record is different from 50,000. Set a threshold (amount, row count, number of recipients) above which the action needs approval.
4. Is it novel? An action type, customer segment or data source the system has not handled before deserves a human the first few hundred times.
5. Would you have to explain it to a regulator, auditor or journalist? If the honest answer is yes, you want a named person’s signature on it, not a log line.

If all five answers are “no”, human on the loop is usually right: let it act, monitor with clear thresholds, and sample its work. If the action is also trivial and well tested (summarising, tagging, searching), human out of the loop with periodic audit is fine.

Two adjustments keep this honest. First, revisit the answers when an agent gets new tools or an automation or application gets new permissions, because one change can quietly turn a read-only system into one that writes. Second, prefer a programmatic step to an agentic one wherever both would work. A tested script that always does the same thing needs far less oversight than an agent deciding what to do each time. That principle, programmatic before agentic, is how @Human picks between the two, and it lowers token costs too.

How do you stop human in the loop turning into rubber-stamping?

Automation bias is the quiet failure of every HITL design. Approvers see hundreds of requests, nearly all of them fine, and start clicking yes without reading. The control still exists on paper. In practice it has gone.

Watch three numbers for every approval gate: the approval rate, the median time to approve, and how often approvers change or reject the request. A gate where 99.5% of requests are approved in under ten seconds and none are ever edited is telling you something. Either the gate is in the wrong place and should become on-the-loop monitoring, or the approver is not really looking.

Practical fixes that work:

• Show the approver what matters. The proposed action, the data it touches, why the agent or workflow proposed it, and what happens if they say no. Not a wall of JSON.
• Make gates rarer and sharper. Fewer, better-placed gates get real attention. Use thresholds so small, routine actions flow through.
• Require a reason for high-impact approvals, and occasionally insert known-bad test requests to check that reviewers catch them.
• Name the approver. A signed approval by a specific accountable role carries weight. An “approved by: system” field does not.
• Escalate when nobody answers. Decide in advance what happens if the approver is on leave: the action waits, goes to a deputy, or is refused. Never default to approve.
• Make a signature lapse when the thing it approved changes. An approval given to version 3 should not quietly carry over to version 4.

How do you make human on the loop real?

HOTL fails differently: everybody assumes somebody else is watching. Effective on-the-loop oversight needs four things written down.

• Thresholds that trigger a human. Error rate, cost per hour, number of actions, unusual tool calls, confidence below a set level. Each threshold names who gets alerted and how fast they must respond.
• A tested stop. A way to pause one agent, automation or application, or all of them, held by a named role, and rehearsed. Article 14 explicitly mentions a “stop” button. You should also be able to run the business with AI switched off; @Human is built so you can always unplug.
• Sampling. Review a fixed share of routine actions every week, even when no alert fires. This is how you catch slow drift.
• Incident records. Every intervention logged as an incident with cause, impact and fix, linked to the risk scenario it relates to. This is your evidence for auditors and your input for tightening the design.

Here is what that looks like for a customer support agent. The agent answers tickets on its own, so it runs on the loop. Two runtime enforcements check every reply: one blocks refund or legal promises, the other rephrases compensation wording. Monitoring rules then watch the enforcements themselves. If the agent keeps producing replies that get withheld, or starts deleting tickets in bulk, a person is alerted. No reply waits for approval, yet nothing the business has not authorised reaches a customer.

How does @Human handle human oversight for AI agents, automations and applications?

@Human by Planet Crust is the open-source, compliance-first AI platform for organisations that answer to somebody. You build compliance-led AI agents, automations and applications in one place, and oversight is built into how each one is defined, not added afterwards.

• Signed approval gates on any action you choose. AI agents and automations cannot sign a gate; only an accountable human role can. That is your HITL layer, with evidence per decision.
• Runtime guardrails and enforcement, plus monitoring and incident tracking for the HOTL layer.
• Accountable roles, risk scenarios and a sensitive-data register, so every gate and alert maps to a named owner and a known risk.
• Classification of every system against the EU AI Act and ISO/IEC 42001, so you know which actions sit in high-risk territory before you design the oversight.
• Self-hosted and open source. Your data and models stay with you, you can use any AI provider, and you can run with AI switched off.

Pricing is pay what you can, from €1 a month for the whole open-source platform, with support plans for larger organisations and free builds for not-for-profits. You can also read.

Checklist: human oversight for AI agents, automations and applications

1. List every action each AI agent, automation and application can take.
2. Run each action through the five-question test. Mark it HITL, HOTL or out of the loop.
3. Put signed approval gates on every HITL action, with a named accountable role and a deputy.
4. Set HOTL thresholds, alert routes and response times. Write them down.
5. Build and rehearse a stop for each system and for all of them at once.
6. Track approval rate, time to approve and edit rate on every gate. Move or fix gates that have become rubber stamps.
7. Sample routine actions weekly.
8. Log every intervention as an incident tied to a risk scenario.
9. Re-run the test whenever an agent gets a new tool or an automation or application gets new permissions.
10. Check your dates: 2 December 2027 for standalone high-risk systems under the EU AI Act.

Frequently asked questions

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

In human in the loop, a person must approve a decision before it takes effect. In human on the loop, the system acts on its own and a person supervises, with the power to intervene or stop it.

Is human on the loop enough for EU AI Act compliance?

It can be, if the overseers can genuinely understand, override and stop the system as Article 14 requires. For irreversible or high-impact actions, most organisations will still want a human-in-the-loop gate, and some biometric uses legally require two people to verify.

What is human out of the loop?

The system operates with no routine human involvement. People design, test and audit it, but do not supervise individual decisions. It suits low-risk, reversible, well-tested tasks only.

What is human in command?

Human in command is the authority to decide whether and how an AI system is used at all, including switching it off. The EU High-Level Expert Group on AI listed it alongside HITL and HOTL in 2019.

When do the EU AI Act human oversight rules apply?

For standalone high-risk AI systems listed in Annex III, from 2 December 2027, after the Digital Omnibus (Regulation (EU) 2026/1744) moved the original 2 August 2026 date. For AI inside Annex I regulated products, from 2 August 2028.

Can an AI agent or automation approve an action instead of a person?

Technically you can build that, but it is not human oversight and will not satisfy Article 14. In @Human, no agent or automation can sign an approval gate. Only an accountable person can.

How do I know if my human-in-the-loop gate is working?

Track approval rate, time to approve and how often reviewers edit or reject. Near-100% approval in seconds with no edits means the gate is either misplaced or being rubber-stamped.

---

Want to see signed approval gates and runtime guardrails on your own AI agents, automations and applications? Book a free walkthrough. A real person replies within one working day.