AI 扩展计划 / Playbooks

AI Human Oversight / HITL Playbook

Human oversight 不是在 AI 流程末端增加审批按钮, 而是把人类判断、授权、证据、升级、覆盖、撤销、停机和复盘设计成一套可运行的控制系统。

832 行AI_HUMAN_OVERSIGHT_HITL_PLAYBOOK.md

AI Human Oversight / HITL / Handoff Playbook

核心导读: Human oversight 不是在 AI 流程末端增加审批按钮, 而是把人类判断、授权、证据、升级、覆盖、撤销、停机和复盘设计成一套可运行的控制系统。

系统边界: 本文覆盖 AML Copilot、KYC Review Assistant、Credit Underwriting Copilot、Payment Dispute Assistant、Customer Service Copilot、Branch / Contact Center Agent Assist 和金融零售内部知识助手。重点是监督原理、风险分层、架构控制、评估证据和治理边界。

重要说明: 本文是系统学习和内部治理训练材料, 不是法律意见、合规结论、审计意见或模型验证报告。正式项目必须由 Legal、Compliance、Risk、Model Risk、Internal Audit、Security、Privacy、Data Owner、Business Owner 和管理层结合机构类型、司法辖区、业务用途、客户影响和内部政策确认。

Source Anchors

以下官方来源作为学习锚点。本文把它们转成产品、流程、架构和证据设计语言, 不把任何条款简化成单一检查项。正式项目应记录访问日期、适用性判断和 legal / compliance sign-off。

Anchor	Official link	本文使用方式
EU AI Act Article 14 Human Oversight	https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14 和 https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng	用于定义高风险 AI 的人类监督目标、能力要求、解释输出、忽略/覆盖/撤销输出、干预和停止机制。
EU AI Act Article 4 AI Literacy	https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-4 和 https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng	用于把监督者培训、AI literacy、角色能力和上下文意识纳入上线条件。
NIST AI Risk Management Framework	https://www.nist.gov/itl/ai-risk-management-framework	用 Govern / Map / Measure / Manage 组织人类监督的治理、场景、度量和处置闭环。
NIST AI RMF Generative AI Profile	https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence	用于 GenAI 特有风险: hallucination、data leakage、misuse、prompt injection、tool misuse、information integrity、third-party dependency。
ISO/IEC 42001	https://www.iso.org/standard/42001	用 AI management system 思路设计责任、能力、运营控制、绩效评估、持续改进和管理层承诺。

1. 核心导读与学习主线

Human oversight 不是“在页面上放一个批准按钮”。它是一个覆盖业务流程、AI 系统边界、角色授权、UI 证据、升级路径、停机机制、培训、监控和审计的控制体系。

更准确的定义:

AI human oversight =
在明确风险边界内, 让具备能力、授权和时间的人,
基于可理解的证据和可操作的界面,
对 AI 输出、建议或动作进行判断、质疑、升级、覆盖、撤销或停止,
并留下足以复盘、审计和持续改进的证据。

这份手册围绕三组系统能力展开:

能力域	需要回答的系统问题	典型证据
流程与例外建模	人在 AS-IS / TO-BE 流程中监督什么、何时监督、凭什么监督、如何升级	BPMN、HITL requirement、handoff rule、audit field matrix、training requirement
风险分层与监督策略	哪些地方必须人工复核、哪些可以抽样监控、哪些必须停机, 监督成本如何进入系统价值判断	Oversight strategy、risk-tiered intervention matrix、reviewer capacity model、adoption metric
架构控制与运行证据	人工监督如何落实到系统边界、权限、工具调用、日志、追踪、回滚、kill switch 和可观测性	C4 / sequence diagram、control architecture、trace schema、stop switch design、monitoring dashboard

2. 为什么人类监督不只是 Approval Button

很多 AI 项目会在高风险流程中加一个“Approve”按钮, 然后宣称已经有人类监督。真实风险在于: 按钮存在不等于人能有效监督。

2.1 弱监督模式

弱模式	表面上看起来合规	实际问题
Rubber stamp approval	每个 AI 建议都要人工点批准	审核人没有足够证据、时间或能力, 最终只是批量确认。
Hidden automation	文案写着“AI 仅供参考”	工作流、指标和管理压力让员工实际上默认采纳 AI。
Empty escalation	页面有“Escalate”按钮	不知道升级给谁、多久响应、升级后谁负责、原案件是否暂停。
No reversal path	人可以拒绝 AI 建议	但 AI 已经写入下游系统、触发客户通知或改变 case 状态。
Overloaded reviewer	建立了人工复核队列	复核量超出人力, 导致延迟、跳读、抽样失真。
No evidence view	人能看到 AI 输出	看不到检索证据、模型版本、置信边界、政策来源和工具动作。
No AI literacy	员工被要求监督 AI	但不知道 hallucination、automation bias、prompt injection、RAG 过期、tool misuse 的表现。

2.2 有效监督链路

有效的人类监督至少包括十个环节:

Use case scope
-> risk tier
-> decision boundary
-> human role and authority
-> evidence presented to the human
-> UI action set
-> escalation and override path
-> stop / rollback / recovery path
-> audit trail
-> training, metrics and continuous improvement

如果其中任何一环缺失, “人在回路中”就可能只是流程装饰。

2.3 三个核心判断

判断问题	好答案应包含
人监督什么	AI 输出、证据、建议理由、工具动作、异常状态、客户影响、合规边界。
人如何监督	查看来源、比较政策、质疑结论、编辑输出、拒绝建议、升级、要求补证据、停止动作。
人监督是否有效	覆盖率、覆盖质量、override reason、disagreement pattern、抽样复核、事故趋势、培训结果、审计可复现性。

3. EU AI Act Article 14 映射

Article 14 的关键启发是: 对高风险 AI, 人类监督必须通过适当的人机界面和控制措施让自然人能够在使用期间有效监督系统。监督的目的不是形式化审批, 而是防止或最小化对健康、安全和基本权利的风险。

3.1 Article 14 到设计要求

