When Should an AI Workflow Require Human Approval? How to Decide

You have probably already built something good. A workflow that reads incoming requests, drafts a reply, updates a board and moves work along without anyone chasing it. It runs, it saves real hours, and the team trusts it.

Then someone asks a reasonable question. “Should a person sign off before this thing sends anything?”

That deserves a better answer than "add an approval step to be safe" or "the law says you have to". Here is how we decide.

For ordinary business automation, no, and it is worth being precise about why.

The EU AI Act does have a dedicated article. Article 14 is headed "Human oversight" and requires that high-risk AI systems be built so that "they can be effectively overseen by natural persons during the period in which they are in use". It binds high-risk AI systems, a defined category, not all AI. And those obligations do not apply yet.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and extended the timelines. The Commission's policy page now says the rules for high-risk use cases in certain sensitive areas, the Annex III set, apply from 2 December 2027, and the rules for high-risk AI embedded in regulated products, the Annex I set, from 2 August 2028. Article 14 itself was not amended: Article 1 of the amending regulation lists every provision it touches and Article 14 is not among them.

The Act also puts a duty on the organisation using a system, not only the vendor that built it. Article 26, headed "Obligations of deployers of high-risk AI systems", requires deployers to assign human oversight to people with "the necessary competence, training and authority". Remember that phrasing.

No, and this is the most common mistake on the topic. Article 22(1) gives a person "the right not to be subject to a decision based solely on automated processing" with legal or similarly significant effects. For two of the three exceptions in Article 22(2), contract necessity and explicit consent, Article 22(3) requires safeguards including "at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision."

That is a route to a human after the decision, and a right to argue with it. An appeal route, not an approval gate. The word doing the work is "solely", so an automation with a genuine human decision-maker in it sits outside Article 22 altogether. That is why a checkpoint can be a compliance strategy even where no law commands one.

The reach is also wider than people assume. In Case C-634/21, decided on 7 December 2023, the Court of Justice of the European Union considered automated credit scoring and the use of that probability value by third parties. That judgment is also the most practical place for a reader to check any of this, because it reproduces Article 22 in full at paragraph 11.

NIST's AI Risk Management Framework, as currently published, has a subcategory on exactly this. GOVERN 3.2 asks for policies that "define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems", and two of its eight suggested actions ask for "proficiency standards" and "specified risk management training protocols" for the people carrying out oversight tasks. NIST is voluntary guidance. It asks you to name the humans and make them competent, not to add an approval step.

The Model Context Protocol specification, revision 2026-07-28, is blunter: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." SHOULD is a recommendation rather than a requirement, and that wording has survived unchanged across revisions.

One standard you may see cited here is ISO/IEC 42001:2023, the AI management system standard, published in December 2023. Its normative text sits behind a paywall, and its free public page says nothing about human oversight, so we will not tell you it requires any.

Four questions, about a minute per workflow.

1. /01Can you undo it? A board update, a draft, an internal summary: reversible. A payment, a client email, a deletion: not really.
2. /02Does it leave the building? Anything reaching a customer, a candidate, a supplier or a regulator in your name earns a different threshold from anything that stays in your own tools.
3. /03Does it affect someone's rights or money? Pricing, credit, hiring, access, entitlement. That is the same territory GDPR Article 22 and the AI Act's high-risk annexes care about.
4. /04Could you explain the decision tomorrow? If nobody could reconstruct why the system did what it did, attach a person while you fix that.

monday.com's Pipeline Health Agent in monday CRM is a clean worked example of the second question. Its documentation states: "All analysis runs autonomously. Rep nudges require your review and approval before they are sent." A preference called "Rep nudge trust tier" defaults to review and approval, with a surface-only option and a T3 tier that can auto-send inside defined guardrails. The agent is in a Gradual Release, so availability is limited. Thinking is free, sending is gated, and the gate has a dial.

As late as possible, immediately before the irreversible action. Anthropic's Claude Agent SDK documentation shows why. Every tool request runs through a documented six-step order ending in the canUseTool callback that asks the human, and the docs warn that "Auto-approved tools never reach canUseTool", so permission checks placed there "are silently bypassed for that tool". For checks that must run every time, the guidance is a PreToolUse hook, and the SDK now emits a warning, CLAUDE_SDK_CAN_USE_TOOL_SHADOWED, when it detects that shape.

The automation platforms express the same idea as a pause. monday.com's changelog, on 3 August 2026, says you can "Add a human-in-the-loop block in AI Workflows to send approval requests and branch based on the response". Power Automate has "Approvals - Start and wait for an approval" and "Create an approval (v2)". Zapier's Human in the Loop feature has a "Request Approval" action that pauses a Zap until reviewers approve, decline or change the data.

None of it is free. Zapier notes reviewers "must log into their Zapier account to review the request", and Microsoft tells you to store approvals in Microsoft Dataverse if a flow might run for more than 30 days, so an approval step is also a deadline you now own. Availability is gated too. Zapier gates the feature to its paid plans, and Make lists its Human in the Loop app on the Make Enterprise plan and in closed beta.

On monday.com four meters are in play: AI credits, the cap on active AI workflows, your monthly automation action allowance, and the API rate limit. monday lists the AI workflow builder as available on Pro and Enterprise plans, and the cap is product-scoped, which matters here: on the monday AI work platform it is 20 active workflows on Pro and 250 on Enterprise, while on monday CRM, monday service and monday dev it is 5 on Pro and 250 on Enterprise. monday also states that "executing condition steps also counts toward and consumes from your action quota", and an approval block branches, so the waiting is free and the branching is metered.

Because it buys the feeling of control without the control, and then you stop looking.

The clearest documented case is the US Federal Trade Commission's action against Rite Aid. In December 2023 the FTC announced that the retailer "will be prohibited from using facial recognition technology for surveillance purposes for five years" to settle charges over its use of the technology in hundreds of stores. The FTC's case page records a Stipulated Order for Permanent Injunction and Other Relief dated 8 March 2024, and lists the case status as pending.

Here is the part that matters for your workflow. There was a human in the loop. Store employees received the alerts and acted on them. According to the FTC, "The system generated thousands of false-positive matches", and the failures it alleges included having no enforced "procedure for tracking the rate of false positive matches" and not adequately training the employees operating it.

Three independent sources point the same way. The EU legislature named the failure in advance, requiring that a high-risk system be provided so the people assigned to oversee it are enabled "to remain aware of the possible tendency of automatically relying or over-relying on the output produced by a high-risk AI system (automation bias)". Anthropic documents the software version, where an auto-approved tool never reaches the callback you wrote. NIST asks for the same in its two GOVERN 3.2 actions on proficiency standards and training protocols. So a checkpoint is not a step in a diagram. It is a person with the information, the training and the authority to say no, which is what Article 26(2) describes.

You may want a number here. We looked and found none we would publish: no primary, named, dated, method-bearing study quantifies how often AI automations fail for want of an approval step. What circulates instead is consultancy survey figures and AI-generated summaries.

The flip side deserves saying plainly. A checkpoint on a low-stakes, reversible, internal action is drag, and it trains people to click approve without reading. If a step is approved thousands of times with no rejections, that is a queue, not a control.

Most teams we meet do not need more approval steps. They need the two or three they already have to be real, and the rest of the workflow to run clean.