Human in the loop is not a strategy.

Keep a human in the loop has become the standard response to concerns about AI in finance.

It sounds responsible. It is not yet a control design.

A human can review an input before the model runs, evaluate a recommendation, approve a write, inspect the completed transaction, or become involved only when a threshold is crossed.

Those are fundamentally different operating models.

The goal is not human or no human. The goal is to place human authority where it controls material risk.

Four review models

Review everything

Every AI-assisted output receives review before use. This can be appropriate during initial pilots, for high-risk workflows, and while establishing baseline performance. It is difficult to scale and can recreate the original manual workload.

Review by threshold

Human review occurs when value, variance, risk, or uncertainty exceeds a defined threshold. This works best when the process has stable data and clear materiality rules. Thresholds still require testing because low-value items can contain high-risk control problems.

Review by exception type

This model directs the question to the person with the relevant expertise, but poor classification can create unnecessary handoffs.

Review by consequence

The system requires approval before an irreversible or material action, such as releasing a payment, posting a journal entry, changing banking details, overriding policy, or deleting source evidence.

AI should propose, not quietly decide

AI can extract information, summarize documents, identify missing context, propose classifications, explain unusual patterns, and draft questions for a reviewer.

The surrounding control layer should determine whether evidence exists, whether explicit rules are satisfied, whether the decision exceeds a threshold, whether the user has authority, and whether the action has already occurred.

The safest AI workflow does not ask a model to be certain. It makes uncertainty visible and routes it appropriately.

The review paradox

Adding more review does not automatically create more safety. Review can become ceremonial when too many items enter the queue, supporting evidence is missing, reviewers cannot see why an item was flagged, or repeated low-risk approvals create fatigue.

Human review is useful when it is informed, authorized, and proportionate.

Design the escalation contract

1. Which decisions may the system complete?
2. Which decisions may it only recommend?
3. Which conditions require review?
4. Who is qualified and authorized to review them?
5. What evidence accompanies the request?
6. How quickly must review occur?
7. What happens if no one responds?
8. Is the action reversible?
9. How is the decision recorded?
10. How do repeated exceptions improve the system?

This is an escalation contract. It turns a principle into an operating mechanism.

Measure the review layer

• Percentage of reviews that change the recommendation.
• Review time by exception category.
• Percentage returned because evidence is incomplete.
• Number of unnecessary reviews.
• Material problems caught.
• Override rate and reviewer agreement.
• Repeated exceptions and unresolved-item aging.
• Downstream reconciliation failures.

If reviewers almost never change the result, the threshold may be too conservative. If they frequently change it, the automation may not be ready. If reviewers disagree with each other, the underlying policy may be ambiguous.

The leadership decision

The executive question is not whether humans remain involved. It is which decisions require human authority, what evidence those people receive, and how the system behaves when certainty is unavailable.

Human judgment should not be spread evenly across the workflow. It should be concentrated where consequence, ambiguity, and accountability are highest.