Who Signs Off an AI Decision? Approval Design for AI Workflows

Once a business decides some decisions belong to a person rather than the AI (see our earlier piece on which decisions AI should make), a second question follows immediately: who actually does the reviewing, at what point in the process, and checking for what? Get this wrong and the review step becomes theatre. It exists on a diagram, satisfies an auditor for five minutes, and stops nothing in practice.

The rule we apply when we design these gates for clients is simple to state and easy to get wrong in the doing: route human review by what a mistake costs and whether it can be undone, never by how many items there are to check. Volume-based review looks rigorous and behaves like no review at all, for reasons that are worth working through properly.

Why does approving everything end up approving nothing?

Put a person in front of a queue of AI-generated items and ask them to approve each one, and the queue itself changes their behaviour. Ten items a day, a reviewer reads each one. Two hundred items a day, a reviewer develops a rhythm: skim, click approve, skim, click approve. Nobody decided to stop reading. It happened because reading two hundred things properly, every day, is not a job a person can sustain, and the workflow gave them no way to spend their attention selectively.

This is the practical failure of "a human reviews everything" as a governance answer. It sounds like the safe choice. In production it converges on the same outcome as no review at all, except now there is a name against the approval, which is arguably worse: it creates the appearance of accountability without the substance of it. The one drafted email that would have caused a real problem goes through in the same click as the 199 that were fine, because nothing in the process told the reviewer which one deserved their attention.

Where in the workflow should the approval actually sit?

Once you accept that review has to be rationed, the next question is where to spend it. We place approval gates using the same test throughout: what happens if this specific action runs unsupervised, and can it be undone afterwards?

• Before anything irreversible or outward-facing: an email that leaves the building, a price quoted to a customer, a write to a live CRM record that other teams and automations depend on. These get a person in front of them before they execute, not after. Write access to a CRM is the clearest version of this: a bad read produces a bad suggestion, but a bad write changes the system of record, and every downstream process inherits the error silently.
• After the fact, on a sample, for anything cheap and reversible: an internal draft, a first-pass tag, a summary nobody acts on directly. Let these run, then audit a sample regularly. Sampling is not there to catch every error; it is there to catch drift in the system's behaviour before it compounds.
• Approve the plan, not each step, for anything long-running: a multi-step agent process that researches, drafts, checks and files something over several minutes does not need a person nodding at every intermediate action. It needs a person approving the plan before it starts and the outcome before it lands, with the steps in between running on the authority already granted. Reviewing every step of a long process is the same consent-fatigue problem in a different shape.

Notice that none of these three depend on how many items pass through the workflow in a day. They depend entirely on what a single wrong instance costs and whether you can walk it back.

What does a "valid but wrong" output actually look like?

The hardest failures to design a gate against are not the obviously broken ones. A response with a typo or a malformed record gets caught by ordinary validation. The failures that get through are the ones that pass every technical check and are still wrong, because the check was asking the wrong question.

An AI-drafted quote can be correctly formatted, arithmetically sound, addressed to the right contact, and still wrong, because it applied last quarter's discount structure. A CRM update can be a perfectly valid write, matching the schema, and still wrong, because it merged two contacts who share a name but run different companies. A categorisation can tick every field the system requires and still route a complaint from a top account into a general queue where it sits for three days.

In every one of these, "is this well-formed" returns yes. The gate that would have caught it asks a different question: what happens downstream if this runs unchecked? That is a question about consequences in the business, not the shape of the output, and it is usually not the question an automated validation step is built to ask. A reviewer checking format will wave through exactly the errors that matter most.

How do review gates quietly stop working without anyone deciding to remove them?

We have watched the same gate dissolve in three distinct ways, none of which involve a decision to remove it. That is what makes them dangerous: nobody signed off on weakening the control, so nobody notices it has gone.

