Human-in-the-loop: where AI should stop and ask

Write down the action your system will take, who it affects and whether it can be reversed. An assistant that categorises an internal note can usually operate with a lighter review process than one that changes a booking, promises a refund or sends information outside the business. The boundary belongs in application rules, not only in a prompt asking the model to be careful.

Consider a small service business receiving enquiries. AI can summarise the message, suggest the right team and draft a response. Sending an ordinary acknowledgement may be a permitted automatic action. Agreeing a custom price should need approval. Changing the customer's account or disclosing another person's information should require separate identity and permission checks.

A suggestion helps a person decide. An approval workflow prepares an action but waits for someone with the right authority. Automatic execution completes a narrow, permitted action without waiting. Use these as distinct operating modes, visible in the interface and enforced on the server.

Approval needs to bind to the exact proposed action. If the amount, recipient or content changes afterwards, the approval should expire. Otherwise a reassuring “approved” label can become detached from what the system actually does. Keep a record of the reviewed proposal and final outcome without logging unnecessary personal information.

A review screen should show the original request, the proposed action, relevant source material and the reason it stopped. “Low confidence” alone is rarely enough. A clearer explanation is “The invoice total does not match the line items” or “This request falls outside the published cancellation policy”.

Give reviewers clear choices: approve, edit, reject or request more information. Name the team responsible for unresolved work and show how long an item has waited. If nobody owns the queue, the human step becomes a delay rather than a control.

Track the percentage of tasks completed automatically, but also correction rates, review time and the impact of wrong actions. An impressive automation rate is not useful if staff spend more time repairing the output afterwards. Review a sample of successful automatic actions as well as the obvious failures.

Start with a small, reversible workflow. Collect representative exceptions, update the rules and test them before expanding the system's authority. The aim is dependable work with a clear owner. Some decisions should continue to need a person even when the model becomes more capable.