Article 14 监督要点	产品 / 流程设计要求	架构与证据要求
高风险 AI 应设计成可由自然人有效监督	在 use case intake 阶段识别 human role、review point、decision boundary 和不可自动化边界	C4 / BPMN 中标注 AI 与人的交互点、权限边界、review queue、fallback path
监督措施应与风险、自治程度和使用场景相称	按客户影响、自动化程度、可逆性、数据敏感度和监管义务分层设置监督强度	Risk-tiered oversight matrix、release gate sign-off、residual risk record
人应能理解 AI 系统能力和限制	UI 展示能力边界、数据来源、适用范围、known limitations、confidence caveat 和不可用场景	User guide、model card / system card、training completion、limitation acknowledgement
人应能监控 AI 系统运行并发现异常	提供异常提示、质量指标、case flags、retrieval freshness、tool-call warnings、drift signals	Monitoring dashboard、alert log、review sample、incident ticket
人应意识到 automation bias	UI 避免把 AI 建议设计成默认真理, 训练中覆盖过度信任和低信任两类风险	Training record、calibration exercise、override trend analysis
人应能正确解释输出	输出要包含证据、引用、来源时间、推理边界、缺失信息、可疑点和建议下一步	Trace log、retrieval context、citation validator、structured output schema
人应能决定不使用、忽略、覆盖或撤销 AI 输出	每个高影响输出必须有 reject、edit、override、reverse、escalate 的合法路径	Decision log、edit diff、override reason code、reversal workflow
人应能干预或停止系统	设计 route-level、tool-level、case-level、model-level、global kill switch	Stop switch registry、authority matrix、stop event log、restart approval record
特殊高风险场景可要求双人确认	金融零售高影响动作可借鉴 maker-checker、four-eyes principle	Dual approval log、segregation of duties、exception approval

3.2 Article 14 在金融零售中的边界

在金融零售中, 很多 AI 系统未必都直接落入同一法律分类, 但 Article 14 给了一个可复用的设计标准:

如果 AI 影响客户权益、信贷、账户访问、资金流、AML/KYC 结论、投诉处理或监管材料, 人类监督必须强于普通 productivity tool。
如果 AI 只是总结信息, 但总结被员工用于高影响决策, 仍要设计有效监督。
如果 AI 能调用工具改变状态, human oversight 要覆盖动作前、动作中、动作后和异常恢复。
如果 AI 输出进入客户可见沟通, 人类监督要覆盖事实正确性、语气、合规边界和可解释性。

4. Article 4 AI Literacy 映射

Article 4 的启发是: 监督者必须有足够 AI literacy。不能把监督责任交给没有训练的人, 也不能只给一份使用说明。

4.1 AI Literacy 不是泛泛培训

培训层级	监督者必须知道什么	证据
基础概念	AI 输出不是事实本身, RAG 引用可能错, 模型会 hallucinate, prompt 会影响行为	在线课程记录、测验、签收
场景边界	本系统允许做什么, 禁止做什么, 哪些客户或案件不适用	Role-specific playbook、scenario quiz
风险识别	automation bias、wrong citation、missing evidence、policy drift、data leakage、prompt injection、tool misuse	Challenge case drill、red flag checklist
操作能力	如何拒绝、编辑、升级、覆盖、撤销、停止和报告 incident	操作演练记录、case simulation score
责任意识	最终责任人是谁, AI 输出如何进入客户/监管材料, 如何保留证据	Attestation、supervisor review

4.2 角色化 AI Literacy

角色	必修能力	不合格风险
Frontline reviewer	看懂 AI 输出、证据和限制; 能提出异议; 能正确使用 reject / edit / escalate	默认采纳、误拒、漏升级
Senior approver	能处理高风险例外、冲突证据和客户影响判断	把审批变成行政盖章
Operations lead	能管理队列、SLA、抽样复核、人力容量和质量趋势	复核积压、质量下降、指标失真
产品与流程分析职能	能把监督点转成需求、流程、培训和验收标准	只写“需要人工审核”
Architect / Platform owner	能设计权限、日志、stop switch、tool gating 和 traceability	人无法停止、无法复盘、无法撤销
Risk / Compliance / Audit	能检查监督是否真实有效, 不是只看按钮和政策文本	控制存在但不可证明

5. NIST AI RMF 映射

NIST AI RMF 的 Govern / Map / Measure / Manage 可以把人类监督从单点功能变成治理闭环。

RMF Function	对 human oversight 的问题	关键 artifact
Govern	谁对监督机制、监督质量、培训、例外和风险接受负责	AI governance charter、RACI、policy、AI literacy plan、management reporting
Map	这个 use case 的业务场景、受影响人群、自动化边界和伤害路径是什么	Use case canvas、BPMN、harm scenario map、decision boundary map
Measure	如何衡量监督是否有效, 如何测试 reviewer 能否发现 AI 错误	Oversight eval set、reviewer calibration、override analytics、audit sample、incident trend
Manage	当监督发现问题时如何升级、限制、停机、修复、回滚和持续改进	Escalation runbook、kill switch、issue remediation、change gate、quarterly review

5.1 NIST GenAI Profile 到监督控制

GenAI 风险	金融零售表现	Oversight control
Hallucination / confabulation	编造政策条款、交易原因、客户承诺、调查结论	强制 evidence view、citation check、unsupported claim flag、human edit diff
Information integrity	客服回复引用过期费率、KYC 使用旧政策、AML narrative 逻辑断裂	Knowledge freshness indicator、policy effective date、source owner review
Sensitive data disclosure	客服 agent 泄露非本人账户信息、内部助手暴露受限案例	RBAC-filtered retrieval、data masking、least privilege、privacy review
Prompt injection	检索文档或用户输入诱导模型忽略政策、调用工具	Instruction hierarchy、content labeling、tool confirmation、security alert
Excessive agency / tool misuse	AI 自动冻结账户、提交 dispute credit、关闭 AML alert	Tool allowlist、pre-action review、dual approval、transaction limit
Third-party dependency	Vendor 模型升级后输出风格、拒答或准确性变化	Vendor change notice、regression eval、model routing freeze、fallback
Automation bias	员工在高压力队列中默认接受 AI 建议	UI uncertainty, disagreement prompts、reviewer calibration、override metric

