How to define human approval in an AI automation
Defining human approval in an AI automation means placing a verifiable decision before an action requiring control. Sending a notification after a message is published or a record modified is not enough.
In this exercise, an assistant drafts a response to a fictional request. A person must review its content and destination before the workflow can send any message.
Choose what requires approval
Start with the action rather than AI’s declared confidence. External communication, record modification and a text suggestion have different consequences.
The n8n human-review documentation illustrates a tool waiting for approval or denial before executing. We use that concept to design a control without configuring a real service.
Define actions excluded from the pilot and those permitted to produce drafts only. An approval button is not blanket permission for everything an agent might suggest.
1. Show the complete proposal
The reviewer must see what will happen, at which destination and with which data. A generic approval request does not provide enough context for assessing an external response.
| Review information | Fictional example |
|---|---|
| Action | Send a response |
| Destination | Identified channel and recipient |
| Content | Exact proposed text |
| Evidence | Request and relevant policy |
| Version | Identifier of the reviewed proposal |
Do not hide attachments, parameters or field changes inside a shortened description. Approval must correspond to material that will actually be used.
If the reviewer cannot inspect a relevant attachment, record that limitation before asking for a decision. An apparently complete card may omit precisely the detail changing the action’s consequences.
2. Define who may decide
Select an owner and appropriate substitute for the process. Whoever receives a notification is not necessarily authorized to approve the action.
Record whether the decision can be delegated and which situations require another review level. These rules come from the team’s process and should not be invented by AI during execution.
If nobody is available, define a waiting or escalation state. Lack of response must not silently become consent.
3. Design approval, denial and revision
A negative decision must prevent execution and record the appropriate reason. A revision request should produce a new proposal rather than execute the old version while text changes.
Design human review for this fictional response before sending.
Show which information reviewers need and which decisions they can make.
Include approval, denial, requested changes and no response.
If content or destination changes, require review of the current version.
Do not send messages or configure real integrations.If a workflow offers only two options, explain how revision uses available capabilities. Do not promise a button unsupported by the chosen system.
4. Bind the decision to its version
A dangerous failure is approving one draft and executing another. Keep a stable reference to the approved proposal and check it before acting.
Changes to recipient, wording or relevant fields must follow the defined review policy. Old approval should not automatically authorize an operation with different content.
Implementation must also account for repeated and concurrent executions. A process described on paper works only if the application blocks routes bypassing review.
5. Simulate exceptional cases
Test a complete proposal, missing information and a proposal modified after review. Also simulate an unauthorized reviewer and an attempt to execute the same decision again.
For each case, identify which state should be recorded and which action remains blocked. Do not evaluate only the path where everything is immediately approved.
Know when the control is ready
Completion means demonstrating that execution depends on a valid decision about the correct proposal. The person needs understandable context, and the system must preserve that connection.
Common errors are approving vague descriptions, acting before the response and reusing approval after changing a destination. Monitor review volume so approval does not become automatic clicking without reading.
Combine this design with JSON validation so structured inputs are checked before reaching the reviewer.
Frequently asked questions
What should an action reviewer see?
Show the action, destination, content, relevant evidence and exact proposal version.
Does old approval remain valid after changing recipients?
Changes must follow the defined review policy. Do not silently reuse a decision for a different proposal.
Can no response mean approval?
Do not presume consent. Define waiting or escalation and block execution without a valid decision.