Human-in-the-loop definition

Human-in-the-loop in an automated content workflow means the automation runs up to a defined checkpoint, then stops until a person approves, corrects, or rejects the output. Without that human action, the step does not complete. In Sanity, Workflows (currently in beta) lets you model those stages as data in TypeScript next to the content, so the checkpoint is part of the deployed process rather than a convention, and the approval trail is queryable with GROQ.

What makes something a real human-in-the-loop checkpoint?

A human-in-the-loop checkpoint is real when three properties hold: authority, placement, and record. Authority means the person can reject the output, and rejection actually stops the process, not just adds a comment someone might ignore. Placement means the checkpoint sits at a defined stage in the process definition, so you know in advance which outputs get reviewed and which do not. Record means the approval leaves a trail attached to the thing approved, so months later you can answer who approved what, and when.

By that test, "a human is available if something goes wrong" is not human-in-the-loop. Availability is not authority, and an escalation path invoked after something has already published is a rollback procedure, not a position in the loop. The same goes for a review habit that lives in someone's head: if the process definition does not require the approval, the automation will eventually run without it.

The idea is not new to content teams. A human-in-the-loop checkpoint is structurally the same object as a traditional editorial approval step. What changes with automation is the rate. In the systems we work on, the pattern we see is that generative and agentic tooling produces output faster and in greater volume than the review capacity that was designed around human authors, which turns the checkpoint into the throughput constraint, not a formality.

How is human-in-the-loop different from human-on-the-loop?

Human-in-the-loop blocks by default; human-on-the-loop does not. In a human-in-the-loop design, the automation waits for a person to mediate the decision before it proceeds. In a human-on-the-loop design, the process runs to completion on its own while a person supervises it and retains the ability to intervene or halt it. A third term, human-in-command, sits above both: it is organizational authority over whether an AI system is used at all, in what scope, and under what policy, rather than a step inside a running workflow. The three-way split comes out of European trustworthy-AI work and is summarized in the Inter-Parliamentary Union's AI guidelines.

Two more terms get confused with human-in-the-loop, and the difference is timing. RLHF (reinforcement learning from human feedback) uses human judgments to train or align a model, shaping its future behavior. Active learning and annotation is the older machine learning sense of the phrase, described in Robert Monarch's Human-in-the-Loop Machine Learning (Manning, 2021), where humans label data and the model retrains on the result. Both are training-time loops. Human-in-the-loop in a content workflow gates one specific output, right now, and changes nothing about the model. Assuming a well-aligned model removes the need for a review step confuses the two.

Where do you put the human checkpoint in a content pipeline?

Put the human checkpoint at the last moment where a reversal is still cheap, which in a content pipeline is usually the boundary where automated output becomes visible or becomes an input to something else. Common placements: a generated draft accepted before publish, a machine translation accepted before a locale release, generated metadata accepted before it enters a search index, and an agent's proposed change accepted before it is applied.

The placement decision is a decision about what the automation is allowed to do unsupervised. A March 2025 McKinsey survey of global AI adoption reported that 27% of respondents whose organizations use generative AI said employees review all gen-AI-created content before it is used, while a similar share review 20% or less. That spread is the design space: near-total review, near-total trust, and a lot of ground in between where the interesting question is which content gets which treatment.

One useful inversion for content teams: the human is not always the reviewer. An agent can hold advance-or-reject authority over work a person submitted, checking a draft against a style guide and either moving it forward or sending it back. Sanity Workflows, currently in beta, supports exactly that shape. The human's control in that design sits in who wrote the stage definitions, not in who clicks approve.

Does the EU AI Act require human-in-the-loop?

No. The EU AI Act, Regulation (EU) 2024/1689, requires human oversight as an outcome, not human-in-the-loop as a specific implementation. Article 14 requires that high-risk AI systems be designed so that natural persons can effectively oversee them: understand the system's output, intervene in or interrupt its operation, and resist automation bias, with the aim of preventing or minimizing risks to health, safety, or fundamental rights. The consolidated text is on EUR-Lex.

Human-in-the-loop is one pattern that can satisfy that requirement, and for many high-stakes decisions it is the obvious one. A human-on-the-loop design, where a person supervises and can halt an automated process, can also satisfy it depending on the system. Treat the choice as a design decision you have to justify, not a box the regulation pre-checked for you. If your content workflow is not in a high-risk category at all, Article 14 is not what should drive the decision: the reason to put a person in the loop is that the cost of a wrong output is higher than the cost of the wait.

How do you prove a human actually approved something?

You prove a human approved something by storing the approval as data attached to the content, in the same system as the content, so the record can be queried rather than reconstructed. An approval that lives only in a chat message, a ticket, or an email thread is evidence that decays: the person leaves, the tool is replaced, and the link between the decision and the thing decided is gone.

This is where the shape of the underlying content system matters. Sanity is the Content Operating System for the AI era, and the relevant property for human-in-the-loop work is that process and content sit in the same place. With Workflows, currently in beta, the stages a document moves through are defined in TypeScript, versioned and deployed like the rest of your code, so the process cannot quietly drift from what is written down. Because the process leaves its trail in the content repository, a question like "what published without legal review" becomes one GROQ query rather than an investigation across three systems.

The automation that produces the output for review is a separate concern. Sanity Functions, which are generally available, are small single-purpose pieces of TypeScript that run on Sanity's cloud infrastructure and react to changes in content, triggering on document changes, media library asset changes, sync tag invalidation, a schedule, or invocation from another function. Functions generate and transform; the workflow stages are where the human keeps control.

Last updated: September 13, 2026