5.2 ISO/IEC 42001 到管理系统

ISO/IEC 42001 管理系统视角	HITL 设计转化
组织环境和相关方	识别客户、员工、监管、业务 owner、风险职能和第三方对监督的期望
领导力和责任	明确 human oversight owner、business accountability、risk acceptance authority
规划和风险处置	把监督控制纳入 AI risk treatment plan 和 release gate
支持和能力	建立 AI literacy、岗位培训、知识库和操作手册
运营控制	设计 review queue、handoff、override、stop switch、change control
绩效评估	跟踪监督有效性、事故、抽样质量、用户校准和控制失效
改进	用 incident、audit finding、reviewer feedback 和模型变更持续更新监督机制

6. Oversight Taxonomy

6.1 按人和 AI 的控制关系分类

类型	定义	适合场景	不适合场景
Human-in-the-loop	AI 输出在生效前必须经人复核或批准	信贷 memo、AML SAR draft、支付补偿、KYC 例外	低风险、海量、实时且可逆的辅助提示
Human-on-the-loop	AI 可持续运行, 人通过监控、抽样、阈值和告警监督	客服知识助手、欺诈排队建议、文档分类	高影响不可逆动作、强监管结论
Human-in-command	人拥有策略、目标、边界、停机、回滚和风险接受权, AI 只能在授权范围内运行	企业 AI 平台、agentic workflow、tool-using assistant	没有明确 owner 或缺少停机机制的系统

6.2 按时间点分类

时间点	监督方式	示例
Pre-decision	AI 输出进入决策前人工复核	信贷拒绝理由生成前由 underwriter 确认
Pre-action	AI 调用工具或改变状态前人工确认	支付 dispute 临时入账前审批
In-flight	流程运行中实时告警和人工接管	客服对话触发投诉、法律威胁或高净值客户升级
Post-review	事后抽样、趋势分析、质量复核	客服回复抽样, KYC 文档分类抽检
Fallback	AI 不确定、失败、越权或异常时交给人	RAG 缺少有效政策来源时升级给 policy SME

6.3 按 AI 行为分类

AI 行为	默认监督强度	设计重点
Read / retrieve	低到中	权限过滤、来源有效期、引用准确性
Summarize	中	完整性、证据覆盖、遗漏风险
Classify	中到高	阈值、误分成本、抽样复核、bias
Recommend	高	解释、替代方案、人工最终判断、override
Draft	高	编辑、引用、合规语言、客户可见性
Decide	极高	多数金融零售高影响场景应避免完全自动化
Act	极高	工具权限、动作前审批、限额、撤销、停机

6.4 按复核覆盖分类

覆盖方式	适合条件	风险
100% review	高影响、不可逆、监管敏感、客户权益重大	成本高、队列拥堵、审核疲劳
Risk-based review	有可靠风险信号、案件量大、错误成本分层明显	风险信号漏检会导致低估
Stratified sampling	低中风险、需要持续质量监控	样本设计不当会掩盖少数群体风险
Exception review	只复核异常、低置信、政策冲突、客户投诉	正常样本中的系统性偏差可能被忽视
Shadow review	AI 不影响决策, 人独立处理, 用于比较和校准	不能作为生产控制替代正式监督

7. Risk-Tiered Intervention Matrix

7.1 四级风险与默认监督策略

Tier	定义	默认监督策略	Release gate
Tier 0: Not allowed	违反法律、内部政策或 risk appetite, 或缺少可接受控制	停止、重设边界或改用非 AI 方案	不进入 pilot
Tier 1: High impact	影响客户权益、信贷、资金、账户、AML/KYC 结论、监管材料或重大运营风险	HITL、pre-action approval、dual control、full audit、kill switch	Legal/Risk/Compliance/Business/Architecture sign-off
Tier 2: Controlled business use	影响业务流程, 有人工最终判断, 错误可纠正但有运营或客户影响	Risk-based review、exception escalation、sample QA、clear override	Standard risk review、eval gate、training completion
Tier 3: Low risk productivity	内部效率辅助, 不影响客户权益, 不处理敏感动作	Human-on-the-loop、usage policy、light logging、periodic review	Owner approval、data boundary confirmation

7.2 干预矩阵

触发因素	Tier 1 干预	Tier 2 干预	Tier 3 干预
AI 低置信或证据不足	必须人工复核, 输出不得生效	升级或要求补证据	提示用户谨慎使用
引用与结论不一致	阻断流程, 进入质量事件	标记异常, 抽样扩大	记录反馈
涉及客户资金或账户状态	人工审批和双人确认	预设限额内人工确认	不允许自动动作
涉及信贷拒绝、额度、定价	人工最终决策, 解释证据保留	不建议直接用于客户决定	仅用于内部研究
涉及 AML / KYC 重大结论	L2 reviewer 复核, 合规留痕	分层升级	仅总结公开政策
客户投诉、法律威胁、监管关键词	立即升级, AI 停止自动回复	升级给 supervisor	提示人工处理
Prompt injection 或工具越权	停止相关 route / tool, 启动 incident	暂停能力并调查	安全反馈记录
模型或知识库重大变更	重新 eval 和审批	回归测试后发布	owner review

7.3 Handoff 决策树

AI output generated
-> Is the use case Tier 1?
   -> yes: human review before decision or action
-> Does output affect customer rights, money, account status or regulatory record?
   -> yes: human review and decision log
-> Is evidence missing, stale, contradictory or unauthorized?
   -> yes: fallback to human specialist
-> Is there a tool action or irreversible state change?
   -> yes: pre-action approval and rollback path
-> Is user/customer showing distress, complaint, legal threat or fraud signal?
   -> yes: escalation queue
-> Otherwise:
   -> risk-based monitoring, sampling and feedback loop

8. UI / UX 与工作流要求

8.1 监督界面的最小组件

