Put human approval where consequences begin.
A practical framework for deciding what AI may observe, prepare, execute within bounds, or pause for a named person—before a workflow reaches customers, money, commitments, or sensitive systems.
Human-in-the-loop is not one setting.
An AI workflow can have different authority at each step. The useful question is not whether AI is autonomous; it is which specific action is allowed, under which conditions, with what evidence, and who owns the exception.
Observe
Read permitted information, detect an event, classify a request, or prepare an internal summary without changing a business record or contacting someone.
- Identify a new inquiry
- Summarize an inbox thread
- Flag a missing field
Prepare
Recommend a route, draft a response, assemble a document, or propose a record update while a person remains responsible for the consequential action.
- Draft a customer reply
- Prepare a proposal
- Recommend lead routing
Act within bounds
Complete a reversible, tested action when required data, permissions, thresholds, consent, and stop conditions are satisfied.
- Create an internal task
- Send an approved reminder
- Update an allowed CRM field
Approve or escalate
Pause before sensitive, unusual, expensive, public, legally meaningful, money-touching, access-changing, or hard-to-reverse actions.
- Approve pricing or terms
- Authorize a refund
- Publish a sensitive response
Define posture, owner, evidence, and stop condition.
Use this as a workshop starting point. The final matrix should be specific to your workflow, permissions, systems, customers, and risk decisions.
| Action | Default posture | Accountable role | Evidence to retain | Stop or escalate when |
|---|---|---|---|---|
| Internal task creation | May run automatically | Process owner defines rules | Trigger, assignee, due date, source record | Missing owner, duplicate task, or invalid record |
| Routine appointment reminder | May run within approved template and consent rules | Service or operations owner | Recipient, approved template, send status, opt-out state | Opt-out, disputed appointment, sensitive note, or delivery failure |
| Customer-service response | Draft first; bounded routine replies may earn automation | Service owner or assigned representative | Request, approved source, draft, edits, final sender | Complaint, uncertainty, sensitive data, exception, or high-value account |
| Lead qualification and routing | Recommend or route inside documented criteria | Sales owner defines criteria and exceptions | Source, stated needs, rule or reason, assigned owner | Ambiguous intent, conflicting data, restricted category, or no owner |
| Proposal pricing or scope | Human approval before commitment | Authorized sales or delivery owner | Inputs, price source, scope version, approver, timestamp | Missing inputs, nonstandard discount, unusual terms, or stale pricing |
| Contract, refund, or payment action | Explicit approval | Authorized business role | Source record, amount or terms, approver, decision, resulting action | Any mismatch, permission failure, threshold breach, or disputed request |
| Public content or reputation response | Review before publishing when brand or sensitivity is involved | Named communications or business owner | Source context, draft, edits, channel, publisher | Legal threat, crisis, personal data, uncertain facts, or hostile context |
| Access, deletion, or security change | Authorized human approval; consider separation of duties | System or security owner | Requester, target, reason, approver, execution result | Unverified request, excessive scope, missing backup, or failed authorization |
Use the smallest control that fits the consequence.
Blanket approval creates unnecessary queues. Blanket autonomy hides consequential decisions. These patterns let one workflow use different controls at different steps.
Threshold approval
Allow routine values inside an approved range and pause when an amount, discount, risk, or scope crosses the threshold.
Field-level approval
Let the workflow update low-risk fields while protecting pricing, permissions, commitments, status, or other consequential fields.
Exception routing
Define named reasons to stop and route: missing information, conflicting records, unusual language, delivery failure, or an unsupported request.
Preview and edit
Show the source context, proposed action, and editable output together so the approver can make an informed decision.
Timeout and fallback
Specify what happens when no one responds: remind, reassign, expire, or return to manual handling instead of silently proceeding.
Pause and revoke
Give an accountable owner a documented way to pause the workflow and revoke credentials or permissions when behavior is questionable.
Earn authority one action at a time.
Start conservative, test the actual failure modes, and expand only when observed behavior supports a wider boundary. A successful demo is not the same as an operated workflow.
- 01
Map the action
Name the trigger, information used, proposed action, affected person or system, and what changes if the action succeeds.
- 02
Classify consequence
Consider reversibility, money, commitments, privacy, security, public impact, customer harm, and the cost of delay.
- 03
Assign authority
Choose automatic, prepare-only, approval-required, or prohibited—and name who owns approval and exceptions.
- 04
Test the boundaries
Exercise normal, incomplete, conflicting, adversarial, high-value, and failure cases before widening authority.
- 05
Launch narrowly
Begin with limited scope, visible activity, conservative permissions, and a practical return to manual handling.
- 06
Review real behavior
Measure overrides, errors, escalations, response time, completion, and outcomes before changing the approval posture.
Human control is a workflow design decision.
Can an AI workflow take action without human approval?
It can for explicitly permitted, low-risk, tested actions within clear rules and system permissions. Human approval is a stronger default when an action is sensitive, unusual, expensive, public, money-touching, access-changing, or difficult to reverse.
Does human approval make automation too slow?
Poorly designed approval can create a bottleneck. The answer is not to remove every control; it is to reserve approval for consequential decisions, give approvers useful context, route to a named role, define timeouts, and automate reversible steps around the decision.
Who should approve an AI-generated action?
The role already accountable for that business decision should usually approve it. Approval should follow authority, not technical familiarity: pricing may belong to sales leadership, refunds to an authorized service role, and access changes to a system owner.
Is a human-in-the-loop enough to make an AI workflow safe?
No. Approval is one control. The workflow also needs appropriate data access, approved sources, permissions, tests, stop conditions, exception handling, monitoring, documentation, and a defined response when connected systems fail.
What should an approval record contain?
The useful record depends on the systems and risk, but it may include the trigger, source context, proposed action, model or rule output, edits, decision, approver, timestamp, execution result, and escalation reason. Logging capability must be confirmed for the actual tools.
Map the authority before connecting the action.
Bring one AI-assisted process. We'll identify its sources, proposed actions, approval boundaries, exceptions, and accountable owners before deciding what is worth implementing.