S71：人机职责图：Decision Rights、Review Tier、Queue、Override、Appeal 与 Automation Bias

内容类型：预习教材（不代表已完成）
日期：2027-02-01
阶段：P2 · AI Systems Engineering 90
总路线：Day 161
周次节奏：W11 · 周一概念与阅读
状态：教材已备；学习未完成

一句话定义

Human-AI operations 是将“人在环中”具体化为谁建议、谁决定、何时必须复核、工单如何排队、决定如何被 override/appeal，以及人类容量与认知偏差怎样成为系统约束。

学习目标

1. 画出 propose、review、approve、execute、override、appeal 和 audit 的 decision rights。
2. 将 review tier 与风险、不确定性、可恢复性和人类容量联系，而不是一律复核。
3. 识别 automation bias、under-reliance、fatigue、rubber-stamping 和责任漂移的界面/运营成因。

核心知识

Decision rights 应作用于 action 而非抽象“系统”。AI 可以生成证据摘要，但是否冻结账户、拒绝客户、发出交易或提交报送需要单独定义。“人类可以随时接管”若没有入口、时限、所需证据和接管后状态语义，只是口号。

Review tier 可按风险分为：自动通过但可抽查；同步人工复核；两人或专业权限审批；直接拒绝自动化。分层输入不宜只用 model confidence，还要考虑 action impact、data sensitivity、novelty、conflicting evidence、可撤销性与 queue capacity。

Queue 是产品机制，也是可靠性机制。每个工单需 priority、due time、risk tier、evidence snapshot、model/release id、assignment、lease/lock 与 status history。只有进队没有容量管理，会让高风险工单在 backlog 中老化，甚至让自动回退逻辑放行。

Override 与 appeal 不是同一件事。override 是操作人修改当前建议/决定，需 reason code、evidence 与 actor；appeal 是受影响者或后续复核者要求重审，需新证据、独立性、SLA 和 remediation。两者数据可用于学习，但不应未经审查就自动反馈到模型。

机制与推导

人工容量可用粗略排队关系思考：utilization ρ = arrival_rate / service_rate。当 ρ 长期接近 1，等待时间和长尾会快速增大，所以 review-everything 可能比风险分层更不安全。审核价值可简化为：

review_priority ∝ expected_harm × uncertainty × review_value / expected_effort

它不是自动决策公式，而是提醒不要用 confidence 单排队。评估人机流程时应同时看 outcome、override quality、appeal rate、queue age、review time 与不同群体的误差。

最小练习或观察

1. 选一个文档审核或 wallet 交易预览案例，列所有 action 与不可逆影响。
2. 对每个 action 填 AI、一线 reviewer、高级 reviewer、用户与系统 owner 的 RACI-like decision rights。
3. 定义三个 review tier，写入队条件、SLA、fallback 和不能自动的动作。
4. 为 override 与 appeal 分别写最小字段，检查是否可追溯到当时证据与版本。
5. 不要开展真实用户实验；今日产出只是一张职责图。

常见误区与边界

• 在流程末端加一个“人工确认”框，却不给人时间、证据、权限与退出。
• 只按 model confidence 排队，忽略高影响但模型自信的错误。
• 将 override 率越低当作越好；低值也可能表示界面导致 automation bias。
• 把 appeal 当作例外而不记录，失去公平性与修复证据。
• 职责图不是劳动流程、法律责任或组织实际授权的认定。

系统 / 金融 / Web3 连接

在 AML 中，AI 可整理证据，调查员可修改叙述，但法定报送的批准权应单独定义。在 Web3 中，agent 可提交 unsigned transaction 建议，用户签名不应被一个模糊“同意”按钮代替；钱包界面应先显示 chain、contract、amount、allowance 与 simulation evidence。

自检问题

1. decision right 为什么应按 action 而不是按系统定义？
2. review-everything 为什么可能增加系统风险？
3. override 与 appeal 的主体、时间与证据有何不同？
4. 你的职责图是否给 reviewer 真正的拒绝和升级能力？

专业课程对齐

• Google PAIR Guidebook：精读人机交互、反馈、可解释性、错误与用户控制，映射 evidence presentation 和 automation bias。
• NIST AIRC / AI RMF：精读人类监督、roles/responsibilities、context 与风险管理，校准 decision rights 与 review tier。
• DORA：选读开发者体验、软件交付与组织性能研究，用来提醒 DevEx 与安全决定应共同设计。

深入学习提示

先用 PAIR 审视界面如何影响判断，再用 NIST 放回风险与责任，最后用 DORA 检查工程师和 reviewer 的工作负担。读每项建议时都问：它改变了哪个人在哪个时点的信息、权限或成本？

学后填写区

• 案例与主要 action：
• decision rights / review tiers：
• queue 与 fallback：
• override / appeal 证据：
• automation bias 风险：