Where should human approval remain in an AI workflow?

AI drafts a customer reply. A person checks the grammar and clicks Send.

The grammar is correct. The delivery date AI promised is impossible.

A human was involved, but the important decision was never checked. This is the weakness hidden inside the phrase human in the loop: it tells us that a person appears somewhere in the process. It does not tell us what that person must understand, which evidence they must inspect, or which action they have the authority to stop.

Human approval becomes useful only when it is attached to a specific decision in a specific workflow.

Start with the consequence, not the approval button

The first question is not “Where can we add a review step?” It is: what can this AI action change?

An internal label that can be corrected in seconds carries a different consequence from an email that commits the company to a price. A draft task carries a different consequence from a production deployment. A recommendation carries a different consequence from a decision about a person.

A practical rule is to make approval earlier and more explicit as the action becomes harder to reverse, more visible outside the company, or more consequential for money, rights, safety or a person’s work.

This does not mean every AI output needs a manager standing over it. NIST’s AI Risk Management Framework makes the distinction clearly: some systems may not need human oversight, while other uses do. What matters is that the human roles and responsibilities are defined rather than assumed.

An approval point needs five things

For every AI-assisted step, write down five things:

The action. Is AI drafting, recommending, updating a record, sending a message or making a decision?
The consequence. What changes if the output is wrong, incomplete or sent to the wrong place?
The evidence. Which source must the reviewer compare the output against?
The owner. Which named role has the knowledge and authority to approve, reject or stop the action?
The recovery. Can the action be reversed, and how will the team know that it needs to be?

“A manager checks it” is still too vague. A usable instruction sounds more like this: the account owner confirms the quoted price and delivery date against the approved proposal before the reply can be sent.

Now the person knows what to check. The company knows who owns the decision. The workflow can record whether approval happened.

Workflow 1: meeting notes becoming tasks

AI can prepare the meeting summary, identify possible decisions and draft tasks. The human check belongs before those tasks become commitments for other people.

The reviewer confirms:

Was this actually agreed, or merely discussed?
Did the named owner accept the task?
Is the deadline real?
Is any important qualification missing from the summary?

For a low-risk internal meeting, the system might create draft tasks that are easy to correct. For a client commitment, budget decision or regulated action, a named owner should confirm the decision before it moves into the system of record.

The human is not checking whether the sentence sounds professional. The human is checking whether the task represents what the room decided.

Workflow 2: customer replies and commercial promises

AI is useful for preparing a response, finding relevant context and keeping the wording clear. Sending the reply can change the company’s obligations.

Before Send, the account owner may need to confirm:

price and discount,
scope and exclusions,
delivery date,
confidential or personal information,
and whether the response matches the approved contract or proposal.

The approval boundary belongs before the external promise, not after the email has already reached the customer.

Workflow 3: invoices and exceptions

AI can extract invoice data, match it against a purchase order, identify missing fields and prepare an exception summary. A standard, well-tested match may eventually need only sampling and monitoring.

An exception is different. If the amount differs, the supplier is unknown, the purchase order is missing or bank details changed, a named finance owner should decide what happens next. AI can collect the evidence and recommend an action. The owner approves the exception or stops the payment.

The human role is judgement over the exception, not retyping the invoice.

Workflow 4: code and production changes

AI can propose code, write tests and explain a change. Passing tests are evidence, but they are not the whole decision.

The reviewer needs to understand what changed, whether the tests cover the relevant failure modes, which data or permissions the code touches, and how the team can roll it back. A production deployment should retain a clear owner and the technical ability to stop or reverse the change.

This is the same approval principle in a more technical setting: the person checks the consequence and the evidence, not the confidence of the explanation.

Workflow 5: decisions about people

AI may help organise permitted information, prepare interview notes or point to missing evidence. Decisions about hiring, performance, access or employment carry direct consequences for a person and may also fall under specific legal requirements.

The decision should remain with a competent person who can inspect the source information, question the recommendation and disregard it. The exact legal duties depend on the use and jurisdiction, so this is where the organisation’s legal or compliance owner must be involved.

For high-risk AI systems, Article 14 of the EU AI Act is more specific about human oversight. It addresses understanding system limitations, recognising automation bias, interpreting outputs, overriding or reversing them, and stopping the system. Those requirements do not make every office assistant workflow a high-risk system. They do show why a passive final click is not meaningful oversight.

When can approval become lighter?

Approval does not have to remain fixed forever. It can change when the team has evidence that the workflow is reliable.

A low-consequence, reversible internal action may move from reviewing every result to sampling. A repeated classification task may run automatically while exceptions are routed to a person. A customer promise, payment exception, production release or consequential people decision may keep mandatory approval even when the drafting becomes excellent.

The change should follow evidence: logged errors, known failure modes, successful recovery tests and clear exception handling. Familiarity with clicking Accept is not evidence.

Microsoft’s research-backed Guidelines for Human-AI Interaction add useful design checks here: make clear what the system can do and how well it can do it, support correction when it is wrong, explain why it behaved as it did, and give people meaningful control.

How to teach the boundary to a team

Do not begin with a generic slide saying that people remain responsible. Put one real workflow on the screen.

Show the team:

what AI receives,
what it may prepare,
what it may change,
which evidence the person checks,
what requires approval,
and what happens when something looks wrong.

Then practise with an output that contains a believable mistake. Can the person find it? Do they know which source to check? Can they reject the output, stop the action and explain why?

That is a stronger test than asking whether they completed an AI course.

The boundary in one sentence

AI may prepare more of the work as the system improves. A named person should still own the point where an error becomes a consequential action, unless the organisation has evidence, controls and a recovery path that justify moving that boundary.

Human approval is not a final click. It is a defined responsibility inside the workflow.