UI 组件	目的	设计要求
AI output panel	展示建议、摘要、草稿或动作请求	清楚标明 AI 生成, 避免把输出视觉上设计成最终事实
Evidence panel	让人看到支持输出的证据	显示来源、时间、权限、引用片段、有效期和缺失证据
Risk flag panel	告诉审核者为什么需要关注	标出客户影响、政策冲突、低置信、异常交易、投诉信号
Action panel	支持人做真实选择	accept、edit、reject、override、escalate、request evidence、stop route
Reason capture	捕获人工判断理由	高风险动作必须选择原因并允许简短说明
Diff view	比较 AI 原文与人工编辑	保留 edit diff, 用于质量改进和审计
History / trace	复盘上下文	显示 case state、AI version、prompt version、retrieved docs、tool calls
SLA / queue view	管理人工容量	显示优先级、截止时间、积压和升级状态

8.2 防止 Automation Bias 的界面原则

风险	UI 反模式	更好的设计
默认采纳	大按钮是 Approve, 小链接是 Reject	同等清晰地展示 accept / edit / reject / escalate
过度置信	显示单一百分比置信度	展示证据状态、缺失信息、适用边界和冲突信号
证据不可见	只展示总结	默认展开关键证据和来源有效期
责任模糊	页面写“AI 建议仅供参考”	明确当前 human role 是 final decision maker 还是 reviewer
审核疲劳	每条都要求人工点击	按风险分层, 给高风险更多证据和时间
质疑成本高	反对 AI 需要写长说明	提供 reason code、快速标注和一键升级

8.3 Handoff 工作流要求

要求	说明
Context complete	交接给人时必须带上用户输入、AI 输出、证据、日志、风险标记、已执行动作和下一步建议。
No silent drop	任何 fallback 或 escalation 都不能让 case 消失在队列外。
Clear ownership	每个升级队列有 owner、SLA、backup owner 和超时规则。
State freeze	高风险异常时冻结自动动作, 防止 AI 继续改变状态。
Customer protection	客户可见流程应给出准确、克制的等待说明, 不暴露内部模型或调查细节。
Feedback loop	人工结论回流到 eval set、prompt improvement、knowledge quality 和培训材料。

8.4 工具调用 UX

工具动作	默认控制
Read-only query	RBAC、purpose binding、logging
Draft creation	Human review、edit diff、source citation
Case status change	Pre-action approval、reason code、reversal path
Payment / credit adjustment	Dual approval、limit、segregation of duties、audit
Customer communication	Compliance language check、human approval for high impact
Account restriction / release	Senior approval、risk owner notification、post-action QA

9. Responsibility Design and RACI

9.1 核心角色

Responsibility domain	责任
Business Process Owner	对业务流程结果、人工岗位设计和运营政策负责
Product Capability Owner	对 use case scope、价值、体验、发布节奏和采用负责
Process Analysis Owner	对流程证据、需求、例外、角色、handoff 和验收标准负责
Solution Architect	对系统边界、集成、权限、日志、fallback、stop switch 和 NFR 负责
Frontline Reviewer	在授权范围内审核、编辑、拒绝或升级 AI 输出
Senior Approver	处理高风险例外、重大客户影响和双人确认
Risk / Compliance	对风险分级、控制适用性、合规边界和证据要求提出挑战
Model Risk / Validation	对模型和系统验证、评测覆盖、限制和持续监控提出有效挑战
Security / Privacy	对访问控制、数据保护、prompt injection、tool misuse 和日志保留负责
Operations Lead	对复核队列、SLA、人力容量、质量抽样和一线反馈负责
Internal Audit	检查监督控制是否按设计执行、证据是否可复现

9.2 RACI: Oversight Design

Activity	Product	Process Analysis	Process Owner	Architect	Risk	Compliance	Ops	Security
Define AI behavior boundary	A/R	R	C	C	C	C	C	I
Identify decision points	A	R	R	C	C	C	C	I
Set risk tier	C	C	C	C	A/R	A/R	I	C
Design human review workflow	A	R	A/R	C	C	C	R	I
Design evidence UI	A/R	R	C	R	C	C	C	C
Define override and escalation	A	R	A/R	C	A/R	C	R	C
Define kill switch	C	C	C	A/R	A/R	C	R	A/R
Approve release gate	A	C	A	R	A/R	A/R	C	A/R

9.3 RACI: Production Oversight

Activity	Frontline	Senior Approver	Ops	Product	Architect	Risk	Audit
Review AI output	R	C	A	I	I	I	I
Override AI recommendation	R	A/R for high risk	C	I	I	C	I
Escalate exception	R	A/R	A/R	I	C	C	I
Trigger route stop	C	C	A/R	A	A/R	A/R	I
Investigate incident	C	C	R	A	R	A/R	I
Sample QA	C	R	A/R	C	I	C	C
Control testing	I	I	C	I	C	C	A/R

10. Escalation、Override、Stop / Kill Switch

10.1 Escalation Ladder

Level	触发	响应
L0 Self-correction	低风险、证据轻微缺失、格式错误	用户编辑或要求 AI 重新生成, 保留反馈
L1 Frontline supervisor	客户影响、政策不确定、重复错误	supervisor review, SLA 内给出结论
L2 Specialist	AML/KYC/credit/payment 专业判断、冲突证据	SME 或二线团队处理, 冻结相关自动动作
L3 Risk / Compliance	合规边界、监管材料、潜在客户损害	formal issue, risk acceptance or remediation
L4 Incident command	大规模错误、数据泄露、工具越权、客户资金影响	war room, route stop, customer remediation, management reporting

10.2 Override 类型

Override 类型	含义	必要记录
Ignore	不采用 AI 输出, 人独立处理	reason code、case outcome
Edit	修改 AI 草稿后使用	edit diff、edited fields、reviewer
Reverse	撤销已进入流程的 AI 影响	original action、reversal reason、approver
Escalate	交给更高权限或专业团队	escalation level、recipient、SLA、decision
Conditional accept	接受但加限制或补控制	condition、expiry、follow-up owner

10.3 Stop / Kill Switch 类型

Switch 类型	作用范围	示例
Case-level stop	单个 case 暂停 AI 继续处理	客户威胁法律行动, AI 停止生成回复
Route-level stop	暂停某类请求或 workflow route	暂停 credit adverse action draft route
Tool-level stop	禁用某个外部工具或写操作	禁止 AI 调用 payment adjustment API
Data-source stop	停用某个知识源或索引	KYC policy index 发现版本混用
Model-level stop	停用某个模型版本或模型供应商路由	vendor model update 后质量下降
Global stop	停止整个 AI capability	大规模数据泄露或系统性错误