Trust creep. A step gets reviewed closely for its first few weeks. The outputs are consistently fine. The reviewer starts skimming, then starts approving on sight, then starts approving before finishing the read. Nothing about the underlying task changed, and the one week it produces a genuinely wrong output is statistically no different from any other week: it is simply the one where the reviewer's attention has fully worn down.

Quiet full automation. A workflow is designed as "AI drafts, person approves". The person doing the approving moves teams, or gets busy, and nobody restaffs the review. The outputs keep going out, because nothing in the software actually required a person to click anything, only the process document assumed one would be there. The workflow has become fully automated by neglect, not by decision.

The gate exists on paper, not in the system. A policy document says a person must sign off before a certain action runs. The software that performs the action has no such check built in. A busy person, or an AI agent with the same access, can simply do the thing the policy says requires sign-off, because nothing stops them. A written rule that a person or a model can bypass under time pressure is not a control. It is a hope.

What makes an approval gate real, rather than a line in a policy document?

An approval gate is only a genuine control when it specifies three things concretely: who reviews it, what they are checking for, and at which point in the flow the check happens. Missing any one of those three, what looks like a gate on paper is not one in practice.

"A senior person reviews AI outputs before they go out" fails this test on all three counts. Which senior person, specifically, and what happens when they are on leave? Reviews for what: tone, factual accuracy, commercial exposure? Before which outputs, and does "before they go out" mean before drafting or before sending? Compare that with: the account manager on the deal approves any AI-drafted quote that includes a non-standard discount, checking it against the current approval matrix, before the quote is emailed to the customer. That version can be built into software, tested and audited. The vague version cannot, and that gap is exactly where the three failure modes above take hold.

This is also where the gate has to live: enforced in the software the AI and the person both operate through, not only written down as a policy that depends on people remembering it under pressure. A gate built into the workflow (the send button disabled until a reviewer field is populated, the CRM write blocked until a status changes) survives someone being busy, being new, or being an AI agent with no concept of a policy document at all. A gate that exists only in a wiki page survives none of those. For a fuller treatment of how these controls sit inside a wider governance structure, see our guide to building an AI governance framework for a UK business. Approval design is one component of that structure, not a substitute for it, and it is a specification we build alongside the workflow itself when we scope an AI implementation, rather than a governance add-on bolted on afterwards.

Frequently asked questions

Should every AI-generated output get human approval before it is used?

No. Requiring approval on everything regardless of stakes is what causes consent fatigue in the first place: a reviewer facing a large volume of low-risk items stops reading them properly, so the one item that mattered goes through unchecked along with the rest. Reserve pre-action approval for outputs that are irreversible or outward-facing, and handle cheap, reversible outputs with after-the-fact sampling instead.

Who should be the named reviewer for an AI approval gate?

Whoever is accountable for the outcome if the action turns out to be wrong, not whoever happens to be available or holds the most senior title. For a customer-facing quote, that is usually the person who owns the account and will field the customer's call if the number is wrong. A vague label such as "someone senior" is precisely the gap that lets a gate go unstaffed when the person holding it moves on.

How do we stop an approval step from being skipped under time pressure?

Build the check into the software the action runs through, rather than relying on a written instruction that a busy person, or an AI agent, can bypass. If the system will not send the email, execute the write or release the payment until a reviewer field is populated by an authorised person, the gate holds regardless of how much pressure anyone is under. A policy that depends on someone remembering to follow it is not a control in the way a disabled button is.

Does a long-running AI agent need approval at every step it takes?

Not usually, and requiring it tends to backfire. Approving dozens of intermediate steps in a single agent run recreates the same fatigue problem as reviewing every item in a queue: the reviewer's attention wears out before the step that actually mattered. The more reliable pattern is to approve the plan before the agent starts and the outcome before it is acted on externally, with the steps in between running on the authority already granted.

John Kelleher is a Claude Certified Architect (Foundations and Professional) and leads SpotDev, a Claude Registered Partner and OpenAI Select Partner.