Human in the loop: redesign the process before you automate it

Adding AI to every step of an old process can preserve its delays. A better starting point is to describe the outcome the process must produce, then redesign the path from request to result. This is a design recommendation, not a claim that every process should be automated.

Map the work before assigning it

Choose one real workflow and trace ten to twenty recent cases from arrival to completion. Record the trigger, information used, handoffs, decisions, exceptions, systems touched and time spent waiting. Include cases that went wrong. Ask which steps exist only because information is copied between tools, and which steps protect quality or accountability.

For example, a supplier invoice may arrive by email, be retyped into a spreadsheet, checked against a purchase order, approved by a manager and entered in finance software. The useful redesign is not “let an agent do the spreadsheet.” It is a flow that captures the invoice once, checks it against approved records, sends discrepancies to a person and records the approved outcome.

Choose action boundaries by consequence

Separate preparation, recommendation and execution. AI may extract fields and draft a response without changing a system of record. A payment, denial, sensitive message or irreversible update needs a stronger control. Use the consequence of an error, reversibility and confidence in the evidence to set the boundary.

The NIST AI Risk Management Framework calls for defined and documented human oversight in context. OWASP’s prompt injection guidance also recommends approval before high-risk tool actions. Those sources support the principle; the exact thresholds must fit your organisation.

Make human review a real control

An “Approve” button is insufficient if the reviewer cannot see the source, the proposed action and the uncertainty. Show the original request, relevant records, what the AI inferred, what it could not verify and the downstream effect of approval. Let the reviewer edit, reject and escalate. Record who decided and what changed.

Design capacity as well as interface. If too many routine items require approval, the queue becomes a bottleneck; if reviewers rarely see unusual cases, they may lose context. Start with broader review, measure error patterns and narrow the review scope only when evidence supports it. AWS guidance on production feedback loops describes structured human feedback and review for unfamiliar or higher-risk scenarios.

Test the whole flow, including failure

Build a case set from ordinary work, missing documents, conflicting values, duplicate requests, permission failures and adversarial content. Measure useful outcomes: completion time, correction rate, exception rate, reviewer effort and errors that reached a system of record. Compare with the current baseline, not a polished demo.

• Verify that untrusted document text cannot change instructions or trigger unauthorised actions.
• Check that a failed integration produces a visible, recoverable exception rather than a false success.
• Confirm that reviewers can stop an action and recover the original case.
• Review complaints and corrections after launch, then add them to the case set.

A practical first move

Select one process owner, one contained workflow and a small set of representative cases. Produce a future-state map, an action boundary, a review design and acceptance criteria before selecting tools. This gives the team a useful delivery brief and exposes whether an agent, conventional automation or a simpler process change is the right implementation.