Skip to content
Cortaris

Governance

Human in the loop AI: levels, release points and the EU AI Act

What human in the loop means for AI agents in operations, when human on the loop is enough, and how to widen release rights per case category on evidence from shadow mode. With a template and the rules from the EU AI Act, GDPR and German works council law.

10 min readUpdated 11 October 2026

What human in the loop AI means

Human in the loop AI means that a person reviews and releases each output of an AI system before it takes effect, for example before a credit note is posted or a customer reply is sent. For AI agents acting in an ERP, CRM or ticket system, it marks where in the workflow a person signs off, and the EU AI Act calls the broader duty human oversight (Article 14).

In its 2019 Ethics Guidelines for Trustworthy AI, the High-Level Expert Group on AI set up by the European Commission distinguished three approaches: human in the loop, with intervention in every decision cycle; human on the loop, with intervention in the system's design and monitoring of its operation; and human in command, the decision whether and how to use a system at all. The guidelines state that intervening in every cycle is in many cases neither possible nor desirable. In return, the less oversight a person can exercise over a system, the more extensive the testing and the stricter the governance have to be.

In an agentic workflow the level is therefore a setting per case category, not a matter of principle. The same claims workflow can send a request for missing delivery notes without individual release but never a refusal without a claims handler's decision.

Human in the loop vs human on the loop vs human out of the loop

The three levels differ in when a person steps in. In the loop means before every effect, on the loop means during operation through samples, metrics and alerts, and out of the loop means no longer in the individual case, only through rules and periodic reviews.

That makes the level a decision about which errors reach the customer. In the loop, the release catches a wrong proposal before it acts. On the loop, the error acts first and is found by a sample or an alert, so this level suits only cases whose effect can be corrected.

LevelWho decidesWhen it fitsRiskExample in the workflow
Human in the loopA person releases, edits or rejects every proposal.New case categories, high amounts, external effect, decisions about peopleRelease turns into a formality at high volumes (automation bias).A claims handler checks and releases the proposed credit note for a complaint.
Human on the loopThe agent acts within rules; a person monitors samples, metrics and alerts and steps in.Categories with proven acceptance numbers and a correctable effectAn error takes effect before anyone finds it; gradual decline only shows up in reviews.The agent requests missing photos or delivery notes; the team lead checks a weekly sample.
Human out of the loopNobody in the individual case; rules and thresholds decide, a person reviews periodically.Internal, reversible steps where an error does little harmErrors pile up unnoticed if reviews and alerts are missing.The agent routes incoming cases to the right queue in the ticket system.
The level applies per case category and action, not to the agent as a whole.

Setting release points per case category: a release design template

Set the level for each combination of case category and action, and lower it only when numbers from shadow mode support that for the specific category. In shadow mode the agent drafts against real, live cases while people keep deciding; the glossary of AI agent terms defines shadow mode, confidence threshold and straight-through processing.

Agree the acceptance numbers before shadow mode starts. Three measures per category are enough, namely the share of proposals released unchanged, the share with a material correction and the count of critical deviations such as a wrong amount or customer. Add a minimum case count, so that a rare category is not released on a handful of examples.

The workflow owner decides on widening together with whoever carries the risk, which for credit notes means finance. Every widening stays reversible, because a category falls back to the previous level as soon as the correction rate in operation crosses the agreed limit. How we work sets out the route from assessment to shadow mode in 90 days.

The template applies this to claims handling with AI agents, where the agent assembles the case file and proposes a resolution with reasoning. Its case counts and rates are examples to replace with your own.

Case categoryLevelWho releasesCriterion for the next level
Request missing evidence from the customerHuman in the loopClaims handler, one clickHuman on the loop once at least 300 cases show 95 in 100 messages released unchanged and none sent to the wrong recipient
Credit note below the threshold with clear evidenceHuman in the loopClaims handlerHuman on the loop up to an amount set by finance once at least 500 cases show no released proposal with a wrong amount or rule
Claim above the threshold or unclear liabilityHuman in the loop with full reviewClaims or quality specialistNone; finance reviews the threshold monthly
Refusal of a claimHuman in the loop, permanentlyClaims handler with decision authorityNone; refusals stay with people
Payout or offsetOutside the agentAccounts team under the four-eyes principleNone; the agent never triggers payments
Routing the case to team and categoryHuman on the loopTeam lead, via samples and the misrouting rateHuman out of the loop once the misrouting rate stays below the baseline for three consecutive months
Example values for orientation; the level shown applies at go-live. The workflow owner and finance set case counts, rates and amounts before shadow mode.

Human in the loop and the AI Act: Articles 14 and 26

The EU AI Act prescribes neither the term human in the loop nor oversight for every system. Human oversight under Article 14 and the deployer duties under Article 26 apply to high-risk AI systems, from 2 December 2027 for systems listed in Annex III and from 2 August 2028 for products under Annex I, the dates fixed by Regulation (EU) 2026/1744.

Article 14 governs the design of the system, so it falls first on the provider, and the system has to give the people overseeing it the five abilities in Article 14(4). A company that has an agent built for its own operations and puts it into service itself should check early whether that makes it a provider under Article 3(3) and (11).

Article 26 requires deployers to use the system according to its instructions for use and to assign oversight to people with the necessary competence, training and authority. Deployers also ensure that input data under their control is relevant and sufficiently representative, monitor operation, keep automatically generated logs for at least six months and inform workers and their representatives before use at the workplace. The AI Act check for a single workflow gives a first orientation on whether a workflow is high-risk; binding classification is for your compliance function or counsel.

