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.