Human-in-the-Loop Workflows
Deciding what an AI system may do on its own, what needs approval, and what it must never touch — before you connect it to anything.
The question isn't whether to keep a human in the loop. It's which loop, at which point, with what authority.
"A human reviews everything" is not a design. It either becomes rubber-stamping within a fortnight, or it makes the system slower than doing the work manually.
This is how to decide properly.
Read the automation planning checklist · Request Your Free Systems Audit
Four levels of autonomy
Classify every action an AI system can take into one of four levels. Decide this before connecting it to anything.
| Level | Actions | Example |
|---|---|---|
| Autonomous | Reading, searching, analysing, drafting, internal reports, proposals | Summarise this week's enquiries |
| Needs approval | Anything customer-facing, publishing, significant data changes, new automations in production, configuration | Send this reply to the customer |
| Never autonomous | Payments, budgets, access and permissions, destructive deletions, revealing credentials, commercial commitments | Pay this invoice |
| Standing approval | Specific, named, pre-agreed tasks | File this link in the reading list |
Two things make this work.
The classification is by effect, not by task. "Draft an email" is autonomous. "Send an email" is not, regardless of how routine the email is.
Standing approval is narrow and explicit. It covers named tasks, not categories. "Anything in the content folder" is not standing approval — it's an unbounded permission with a reassuring name.
The rule that holds it together
A task being on an approved list doesn't override its action class.
If a task is pre-approved for daily automatic execution, but executing it would send a message to a customer, it still needs approval for that part.
Without this rule, approval lists quietly become permission escalations. Someone approves "post the weekly summary," and six months later it's publishing externally because the summary moved.
Where to put the human
Not everywhere. In the places where a mistake is expensive and detection is slow.
Before the action, when
- It reaches a customer
- It moves money
- It changes a permission
- It deletes something
- It's publicly visible
- It would be expensive or slow to reverse
After the action, when
- It's internal and reversible
- Volume is too high for per-item review
- A sample review would catch systematic problems
- The cost of a single error is low
Not at all, when
- It's a read
- It's a draft nobody will see until a human sends it
- It's an internal report
- It's a proposal awaiting a decision
Designing the approval step
Approval that's annoying gets bypassed. Approval that's trivial gets rubber-stamped. Both produce an unsupervised system with a supervision ritual attached.
Show what changed, not everything. A diff, not a document.
Make rejection as easy as approval. If approving is one tap and rejecting requires an explanation, you've designed a yes machine.
Batch where possible. Twenty approvals in one screen gets more attention than twenty notifications across a day.
Include enough to judge. An approval request that can only be assessed by opening three other systems won't be assessed.
Record who approved what. Both for accountability and because the pattern tells you which approvals are real.
The rubber-stamp test
A month after launch, look at the approval log.
If the approval rate is 100%, one of three things is true: the system is genuinely reliable and the approval can be relaxed, the approver isn't actually reading, or the approval requests don't contain enough to judge.
All three need a response. The first is good news. The other two mean the control is decorative.
Escalation rather than blocking
A good system doesn't stop when it's uncertain — it asks.
Design the uncertain path explicitly:
- What does the system do when it can't determine the right action?
- Who does it ask?
- What happens if nobody responds within a defined period?
- Where does the work wait in the meantime?
The default for an unanswered escalation should be inaction, not a guess. Systems that proceed on timeout produce exactly the errors the loop existed to prevent.
Domain isolation
If an AI system touches more than one area of your business, decide what may cross between them.
Nothing should transfer automatically — not information, not credentials, not conclusions drawn in one area applied to another.
Each crossing needs a stated purpose, a source, a destination, and an approval class.
This matters most where one area is genuinely sensitive. The protection isn't a preference about tidiness; it's that cross-contamination is hard to detect after the fact and harder to undo.
What to log
Every action, with enough detail to reconstruct what happened:
- What was done, and when
- What triggered it
- What data it used
- Whether it was approved, by whom
- What the result was
Without this, you can't audit, debug, or answer the question that eventually gets asked: why did it do that?
Guards worth having
Preview before execution. The system shows what it's about to do before doing it, for anything in the approval class.
Verify after execution. It checks the result rather than assuming success.
Backup before significant change. Especially for anything touching stored data.
Secrets never appear in outputs. Not in logs, not in reports, not in memory. The system references where credentials live, never their values.
Rollback exists and someone knows about it. Written down, not improvised during an incident.
Evidence discipline
An AI system that reports its findings should distinguish between what it verified and what it inferred.
Four states are enough:
| State | Meaning |
|---|---|
| Confirmed | Verified directly, or approved by a person |
| Partially confirmed | Tested in a limited way |
| Proposed | A suggestion, not yet decided |
| Unknown | Not established |
The failure this prevents is subtle and common: a proposal made three weeks ago gets restated as a fact, and then acted on. Keeping the states separate stops confident-sounding output from becoming an undocumented decision.
Likewise, when two sources disagree, the system should report the conflict rather than silently picking one.
Starting points
Start more restrictive than you think you need. Expanding autonomy after a system proves reliable is easy. Contracting it after an incident is expensive, and you'll overcorrect.
Expand on evidence. Move a task from "approval" to "autonomous" when the log shows a stretch of correct behaviour, not when approving it becomes tedious.
Review the classification quarterly. Tasks change shape. A task that was internal six months ago may now produce something customers see.
Decide what the system may do before you connect it to anything. The classification is the design.
Thinking about AI in your operations?
A free systems audit covers where it would help, where it wouldn't, and what needs to exist first.