In brief
- The required level of human control depends on the impact and reversibility of a decision or action.
- A reviewer must be able to see relevant inputs, sources, uncertainty and planned consequences.
- High volume, time pressure and repetitive confirmation create automation bias and ineffective oversight.
- Approvals should be logged, assessed regularly and supported by automated limits where necessary.
Which cases need human control?
Not every summary needs the same review as a dismissal, payment or medical recommendation. The organisation assesses failure impact, affected people, reversibility and legal or internal obligations, then creates graduated control rules.
| Error impact and reversibility | Appropriate control | Review point | Example and escalation |
|---|---|---|---|
| Low impact and easy to correct | Sampling and retrospective quality review | After use, supported by continuous evaluations | Internal wording draft; repeated patterns go to the product owner. |
| Medium impact or external communication | Mandatory review by an accountable domain expert | Before sending or writing to the system of record | Customer response; missing source or exception escalates to a specialist. |
| High impact or hard to reverse | Explicit approval, with dual control where appropriate | Immediately before action with the change and consequence visible | Payment, deletion or contract change; deviations go to the process or risk owner. |
| Unmanageable impact or no effective review possible | Do not automate this decision step | Keep the task outside the approved AI path | Sole decision about employment or treatment without a sound legal and process basis. |
What makes review meaningful?
The reviewer must understand what AI contributed and cannot see only the finished result. Evidence, changes, missing information and possible alternatives should be presented so an independent decision is possible.
- Clear domain accountability and decision authority
- Access to original data and sources, not only the AI response
- Visible uncertainty, conflicts and system limitations
- Sufficient time and training for genuine assessment
- The ability to amend, reject, escalate or stop
How is approval built into a process?
The application does not decide for itself whether oversight is needed. Approval rules are defined outside the model using action type, value, data class and risk. Where roles differ, preparation and approval are separated.
- Step 1
Define triggers
Specify actions, thresholds and risk cases that require review.
- Step 2
Show context
Present the proposal, evidence, changes and consequences clearly.
- Step 3
Verify authority
Accept approval only from an authenticated and responsible role.
- Step 4
Record the decision
Keep version, person, time, correction and rationale traceable.
How do you recognise rubber-stamping?
If almost every proposal is confirmed without reading, the control may be poorly designed. The team observes correction rates, review time, escalation and errors after approval and asks reviewers which context they lack.
- Avoid automatic consent or preselected approval
- Have specialists sample both accepted and rejected cases
- Match review workload and case volume to available capacity
- Feed recurring errors back into the system, data and evals
- Reduce automation when review demand cannot be managed
Example: changing supplier bank details
An agent reads an email and prepares a change to bank details. The application shows old and new values, the original message, the identified supplier account and a warning for a mismatched domain. Only an authorised second person can approve after an independent callback. The model cannot skip the control or mark it as completed.
What to remember
Use human control where impact and uncertainty justify it. Design and measure review as a safety function in its own right, not the final button in a process.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed