When should a human approve an AI action?

Name the decision that the person is making.

A button labelled “Approve” does not tell a reviewer what they are authorising. Are they accepting a draft, agreeing with a classification, permitting an external message or approving a change to a business record? Those decisions have different consequences and may belong to different people.

Start by separating preparation from execution. A workflow can gather documents, check required fields and draft a recommendation before anyone approves a consequential action. The approval should sit immediately before the action it controls, with any further checks required by the receiving system still in place.

For a proposal, the decision might be: approve this version for sending to this recipient at these terms. For document intelligence, it might be: accept this comparison packet as ready for legal review. Accepting a packet must not silently become signing a contract. For process intelligence, approving a guide confirms its reviewed content; it does not give a reader spending authority or access to an ERP system.

Give the reviewer an evidence packet.

A useful review screen reduces the effort of checking the result without hiding uncertainty. Put the proposed action next to the evidence that supports it. Show the original input, the relevant source references, changes from the previous version and any failed checks.

The packet should answer these questions:

• What exactly will happen if I approve?
• Which record, document, recipient or reporting period does this affect?
• Which source versions were used, and are they current enough for this decision?
• What did the workflow calculate, and what did AI infer or draft?
• Which limits, exceptions or unresolved conflicts remain?
• What happens if I reject it or ask for changes?

Do not make a model’s confidence score the only evidence. A confident answer can still use the wrong source or misunderstand the intended action. If the reviewer must search several systems to reconstruct the basis of every suggestion, the approval interface has transferred the work instead of making it easier.

In the Document Intelligence demo, the comparison identifies source clauses and rule checks before review. It is a synthetic example of a packet, not legal advice or a claim that a real contract has been checked.

Bind approval to the person, version and action.

An approval record needs enough context to prevent it being applied to a different action later. In a real implementation, define the authorised role, the exact proposed action, the input or output version and any expiry. Use the customer’s identity and access controls to establish who can approve; possession of a link alone should not imply the right to approve.

If the proposal changes after approval, the old decision no longer covers the changed proposal. If a recipient changes, check again. If source data is refreshed, decide whether that change invalidates the prior review. These rules should be explicit rather than inferred by an AI step.

Execution also needs its own control. An approval event and a successful action are different records. A network timeout after sending a message does not prove that the message was not sent. Use an operation identifier and the receiving system’s supported reconciliation or idempotency mechanism to avoid blindly repeating a consequential action.

Decide what happens when nobody approves.

An unanswered request should remain pending or expire according to the agreed policy. It should not turn into approval when a timer runs out. A rejected action should have a reason and a clear next step: revise, route to another responsible role or stop.

Escalation needs equal care. Sending a reminder is different from handing over the right to approve. If a substitute reviewer is allowed, define that role in advance. Preserve the original context when a case moves between people so that the new reviewer sees the same unresolved issues.

For an unavailable approval service or an invalid response, stop the controlled action and retain enough state to recover. Avoid asking someone to approve an old packet after newer inputs have already arrived. Keep a clear distinction between waiting for a human, retrying a technical step and investigating an uncertain execution result.

Test attempts to skip the approval.

The happy path is only one case. Acceptance tests should cover the situations where the workflow must refuse to continue:

1. A reviewer rejects the action; execution remains blocked.
2. Approval expires before execution; a new decision is required.
3. The input changes after review; the previous approval cannot be reused.
4. The same approval message arrives twice; the action is not duplicated.
5. Someone without the appropriate role tries to approve; the attempt is rejected.
6. A system times out after an attempted action; recovery checks the outcome before retrying.
7. The workflow is replayed; old approval state does not carry into the new run.

The local demos test pausing, approval and reset behaviour. They do not authenticate real approvers or exercise a customer’s permission model. Those require integration tests against the chosen systems and identity provider. Keep that distinction in the evidence you use to decide whether to launch.

Make review proportional and worth the person’s attention.

Requiring approval for every harmless formatting step can create a queue of clicks. Requiring none for externally visible actions can create a different problem. Group low-consequence preparation work, then place a clear approval step before the meaningful decision.

Measure how long review takes, how often reviewers change the draft and how many cases need escalation. High approval rates alone do not show that the process is working: people may be approving without enough evidence. Sample the quality of the decisions as well as the throughput.

In larger companies, separate review responsibilities can be appropriate. A subject-matter reviewer may confirm correctness while an authorised business owner permits release. In smaller teams, the same person may perform both roles, but the two decisions should still be understandable.

The aim is an interface that makes clear who may approve what. See the engineering principles, the Process Intelligence example or use the Workflow Fit Checker to identify where your own approval step is still unclear.