Designing human-in-the-loop AI for operations

Consider an accounts team receiving invoices by email. A model can extract supplier, amount, tax, and purchase-order fields, but extraction is only one step. The useful system also retrieves the attachment, checks the supplier and purchase order, routes ambiguous cases, records corrections, and writes approved data into the accounting platform. The workflow — not the model response — is the unit of design.

Baseline one bounded workflow

Document the current volume, handling time, queue age, rework rate, and cost of a wrong decision. Sample the real variation: scans, photographs, unusual layouts, multiple languages, missing records, and duplicate submissions. Choose a first scope where a reviewer can determine correctness. If the team cannot label a good result consistently, automation will not resolve the underlying ambiguity.

Give review a specific job

“Human in the loop” is incomplete unless the loop has rules. Decide which fields or decisions always require approval, which may pass automatically after validation, and which conditions force escalation. Show the source beside the proposal, highlight evidence, and let reviewers correct rather than re-enter data. The interface should explain why an item reached the queue without presenting model confidence as certainty.

Integrate through controlled boundaries

Treat model output as untrusted input. Validate types, totals, identifiers, permissions, and business rules before any write. Use idempotency keys so retries do not create duplicate records. Keep source documents, model and prompt versions, extracted values, reviewer changes, and downstream write results in an audit trail. Personal and confidential data should be minimised and handled under an explicit retention policy.

Design failure as a normal state

Models time out, providers throttle requests, source formats drift, and downstream systems become unavailable. A durable workflow can retry safe steps, quarantine malformed items, resume after interruption, and show operators what is waiting. Manual processing must remain possible. When a provider or model changes, replay a representative evaluation set before sending production work through the new configuration.

Measure the whole operation

Field accuracy matters, but it is not the outcome. Track end-to-end handling time, backlog age, straight-through processing rate, reviewer time, correction rate by field, exception categories, and downstream reversals. Compare them with the baseline and segment results by document or case type. A high automation rate that creates difficult rework can make an operation slower.

Expansion should follow evidence. Add case types or reduce mandatory review only after observed performance supports the change and the business owner accepts the risk. This approach may look modest beside an open-ended AI programme. It is also how a model becomes a dependable, accountable part of daily work.