“Human in the loop” is often presented as a general safety principle. An operating team needs something more concrete: where the person appears, what evidence they see, who has authority to approve, and what the workflow does after a rejection.
A practical division of labor is to let the AI agent prepare, organize, generate, and check while a person owns consequential decisions. That structure removes repetitive work without assigning accountability to a system that cannot accept responsibility.
Three tests for an approval point
Is the action difficult to reverse?
Generating a draft can be repeated. Deleting production data may be impossible to undo. Reversible actions can support more automation, while irreversible actions need stronger confirmation, backups, and approval.
Can it affect customers, money, or legal responsibility?
An internal classification mistake may create rework. Publishing an incorrect price, sending a refund, or making a contractual commitment can create immediate commercial consequences. The larger the impact, the more important it is for an identified owner to decide.
Does it exceed the authorization already granted?
Even a relatively ordinary action should stop if it goes beyond the current task, data scope, financial threshold, or tool permission. An agent should not expand its own authority simply to finish the job.
A practical approval matrix
| Workflow stage | What the agent can do | What a person decides |
|---|---|---|
| Data access | Read authorized files and fields | Whether a new source may be connected |
| Content generation | Prepare product, support, or report drafts | Whether facts, brand rules, and obligations are satisfied |
| Quality checks | Flag missing fields, anomalies, and inconsistencies | Whether an exception is acceptable or more information is required |
| Export | Create a preview file or pending action list | Whether results may enter an external system |
| Publish and send | Prepare content and recipient lists | Whether to publish publicly or send in bulk |
| Transactions | Calculate a recommendation and organize evidence | Whether to pay, refund, reprice, or place an order |
| Data changes | Produce a change plan and diff | Whether to delete, overwrite, or migrate production data |
| Permission changes | Report a missing permission | Whether to grant more access or extend authorization |
What an approval screen should show
A single Approve button is not enough. The reviewer should see at least:
- the exact proposed action and affected objects;
- the data and sources used;
- checks already completed by the agent;
- known exceptions and unresolved questions;
- whether the action can be reversed;
- how the reviewer, time, and outcome will be recorded.
Without this context, approval becomes ceremonial. A well-designed review point lets the person make a focused decision instead of repeating all of the work the agent just performed.
Match the control to the risk
Low risk: sample review
Internal tags, first-pass classification, and draft formatting may run automatically with a proportion of results sampled for review. If the error rate rises, the team can tighten the workflow.
Medium risk: exception-based intervention
Product-field checks and customer-response drafts are common examples. Normal items can continue, while missing data, low confidence, rule conflicts, and sensitive topics enter a human queue.
High risk: explicit approval for each action
Publishing, repricing, refunds, payments, deletion, bulk communication, permission elevation, and external commitments belong here. The agent may prepare the action, but it should not bypass the authorized reviewer by default.
OpenAI’s practical agent guide identifies failure thresholds and high-risk actions as important triggers for human intervention. The NIST AI RMF Playbook offers practices across governance, mapping, measurement, and risk management. Together, these sources support a central design principle: human control should be specified when the workflow is created, not added only after an incident.
Approval is not the only safeguard
People can still click the wrong button. Approval should therefore operate alongside least-privilege access, value or volume limits, preview environments, operation logs, recoverable backups, and staged release. A bulk workflow can begin with a small sample and expand only after the team confirms the format and boundaries.
Failure paths also matter. If approval is denied, which step receives the work for correction? Who supplies missing data? Does an expired request cancel automatically? Explicit answers keep the process controlled when normal execution breaks down.
DoPilot’s stated boundary
DoPilot’s public product facts identify publishing, repricing, refunds, payments, deletion, bulk messages, external commitments, and other irreversible actions as boundaries requiring explicit authorization and human approval. DoPilot Desktop is still in private preview, and product-specific data paths and enterprise delivery scope must be confirmed rather than inferred from a demonstration interface.
A team can begin by mapping one real process and assigning each step to one of three categories: automatic, human intervention on exception, or explicit approval. That simple map often determines whether automation will be safe and useful more clearly than an early debate about model selection.
Sources and further reading
Frequently asked questions
Does human approval defeat the purpose of automation?
No. An agent can still collect information, prepare drafts, validate fields, and explain differences. People handle only the smaller number of consequential decisions.
Which actions should not be unattended by default?
Payments, refunds, repricing, publishing, deletion, bulk messages, permission elevation, and external commitments should not execute without explicit authorization and human approval.