10.4 Stop Switch Runbook

Step	操作	Owner
Detect	通过告警、用户反馈、QA、incident 或审计发现触发	Ops / Risk / Security
Classify	判断影响范围、客户影响、资金影响、监管影响和可逆性	Product / Risk / Architect
Contain	执行 case / route / tool / model / global stop	Architect / Platform Owner
Preserve	保存 prompt、output、retrieval、tool trace、human actions 和相关日志	Platform Owner / Security
Communicate	通知业务、风险、合规、客服、管理层和供应商	Product / Ops / Risk
Remediate	修复 prompt、index、policy、tool permission、training 或流程	Product / Architect / Owner
Restart	通过回归评测、风险复核和审批后恢复	Governance forum
Review	复盘根因、控制失效、客户补救和后续监控	Risk / Audit / Product

11. Audit Trail 与证据保全

11.1 最小日志字段

字段	说明
Trace ID	一次 AI 交互或 workflow run 的唯一编号
Use case ID	与 AI inventory 一致
User / reviewer role	用户角色、复核人角色、权限级别
Customer / case reference	按隐私和访问控制要求记录可追溯引用
Timestamp	输入、输出、人工动作、工具动作和审批时间
Model version	模型、路由、temperature、provider、deployment
Prompt version	system prompt、policy prompt、workflow prompt 版本
Knowledge version	index、document id、effective date、source owner
Retrieved evidence	文档、片段、引用位置、权限过滤结果
AI output	原始输出、结构化字段、风险标记
Tool calls	tool name、parameters、response、success/failure、side effect
Human action	accept、edit、reject、override、escalate、stop
Human rationale	reason code、说明、审批层级
Diff	AI 输出与人工最终文本差异
Downstream effect	是否进入客户沟通、case note、系统状态或监管材料
Incident link	关联 issue、alert、complaint、audit finding

11.2 审计可复现性标准

一个高影响 AI case 至少应能复盘:

当时用户问了什么。
AI 使用了哪个模型、prompt、知识库和工具。
AI 看到了哪些证据, 哪些证据没有权限访问。
AI 输出了什么, 哪些内容被人工修改。
人为什么接受、拒绝、覆盖或升级。
输出进入了哪个下游系统或客户沟通。
如果发生问题, 哪个控制本应发现但没有发现。

11.3 Evidence Pack

Evidence	用途
Oversight design memo	说明监督策略、风险分级和角色授权
BPMN / workflow map	证明人机交互点和升级路径
UI screenshots	证明证据、操作、警示和责任边界可见
Trace schema	证明日志字段足以复盘
Training completion	证明监督者具备 AI literacy
Reviewer calibration result	证明监督者能发现关键错误
Override analytics	证明人不是橡皮图章
Stop switch test	证明系统可被及时停止
Incident drill record	证明团队演练过异常
Quarterly control review	证明监督机制持续有效

12. Training / AI Literacy 体系

12.1 培训路径

模块	内容	适用角色	验收方式
Foundation concepts for reviewers	LLM、RAG、hallucination、automation bias、limitations	Frontline / Supervisor	场景题测验
System boundary	本 use case 能做什么、不能做什么、何时升级	所有使用者	Role acknowledgement
Evidence reading	如何判断引用是否支持结论、如何识别过期政策	Reviewer / SME	Case simulation
Override practice	accept、edit、reject、reverse、escalate 的正确用法	Reviewer / Supervisor	抽样评分
Incident and stop	数据泄露、越权工具、系统性错误的响应	Ops / Product / Architect / Risk	Tabletop exercise
Audit readiness	如何保留理由、证据、审批和复盘材料	Product / Process Analysis / Ops / Risk	Evidence sample review

12.2 Reviewer Calibration

监督者需要被校准, 否则不同人对 AI 错误的判断会严重不一致。

校准活动	做法	输出
Golden case review	多名 reviewer 独立审核同一批案例	agreement rate、分歧原因
Adversarial case drill	加入错误引用、缺失证据、诱导性用户输入	识别率、升级准确率
Override reason audit	检查人工覆盖理由是否足够具体	reason quality score
Refresher training	针对常见误判更新培训	updated playbook、quiz result

13. Metrics

13.1 监督有效性指标

Metric	含义	使用方式
Human review coverage	应复核案例中实际复核比例	验证控制是否被执行
Override rate	人工拒绝、编辑、撤销或升级 AI 的比例	过低可能是橡皮图章, 过高可能是 AI 质量差
Meaningful edit rate	人工对关键字段做实质修改的比例	衡量监督是否真正参与
Escalation precision	升级案例中真正需要升级的比例	评估风险信号质量
Escalation miss rate	事后发现应升级但未升级的比例	高影响指标, 需要持续降低
Reviewer agreement	多名审核者对同一案例判断一致性	衡量培训和标准清晰度
Time-to-review	从 AI 输出到人工复核完成时间	监控 SLA 和容量
Time-to-stop	发现重大问题到停止相关能力的时间	衡量 incident readiness
Audit replay success	抽样案例能否完整复盘	验证日志和证据链

13.2 业务与风险平衡指标

指标	业务含义	风险解释
Cycle time reduction	AI 是否缩短处理时长	不能以牺牲复核质量换速度
Rework rate	人工后续返工比例	高返工说明 AI 或监督标准有问题
Complaint rate	客户投诉趋势	客户可见 AI 使用必须重点监控
Policy exception rate	输出或人工决策偏离政策比例	触发流程或知识库复核
Incident severity trend	AI 相关事件严重度	决定是否扩大、限制或暂停
Cost per reviewed case	人工监督成本	Product Owner 需要纳入商业可行性
Adoption with calibration	用户采用率与 override 质量结合	避免把高采用误读成高信任

13.3 预警阈值设计

