AI may prepare – humans must decide

Agentic systems can collect data, compare alternatives, prepare text and code, test policies and propose an action. That productivity creates a dangerous confusion: because preparation looks polished, approval seems to be only the final click. A person then decides formally while the system decides in practice.

Meaningful control therefore starts by separating preparation, decision and execution. AI may structure evidence and justify a proposal. An authorised person decides in defined consequential cases. Only approval bound to the exact proposal may unlock execution.

A risk-based principle, not a universal legal claim

Not every AI use needs an individual human decision. A spelling correction, reversible test or low-risk classification may be automated. Impact and protection needs rise for employment, credit, healthcare, access to services, publication, payment, deletion and far-reaching system changes.

The EU AI Act requires high-risk AI systems to support effective human oversight. GDPR Article 22 addresses certain decisions based solely on automated processing that produce legal or similarly significant effects. Both provisions have narrower scopes than „a human must always decide". Sound governance applies their control logic through a context-specific risk model without overstating the law.

The decision threshold should consider impact on people or assets, reversibility, scale, data sensitivity and uncertainty. Regulatory duties, external visibility and cumulative harm add further reasons for review.

Preparation and decision require a hard boundary

AI can complete a case file, flag missing evidence, calculate alternatives and draft a recommendation. It must not silently change criteria, fabricate approval or grant itself execution rights. Preparation creates a decision proposal, not authorisation.

The boundary is technical. Every proposal has an ID, version, expiry and hash over its action scope. A change to recipient, amount, record, target system, content or condition invalidates prior approval. Execution checks not merely whether someone once agreed but whether that person was entitled to approve this unchanged action.

Six conditions for meaningful oversight

A person in the workflow is not automatically a human-in-the-loop. Effective oversight requires:

1 · Competence: domain knowledge and understanding of system limits and failure modes.

2 · Information: access to sources, deviations, uncertainty, alternatives and expected impact.

3 · Time: an operationally realistic review window.

4 · Authority: permission to reject, restrict, return or escalate.

5 · Independence: incentives that do not reward approval volume alone.

6 · Timeliness: a decision before external effect, with power to prevent it.

Without these conditions, oversight becomes decoration. A non-specialist reviewing one hundred cases per hour without rejection authority is not an effective decision maker even if a name appears in the log.

Evidence must be decision-ready

The reviewer needs a compact, verifiable decision packet rather than an uncontrolled raw-data dump. It describes the proposed step, affected objects or people, purpose, input versions, relevant sources, deviations, uncertainties, alternatives, policy result, expected side effects, rollback and expiry.

A diff shows what changes from the last approved state. For large sets, representative cases, outliers and threshold cases are visible. The proposal states what the system does not know. A confidence number without calibration, reference population and decision context is not an explanation.

The interface must not present the recommendation as neutral truth. Reject, edit and escalate must be as usable as approve. Sources appear before or alongside the recommendation. Otherwise the design amplifies automation bias.

Traffic-light logic makes thresholds explicit

A traffic light does not replace judgement, but prevents improvised ownership:

Green: low impact, reversible, familiar data, policy-compliant and within tight limits. Automatic execution or sampled review may be suitable.

Amber: novel source, threshold proximity, conflicting evidence, unusual scale or elevated uncertainty. The process pauses for qualified review.

Red: prohibited action, missing mandatory evidence, sensitive or irreversible effect, conflict of interest or exceeded limit. Deny or escalate; red is not a larger approval button.

Rules live in versioned policy and are testable. If a model freely chooses its own colour, it indirectly controls oversight. Classification and permission checks therefore need deterministic logic or an independent control component.

Approval must bind to effect

„Looks good" in chat is not durable authorisation. Approval records decision maker, role, time, proposal ID, hash, scope, conditions and expiry. Irreversible, financial or highly sensitive actions may require dual authorisation.

