Human-in-the-loop AI: designing the approval step so it isn't a rubber stamp

Human-in-the-loop AI: the short answer

Human-in-the-loop AI means a person reviews what an AI system proposes before it takes effect: the reply before it goes out, the payment before it leaves. That protects you only if the review is real. The person needs few enough items to read each one, the evidence beside each proposal, the authority to say no, and occasional planted mistakes to catch. Otherwise the approval step becomes a rubber stamp.

This guide is for the owner or operations lead of a firm of 10 to 50 people. You are about to switch on AI that drafts replies, reads invoices or updates records, and the vendor says a person approves everything.

Check that promise. Under UK and EU data protection law, a sign-off with no real review counts as no human involvement at all. In practice, a reviewer who approves everything adds a delay and removes no risk.

We build AI agents with a human approval step wherever a mistake would be expensive. That step is easy to add and easy to get wrong.

In, on or over the loop: where a person can sit

A person can sit in three places around an AI system. The label matters less than when they act.

Most setups need all three, for different actions. The rest of this guide is about the first, because that's where the rubber stamp lives.

An agent that acts on its own needs this design most. A workflow with one AI step needs it too, in fewer places. AI agents vs workflows explains the difference.

What to send to a person

Send a person the items where a mistake would be expensive, or where the machine has a reason to doubt itself. Leave the rest to checks in code and a sample. Six triggers cover most cases:

1. The action can't be undone: a payment, an email to a customer, a deletion.
2. It makes a promise: a price, a refund, a delivery date or a contract term. Your customer holds you to it, as our checklist of what not to automate with AI explains.
3. It decides something about a person: a job applicant, an employee, a customer's credit or account.
4. A check failed. The invoice total doesn't match the purchase order, or the customer isn't in your system.
5. The model marked a field as unsure, or the input was hard to read, such as a blurred scan.
6. It's new or unusual: a first order from a new customer, new bank details, an amount far outside the usual range.

Everything else gets a sample: a few items a week that someone reads in full, to learn whether the machine is drifting.

Say you run a 25-person building supplies distributor, with AI reading supplier invoices and sorting the shared inbox. The routing might look like this.

Routing fewer items is the first defence against the rubber stamp. A queue that shows a person everything teaches them to skim everything.

Why approval steps turn into rubber stamps

Approval steps decay for four reasons, and a lazy reviewer isn't one of them. Each is a design fault, so each has a design fix.

Too many items, too few problems

A 2006 review of 17 studies found that clinicians override drug safety alerts in 49% to 96% of cases (van der Sijs et al., JAMIA). The authors noted that many overrides were justified. They aimed the fix at the software and the organisation: alerts with low specificity, unclear information and needless interruptions.

Airport security sees the same effect. When threats are rare, screeners detect fewer of them (Riz à Porta et al., Sensors, 2022). When 99 items in 100 are fine, a reviewer learns to expect fine.

One click, no context

Microsoft found that "about 1% of users will accept a simple approval request on the first try", for sign-ins they never started (Microsoft, 2022). Its fix made people type a number shown on the login screen, and told them where the request came from. In Microsoft's studies, those two changes stopped the attacks. An Approve button that asks for nothing gets pressed.

The machine answers first

People lean on a confident machine answer, even when it's wrong. The EU AI Act calls this "automation bias" in Article 14. Explaining the AI's reasoning doesn't cure it.

In an experiment by Harvard researchers with 199 participants, designs that forced people to think cut overreliance compared with simply adding explanations (Buçinca et al., 2021). One asked for the person's own decision before showing the AI's. Participants liked those designs least, so expect some grumbling.

The job rewards yes

If the reviewer is judged on items cleared per hour, every rejection costs them. If rejecting means a form and approving means one click, approvals win. A polished draft also looks finished, so it reads as correct.

How to design an approval step that gets real review

Each fault above has a fix you can build into the screen and the process. Here they are, using the invoice queue from the table above.

1. Say why the item is here. The first line reads "New bank details for this supplier" or "Total differs from the purchase order", so the person knows what to check.
2. Put the evidence beside the proposal: the scan or the customer's email on one side, what the AI read or wrote on the other, with the doubtful fields marked. A reviewer can't judge what the screen doesn't show them.
3. Show the exact action: the email as it will be sent, the account the payment will go to. Don't show the AI's summary of its plan. The approval covers that action only, so if the record changes before it runs, the system checks again and asks again.
4. Make approving a small act of attention. Ask the person to type the last four digits of the new account, or tick which check they did. Where their judgement is the point, such as a credit application, ask for their call before showing the machine's.
5. Make no as easy as yes. Reject in one click with a reason from a short list, edit in place, and pause the whole automation from the same screen. Nobody should need a manager's signature to say no.
6. Record the decision as data: who decided, when, what they saw, what they chose and why. We record each decision as a required field with a short list of allowed values, because a missing field is easy to spot and a missing sentence isn't.
7. Give the reviewer authority, training and time. They need to overrule the machine without justifying themselves to it, and to know the kinds of mistakes it makes. Review time is a real running cost, which is why our guide to what an AI agent costs to run gives it its own line.

When the system escalates a case instead of asking for a yes or no, the same rule applies. The person gets what the AI found and why it stopped, so they don't start cold.

How to tell whether your reviewers are really reviewing

An approval rate tells you nothing on its own. If people approve 99% of items, either the machine is right 99% of the time or nobody is looking. Four measures tell the two apart.

1. Planted mistakes. Each week, slip a few items with a deliberate error into the queue: a wrong total, changed bank details, a reply with the wrong date. Count how many come back. Airport security has done this for years. Threat image projection adds pre-recorded images of threat items to X-ray images of real bags, and the hit rate shows which screeners need retraining (Riz à Porta et al.). Keep planted items out of the live workflow, so none can be sent or paid.
2. Time per item against its size. A two-page contract approved faster than anyone could read it wasn't read.
3. Edits and their reasons. Every edit is a case the machine got wrong, and the reasons show you which rule to add. Months with no edits mean a very good machine or no reading. The planted mistakes tell you which.
4. What happens after approval: credit notes, corrections and complaints traced back to items someone approved.

If planted mistakes get caught and real items pass unchanged for months, that kind of item may not need a person any more. Move it to sampling, one kind at a time. The exception is a decision that seriously affects a person, such as turning down credit. Drop real review there and you are making automated decisions in the legal sense, with the duties that brings.

What UK and EU rules count as real human review

Data protection law in the UK and the EU treats a decision with only token human involvement as automated. For decisions with legal or similarly significant effects on a person, such as refusing credit or ending a contract, that brings extra duties or a restriction.

In the UK, Article 22A of the UK GDPR has applied since 5 February 2026. A decision is based solely on automated processing if there is "no meaningful human involvement". Where such a decision has legal or similar effects, you need safeguards: tell the person, let them make their case, offer human intervention and let them contest it.

The ICO's draft guidance, last updated on 31 March 2026, says involvement must be "active and not just a token gesture". The reviewer acts while the outcome can still change, understands the system's limits, weighs the relevant data and has the "discretion and authority to alter the decision". "Ad hoc spot-checking isn't sufficient", and you should record how the person was involved.

In the EU, Article 22 of the GDPR gives people the right not to be subject to solely automated decisions of that kind, with narrow exceptions. The guidelines the EDPB endorsed say oversight must be "meaningful, rather than just a token gesture", by "someone who has the authority and competence to change the decision". Changes to the GDPR were still under negotiation in 2026, so check the current text.

The EU AI Act adds rules for high-risk systems, such as AI used in recruitment or credit scoring. After the 2026 AI omnibus, they apply from 2 December 2027.

Most of what a small firm automates, such as reading invoices and sorting email, falls under none of these. The tests still make the best free specification of a review step we know. We aren't lawyers, so if your AI touches decisions about people, ask yours.

What the Uber drivers' case shows

The clearest public example of a rubber stamp failing in court comes from Amsterdam. Drivers whose Uber accounts had been deactivated for alleged fraud asked what automated decision-making lay behind it.

Uber said at least two staff in its risk team decided each fraud deactivation, unanimously, under internal protocols. For three of the drivers, its records showed that one to three staff had added a note after a fraud signal.

On 4 April 2023 the Amsterdam Court of Appeal found the notes did not show the review "was much more than a purely symbolic act" (our translation). Nor did they show that the staff had weighed all the relevant data. Uber hadn't said what those staff were qualified to judge, and nobody had heard the drivers' side.

The court treated the three deactivations as automated decisions, which entitled the drivers to meaningful information about the logic involved (ECLI:NL:GHAMS:2023:793). A fourth driver had had a personal conversation with Uber before his account was deactivated. For him, the court accepted that real human involvement had taken place.

A note saying someone looked isn't evidence that they reviewed. What counts is what they saw, what they weighed and whether they could change the result, recorded at the time.

When you don't need a person in the loop, or us

Some actions don't need an approval step, and some approval steps don't need a builder.

• The action is cheap and easy to undo: sorting, tagging, an internal draft. Put a person over the loop with a weekly sample instead.
• Code can do the check. If a rule can compare the invoice with the purchase order, a person staring at two matching numbers adds a delay, not safety.
• The volume would force a rubber stamp. If one person would face hundreds of items a day, fix the routing, or accept that the job isn't ready to automate.
• One person drafts with AI and sends the result themselves. They are already the loop.
• Your tool already has an approval step. Zapier's Human in the Loop pauses a workflow for review, and n8n can require approval before an AI agent uses a tool. If your automation already runs there, use them with the design rules above.

If you can't tell whether your setup is real review or a stamp, get an independent read before you add more automation. It costs less than finding out from a customer.

Check your own approval step this week

Take one approval step you have now, or one a vendor has promised, and answer five questions.

1. How many items reach the reviewer on a normal day, and how many of those are ever wrong?
2. What does the screen show besides an Approve button?
3. Can they reject in one step, and does rejecting cost them anything?
4. Is each decision recorded with who made it, what they saw and why?
5. When did someone last put a known mistake in front of them?

Then plant three known mistakes next week and count how many come back. That count tells you more about your human in the loop than any demo.

Questions

Who should review: the person who used to do the job, or a manager?

Usually the person who used to do the job, because they know what a wrong answer looks like. A manager's click adds authority but rarely attention. For a decision that seriously affects a person, such as refusing credit, the reviewer also needs the authority to change the outcome. Choose someone who has it, or give it to them in writing.

Can a second AI check the first one instead of a person?

A second model makes a useful check. It can compare what the first one read with the source and send disagreements to the queue. It doesn't replace the person on expensive actions, because it can miss the same things for the same reasons. Under UK and EU data protection law, it also isn't human involvement.

Won't the review slow everything down?

Only for the items you route to a person, which is why routing matters. Everything that passes the checks goes straight through. If the queue becomes the bottleneck, look at why items land there. Each recurring reason is either a rule to add or a sign the job isn't ready to automate.

How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.