Applied AI
Make human approval explicit in AI-assisted workflows
A review button is not an approval process by itself. Specify who authorizes each consequential action, what they inspect, and how the system prevents a changed proposal from using an earlier approval.
An AI assistant can prepare a useful action without having authority to carry it out. Trouble starts when a workflow treats a general request, a preview, or silence as approval. Make the boundary explicit: preparation creates a proposal, approval authorizes a particular proposal, and execution applies only that approved proposal.
Choose the actions that need a decision
List the consequences of each operation before drawing the approval screen. Sending a customer commitment, changing account access, and editing an internal draft should not automatically share the same rule. OWASP recommends human approval before high-impact actions and authorization enforced by downstream systems.[4]
Define approval requirements by the operation’s effect, not by whether the model sounds confident. Document who can approve, who must supply missing evidence, and who can cancel. NIST calls for defined and differentiated responsibilities in human oversight of AI systems.[7] The workflow should make those responsibilities visible to staff.
Show the real proposal
Present the target record, intended changes, supporting evidence, and expected consequence together. Let reviewers compare the current state with the proposed state. Avoid a vague confirmation that merely asks whether the user trusts the assistant. The reviewer needs enough information to identify the specific action being authorized.
Bind approval to that exact proposal. If the recipient, amount, scope, or material text changes, request fresh approval. Set an expiration rule appropriate to the task. For example, a decision based on available inventory should not remain valid indefinitely after inventory changes. These are recommended design controls, not a universal approval standard.
Approval checklist for implementation
Use the following checks when reviewing both the interface and the server-side execution path. A visible button is insufficient if a different route can bypass the same requirement.
- Verify the reviewer’s authority for the specific record and operation.
- Store the proposal version and the reviewer’s explicit decision.
- Invalidate approval when material inputs or proposed effects change.
- Provide rejection, correction, and escalation paths without forced acceptance.
- Read back the target after execution and show whether the approved change actually occurred.
Hypothetical example: a delivery exception
A hypothetical distributor uses AI to draft a message offering a replacement shipment. The service lead sees the affected order, proposed items, recipient, and delivery caveat before approval. The assistant later suggests a different replacement item because the original becomes unavailable.
That revision returns to review instead of reusing the earlier approval. If execution fails, the system reports failure rather than presenting the approved preview as a sent message. The service lead can then choose another replacement or contact the customer without relying on an inaccurate completion status.
Budget for meaningful review
Approval adds delay and reviewer workload. Restrict it to decisions that justify that cost, and test whether reviewers can find deliberately introduced errors. If staffing cannot support meaningful review, reduce the assistant’s authority or narrow the workflow. Do not hide the gap behind an approval step that everyone routinely accepts.
