AI Human Review Operations：人工审核容量架构
Human review 不是页面上多一个“人工确认”按钮，而是一套生产运营能力。它需要定义 review unit、队列、技能、SLA/OLA、容量、校准、质量抽样、升级、疲劳控制、override governance 和证据。没有这些能力，human-in-the-loop 会变成控制剧场：形式上有人，实际上无法发现、理解或阻断风险。
AI Human Review Operations / Capacity Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_HUMAN_REVIEW_OPERATIONS_CAPACITY_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织治理、度量、处置和改进 |
| NIST Human-Centered AI | https://www.nist.gov/programs-projects/human-centered-ai | 参考 human-centered AI、AI user trust 和人机工作系统设计 |
| NIST AI Use Taxonomy PDF | https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.200-1.pdf | 用 AI contribution to human task 的 taxonomy 拆解 review unit |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 语言连接责任、运行控制、能力和绩效评价 |
| FFIEC Business Continuity Management booklet | https://ithandbook.ffiec.gov/it-booklets/business-continuity-management.aspx | 用 critical operations、dependencies、training 和 exercise 设计 surge review |
核心导读
Human review 不是页面上多一个“人工确认”按钮，而是一套生产运营能力。它需要定义 review unit、队列、技能、SLA/OLA、容量、校准、质量抽样、升级、疲劳控制、override governance 和证据。没有这些能力，human-in-the-loop 会变成控制剧场：形式上有人，实际上无法发现、理解或阻断风险。
金融零售 AI 中，人工复核常被用作补偿控制，但它本身也会失效。队列过载、复核员训练不足、reason code 粗糙、独立性不足、低 override rate 被误解为高质量，都会让人审从控制变成瓶颈。
问题定义
AI human review 失败通常出现在运营层，而不是模型层：
- 高风险输出全部进入人审，但队列积压导致监管处理时限被突破。
- reviewer 只能看到 AI 摘要，看不到原始证据、RAG source、tool trace 和政策版本。
- 复核指南不清，两个 reviewer 对同一 case 做出相反判断。
- 低 override rate 被报告为“模型很好”，实际是 reviewer rubber stamp。
- incident 时临时调人支援，但支援人员没有技能、权限或系统访问。
- override 原因记录为“other”，无法用于模型修复、QA 或审计。
因此，人审架构要解决的问题是：哪些事件需要复核，谁有资格复核，复核员看到什么证据，如何做决定，容量是否足够，质量如何校准，复核行为如何进入证据和改进闭环。
核心原理/方法
核心概念是 review unit。不要抽象地说“这个输出需要人审”，而要定义被复核对象：
| Review unit | 示例 | 风险 |
|---|---|---|
| Output review | 客户可见回答、销售话术、投诉回复 | 错误承诺、误导、缺失 disclosure |
| Action review | 退款、拒绝争议、冻结账户、提交 SAR narrative | 资金、合规、客户损害 |
| Evidence review | RAG source、交易证据、客户文件、模型解释 | 证据不足或引用错误 |
| Override review | 员工覆盖 AI 建议、AI 覆盖规则结果 | 控制绕过、责任不清 |
| Exception review | waiver 范围内的生产事件 | 残余风险失控 |
| Calibration review | gold case、blind review、二次裁决 | reviewer 一致性和质量 |
队列经济也要显式建模：
| 变量 | 说明 |
|---|---|
| Arrival rate | 每小时/每日进入队列的 review unit 数量 |
| Handling time | 不同类型 case 的平均处理时间和尾部分布 |
| Skill mix | 产品、合规、语言、区域、牌照、欺诈、投诉等技能 |
| SLA / OLA | 对客户、监管、内部控制的处理时限 |
| Escalation | 超时、高风险、不确定、冲突判断的升级规则 |
| Surge capacity | incident、活动、模型退化、供应商故障时的临时容量 |
| Quality sampling | 按风险、reviewer、队列、输出类型进行抽样复核 |
系统/架构模型
AI Workflow Event
-> Review Policy Engine
-> Risk & Skill Router
-> Queue Orchestrator
-> Reviewer Workspace
-> Structured Decision Capture
-> QA / Calibration Layer
-> Workforce Capacity Planner
-> Evidence Ledger
-> Feedback / Corrective Action Loop
关键组件：
| 组件 | 职责 |
|---|---|
| Review policy engine | 根据 use case、risk tier、客户影响、工具动作和 exception 状态决定是否复核 |
| Risk & skill router | 将 case 分配给具备产品、法规、语言、区域或牌照技能的 reviewer |
| Queue orchestrator | 管理优先级、SLA、积压、暂停、重派、升级和 surge mode |
| Reviewer workspace | 展示 AI 输出、原始输入、证据、source、policy、tool trace、历史决策和禁止项 |
| Decision capture | 强制结构化 reason code、decision、confidence、evidence viewed、override rationale |
| QA / calibration | 通过 gold cases、blind review、adjudication 和抽样二审监控一致性 |
| Capacity planner | 预测到达量、处理时间、技能缺口、峰值和 incident 容量 |
| Evidence ledger | 保存复核动作、证据版本、审批链、时间戳和后续纠正行动 |
Review policy engine 必须在 workflow 层，而不是只靠页面提示。Queue orchestrator 必须理解技能、SLA、容量和冲突规则。Evidence bundle 必须版本化，包含 AI/model/prompt/source/policy/tool trace。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 全量人审 vs 风险分层 | 全量人审看似稳妥，但会导致积压和橡皮图章；风险分层更可持续，但需要强监控和抽样 |
| 速度 vs 审慎 | 客户等待和监管时限需要速度；高影响动作需要足够证据和独立判断 |
| AI-assisted review vs independent review | AI 可帮 reviewer 摘要证据，但不能遮蔽原始证据或替代独立判断 |
| 低 override rate vs 高质量 | 低 override 可能表示模型好，也可能表示 reviewer 不挑战；必须结合 QA、gold cases 和 case complexity |
| 中央复核团队 vs 业务嵌入 | 中央团队一致性强；业务团队上下文强。高风险场景通常需要双层结构 |
| 自动升级 vs 人工升级 | 自动升级保障 SLA 和风险阈值；人工升级能处理灰区。两者需要并存 |
人审不能被滥用为所有控制缺口的补偿。若 reviewer 没有足够证据、权限、时间或独立性，人审不能降低残余风险。
证据与控制
人审证据要证明三件事：该复核发生过、复核员有能力判断、判断基于充分证据。
| 证据对象 | 关键字段 |
|---|---|
| Review assignment | queue、risk tier、skill requirement、assigned reviewer、SLA、priority |
| Evidence bundle | 原始输入、AI 输出、retrieved source、tool trace、policy version、customer context |
| Reviewer decision | approve/reject/escalate/modify、reason code、confidence、notes、time spent |
| Override record | 覆盖对象、覆盖方向、理由、授权、二次复核、客户影响 |
| QA result | 抽样规则、gold case score、blind review 差异、adjudication 结果 |
| Capacity record | 到达量、处理量、积压、超时、技能缺口、surge trigger |
| Calibration record | 培训版本、校准样本、通过率、一致性指标、复训动作 |
关键控制指标包括：queue aging、SLA breach、reviewer workload concentration、override concentration、reason-code entropy、gold-case pass rate、inter-rater agreement、evidence-view completeness、post-review incident rate。
金融零售/AI产品场景
支付争议复核：AI 建议 accept / deny dispute。高金额、弱势客户、证据冲突、监管 deadline 接近或 merchant category 异常的 case 应进入 skilled review；reviewer 必须看到交易证据、客户叙述、适用规则、AI rationale 和历史 case。
贷款解释复核：AI 生成拒绝解释。抽样应按产品、segment、reason code 和投诉风险分层，确认输出与 adverse action reason 一致，并保留 reviewer 修改原因。
财富销售内容审批：AI 生成会谈提纲或邮件草稿。复核不只是文字润色，而是检查 approved claim、suitability context、disclosure、冲突和禁止承诺。
AML case narrative：AI 辅助可疑交易叙述。复核员需要原始交易、typology、规则命中、客户资料和 AI 摘要差异；rubber stamp 会直接影响监管报送质量。
反模式
- 用“有人工复核”作为风险接受理由，但没有容量、技能、SLA 和 QA 数据。
- reviewer 只能看 AI 摘要，不能访问原始证据和政策来源。
- 所有 case 进入同一队列，不区分风险、产品、语言、区域和监管时限。
- override reason 大量为 other，无法分析质量和根因。
- 低 override rate 被当作成功指标，未做 blind review 或 gold case 校准。
- incident 时临时增加人力，但没有训练、权限和决策标准。
- 人审记录不能关联到模型版本、prompt、source、tool 和客户结果。
最终心智模型
Human review 是一种运营控制容量，不是一个抽象治理承诺。它必须像核心业务流程一样设计：入口规则、队列、技能、SLA、证据、决策、质量、容量和持续改进。
成熟的人审架构能回答：这个 case 为什么需要复核，谁复核，基于什么证据，如何判断，是否及时，判断质量如何，是否影响后续模型和流程修复。回答不了这些问题，human-in-the-loop 只是把 AI 风险转移给没有工具和时间的人。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。