awesomechecklists
llms.txtGitHub ↗
/

20 — AI Human Review and Escalation Checklist#

Ensure human involvement in AI-assisted decisions is meaningful, authorized, timely, and auditable. A review button, nominal human sign-off, or the ability to view model output does not establish independent oversight or prevent unauthorized downstream execution.

Scope: Backend / API-specific. This file is one part of the 20_AI_Human_Review_and_Escalation.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Scope and applicable jurisdictions / markets:
  • Human review use cases, affected persons, and consequential actions:
  • Reviewer roles, delegation, approval policy, and escalation owners:
  • Queue targets, safety thresholds, and review system versions:
  • Reviewer / owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Copy this checklist into project-specific review records and leave all repository template boxes unchecked.
  2. Assess whether a human can genuinely understand, challenge, reject, correct, override, and where necessary halt the AI-assisted result. Determine oversight requirements based on use case, harm, autonomy, actual applicable rules, and the authority of the decision maker.
  3. Mark [x] only after verifying reviewer training and permissions, representative review cases, queue behavior, safe approval/rejection/resume tests, appeal flows, incident records, or qualified policy decisions. Keep evidence, defects, accepted exceptions, and justified N/A outside this shared template, keyed by HUMAN ID.
  4. Separate ## API Checks and ## Frontend Checks; document why either may be inapplicable to headless, advisory-only, or offline deployments.
  5. Human approval is not an authorization boundary by itself: independently validate the initiating user's permissions, reviewer's role, exact action, and execution constraints. Do not treat approval as proof an external side effect completed exactly once.
  6. Reassess oversight after changes to AI tools, policies, reviewer staffing, prompt/model versions, automated thresholds, user populations, or supported markets. Coordinate the general governance, agent, safety, and evaluation requirements in those dedicated checklist files.

API Checks#

  • HUMAN-093 Require authenticated and purpose-authorized API access to create, view, claim, approve, reject, and escalate review cases.
  • HUMAN-094 Enforce tenant, user, object, action, and reviewer-role authorization for every case and decision mutation.
  • HUMAN-095 Validate server-owned pending action identifiers and stored tool arguments rather than trusting replacements supplied by clients.
  • HUMAN-096 Bind decision records to immutable or version-checked proposed actions and reject stale approvals after material changes.
  • HUMAN-097 Use atomic transitions, concurrency controls, and replay protection for approvals consumed by resumed agent runs.
  • HUMAN-098 Require reauthorization and independent server-side policy checks before executing a reviewed tool call.
  • HUMAN-099 Ensure denied, timed-out, and expired review cases cannot be executed by a retry or alternate endpoint.
  • HUMAN-100 Test handoff and nested-agent approval paths for the same authority and policy checks as top-level actions.
  • HUMAN-101 Define explicit review states such as queued, assigned, waiting, escalated, approved, rejected, expired, and executed.
  • HUMAN-102 Keep API representations of approval, execution, partial completion, and actual external outcome distinct.
  • HUMAN-103 Validate role and policy changes invalidate relevant outstanding approvals and reviewer access.
  • HUMAN-104 Use scoped credentials, rate limits, idempotency controls, and resource budgets on review-related APIs.
  • HUMAN-105 Test server behavior for malformed decisions, duplicate submissions, stale browser sessions, and missing evidence.
  • HUMAN-106 Record safe audit identifiers for pending calls, decisions, reviewer authority, state transitions, and execution outcomes.
  • HUMAN-107 Prevent unauthorized exposure of private case content in logs, traces, response caches, webhooks, or exported review reports.
  • HUMAN-108 Protect review and appeal event delivery against spoofing, duplication, tampering, and out-of-order processing.
  • HUMAN-109 Ensure policy violations and serious incidents trigger trusted escalation or containment independently of the model.
  • HUMAN-110 Exercise graceful failure when reviewer identity, approval storage, or audit infrastructure is unavailable.
  • HUMAN-111 Validate integration contracts for external human-review vendors, including data-handling and permitted reviewer access.
  • HUMAN-112 Test production-equivalent end-to-end review, approval, rejection, timeout, cancellation, and recovery paths before release.

Release gate#

  • Documented decision categories identify which AI outcomes require human intervention, specialist review, dual control, or immediate suspension according to impact and applicable law.
  • Qualified reviewers have real access to the necessary evidence, time, training, authority, and accessible controls to approve, reject, change, escalate, or stop a decision.
  • Review queues, prioritization, assignment, decision thresholds, staffing, expirations, and safe backlog/outage behavior have been tested under representative workload.
  • Approval, denial, and override controls are bound to authenticated, authorized reviewers and the exact action parameters; stale, replayed, forged, and changed requests cannot execute.
  • Significant decisions, reviewer disagreements, appeals, overrides, completed actions, and incident escalation are traceable with appropriate privacy, integrity, and retention safeguards.
  • Human-review effectiveness and potential automation bias have been evaluated with representative benign, ambiguous, and high-impact cases, including false approvals and unjustified rejections.
  • API and frontend pathways accurately distinguish proposals from confirmed effects and handle waiting, denial, timeout, failed resume, cancellation, and correction accessibly.
  • A named risk owner has reviewed residual limitations, complaint/redress obligations where applicable, response runbooks, emergency halt mechanisms, and the exact release configuration.

Domain-specific approval rule: Block release if human review is legally or risk-required but the reviewer cannot independently challenge or stop outcomes; if unapproved, altered, or replayed actions can execute; if high-impact cases can be silently auto-approved during overload; or if mandatory records and escalation routes are unavailable. Human oversight must be proportionate and effective, not merely ceremonial.

Trusted references and scope#

The primary standards, laws, risk-management guidance, and implementation references below inform the checklist. Apply vendor features and legal requirements only where relevant to the particular application and deployment.

Applicability: The NIST AI RMF is voluntary. The EU AI Act imposes Article 14 oversight design requirements and Article 26 deployer obligations for applicable high-risk AI systems; its implementation and application dates require current, qualified legal review and are not identical for all AI products. GDPR Article 22 applies in specific circumstances involving solely automated decisions with legal or similarly significant effects, including exceptions and safeguards; not every AI suggestion triggers that article. OpenAI Agents SDK and Microsoft Agent Framework approval facilities have different behavior for reused/standing approvals, nested agents, saved state, and resumed tool calls. Their native controls must be supplemented with trusted application authorization, concurrency controls, replay prevention, and recovery of external side effects. WCAG 2.2 requirements depend on the applicable conformance target and governing accessibility law.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: review queues, approval boundaries, appeals, escalations, and audit trails; include API and service behavior where applicable.
  • Cross-stack: Playwright.
  • Python: pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: Playwright + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

  • agent-governance — Review human oversight and escalation rules (github/awesome-copilot, 41,073 repo stars).
  • signed-audit-trails-recipe — Check review-event and override auditability (wshobson/agents, 42,437 repo stars).
  • audit-integrity — Assess approval and audit-history integrity (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.