Human review needs a defined action, evidence the reviewer can inspect and authority to change what happens next. Naming a reviewer is only the beginning. Give that person the time, relevant skills and practical means to reject, pause or escalate a proposed action.
In a controlled experiment, Buçinca and colleagues (2021) found that designs encouraging deliberate thought reduced overreliance on incorrect AI advice, with a usability trade-off. That is a reason to test how reviewers actually work, including with the three review levels proposed here, which the study did not test.
Start with the action and its consequences
Map the path from input to final use. Ask who may be affected, what can go wrong and whether a harmful action can be reversed. Choose review depth and timing around that context. A fluent answer alone does not establish factual accuracy or permission to act.
Illustrative customer-support example
An AI agent may read approved guidance and draft a reply in an authorised workspace. Sending replies or modifying customer records requires separate authority and technical permissions. The support lead authorises the scope; the reviewer compares the draft with the guidance. This is a fictional example, not a client result.
Three review levels: Ada’s advisory pattern
These levels are Ada’s practical design pattern, not legal categories. Combine them to fit the task: a routine draft may need only the first, a consequential action all three.
Level 1: Review the output
Check wording, factual claims, missing context and suitability before using the draft. The reviewer can correct, reject or rewrite it. Even a routine drafting task may need deeper review if it uses sensitive data or affects a consequential decision.
Level 2: Review the evidence
Compare material claims with the underlying sources. In the support example, show the relevant approved guidance, its version and any unresolved conflict. A link supplied by the model is a lead to check, not proof. Record discrepancies and escalate missing or contradictory evidence.
Level 3: Review the decision and action
Inspect the intended action, recipient, affected record, applicable rule, supporting evidence and expected consequences. The reviewer must be able to withhold approval and stop the action before execution. For consequential uses, Ada recommends this broader review; applicable legal duties depend on jurisdiction, system, role and context.
Output
Evidence in this pattern: Draft and intended audience
Reviewer’s authority: Correct or reject before use
Evidence
Evidence in this pattern: Approved sources, versions and conflicts
Reviewer’s authority: Challenge claims and escalate missing evidence
Decision and action
Evidence in this pattern: Actual action, target, rule and consequences
Reviewer’s authority: Withhold approval or stop before execution
Make approval enforceable
For the support pilot, keep sending and customer-record changes outside the agent’s permissions. If either action is proposed later, reassess it separately. Define the authorising owner, allowed tools and data, the approval event and when a changed proposal needs fresh approval. A reviewer seeing one draft should not unknowingly authorise a different message or recipient.
Ask the responsible technical team to demonstrate that denied actions stay blocked, approval cannot be bypassed, a pause stops new actions and revoked delegated access no longer works. Preserve action records, including approval, outcome and exceptions, with appropriate access and retention. Check uncertain in-flight actions before retrying; avoid duplicate sends or updates. Agree recovery and reauthorisation before restarting.
NIST’s Generative AI Profile includes source verification and attention to human-AI configuration. It is risk-management guidance, not legislation or this three-level pattern. Guidance: NIST Generative AI Profile, Section 2.7 and MS-2.5-003.
Legal scope in Switzerland and the EU
The three levels are a design pattern. Several legal rules set minimum conditions for human involvement in specific decisions. Check them for the actual decision, your role and where its effects arise.
Legal anchors (CH/EU)
- Switzerland, FADP Article 21: if a decision is based exclusively on automated processing and has a legal consequence for, or a considerable adverse effect on, the person concerned, the controller must inform that person. On request, the person may express their point of view and ask for the decision to be reviewed by a natural person. Article 21(3) sets out exceptions, and Article 21(4) adds rules for federal bodies. FADP, Article 21 (English translation, not legally binding)
- EU, GDPR Article 22: a person has the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them, unless an exception applies. Under the contract and explicit consent exceptions, the controller must at least offer human intervention and the chance to express a view and contest the decision. In SCHUFA (C‑634/21, 7 December 2023), the Court of Justice held that an automatically established credit score is itself such a decision where a third party draws strongly on it to establish, implement or terminate a contract. GDPR, Article 22; Judgment in C‑634/21
- EU AI Act, high-risk systems: Article 14 requires providers to design high-risk systems so that natural persons can oversee them effectively, including, as appropriate and proportionate, by disregarding, overriding or reversing the output and by stopping the system. Article 26(2) requires deployers to assign human oversight to natural persons with the necessary competence, training, authority and support. Under Article 113, as amended by Regulation (EU) 2026/1744, these duties apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Article 6(1) systems related to products under Annex I, Section A. Under Article 2(2), neither article applies to systems related to products under Annex I, Section B, for which only Articles 6(1), 60a and 102 to 112 apply; delegated acts under Article 2(13) may limit Article 14 for Section A systems. Systems placed on the market or put into service before those dates are covered only as set out in Article 111(2); Article 111(1) sets separate rules for components of the large-scale IT systems established by the acts listed in Annex X. Consolidated AI Act
In practice, record what the reviewer examined besides the AI output and what they changed. That record helps show whether a person actually weighed the decision.
Where the EU AI Act applies, Article 4, as replaced by Regulation (EU) 2026/1744 with effect from 27 July 2026, requires providers and deployers to take measures supporting the AI literacy of their staff and others dealing with the operation and use of AI systems on their behalf, taking into account their knowledge, experience, training, the use context and affected people. It does not require providers or deployers to guarantee a specific level of AI literacy for any individual, and it does not mandate these review levels. Legislation: consolidated AI Act, Articles 2 and 4.
The NIST NCCoE paper on agent identity and authorisation explores delegation and action records. The cited February 2026 document is a draft concept paper for a proposed project, not a final standard or compliance requirement. Draft research: agent identity and authorisation.
Put the pattern to work
Record the action boundary in the use-case register, rehearse it with the pilot worksheet, and review corrections and control tests in the monthly worksheet. Use the vendor worksheet to check whether the tool actually supports the intended review.
Ada’s workflow and pilot service helps design and evaluate those steps. Bring one workflow for discussion.