Confirmation applies once or to an explicitly defined batch. It cannot become a reusable general mandate. Before execution, a gate verifies identity, permission, immutability, expiry and policy. The action then receives its own execution ID and outcome evidence.

This chain also addresses race conditions. If material inputs change after review, a new decision is required. Idempotency keys prevent duplicate payments, messages or deletions in external systems.

Separation of duties reduces blind spots

For critical workflows, proposal, domain review and technical execution should not share one identity. AI prepares, a qualified person decides, and a narrowly privileged executor performs only the approved action. Very high impact can require two independent approvals.

Separation should remain proportionate. Small teams can introduce a second role by sampling, threshold or escalation. The essential rule is that no actor may silently create the proposal, policy exception and audit evidence together.

Escalation is a process of its own

Amber and red cases must not disappear in a queue. The system defines domain and technical routes, delegates, response targets and safe waiting states. Effect stays blocked while the decision is open. Timeout never means approval by default.

An escalation packet includes the review path and precise unresolved question. The next authority understands why first-level review was insufficient. Conditional decisions return machine-readable constraints such as reduced scope, additional validation or a shorter time window.

Automation bias must be measured

People accept fluent recommendations too quickly, especially under pressure. Countermeasures include independent checking of selected facts, hidden quality cases, varied presentation, written rationale for high-impact approval and reviewer calibration.

Metrics must cover more than throughput: override rate, reviewer agreement, returned cases, duration by risk, later-discovered misapprovals, false escalations and outcomes for affected groups. A near-zero rejection rate may indicate excellent quality or rubber stamping. Test cases and outcome data distinguish them.

Affected people need a challenge route

Where decisions significantly affect people, human oversight does not end with internal approval. Depending on context, people need understandable information, an accessible contact, correction of inaccurate data and a genuine reconsideration. A second look must not merely repeat the same model response.

The decision log connects proposal, sources, accountable person, conditions, execution and later correction. Provenance shows which data and policy versions supported the outcome. Access is protected because such logs often contain sensitive data.

Test the oversight mechanism itself

Before rollout, scenarios cover missing evidence, contradictory data, manipulated recommendations, expired approvals, altered scope, unavailable reviewers and duplicate execution. The gate must stop safely, escalate correctly and resume from confirmed state.

Exercises verify that reviewers understand limits and actually challenge proposals. Incident analysis examines not only the model but interface, workload, incentives, policy and permission architecture.

A protocol for accountable decisions

1 · CLASSIFY: determine impact, reversibility and protection need.

2 · PREPARE: create proposal and evidence without execution rights.

3 · EXPLAIN: show diff, sources, uncertainty, alternatives and limits.

4 · CHALLENGE: support contradiction, counter-checking and policy tests.

5 · DECIDE: an authorised person approves, restricts, rejects or escalates.

6 · BIND: attach identity, version, scope, conditions and expiry.

7 · EXECUTE: perform only the bound action with minimum privilege.

8 · TRACE: reference outcome, side effects and provenance durably.

9 · REVIEW: evaluate quality, overrides and real outcomes.

This design avoids both bottleneck and theatre. AI performs demanding preparation. People retain decision power where consequences, rights and accountability require it.

Worksheet: Design a Human Decision Gate

1. Select one agentic workflow and name its possible effects.

2. Separate preparation, decision and execution roles.

3. Define measurable green, amber and red thresholds.

4. Design the evidence packet with diff, sources, uncertainty and rollback.

5. Specify bound approval with ID, hash, scope and expiry.

6. Map escalation, delegate, response target and safe waiting state.

7. Define tests for rubber stamping, stale approval and duplicate execution.

Reflection: Where does a person currently confirm without sufficient information or rejection power? Which effect must be stoppable before execution in the future?

All materials to download — the topic overview and the worksheet:

Scope: Human approval is neither legally required for every AI use nor sufficient by itself. Oversight depends on context, impact, applicable law and risk class. Editorial and technical review: 17 July 2026.