Where Should Human Approval Sit in a Small-Business AI Workflow?

Put human approval immediately before an AI workflow takes an action that commits your business, affects a person, moves money, publishes content, changes access, or alters an important record. Let the system prepare the work first. The reviewer should then see the proposed action, its source information, and any exception before choosing to approve, edit, reject, or handle it manually.

Which AI actions need human approval?

The approval boundary should depend on the action, its consequences, and how easily your team can correct a mistake. One agent may summarize a customer message without approval, prepare a reply for review, and require explicit permission before sending it.

Use this grid as a starting point for a new workflow:

Read and prepare

Examples: Extract fields, classify a request, summarize a document, draft a reply. Starting control: Run within approved data access and log the result. Reason: Nothing has been sent or committed, and a person can inspect the output.

Reversible internal change

Examples: Add a tag, create a task, update a noncritical status. Starting control: Review during the pilot, then consider narrow automation with monitoring. Reason: The action changes a system but can usually be found and corrected.

External or business commitment

Examples: Send a message, publish content, quote a price, promise a date, approve a refund. Starting control: Require active approval from a named owner. Reason: The action affects a customer, money, reputation, or delivery expectations.

Destructive or sensitive action

Examples: Delete records, change permissions, alter financial data, decide an employee or customer outcome. Starting control: Keep manual or require stronger approval and recovery controls. Reason: The damage may be difficult to reverse or explain.

This table is a design aid, not a universal policy. A CRM tag used only for internal sorting carries less risk than a status that cancels service. A draft remains easy to change until another system sends or publishes it. Define the boundary for each action the workflow can take rather than assigning one autonomy level to the whole agent.

The NIST AI Risk Management Framework supports this action-specific approach. It asks organizations to define human oversight roles, document how people will use and oversee AI output, and assess the oversight process. The framework is voluntary and broad. A small business still needs to translate those principles into controls its team can operate.

Where should the approval checkpoint sit?

Place the checkpoint after the AI has assembled the information needed for a decision and before the workflow executes the consequential action. If approval happens too early, the person still has to gather context and do most of the work. If it happens after the action, it becomes a retrospective check rather than a control.

A practical flow has six steps:

1. An authorized event starts the workflow, such as a new inquiry or draft product record.
2. The system reads only the approved sources needed for the task.
3. The AI prepares a bounded result, such as a classification, summary, qualified record, or draft.
4. A rule checks the action, its consequence, and any exception. Low-confidence or unusual cases move to manual handling.
5. When approval is required, a named person approves, edits, rejects, or reroutes the proposed action.
6. The workflow executes the approved action and records the outcome.

The manual path is part of the workflow. It should identify who receives an exception, what context follows the case, and what happens if nobody responds. A system that merely stops without notifying an owner has paused the work but has not handled the exception.

Approval should also happen where the responsible person can act. That may be an internal tool, CRM queue, or team communication channel. The interface matters less than the decision it supports: the reviewer must have enough evidence, authority, and time to judge the action.

What should the reviewer see?

A useful approval request lets a person understand the proposed action without reconstructing the entire workflow. Showing only an “Approve” button encourages a quick click while hiding the details that make approval meaningful.

Include the following information:

• the exact action the system wants to take;
• the customer, record, document, recipient, or amount it will affect;
• the source information used to prepare the action;
• the relevant business rule or instruction;
• missing information, uncertainty, or an exception that triggered review;
• the fields or content that will change;
• controls to approve, edit, reject, or move the case to manual handling.

The source and the proposal should appear together. For a drafted customer email, show the incoming request, the relevant account context, and the proposed reply. For a CRM change, show the existing value and the new value. For a product listing, show the approved product facts beside the generated copy.

Keep the request focused on one decision. A reviewer who must open several tabs, find the original record, and compare fields manually may spend as much time approving the automation as completing the work directly. That review cost belongs in the evaluation of the workflow.

How did human approval work in the wine merchant case?

In my published wine merchant case, the agent prepares qualified prospects in the client’s CRM, while the client decides whom to contact. The approval boundary sits between research and the commercial relationship.

The client previously searched manually for wine shops and wholesalers, checked them against its criteria, and recorded suitable prospects. I first documented the search sources, disqualifying criteria, and information required in the CRM. I then built an agent to perform that research and recording work.

Several iterations were necessary before the qualification reflected the client’s way of working. The published case does not establish a measured accuracy rate or a number of prospects reviewed, so it should not be treated as a benchmark. It does show why the boundary matters. The agent can prepare a structured list without deciding which business deserves contact or speaking on the client’s behalf.