For every other workflow, which covers most agents in service, quoting and claims handling, the same mechanics are simply good design and leave little to retrofit if a workflow is later classified differently.

  1. 01

    Understand the system's capacities and limitations and monitor its operation, including detecting and addressing anomalies, dysfunctions and unexpected performance (point a)

  2. 02

    Remain aware of the tendency to rely automatically or excessively on its output, known as automation bias (point b)

  3. 03

    Interpret the output correctly, using the interpretation tools and methods available (point c)

  4. 04

    Decide in a particular situation not to use the system, or to disregard, override or reverse its output (point d)

  5. 05

    Intervene in its operation or interrupt it through a stop button or a similar procedure that brings it to a halt in a safe state (point e)

GDPR Article 22: why refusals and payments stay with people

Refusals and payments stay with people because that is where the effect on the customer is greatest. Article 22 GDPR adds a legal reason, because it protects individuals from decisions based solely on automated processing that produce legal effects concerning them or similarly significantly affect them. Such decisions are allowed only where they are necessary for a contract, authorised by law or based on explicit consent. Even then the person has at least the right to obtain human intervention, to express their point of view and to contest the decision.

The Court of Justice of the EU reads the notion of a decision broadly. In case C-634/21 of 7 December 2023 it held that the automated calculation of a credit score by the German credit agency SCHUFA is itself such a decision where a third party draws strongly on the score to establish, implement or terminate a contract with the person. Equally, a decision does not become human just because someone confirms the proposal. The Article 29 Working Party guidelines, endorsed by the European Data Protection Board, require oversight that is meaningful rather than a token gesture, carried out by someone with the authority and competence to change the decision.

Article 22 does not usually apply to business customers that are not natural persons; for consumers, sole traders and employees it can apply directly. Two operational reasons point the same way. A wrong refusal can cost the customer relationship, and a payment is hard to recover once made, even when a manipulated email with changed bank details triggered it.

Automation bias: when release becomes a formality

Automation bias is the tendency to rely automatically or excessively on a system's output, and Article 14(4)(b) of the AI Act names it explicitly. It grows with the quality of the agent, because the rarer a wrong proposal, the less a reviewer finds by checking the evidence, and the more likely the check is skipped.

A measurable warning sign is a review time per case shorter than reading the evidence takes. Metrics like this belong in the monthly KPI review that Managed Run for AI workflows in production provides for each workflow, analysed at team and category level rather than as ratings of individual employees.

Design helps more than appeals to diligence, and five measures work directly on the mechanics of release.

  1. 01

    Weekly samples of fixed size from categories without individual release, checked by someone who did not release those cases

  2. 02

    Rotating reviewers per category, so nobody gets used to one agent and one type of case

  3. 03

    Release screens that show the evidence, the sources and the rule applied, not just the proposal and an approve button

  4. 04

    In samples, the evidence first and the agent's proposal second, so the review does not start from the proposal

  5. 05

    Test cases with a known correct outcome that run through the queue like normal cases and show whether release still means review

Works councils and release logs in Germany

In Germany, a release log that records who released or corrected what and when can trigger the works council's right of co-determination. Section 87(1) no. 6 of the Works Constitution Act (BetrVG) covers the introduction and use of technical devices designed to monitor employees' behaviour or performance. The Federal Labour Court treats a device as designed for this when it is objectively suitable, whatever the employer intends (order of 13 December 2016, 1 ABR 7/15).

Section 90(1) no. 3 BetrVG adds a duty to inform the works council in due time about plans for working procedures, including the use of artificial intelligence, and for high-risk systems Article 26(7) of the AI Act requires informing workers' representatives before use at the workplace. Your employment lawyers assess how far co-determination reaches in a given workflow; for the schedule, the talks should start before shadow mode, when the first logs are written.

A works agreement should settle three points in advance, namely the purpose of the log, such as workflow quality and traceability, who may access it and how long it is kept. Automation bias metrics can be analysed at team and category level, so no report rates individual employees. Outside Germany, check the local rules on informing and consulting employee representatives.

Questions

Common questions

What is the difference between human in the loop and human on the loop?
With human in the loop, a person releases every output before it takes effect. With human on the loop, the agent acts within rules while a person monitors samples, metrics and alerts and steps in when something deviates. Human on the loop therefore suits only cases whose effect can be corrected.
Does the EU AI Act require human in the loop?
No, neither as a term nor for every system. Article 14 requires human oversight for high-risk AI systems, commensurate with the risks, level of autonomy and context of use, and only for remote biometric identification under Annex III point 1(a) does Article 14(5) require at least two people to verify and confirm a result separately. Article 4 on AI literacy applies to all AI systems, and a company AI policy is the natural place to address it.
How do you design human oversight for AI agents?
Per case category and action rather than per agent. Each category gets a level, a named role that releases and a criterion for the next level, and the control set adds permissions, thresholds, logging and escalation. Shadow mode against live cases supplies the numbers for every change of level.
Is clicking approve enough human oversight?
Only if a real review sits behind the click. The guidelines on Article 22 GDPR endorsed by the European Data Protection Board require a person with the authority and competence to change the decision who considers all the relevant data. Release screens with evidence and sources, samples and test cases make that review demonstrable.
When can an AI agent act without human approval?
Only once shadow mode has met the acceptance numbers agreed in advance for a specific case category, and the workflow owner and whoever carries the risk agree. The widening applies to that category only and falls back if the correction rate in operation rises. Refusals and payments are excluded.

Next step

Start with one workflow.

Bring the process that costs you the most time. In 30 minutes we tell you whether it is worth automating, roughly what it would take, and which step comes first.