信号	可能含义	行动
Override rate 突然接近 0	审核者默认采纳、UI 诱导、培训失效	抽样复核、访谈、重新校准
Override rate 突然升高	模型、知识库或政策变更导致质量下降	回归评测、route 降级
Escalation backlog 增长	容量不足或风险信号过宽	调整规则、人力和 SLA
Unsupported claim 上升	RAG、prompt 或模型行为异常	增加 citation gate、修复 index
Stop switch 从未演练	停机能力未经验证	安排 tabletop 和技术演练

14. Failure Modes

Failure mode	表现	检测方式	控制
Oversight theater	有审批按钮但没有真实判断	override rate、review time、reason quality	强制证据视图、校准、抽样复核
Automation bias	人默认相信 AI	adversarial case drill、edit pattern	UI 降低默认采纳、培训、理由捕获
Reviewer overload	队列积压、审核时间过短	SLA、queue depth、review duration	风险分层、人力容量模型、抽样策略
Unclear authority	不知道谁能覆盖或停止	incident review、role survey	authority matrix、runbook
Missing evidence	人看不到来源或下游影响	audit sample	evidence panel、trace schema
Escalation dead end	升级后无人处理	escalation SLA、aged case	owner、backup、timeout rule
Shadow automation	人名义上决策, 实际按 AI 排序处理	workflow analysis、decision correlation	独立复核、排序解释、random QA
Stop failure	发现问题后 AI 继续运行	incident drill	kill switch test、权限预置
Poor training	人不知道 AI 失败模式	quiz、simulation	role-based AI literacy
Model change drift	供应商或内部模型变化导致监督失效	regression eval、quality trend	change gate、vendor notice、rollback
Audit gap	出事后无法重建过程	replay test	log schema、retention、evidence pack

15. 金融零售场景设计

15.1 AML Copilot

维度	设计
AI 作用	汇总 alert、交易模式、KYC profile、历史 case notes, 生成 investigation summary、red flag checklist、SAR draft
禁止边界	不自动关闭 alert, 不自动提交 SAR, 不替代 AML policy 判断
默认监督	Tier 1: analyst review + L2 review for high-risk cases
关键证据	交易、客户资料、历史警报、制裁筛查、政策条款、AI 引用
Escalation	制裁命中、可疑叙事冲突、客户高风险、跨境异常、证据不足
Override	analyst 可编辑 narrative, L2 可拒绝 AI 结论, compliance 可要求 route stop
Metrics	SAR draft edit rate、unsupported claim、missed red flag、review time、L2 disagreement
Red line	AI 不得作为是否提交 SAR 的唯一依据

15.2 KYC Review Assistant

维度	设计
AI 作用	检查材料完整性、提取身份信息、比对政策要求、生成 remediation checklist
禁止边界	不自动通过高风险客户, 不绕过 enhanced due diligence
默认监督	Tier 1 / Tier 2: risk-based review, high-risk customer 100% review
关键证据	客户文件、有效期、来源、政策要求、缺失项、EDD 规则
Escalation	PEP、制裁接近匹配、文件疑似伪造、受益所有人不清、国家风险
Override	reviewer 可要求补件、升级 EDD、拒绝 AI 完整性判断
Metrics	false complete rate、missing document catch rate、EDD escalation accuracy、rework
Red line	AI 不得把“文件看起来完整”当成“客户风险可接受”

15.3 Credit Underwriting Copilot

维度	设计
AI 作用	整理申请材料、生成 credit memo draft、引用信贷政策、提示缺失信息
禁止边界	不自动批准或拒绝贷款, 不生成无依据的 adverse action reason
默认监督	Tier 1: underwriter final decision, senior approval for exception
关键证据	申请数据、收入资料、信用报告引用、政策条款、例外审批
Escalation	政策例外、边缘评分、受保护类别风险、adverse action、异常收入证明
Override	underwriter 可拒绝 AI memo, 修改理由, 要求重新检索证据
Metrics	memo edit rate、policy citation accuracy、adverse reason specificity、exception review quality
Red line	不能因为模型复杂而无法给出具体、准确、可审计的信贷原因

15.4 Payment Dispute Assistant

维度	设计
AI 作用	汇总 dispute 信息、识别交易类型、推荐下一步材料、生成客户沟通草稿
禁止边界	不自动拒绝客户 dispute, 不无审批发放高额临时入账
默认监督	Tier 1 for money movement, Tier 2 for draft communications
关键证据	交易记录、商户信息、客户声明、规则时限、历史 dispute
Escalation	大额、欺诈、重复 dispute、监管时限临近、客户投诉升级
Override	agent 可编辑客户回复, supervisor 批准临时入账或拒绝
Metrics	resolution time、wrong denial、provisional credit error、customer complaint
Red line	AI 工具调用不得绕过金额限额和双人审批

15.5 Customer Service Copilot

维度	设计
AI 作用	搜索政策、建议回答、总结对话、生成 after-call note
禁止边界	不承诺费用减免、信贷结果、合规结论或法律解释
默认监督	Tier 2: agent review for customer-visible response, exception escalation
关键证据	知识库文章、产品条款、生效日期、客户上下文权限
Escalation	投诉、法律威胁、客户脆弱性、身份验证失败、高额交易争议
Override	agent 编辑回复, supervisor 处理投诉或例外
Metrics	first contact resolution、wrong answer rate、agent edit rate、escalation miss
Red line	AI 不得替代身份验证、投诉分级和监管要求的客户通知

16. Artifacts / Templates

16.1 HITL Design Brief

Section	内容要求
Use case	业务流程、用户、客户影响、AI 行为类型
Risk tier	分级、理由、客户/监管/资金/数据影响
Decision boundary	AI 可以建议什么, 人必须决定什么, 哪些动作禁止自动化
Human role	reviewer、approver、specialist、commander 的职责和授权
Review point	pre-decision、pre-action、in-flight、post-review、fallback
Evidence	人必须看到的来源、引用、缺失信息、版本、下游影响
Actions	accept、edit、reject、override、reverse、escalate、stop
Escalation	触发条件、接收队列、SLA、backup、超时处理
Stop switch	stop 类型、触发、权限、恢复条件
Metrics	监督有效性、质量、风险、容量和业务指标
Training	角色化 AI literacy、演练和校准要求
Audit trail	日志字段、retention、抽样复盘要求

