Building AI Workflows with Human Approval

Begin with a decision boundary

An AI-assisted workflow needs a precise answer to a practical question: what may the system suggest, and what may it actually change? Drafting a purchasing summary and placing a purchase order have different consequences. Treating both as one conversational task hides the point where a recommendation becomes a financial commitment.

Consider a hypothetical maintenance company reviewing requests for replacement equipment. An assistant could summarize the request, identify missing information and prepare a comparison. The purchasing system should still determine whether the employee can submit the request, whether the budget is available and who must approve it. A persuasive explanation is not authorization.

Write the boundary as a list of allowed operations. A pilot might read approved catalog information and create an unsubmitted draft. It should have no ability to change bank details, approve its own proposal or send an order. Start with the smallest operation that removes useful work from the process.

Make approval an informed decision

A confirmation button is weak protection when the reviewer cannot understand what will happen. Show the proposed action, affected records, important values, source evidence and any uncertainty. The reviewer should see a clear difference between information obtained from a business record and an inference generated by the assistant.

Approval should apply to a specific proposal. If the supplier, quantity, recipient or price changes, require another review. An approval given before a long-running task should not silently authorize a materially different result later. Set an expiry appropriate to the process, and check permissions again when the action executes.

For a purchase request, the review screen could show the original request beside the proposed order. Missing supplier identity should block submission rather than be filled with a plausible guess. If two people must approve a high-value request, the workflow should enforce that rule independently of the language model.

Keep enforcement outside the conversation

OWASP's Excessive Agency guidance identifies risks from granting an AI application unnecessary abilities. Our practical recommendation is to translate each permitted action into a narrow, validated business operation.

A tool that creates a draft purchase request should accept a defined set of fields and reject unexpected ones. The application must verify record ownership, allowed state transitions and limits. Do not let generated text select arbitrary database statements, destinations or commands. An instruction inside a document is content to examine, not a new permission grant.

Retries need business safeguards too. If a network response is lost after a request was created, repeating the operation must not create a second order. Use an operation identifier and an explicit reconciliation path. When the application cannot establish whether the action succeeded, show that uncertainty and route it to an operator.

Design exceptions before the happy path

A workflow may encounter an unavailable approver, conflicting records, an expired session or a failed downstream service. Decide which cases wait, which return to the requester and which require a different authorized person. Avoid a fallback that grants broader privileges merely to keep the queue moving.

A useful pilot includes a manual path that people have actually rehearsed. If the assistant is disabled, staff should still know where the authoritative request is stored and how to finish it. Keep the proposed action and the final action distinguishable so a reviewer can reconstruct what changed.

Define a stop condition. Examples include repeated unauthorized action attempts, unexplained changes to recipients or a sudden rise in rejected proposals. A named process owner should be able to suspend automation while preserving the work queue.

Test the boundary, then measure the workload

Build test cases around failure consequences rather than impressive demonstrations. Include an ambiguous supplier name, conflicting amounts, an instruction hidden in an attachment, a revoked approver and a repeated submission. Verify that an ordinary user cannot obtain an approval role by asking for one.

Measure accepted suggestions, correction effort, escaped errors and total completion time. Count time spent checking the assistant's work. A faster draft may provide little benefit if reviewers must rebuild the evidence manually. Keep severe errors separate from average quality: one unauthorized payment is not cancelled out by many accurate summaries.

NIST's Generative AI Profile provides a voluntary risk-management reference. It does not certify a particular workflow or replace the organization's acceptance criteria.

Before expanding the pilot, confirm that ownership, permissions, review evidence, retry handling and suspension procedures all work. PRAESYNX can discuss software workflow design and integration; requirements should begin with your actual process and its exceptions.