What is Human-in-the-Loop?
Human-in-the-Loop (HITL) is a way of designing AI systems in which the AI may analyse, recommend or draft, but a person with authority must review and decide before the action takes effect. In short: the AI prepares, a human decides.
The term is widely used in the Ethics Guidelines for Trustworthy AI published in 2019 by the European Commission's High-Level Expert Group on AI. The guidelines name three ways to secure human oversight: human-in-the-loop, human-on-the-loop and human-in-command.
In machine learning, HITL also has a narrower meaning: people label data and grade outputs so a model can be retrained. This article uses the broader meaning common in business operations: a human approval point inside a process that an AI Agent or automated system is executing.
A simple example
Illustrative example: an AI Agent reads a customer complaint, checks the order history and drafts a reply together with a proposed refund. The reply is sent and the refund created only when a customer-service agent clicks approve. If the agent edits or rejects it, the system records why.
What HITL is not
- It is not a person redoing the AI's work: the reviewer looks at a prepared result.
- It is not a ceremonial “OK” button: the reviewer must see enough information and have the power to stop.
- It is not required at every step: it belongs where an error has meaningful consequences.
HITL vs HOTL vs full automation
The three levels of human involvement differ on one question: may the system act before a person has looked? With HITL, no. With human-on-the-loop (HOTL), the system acts within set limits while a person supervises through dashboards and alerts and intervenes when something looks wrong. With full automation, people mainly design the rules up front and review periodically afterwards.
No level is “better” everywhere. One system can use all three for different kinds of action. The table below helps choose the right level per action, not per system.
| Level | What the human does | Strengths | Limits | Fits when | Illustrative example |
|---|---|---|---|---|---|
| Human-in-the-Loop (HITL) | Approves, edits or rejects before the action takes effect | Highest control, clear accountability | Slower, costs reviewer time, drifts into rubber-stamping at high volume | The action is hard to undo, affects someone's rights or interests, or the law requires it | Sending a student assessment result to parents |
| Human-on-the-Loop (HOTL) | Monitors while the system runs, receives alerts, can pause or reverse | Fast and scalable, with a person still accountable | Errors can spread to many items before anyone notices | Medium risk, easy to reverse, good logs and alerts in place | Classifying and tagging customer support tickets |
| Full automation | Sets initial rules, samples periodically, handles incidents | Highest speed and scale | Few chances to catch an error in time | Low risk, high volume, trivially reversible | Spam filtering, normalising data formats |
When HITL is mandatory under Vietnamese law
Vietnam's Law on Artificial Intelligence No. 134/2025/QH15 took effect on 1 March 2026 (Article 34). Article 4(2) sets the foundational principle: AI serves people and does not replace human authority and responsibility, and human control and the ability to intervene must be maintained over all decisions and behaviour of AI systems. Article 7(4) also prohibits obstructing, disabling or falsifying human supervision, intervention and control mechanisms.
The law does not use the phrase “human-in-the-loop” and does not require every output of every system to be approved. What it requires is real control and the ability to intervene. How far that goes depends on the risk classification under Article 9. For an overview of the law, see Vietnam's AI Law 2025.
High-risk AI systems
For high-risk systems the duties become concrete. Article 14(1)(d) requires providers to design systems that ensure human oversight and intervention. Article 14(2)(b) requires deployers to ensure human intervention during use. Article 14(1)(c) requires technical documentation and activity logs at the level needed for conformity assessment and post-deployment inspection.
Decision 33/2026/QD-TTg (signed 30 June 2026, in force 15 August 2026) issues the List of high-risk AI systems. According to published reporting on the Decision (Báo Pháp Luật Việt Nam), it covers 46 systems in 6 sectors: education; ethnic and religious affairs; health; banking; judicial proceedings; and transport. Article 1(2) of the Decision restates that using AI does not change, transfer or remove the authority and responsibility of the competent person, and that human supervision, control and intervention must be ensured during operation.
- Education: AI providing self-study content under the curriculum using uncontrolled data sources; AI that automatically tests, assesses or ranks learners; AI that monitors and analyses learner behaviour.
- Banking: AI that automatically executes electronic transactions; AI that automatically decides on credit.
- Health: AI-assisted surgery systems and surgical robots.
Deadlines and sensitive sectors
Listed systems already running before 15 August 2026 must complete their compliance obligations before 1 September 2027 in health, education and finance, and before 1 March 2027 in other sectors. Article 35 of the Law separately gives systems running before 1 March 2026 a transition period of 18 months (health, education, finance) or 12 months (other sectors).
Beyond the list, Article 6 requires stricter risk management in essential sectors; for education, that means preventing risks in assessing, classifying and affecting learners. For public bodies, Article 27(2) states that an AI system does not replace the decision-maker's authority and responsibility.
Deciding where approval points go
The law sets the floor. Within it, a business still has to decide which steps need a human. A practical method is to list every action the AI can take and score each against the four questions below. One “yes” among the first three is enough to put HITL on that action.
- Is the action hard or impossible to undo (sending externally, moving money, deleting data, publishing)?
- Does the result directly affect a specific person's rights, interests or opportunities (a student, customer, applicant, borrower)?
- Does the action fall under the high-risk list or an essential sector?
- If an error went unnoticed for a week, would the consequence be acceptable? If not, at least HOTL with alerts is needed.
Volume decides the mechanism
Once a human must be involved, volume decides how. Low volume: approve every item. Medium volume: approve every exception plus a sample. High volume where the risk allows: move to HOTL, approving exceptions only and reviewing samples periodically. Write the thresholds down and review them when volume or quality changes.
The NIST AI RMF does not impose a single oversight pattern; it places roles, measurement and risk management within its four functions, Govern, Map, Measure and Manage. Deciding per class of action, as above, fits that approach.
Designing an effective approval queue
An approval point only works if the reviewer can see what they are approving, understands the consequence and can stop it. Article 14 of the EU AI Act says overseers must understand the system's capabilities and limits, stay aware of the tendency to over-rely on automated output (automation bias), and be able to disregard, override or stop the system. Although that is EU law, these requirements make a good checklist for any approval queue.
What each queue item should show
- The original request and the input data the AI used, with sources.
- The draft or proposed action, and how it differs from the current state.
- The reasons or evidence the system offers, plus the points it is unsure about.
- The consequence of approving (who receives it, what amount, which data changes) and whether it can be undone.
- Three clear choices: approve, edit then approve, reject with a reason.
The rejection path and time limits
The rejection path decides long-term quality. Rejected items must return to a queue with an owner, and the reason must be recorded in structured form so the team can review it when updating the AI's instructions. Every queue also needs a time limit and a backup reviewer: if nobody has approved an item in time, it escalates rather than being approved automatically.
Preventing rubber-stamping
- Don't let one reviewer process too many items in a row; rotate or cap the number.
- Occasionally insert test items with a known answer to measure attention.
- Track approval rate and time per item; near-100% approvals in a few seconds is a signal to look closer.
- Separate duties: whoever configures the AI does not approve that configuration's output on high-risk actions.
Logging: who decided, when, and on what basis
Every decision in the queue should leave a record: the request, the AI's draft, the changes, the approver, the time and the reason. That record serves three purposes: tracing incidents, improving the AI's instructions, and meeting the activity-log duty for high-risk systems under Article 14(1)(c). Article 28(3) of the Law also requires organisations to provide technical documentation and logs during inspections.
Store logs where neither reviewers nor AI operators can edit them, with access control and a defined retention period. Designing permissions and logs for AI Agents is covered in detail in access control and audit logs for AI Agents.
A rollout plan for HITL
Teams usually start a new system with strict HITL, then relax to HOTL for action types that have enough data showing stable quality. The reverse, automating everything and adding approval points after an incident, tends to cost more.
- List the actions the AI can take and classify their risk under Article 9; check them against the high-risk list.
- Choose HITL, HOTL or automation for each action type; name the person with approval authority.
- Design the queue with full context, a rejection path, time limits and a backup reviewer.
- Turn on tamper-proof logging before going live.
- Measure edit rate, rejection rate and review time monthly; relax control only when the numbers support it.
- Review again when the process, the AI model or the regulation changes.
Frequently asked questions
What is Human-in-the-Loop?
Human-in-the-Loop is a way of designing AI systems in which the AI analyses and proposes, and a person with authority must approve, edit or reject before the action takes effect. In short: the AI prepares, a person decides, and every decision is logged.
What is the difference between Human-in-the-Loop and Human-on-the-Loop?
HITL requires approval before an action. HOTL lets the system act within set limits while a person supervises through alerts and can pause or reverse it when something goes wrong.
Does Vietnam's AI Law require a human to approve every AI output?
No. Article 4(2) of Law 134/2025/QH15 requires human control and the ability to intervene to be maintained; for high-risk systems, Article 14 requires design and operation that ensure human oversight and intervention. The exact level depends on each system's risk.
Which education AI systems are high-risk in Vietnam?
Under Decision 33/2026/QD-TTg: AI providing self-study content using uncontrolled data sources, AI that automatically tests, assesses or ranks learners, and AI that monitors and analyses learner behaviour. Read the annex itself before classifying your own system.
How do you stop reviewers from just clicking approve?
Show full evidence and consequences, cap how many items one person reviews in a row, insert test items, track approval rates and times, and separate the people who configure the AI from those who approve its output.