AI workflow approvals: who checks which action?

“Draft plus sign-off” is particularly useful for messages, data changes and handoffs with meaningful consequences. AI prepares the work; an organised process determines whether it is executed. This guide describes our practical design approach, not a blanket legal approval for AI use. Sources and product capabilities were checked on 26 September 2026.

Begin by identifying what becomes difficult to reverse after the next step. An internal summary can often be corrected. A sent message reaches a recipient. Changed bank details may affect a later payment process. These effects need different controls.

The following matrix is a process-design example of review points for six activities in an AI workflow:

This does not replace assessment of professional, privacy or other applicable requirements. Human consent cannot make an impermissible purpose permissible. A review button also does not establish that someone understood the content.

Role. Name the role authorised to decide and the person who fills it in practice. A knowledgeable employee may identify an error without having authority to approve the change. A technically privileged administrator may lack the business context. Both capability and authority need to fit the specific decision.

Cover and escalation. Define cover and escalation. Time-sensitive work needs a fallback if nobody is available. Reminders can help but cannot replace missing approval. After a deadline, a request might move to a named deputy or be deliberately deferred.

NIST framework. The voluntary NIST AI Risk Management Framework treats roles, responsibilities and human oversight as part of managing AI risk. It can inform organisational design but is not a DACH legal requirement and does not prescribe the process described here. NIST AI RMF Core.

Original, proposal and effect. A useful review screen connects the original information, the proposal and its intended effect. For a customer reply, a summary of the draft is insufficient. Show the complete content, recipient and attachments. For a master-data change, show the previous value, proposed replacement and source.

Uncertainty. Express uncertainty in an actionable way. “Customer matching is ambiguous” calls for a different check from “the wording is unclear.” A percentage supplied by the model does not automatically explain that distinction. Its reliability would need separate evidence for the intended purpose.

No unnecessary information. Avoid unnecessary information. Twenty irrelevant fields can hide the one important recipient mismatch. Put critical details first, make sources accessible and explain what the button does: save internally, send a message or change the authoritative system.

Three outcomes. At minimum, distinguish approval of the present proposal, return for correction and rejection. A request for clarification may be another useful option. Each decision should lead to a defined next state.

After a decision. If a proposal is rejected, the AI must not evade the decision with a slightly different action producing the same result. A correction creates a new version. Partial acceptance of a package must either be explicitly supported or return the entire package for another review.

Product models. Products provide different decision models. Microsoft documents, among others, first-response approvals, approval by everyone and sequential approvals. Selecting one determines the actual decision procedure; adding an approval step alone does not establish whose consent is required. Power Automate approvals.

Fixed action. Approval should identify a fixed action through a unique reference. That includes the recipient, content, affected records and relevant starting information. If those details change after review, reconsider whether the previous approval remains valid.

Synthetic example. In a synthetic example, someone approves a message to contact A. Before sending, the CRM mapping is corrected to contact B. The earlier decision must not silently authorise sending to B. Present the new proposal even if its wording remains unchanged.

Stale prerequisites. Stale prerequisites create a similar problem. A case resolved meanwhile may no longer need a reminder. Before execution, check that the approved proposal still fits the current state. An approval with unlimited validity can otherwise trigger an obsolete action hours later.

The following process is fictional and contains no real client information. A professional-services firm has an approved document list for a particular period. The system compares it with known intake and prepares a polite request for missing items. A responsible professional determines which documents are required; the language model does not make that decision.

The fictional document request then runs through five steps:

1. Prepare. The proposal shows the client, period, supposedly missing documents, latest included receipts and complete message.
2. Review and correct. The reviewer notices that one document arrived that morning but was not assigned correctly. They correct the assignment first, after which the proposal is updated.
3. Approve the version. The source and message now agree. Approval is recorded for that version.
4. Recheck before sending. Immediately before sending, the workflow checks whether relevant intake has changed. A new matching document stops the stale draft. Otherwise, the approved content is sent to the verified recipient.
5. Establish the sending result. The case then receives a sending reference. If the connection fails between sending and saving the status, the outcome is initially uncertain. Recovery investigates whether the message already went out. A technical restart must not turn that uncertainty into a second document request.

The final business evidence is complete: the appropriate checklist was reviewed, the specific message approved and its sending state established. A green execution without those details would be less useful for later handling.

Joint approval. One case can contain an email, a CRM task and a document export. Decide whether these are approved together or separately. Joint approval makes sense only when the reviewer can assess the full scope and the actions belong together operationally.

Separate decisions. Separate decisions may involve different roles. Sales might review the reply while another person approves an export. The interface must show which parts are approved and which remain pending. Calling the whole package “approved” would be too imprecise.

Partial failures. Technical partial failures remain possible even after every decision is approved. If the email succeeds but the export fails, do not execute the entire package again. Record the outcome of each action and continue only where the intended effect is still missing.

Cancellation. Include cancellation rules for dependent actions. If a case is withdrawn after the task was created but before the message was sent, the next step should follow the agreed business rule. Do not assume that earlier approval makes every remaining action appropriate forever.

Routine queue. When every low-impact field needs a decision, review becomes a routine queue. That can reduce attention to important cases. Distinguish standard checks that explicit rules can perform reliably from decisions needing actual judgement.

Understandable exceptions. Make exceptions understandable. A missing mandatory field or conflicting customer identifier can create a review case. A vague model score labelled low confidence is less useful without an explained connection to the problem. Staff should know why the case was presented and which information is missing.

Later simplification. Simplify later based on observations. When a class of cases is handled consistently under clear criteria, consider whether a rule-based step would suffice. Do not remove review simply because approval rates are high; proposals may be receiving unread acceptance.

Review time. Measure reading, source checking, corrections and clarification. A long generated draft may take more effort to review than a short message takes to write manually. The number of drafts prepared is therefore not evidence of reduced work.

Comparison. Compare equivalent case types before and after implementation. Also observe waiting time, stale approvals, repeated submissions and errors discovered after execution. Sample completed outcomes so that an apparently smooth process does not merely reflect insufficient attention.

n8n. For example, n8n offers human review of individual agent tools. That capability can support this design. Responsibility, understandable presentation, version binding and business acceptance still need to be implemented for the actual process. n8n human review for tool calls.

Quality and speed. Keep quality and speed visible together. A shorter approval time is welcome only if the relevant checks still occur. If review becomes slow, investigate whether proposals lack sources or contain unnecessary content before encouraging people to approve faster.

Before production, test an approval process against at least six cases:

• a correct proposal
• an incorrect recipient
• missing source information
• a change after approval
• explicit rejection
• an unavailable reviewer

Include a link clicked twice, a stale case and a connection failure immediately after the action.

For every case, state in advance what may happen and what must be prevented. Then inspect the actual destination. A correct message in the approval interface is insufficient if an email was sent twice or the wrong record changed.

Begin with one concrete action and a named decision-maker. Record proposal, decision, execution and result as separate states. Expand once that path remains understandable under corrections and outages, without reducing human involvement to a ceremonial confirmation click.

These pages show approvals in worked examples and cover the decisions around them:

• AI automation: tasks, selection and implementation
• AI automation costs: a first-year budget for SMEs
• Introducing AI: software, an internal team or an agency?
• A tax-firm document workflow: a worked example
• Testing AI document processing: an acceptance template
• How we count results
• n8n service