16.2 Oversight Requirement Pattern

For [use case and workflow point],
when AI [summarizes / recommends / drafts / acts],
and [risk trigger] is present,
the system must route the case to [human role]
before [decision or action becomes effective],
showing [required evidence],
allowing [allowed human actions],
capturing [decision reason and trace fields],
and enforcing [SLA / escalation / stop condition].

示例:

For payment dispute provisional credit,
when AI recommends a credit adjustment,
and the amount exceeds the frontline threshold,
the system must route the case to a supervisor
before any payment action is submitted,
showing transaction evidence, customer statement, rule deadline and AI rationale,
allowing approve, reject, edit amount, escalate and stop tool route,
capturing reason code, approver, timestamp and tool-call trace,
and enforcing four-hour SLA with risk escalation on breach.

16.3 Override Reason Code

Code	含义
EVIDENCE_MISSING	AI 输出缺少关键证据
EVIDENCE_CONFLICT	证据之间或证据与结论冲突
POLICY_MISMATCH	AI 结论与政策不一致
CUSTOMER_CONTEXT	AI 忽视客户具体情境
RISK_ESCALATION	需要更高风险层级判断
TOOL_BOUNDARY	AI 建议的动作超出工具或权限边界
LANGUAGE_RISK	客户沟通语言存在合规或体验风险
DATA_QUALITY	输入数据或知识源质量不足
OTHER_CONTROLLED	其他已记录并可审计的原因

16.4 Audit Log Schema

Field group	Fields
Identity	trace_id、use_case_id、case_id、reviewer_role、business_unit
AI config	model_version、prompt_version、retriever_version、knowledge_index、tool_schema
Input / output	user_input_hash、workflow_state、ai_output、structured_fields
Evidence	document_ids、citation_spans、effective_dates、access_filter_result
Human action	action_type、reason_code、free_text_rationale、edit_diff、approver
Workflow	escalation_level、queue_id、SLA、downstream_system、customer_visible_flag
Risk / incident	risk_flags、incident_id、stop_switch_event、remediation_link

16.5 Release Gate Checklist

Gate question	Pass evidence
是否定义 AI 决策边界	Use case scope、decision boundary map
是否完成风险分级	Risk-tiered intervention matrix
人是否有真实权限	Role authority matrix、UI actions
人是否看到足够证据	Evidence panel screenshot、trace sample
是否能忽略、覆盖、撤销和升级	Workflow test、override log sample
是否能停止 AI route/tool/model	Kill switch test record
监督者是否完成 AI literacy	Training completion、simulation score
是否度量监督有效性	Dashboard metric definition
是否能审计复盘	Audit replay sample
是否有上线后复核节奏	Weekly quality review、quarterly governance review

17. 21-Day Lab

目标: 用 21 天把一个金融零售 AI use case 从“有人审核”升级为可评估、可审计、可停机的 human oversight / handoff 系统案例。

Day	任务	产出
1	选择一个 use case: AML、KYC、credit、payment dispute 或客服	1-page use case brief
2	画 AS-IS / TO-BE 流程, 标出 AI 插入点	BPMN 或流程图
3	定义 AI 行为: read、summarize、recommend、draft、act	AI behavior boundary
4	做 risk tiering, 标出客户、资金、监管、数据影响	Risk-tier memo
5	写 decision boundary: AI 做什么, 人决定什么	Decision boundary map
6	设计 human role: reviewer、approver、SME、commander	Role authority matrix
7	设计 Article 14 mapping	EU AI Act Article 14 control table
8	设计 Article 4 AI literacy plan	Role-based training plan
9	设计 NIST AI RMF mapping	Govern / Map / Measure / Manage matrix
10	设计 evidence UI 草图, 不追求视觉精细	Evidence and action wireframe
11	写 handoff rule: 何时升级、给谁、多久响应	Escalation rule table
12	写 override reason code 和撤销路径	Override and reversal design
13	设计 stop / kill switch	Stop switch runbook
14	设计 audit trail schema	Trace and log schema
15	设计 reviewer calibration cases	10 个 challenge cases
16	设计监督 metrics	Oversight dashboard metric list
17	写 failure modes and controls	Failure mode table
18	做一个场景案例: 从 AI 输出到人工覆盖	End-to-end case walkthrough
19	做 release gate checklist	HITL release gate
20	写 decision narrative	Oversight decision narrative
21	汇总成 evidence pack	Oversight evidence pack

18. Decision Narrative 与 Design Review Questions

本节不再把内容组织成问答背诵，而是把常见挑战转成设计评审议题。每个议题都要能产出一个可检查的设计判断、系统证据和后续治理动作。

18.1 监督定义: 从审批按钮到控制系统

Design Review Question: 这个用例里, 人类监督到底监督什么、何时监督、凭什么监督、能做什么动作, 以及如何证明监督有效?

Decision Narrative: HITL 的核心不是按钮, 而是让有能力和授权的人在正确时间看到足够证据, 能质疑、拒绝、覆盖、升级、撤销或停止 AI, 并留下可审计记录。设计起点应先定义 AI 在流程中的行为边界: summarize、recommend、draft、decide 还是 act。随后按客户影响、自动化程度、可逆性、数据敏感度和监管义务做风险分级。

System Evidence: 高影响场景必须展示 evidence view、decision boundary、override reason、escalation path、kill switch、training record 和 audit trail。有效性不能只看是否有人点击批准, 还要看 review coverage、meaningful edit rate、override reason quality、escalation miss rate、time-to-stop 和 audit replay success。

18.2 Article 14 转译: 从法规要求到产品和架构控制

Design Review Question: Article 14 的监督目标是否已经被转成 UI、workflow、architecture、operations 和 release gate 的可验收要求?

Decision Narrative: Article 14 可转译成五类系统能力: 理解 AI 限制、监控异常、避免 automation bias、正确解释输出、能够忽略/覆盖/撤销/停止 AI。它不是合规附件, 而是用例 intake、系统设计、上线门禁和运行监控的控制要求。

