Human oversight — PACT Standard assessment axis

What this axis protects.

Human oversight protects agency, safety and access to remedy when an AI system informs or makes a decision. Its purpose is not to preserve the appearance of human control. It is to prevent or reduce harm that remains after technical controls, and to keep responsibility attached to people and institutions that can act.

The EU AI Act treats oversight as proportionate to risk, autonomy and context. For high-risk systems, a designated person must be able to understand capabilities and limitations, remain alert to automation bias, interpret outputs correctly and disregard, override, reverse or stop the system where appropriate. Those obligations are a useful floor even where a system is not legally classified as high-risk.

The test is simple: can the responsible person detect a problem, decide independently and change what happens before the harm becomes irreversible?

Where oversight commonly fails.

Rubber-stamping. Reviewers approve outputs under volume or time targets that make independent judgement unrealistic.
Authority without access. A person is nominally accountable but cannot inspect relevant inputs, limitations, confidence, logs or previous similar cases.
Access without authority. A reviewer can see the output but cannot pause the workflow, provide an alternative, escalate the case or require a system change.
Intervention too late. Review takes place after a benefit, opportunity, service or right has already been denied.
Untrained responsibility. Staff are expected to supervise a system without role-specific instruction, domain competence or knowledge of failure modes.
Invisible disagreement. Overrides and appeals are not recorded, so repeated failure patterns never reach the team that can correct them.
No safe fallback. When the system is unavailable or unreliable, staff cannot continue the service through a tested manual route.

Assessment questions.

Which outputs can affect a person’s rights, safety, access, employment, education, health, finances or essential services?
Who owns the final decision, and is that person’s authority written into policy, workflow permissions and performance expectations?
At what exact point can a person pause, disregard, override or reverse the output? Is intervention early enough to prevent harm?
What does the reviewer see: relevant inputs, provenance, uncertainty, system limitations, comparable cases and the reasons a case was flagged?
Can the reviewer reach an independent conclusion, or does the interface, workload or organisational culture anchor them to the system’s recommendation?
What competence and AI literacy does the role require? How is it assessed and refreshed when the system changes?
How can an affected person obtain human reconsideration, provide missing context and receive a reasoned response?
Which override, reversal, complaint and escalation patterns trigger investigation, retraining, suspension or withdrawal?

Evidence to collect.

Authority map: Named owners for review, escalation, suspension and final acceptance of residual risk, including delegated limits and an accountable executive.
Intervention design: A process map showing the last reversible point, available actions, fallback route and the time allocated for meaningful review.
Operator information: Instructions, known limitations, uncertainty guidance, foreseeable misuse, data-quality warnings and the evidence visible at decision time.
Competence record: Role-specific training, practical scenario testing, refresher schedule and evidence that staff understand when not to rely on the system.
Operational record: Override and reversal rates, reasons, review time, escalations, appeals, missed interventions and differences across teams or affected groups.
Fallback test: Results from exercises showing that the service can continue safely when the system is stopped, degraded or unavailable.

Decision thresholds.

Proceed: Oversight roles have sufficient authority, competence, information and time; intervention and appeal routes have been tested; monitoring can reveal whether oversight works in practice.
Proceed with conditions: Remaining weaknesses are bounded and reversible. Conditions name an owner, deadline, interim control and a measurable trigger for reassessment or suspension.
Stop or redesign: No person can meaningfully understand or change a consequential outcome; review is structurally reduced to approval; a safe fallback or remedy is absent; or the institution cannot monitor whether intervention prevents harm.

Do not score this axis from policy alone. Observe the real workflow. Give reviewers difficult and ambiguous cases, measure the time they need, test whether they can disagree without penalty and confirm that an affected person can reach someone empowered to reconsider the outcome.

Lifecycle checks.

Before first use

Define the decision boundary, oversight role, prohibited reliance, escalation path and fallback. Test representative, edge and adversarial cases with the people who will actually supervise the system.

During operation

Monitor overrides, appeals, response time, automation bias indicators, missed harms and workload. Review samples where the human agreed with the system as well as cases where they disagreed.

When conditions change

Repeat the assessment after changes to models, data, thresholds, suppliers, integrations, user groups, law or operational context. An incident, unexplained disparity or repeated complaint is a reassessment trigger, not merely a support issue.

Sources and further reading.

Primary and institutional sources reviewed for this working document. Legal applicability must be assessed for the specific system and context.