Human in the loop by design: where the approval step goes

"Human in the loop" is one of those phrases everyone agrees with and almost nobody designs for.

In most AI projects, the human step is added at the end, usually after something goes wrong. Someone notices an odd email went out, or a wrong figure landed in a report, and the fix is "let's have someone check it first". Then that someone becomes a bottleneck, starts approving things without reading them, and the check stops being a check.

The approval step works when it's designed in from the start, like any other part of the system. That means answering three questions before anything is built: where does the human sit, who are they, and what do they see?

1. Put the check where a mistake becomes expensive

Not every step needs a person. If an AI drafts a reply and a person reads it before sending, the draft step doesn't need its own approval. The sending step does.

A useful rule: put the human at the point where the work leaves your control. That's usually one of these moments:

• Before anything goes out to a customer: emails, quotes, messages, published content.
• Before money moves: refunds, discounts, payments, orders.
• Before records change: updating a customer file, closing a ticket, deleting data.
• Before access changes: adding a user, sharing a file, connecting a new app.

Everything before that point can run on its own, because a wrong draft costs nothing until it's acted on. Everything after it is hard to take back.

This also tells you when to remove a check. If the step only creates something internal and easy to undo, an approval there is mostly friction.

2. Name one owner, not "the team"

"Someone will review it" means nobody will. Each approval point needs one named role that owns it, and a backup for when that person is away.

The owner should be the person who would answer for the mistake. For customer emails, that's whoever owns the customer relationship, not the developer who built the workflow. For refunds, it's whoever owns the budget.

Builders often skip this because it feels like an organisational question rather than a technical one. But it shapes the system: who gets notified, whose queue it lands in, and what happens if nobody responds. Decide what happens on silence, too. In most cases an unapproved item should wait, not go out by default.

3. Show the reviewer what they need, and nothing else

A reviewer who has to open three tabs to understand a request will start approving on trust. Keep the approval screen to what a decision needs:

• What will happen if they say yes, in plain words ("Send this reply to the customer", "Refund 40 to this order").
• The output itself, in full, as the recipient will see it.
• Why the system thinks this is right: the source or rule it used.
• Clear choices: approve, edit, or reject, with a short reason for rejecting.

Editing matters more than people expect. If the only options are yes and no, reviewers approve "close enough" output to avoid redoing the work. Letting them fix a sentence and approve keeps quality up and gives the builders a record of what keeps needing correction.

4. Log every decision

An approval that leaves no trace can't be trusted later. For each decision, record:

• what was proposed,
• who approved, edited or rejected it, and when,
• what was finally sent or changed,
• and the reason, if one was given.

This log does three jobs. It shows accountability when a customer asks what happened. It shows where the AI keeps getting things wrong, so the builders know what to fix. And it gives you the evidence you need to relax a check safely.

5. Earn the right to remove the human

The goal isn't to keep a person in every loop forever. It's to remove them when the evidence says it's safe.

If the log shows a reviewer has approved a certain type of output unchanged, over and over, for a long stretch, that step might be ready to run on its own, perhaps with spot checks instead. If edits are still frequent, it isn't ready, however good the demo looked.

Make that a deliberate decision, made by the owner, with the log in front of them. Not a quiet change because the queue got long.

For owners: three questions to ask your builders

1. At what exact point does a person approve this before it reaches a customer, money or records?
2. Who is that person, and what happens if they don't respond?
3. Where can I see a record of what was approved, by whom?

For builders: three things to design in

1. Approval as a real state in the workflow (pending, approved, edited, rejected), not a comment in a chat.
2. A review screen that shows the action, the output and the reason, with an edit option.
3. A decision log you can query, not just application logs.

A human in the loop is only as good as the loop around them. Put them where mistakes get expensive, give them one clear decision to make, and keep the record. That's what turns "someone checks it" into a control you can rely on.

Ahmed Vaseer is Founder & CEO - Ingenious Concepts. 80+ projects, ISO 27001 certified via Global CB.