System Evidence: UI 需要展示证据、来源、有效期、缺失信息、风险标记和下游影响。Workflow 需要定义 pre-decision、pre-action、fallback 和 escalation。架构需要 trace log、权限、tool gating、stop switch 和回滚路径。运营需要 AI literacy、reviewer calibration、quality monitoring 和 incident runbook。这些证据应进入 release gate, 而不是上线后补文档。

18.3 反橡皮图章: 让人工复核有真实判断权

Design Review Question: 人工复核是否有足够信息、时间、权限和激励来挑战 AI, 还是只是被流程要求批量确认?

Decision Narrative: 防止 rubber stamp 要同时控制界面、队列和指标。审核者必须看到证据和限制, 拥有 reject、edit、escalate、stop 等真实操作权, 并且复核量不能超过可处理容量。审批按钮不应成为唯一显著动作, 高风险输出也不能被设计成默认正确。

System Evidence: 证据包应包含 evidence display spec、reviewer capacity model、override reason code、QA sampling plan、adversarial calibration cases 和 queue pressure metrics。如果 override rate 长期接近 0、review time 极短、evidence-open-before-approve 很低, 这不是质量优秀的证明, 而是监督失效信号。

18.4 信贷监督边界: Copilot 支持但不替代授权决策

Design Review Question: 信贷 AI 是否被限制在材料整理、政策引用和草稿辅助, 还是已经越界影响正式授信、拒绝和 adverse action reason?

Decision Narrative: 信贷场景应把 AI 限制在材料整理、政策引用、缺失信息提示和 memo draft。最终授信、拒绝、额度、定价和 adverse action reason 必须由授权 underwriter 在受控流程中负责, 并保留证据和理由。

System Evidence: UI 必须显示引用来源、政策有效期、例外条件、缺失材料和模型限制。边缘案件、政策例外、拒绝原因、受保护类别风险必须升级。指标包括 policy citation accuracy、memo material edit rate、exception escalation quality、adverse reason specificity、fair lending review trigger 和 audit replay success。

18.5 Agent 工具调用: 对状态改变动作建立前置控制

Design Review Question: AI Agent 调用支付、账户、case 状态或客户通知工具时, 是否有 tool boundary、审批、限额、撤销和停用机制?

Decision Narrative: 监督重点是区分 read-only tool 和 state-changing tool。对改变资金、账户、case status 或客户通知的动作, 必须在动作生效前有授权确认。高金额或高风险动作应使用 dual approval、segregation of duties、limit policy 和撤销路径。

System Evidence: 每次 tool call 要记录参数、响应、审批人、时间、上下游状态和客户影响。异常时应能立即停用具体 tool route 或 risk tier, 而不是只能关闭整个系统。证据包应包含 tool permission matrix、pre-action approval screen、tool-call trace schema、rollback design 和 tool-level kill switch runbook。

18.6 有效性指标: 覆盖、质量、容量和风险结果一起看

Design Review Question: 监督是否被度量为控制有效性, 而不是只度量节省时间或审批数量?

Decision Narrative: Human oversight effectiveness 应同时看覆盖、质量、容量和风险结果。覆盖率说明该复核的是否复核了; meaningful edit 和 override reason 说明人是否真正在判断; escalation miss rate 说明高风险有没有漏掉; reviewer agreement 说明标准和培训是否一致; audit replay success 说明出事后能否复盘。

System Evidence: 监控面板应包含 review coverage、override rate、meaningful edit rate、reason quality、reviewer agreement、time-to-review、time-to-stop、escalation miss、queue backlog、audit replay success 和 incident recurrence。指标必须和业务指标一起解释, 不能用效率收益抵消不可接受的客户伤害。

18.7 AI Literacy: 监督能力是上线条件

Design Review Question: 监督者是否具备理解 AI 能力、限制、失败模式、升级规则和个人责任的能力证据?

Decision Narrative: 没有 AI literacy, HITL 很容易失效。EU AI Act Article 4 的启发是, 监督者不只是签收政策, 还需要理解场景、工具和失败模式。金融零售 reviewer 至少要识别 hallucination、wrong citation、automation bias、prompt injection、data leakage、tool misuse、过期政策和越权建议。

System Evidence: 培训证据应包括 role-based curriculum、challenge case、simulation、calibration score、recertification cadence、knowledge refresh 和 exception drill。AI literacy 的完成情况、挑战样本表现和复训要求应进入 release gate 和 audit pack。

18.8 协作模型: 价值、流程、架构和风险共同闭环

Design Review Question: 监督设计是否把业务价值、流程例外、系统边界、风险挑战和审计证据连成闭环?

Decision Narrative: 成熟 HITL 不按角色话术拆解责任, 而按控制对象组织协作: value boundary、workflow boundary、system boundary、risk boundary 和 evidence boundary。业务侧确认哪些场景值得引入 AI 以及监督成本是否仍有 ROI; 流程侧把人工审核拆成输入、输出、SLA、例外、升级和证据字段; 架构侧把监督落到 trace、UI、workflow engine、tool permission、rollback 和 monitoring; Risk / Compliance / Audit 负责有效挑战和证据检查。

System Evidence: 系统证据包应包含 use case risk memo、BPMN、decision boundary map、oversight requirement、C4 / sequence diagram、RACI、release gate、monitoring dashboard、incident runbook 和 evidence binder index。真正的协作成果不是会议纪要, 而是可运行、可追踪、可审计的监督控制系统。

19. 最小可用总结

一个金融零售 AI 系统如果声称有人类监督, 至少应能回答:

问题	最小合格答案
人监督什么	AI 输出、证据、建议理由、动作请求、异常和客户影响
人何时监督	pre-decision、pre-action、in-flight、post-review 或 fallback
人凭什么监督	来源、引用、限制、缺失信息、风险标记、历史和下游影响
人能做什么	accept、edit、reject、override、reverse、escalate、stop
谁有权停机	route/tool/model/global stop authority 明确
如何证明有效	training、calibration、metrics、audit replay、incident drill
出错后怎么办	containment、evidence preservation、remediation、restart approval

最终标准:

Human oversight is effective only when the human can understand, challenge, change and stop the AI system within a governed workflow.