Human approval in AI applications: make the decision specific
Choose the actions a person must approve, show the evidence and enforce the result in code.
If an AI application can send a message, change a record or run a tool, decide where a person must approve the action. Specify what the reviewer sees, what they can change and how they can stop it. A review button is useful only when the person has the information and authority to make that decision.
Choose approval steps based on what the AI can change
Assess the effect of a wrong result and whether it can be reversed. Changing a supplier’s payment destination may need an authorised person before execution. An internal draft may follow a different process, but can still need access controls and factual checking. Do not assume that every generated sentence needs approval, or that internal use is automatically low risk.
Give the reviewer the proposed action and evidence
Show the exact recipient, record, amount or permission to be changed, together with the relevant source and uncertainties. Let the person reject, edit or ask for more information. Avoid an interface that makes approval easier than reading the evidence. Define the reviewer’s role and training rather than assuming any available employee can make the decision.
Bind approval to the action that executes
Check approval at execution time against the specific action and current authorised user. If the recipient, amount or other material argument changes, require a new decision. Record the approver, time and approved action without unnecessarily retaining sensitive content. A statement generated by the model is not independent evidence of approval.
Specify what happens when nobody responds
Define expiry, escalation and the failure state. Do not let an action requiring approval execute merely because a timer expired or a service restarted. Test rejected, expired, duplicate and changed requests. For an agent, review sequences of tool calls as well as individual actions; several permitted steps can still produce an unintended result.
Check whether the control works in practice
Measure corrections, inappropriate approvals, waiting time and unresolved requests. Investigate repeated overrides and whether reviewers have enough time and information. NIST’s AI RMF distinguishes human and AI oversight roles; Japan’s AI Guidelines for Business are another reference to examine with the buyer. This article proposes risk-based design controls, not a claim that a guideline mandates the same checkpoint for every application.
// Key Takeaways
What to remember
- Choose approvals from the action’s consequences and reversibility.
- Show the exact action and bind approval to what will execute.
- Test rejection, expiry and changed requests, then review operating results.
// FAQ
Frequently asked questions
Does every AI output need human approval?
The appropriate control depends on the task, consequences and applicable requirements. Identify actions needing prior approval and provide other controls for lower-risk uses.
What should happen if an action changes after approval?
A material change, such as a different recipient or amount, should require a new decision. Enforce approval against the action that actually executes.
Last updated:
Demonstrate approval controls in your Japanese AI evaluation.
Share which actions require approval, how the product records it and what happens after rejection or timeout. Our team can coordinate Japanese demonstrations with the prospect’s business and IT teams and document the supported workflow.