A review gate is a point in an AI workflow where a named person approves, changes or reverses an action before it reaches the business. We think it is the single design decision that separates AI systems that stay in production from ones that quietly get switched off, and we think the phrase most people use instead, "human in the loop", is the most dangerous phrase in the field. Not because it is wrong. Because it is reassuring, and it describes nothing.
A loop is a posture. A gate is a design.
Saying a human is in the loop tells you that a person exists somewhere near the system. It does not say where they sit, what they see, what they are allowed to change or what is written down when they do. A gate answers all of it. Where: at the last point before the action leaves your control, so before send, not before draft; before the ledger changes, not before the reconciliation is proposed. Who: a named person, not a team, because a decision shared by a team is a decision nobody made. What they see: the proposed action, the sources it drew on and the system's own confidence. What they can do: approve, edit, reject. What is recorded: all of it.
Most systems described as having a human in the loop have a person near them. Very few have a gate. You can tell the difference in one question: when this goes wrong, who will say it was their call?
The reviewer will become a rubber stamp, and the design has to assume it
Here is the uncomfortable part. Put a competent person in front of a queue of AI outputs that are right ninety-five times in a hundred and, within a fortnight, they will approve the ninety-sixth without reading it. This is not a character flaw. It is what attention does when it is asked to find a rare error in a stream of correct answers, and the aviation and medical literatures have known it for decades. A gate designed on the assumption that the reviewer stays vigilant is a gate designed to fail at exactly the moment it is needed.
So design for the bored reviewer. Show them the sources, not just the answer, so that checking is faster than trusting. Make edit the easiest action, not approve, because a reviewer who can only accept or refuse will accept rather than redo the work. Vary the queue so that the eye does not settle. And measure the reviewer: if their approval rate hits a hundred percent, the gate has stopped working and something needs to change, either the reviewer or the number of items they see.
Three properties, and why they come as a set
A gate enforces three things and each one is useless without the others. Permissioned: the system can only take actions a named person allowed it to take, inside your cloud and your access controls, so the gate can never be asked to approve something the system should not have been able to propose. Reviewed: nothing reaches a decision unjudged. Reversible: every action has a way back, and an audit trail on every answer shows what the system saw, what it did and who said yes. Take away reversibility and the review becomes a place to assign blame rather than to catch mistakes, and reviewers who know they are there to be blamed approve everything and keep their heads down. Take away permissions and the review is the only control, which is one control too few.
The gate is an instrument, not a tax
The objection we hear is that a gate slows the workflow down. At first, by design. But a gate is not a permanent cost; it is an instrument for producing the one thing that lets you remove it, which is evidence. In the first weeks every action is reviewed because nobody yet knows where the system is wrong. The record fills. After a month you know that the system is reliable on category A and unreliable on category C, and the review moves to a sample of A and all of C. After a quarter it moves to exceptions the system flags itself. Every loosening is justified by the log rather than by optimism, and every loosening can be reversed if the log turns.
One rule does not loosen. Anything that touches money, a customer or a commitment keeps a person in front of it, permanently. Not because the system will always be wrong about those things, but because when it is, the business needs to be able to say a person decided. That is not a technical requirement. It is what it means for a company to be responsible for what its software does.
What a gate is not
It is not a disclaimer at the bottom of the answer. It is not a confidence score displayed to nobody. It is not a weekly report of what the system did, which is a way of being told after the fact. And it is not a phase to get through on the way to "real" automation. The gate is what production looks like when software is allowed to act. The businesses that treat it as scaffolding to be removed are the ones that end up switching the system off six months later, without ever being quite able to say why.