For a similar workflow, the reviewer would need the prospect record, the evidence relevant to each qualification criterion, any missing or conflicting information, and a clear choice to accept, reject, or investigate the prospect. Automating the next step, such as sending outreach, would create a separate approval decision with different consequences.

How did the boundary differ for product listings?

In my published Shopify case, the system prepares text, visuals, and product listings as drafts according to the merchant’s instructions. A person validates the listings before publication. Here, the approval boundary sits between private preparation and a public claim about a product.

The page reports 20 to 30 prepared listings per day and attributes an estimated saving of one to two weeks per month to the client. The observation period and measurement method are not documented, so those figures describe this merchant’s reported experience rather than a general expectation.

The draft state creates a useful control because the output remains private and editable. The reviewer can compare the description with approved specifications, check the image, correct unsupported claims, and reject the draft without changing the storefront. Publishing is the consequential action.

The wine merchant and Shopify cases use the same principle in different places. In one, the person controls whether research becomes outreach. In the other, the person controls whether generated material becomes public content. “Human in the loop” is therefore not one standard approval screen. It is a deliberate boundary between preparation and the action that carries business consequences.

How do you prevent approval fatigue?

Require approval for the decisions that deserve attention, then keep routine preparation and low-risk handling outside the queue. If every classification, summary, and internal note asks for the same approval, reviewers learn to click through requests without examining them.

Start with four triggers:

• Consequence: the action affects a customer, employee, payment, public statement, delivery promise, or important record.
• Uncertainty: the output lacks required information, conflicts with a source, or falls outside the tested cases.
• Novelty: the workflow encounters a new request type, data source, recipient, or condition.
• Reversibility: the team cannot quickly find, undo, and explain the action.

Route each request to a named owner who understands the decision. A salesperson may judge lead fit, a merchant may approve product claims, and an operations lead may resolve a record conflict. A shared queue without clear responsibility can become another unattended inbox.

Measure how often reviewers approve without changes, edit the proposal, reject it, or send it to manual handling. Also record review time and later reversals. A high approval rate alone does not prove the gate is unnecessary. The cases may be easy, or reviewers may be clicking without enough context. Review a sample of outcomes and examine whether the action remains low consequence and reversible before relaxing a gate.

When the evidence supports a change, narrow it to a specific action. For example, the workflow might create internal follow-up tasks automatically while continuing to require approval for customer messages. Avoid removing approval for every action because one part of the workflow became reliable.

How should you test the approval design?

Test the complete path from input to outcome, including review and exception handling. The goal is to learn whether the workflow reduces work while keeping important decisions visible and recoverable.

1. List every action the workflow can take and identify the systems, people, money, or commitments each action affects.
2. Choose the initial control for each action and name the reviewer or manual owner.
3. Prepare normal cases, known exceptions, missing information, conflicting sources, and examples that the system should refuse or escalate.
4. Run the pilot without removing the existing fallback. Record the proposed action, reviewer decision, edits, execution result, and any later correction.
5. Compare total handling time, review time, corrections, unresolved cases, and maintenance with the previous process.
6. Repeat the relevant tests when the model, prompt, data source, tool permission, or business rule changes.

NIST recommends testing AI systems before deployment and regularly while they operate. It also calls for documenting how output will be used and overseen. For a small team, the records do not need to become a large governance program. A clear list of actions, owners, tests, decisions, and incidents provides a practical starting point.

When to avoid it

Do not automate a consequential action when nobody owns the review, the reviewer cannot verify the result from available evidence, or the business lacks a safe fallback. Clarify the process or keep that action manual. Adding an approval click does not solve missing authority, poor source data, or a decision nobody can explain.

What to remember

• Set approval per action, based on consequence, uncertainty, novelty, and reversibility.
• Put the checkpoint after the AI prepares the work and before the workflow makes the commitment.
• Show the reviewer the proposed action, its sources, affected record, and exception in one place.
• Measure review time, edits, rejections, unresolved cases, and later reversals before changing the boundary.

If you have an AI workflow in mind, send me the task, the tools involved, and the action you would not want it to take unchecked. We can use one real case to decide where preparation ends, where approval belongs, and whether the workflow needs an internal tool or a simpler automation. The broader AI workflow guide for SMBs explains how I choose the overall build path.

Written by Antoine mazu. Antoine helps small service businesses understand and improve their workflows with solutions tailored to their needs, with or without AI. Based in Bayonne, France, he combines product thinking with hands-on technical execution.

Sources accessed September 14, 2026: Antoine mazu’s work, NIST AI Risk Management Framework Core, and AI Agent, Workflow Automation, or Custom Internal Tool?.