Human Oversight
Part of Human oversight in automated processes
Choosing decisions that still need human approval
Screen automated decisions for authority, judgement, consequence and reversibility before placing prior human approval.
Require human approval before an automated action when the decision needs authority or judgement the automated rule lacks, or when consequence and reversibility make prior review necessary under policy. Assess the decision itself, not only its value. A monetary limit alone cannot settle whether approval is needed.
Separate checking from deciding
Write the proposed decision as a verb and an object: grant access, release an order or accept an exception. List the facts needed and who has authority to decide. Software may validate fields, calculate a value or propose a route without being authorised to make the final decision.
Ask five questions for each proposed decision:
- Is the rule settled?If responsible staff disagree about the same case, resolve the rule before automating the decision.
- Does it require judgement?Identify which circumstances must be weighed and whether an authorised person must do so.
- What could an error affect?Consider people, sensitive access, funds and actions that cannot readily be undone.
- Can the system recognise its limits?Missing, conflicting or stale information needs a defined response, not an apparently certain recommendation.
- Can the reviewer act in time?The action must wait if prior approval is the control.
This screen does not decide the legal position for a particular organisation.
Choose a route and define approval
For each decision, record one of three outcomes: routine action under an agreed rule, human approval before action, or hold for specialist resolution. Record the reason and the person authorised to change that choice. A bounded, reversible action with reliable inputs may fit the routine route. A disputed decision or sensitive permission change may require prior review even when software can recommend an outcome.
Show the approver the relevant facts, proposed action, rule used and known uncertainty. Define whether they may approve that action, return it, decline it or escalate it. State whether approval covers one case, a defined batch or a class of future cases. Do not infer broad authority from one accepted example.
Check that approval is real
Ask the prospective reviewer to explain a sample decision using only what the workflow will show. If they cannot see the evidence, disagree with the recommendation or stop the action, change the design. Name a backup for absence and keep unanswered cases pending at the deadline unless an authorised alternative route applies.
Before launch, trace an ordinary request, a consequential request, a missing fact and a disputed recommendation through the proposed route. Check which authority receives each case and whether execution waits for the required decision.
