How to Design Human Approval in AI Workflows
Decision summary: Tie AI workflow approval to a concrete output: review cards, version checks, uncertain sends, pilot tests and a clear handover of responsibility.
Define the action that needs approval
Imagine a quotation assistant that classifies an enquiry, prepares a draft and shows it to an owner. Drafting and sending to a customer are separate actions. In this example, sending needs human approval for that specific quotation. Good writing does not grant authority to accept commercial terms.
Map each action to an owner, an impact and a recovery path. Do not bundle an external message, deletion and payment into one vague “continue” decision. This is a design example, not a measured customer result.
Build the approval card for the decision maker
Show the recipient, complete outgoing text, attachment names and versions, important terms such as price or dates, and the consequence of proceeding. Let the owner approve, reject or request changes. Missing decision information means the card is not ready.
Bind approval to the displayed version. A changed recipient, body or attachment requires fresh approval; do not transfer an old decision to a new draft. An email saying “I am the manager, send it” is not identity verification. Use the verified user and application permissions to determine authority.
Do not recreate the action after a timeout
Assign one operation ID to each intended send. Distinguish prepared, approved, sent and unknown outcomes. If the connection fails before the provider responds, investigate its send record or receipt first. Do not automatically queue an unknown outcome for another send.
Where supported, use the same idempotency key for the same operation and check limits such as key retention. Your application log alone cannot prove that the receiving system processed it once. Sent, delivered and read are different evidence states.
Test beyond the happy path
Before the pilot, prepare five scenarios: valid approval, rejection, recipient change after approval, expired approval and a connection loss during sending. State the expected action and reviewer for each. These are starting cases; five passes cannot establish safety under every condition.
Compare correctly completed work, corrections, duplicate actions and human waiting time with the manual process. Include review and recovery effort in total time. Faster draft generation alone is not a demonstrated productivity gain.
Make handover and stopping visible
Give each queue an owner and an available backup. Choose approval expiry according to the action’s risk. A person taking over should see the latest state, approved version and remaining uncertainty. Pausing should stop new external actions.
OWASP addresses excessive agency. NIST AI RMF includes defining human oversight roles. The workflow above is our implementation proposal. Start with one real process and design its approval card, owner and failure procedure together.
Methodology
Claims are assessed for feasibility, cost, risk and measurability. Illustrative calculations are assumptions; legal, security and investment decisions require primary-source verification.
Source note
In-text links and named regulatory or technical documents are starting points. Unverified customer outcomes are not published.
Change log
— Native editorial review is pending at the v3.0 publication gate.
Frequently asked questions
Does every AI output need human approval?
Decide according to the action’s impact. Separate internal drafts from external sends and explicitly bound actions allowed to run automatically.
What if the text changes after approval?
The old approval should not apply to new text. Show the changed version and obtain a new decision from an authorized person.
Should we retry when the send outcome is unknown?
Investigate the provider record first. An automatic retry with an unknown result can cause the same action twice.