The Trouble With "Human in the Loop"

"Human in the loop" is one of those phrases that sounds like an unarguable good. A person, checking what the AI is doing, stepping in before it does something daft. Who'd say no to that?

I would — at least to the way it's usually built. Because in most real-time AI systems, a human in the loop is either doing nothing, or it's the most dangerous component you've installed.

Let me explain why, because the fix is the whole point.

The blocking problem

Picture a tool that sits between your application and your AI provider, watching every request. The promise is that when something looks risky — a customer's personal data, a leaked API key, an eye-watering call — it pauses and waits for a human to approve before letting it through.

Now picture that in reality. Your AI request has maybe a couple of seconds before it times out. No human is going to see an alert, weigh it up, and click "approve" in that window. They're at lunch. They're asleep. They're in another meeting.

So one of two things happens. Either the approval is a fiction — it waves things through because it has to, and the oversight is theatre. Or it genuinely blocks, the request dies waiting, and your AI feature breaks. The thing you installed to keep your AI safe becomes the thing that takes it down.

I've watched teams build exactly this and call it governance. A single point of failure with a compliance badge on it.

Two jobs people keep confusing

The mistake underneath all of this is treating two completely different jobs as one.

The first job is oversight: knowing what your AI did, being able to review it, having a record. The second is prevention: stopping a specific thing from happening at all. They feel similar. They are not the same — and they want opposite trade-offs.

Oversight should never block. Its job is to see everything, not to stand in the way of anything. Prevention should block — but only for the narrow set of things you've decided must never happen, with the cost of that decision accepted deliberately.

Conflate them and you get the worst of both: an oversight layer that blocks everything it notices, which is exactly how you end up taking your own AI offline.

What non-blocking review actually looks like

So here's the version that works.

The request always goes through. Always. If it trips a policy — personal data, a leaked secret, a data-loss match, a high-cost call, a flagged keyword — it isn't stopped. It's flagged, and a copy drops into a queue for a human to review after the fact. The AI answered at full speed; the human catches up a minute, an hour, or a day later, with a complete audit trail of what happened and why it was flagged.

Zero added latency. No single point of failure. And the sensitive content is redacted in the queue — a reviewer sees that an email address was caught, shown as [email], not the address itself. Oversight without quietly creating a second copy of the very data you were worried about.

Enterprise vendors call this "human in the loop", or HITL — usually buried in a tier you can't afford. Strip the acronym away and it's simply this: the AI runs, a human reviews, nothing breaks.

When you actually do want to block

There's a place for prevention — but it's a separate, deliberate tool, not the default behaviour of your oversight.

A hard block rule says: this specific thing must never leave, full stop. Card numbers. A particular internal codename. Whatever your one or two genuine red lines are. The big-company world calls this data-loss prevention, or DLP. You set it knowing it can refuse a request, because for that narrow category, refusing is the right answer.

The discipline is keeping the two apart. Block the handful of things that genuinely warrant it. Flag-and-review everything else. Don't let prevention's logic leak into your oversight, or you're right back to building an outage.

The principle underneath

All of this comes back to one rule I won't break: your governance layer should never be the reason your AI goes down.

So the whole thing fails open. If a check errors, if something goes wrong on my side, the request still goes through. I would rather miss a flag than become the cause of your outage. Oversight should ride alongside your AI, not sit in front of it with the power to strangle it.

That's what "taming" your AI should actually mean. Not a leash short enough to choke it. A clear view of everything it's doing, the ability to stop the few things that must be stopped, and a guarantee that the watching never breaks the doing.

I built exactly this into SpendLil's new Business tier — non-blocking human review, hard-block data-loss rules, redacted audit trails, the lot. The features enterprises gate behind contracts you have to phone someone to buy, on a plan a small business can actually afford. Because the principle isn't enterprise-only: nobody should have to choose between watching their AI and keeping it running.