Human-in-the-Loop Without the Bottleneck: Designing Human Oversight

Requiring human approval for every action can erase much of the time saved by automation. Too little oversight can let a small error spread. Done properly, human-in-the-loop is not a compromise in the middle — it is a mechanism designed around risk.

Oversight driven by risk, not by fear

The National Digital Agency’s public-sector guide emphasizes risk management throughout the system lifecycle. The December 2025 interministerial financial-sector report recommends risk-based oversight, institutional accountability, and disclosure measures. These recommendations should not be read as a blanket legal requirement for human approval of every AI action. Process design must reflect the rules that apply to the specific activity.

Instead of asking “does a human need to approve this?”, ask how severe the potential harm is, how reversible the action is, and how reliable the system has proved on comparable cases. Do not treat a model’s self-reported confidence as a calibrated probability of correctness.

The table below illustrates an internal policy, not a universal risk classification or statement of law:

Risk level	Example	Oversight mechanism
Low	Classifying a non-sensitive internal document	Automatic execution with sample review
Medium	Drafting a customer reply	Tested quality threshold, approval on exceptions
High	Rejecting a claim or making a high-value payment	Human approval before execution under the example policy

A human task is part of the process

A good approval task carries context, the agent’s recommendation, supporting evidence, a short explanation, and clear actions. It also needs a response deadline, a designated backup, and an escalation path. The reviewer must have the authority and time to challenge the recommendation.

An approval request sent by email can be part of human oversight, but without tracking it leaves a gap in the process. The process engine needs to know that a case is waiting, who owns it, and what to do when the allotted time runs out.

What to include in the audit trail

• The relevant inputs and evidence, subject to data minimization, access controls, retention rules, and applicable privacy requirements.
• The model version, the prompts, and the tools invoked.
• The system’s recommendation, validation results, and any confidence score with its method and limitations.
• The approver’s identity, the response time, and the reason for any change.
• The final outcome and its business impact.

This record is not only for the regulator. It shows where people correct the model, helps refine rules, and lets you expand automation on the basis of evidence.

Implementing it in Camunda

Decision gateways, user tasks, and timer events let you model approvals, waiting, and escalation. A task deadline alone does not implement escalation; model and test the timeout path. Keep thresholds in explicit rules and test policy changes before deployment.

This lets people retain authority at critical decision points while routine cases follow the approved policy.

Further reading (Hebrew sources)

• Israel National Digital Agency: Responsible use and AI risk management
• Bank of Israel: Recommendations for AI use in the financial sector
• Privacy Protection Authority: Recommendations for personal use of generative AI

Summary

• The level of oversight should follow the risk and the reversibility of the action.
• A human task needs context, an SLA, and an escalation path.
• A good audit trail serves both compliance and continuous improvement.

Want to turn AI policy into a working mechanism? Talk to us