📘 本文件为本笔记系列正文第 5 部分。主文件（前序与总览）含全系列索引：UL 3115 AI人工智能产品安全评估大纲学习笔记（前序） - 概述与总览
第八章：控制监督、透明性与可解释性【引述依据：27–35】
8.1 两块内容的共同前提
控制监督（第 27–30 章）讲"人还能不能管住 AI"，透明性与可解释性（第 31–35 章）讲"人能不能看懂 AI"。这两件事有一个共同前提：只有在人能理解系统行为的前提下，监督才是真实的。
一个反例足以说明：某系统提供了"一键接管"按钮，但操作者不知道系统当前在做什么、为什么给出这个建议、接管后会发生什么。此时"接管权"在形式上存在，在实质上无效——因为操作者无法判断何时该接管。这就是标准把这两章放在相邻位置的原因。
另外一个共同点是：两章的要求都落在人机接口（HMI）与文档披露上，而不是模型内部。这意味着它们的实现成本相对可控，但也最容易被"写进说明书就算做了"。
8.2 控制与监督的四项关键考量（第 28 章）
| 考量 | 核心问题 | 失效后果 |
|---|---|---|
| 人在回路（HITL） | 关键决策是否有人的实质参与 | 形式审核，人成为盖章机器 |
| 干预机制 | 人能否在需要时改变或终止系统行为 | 只能眼睁睁看着错误发生 |
| 监控与报告 | 是否有机制让人知道系统在做什么 | 异常无人知晓 |
| 责任与问责 | 监督者的权限与责任是否明确 | 无人敢停、无人负责 |
"人在回路"这个词在行业里被严重稀释。只要有人在流程里签个字，很多团队就声称自己有 HITL。标准的要求要严格得多：人必须拥有足够的信息、足够的时间、足够的权限，才能做出有意义的判断。三者缺一，HITL 就是装饰。
💡 行业经验提示：检验 HITL 是否真实，用一个指标就够了——人工推翻 AI 建议的比例。如果这个比例接近零，说明人没在真正审核（要么信息不足无法判断，要么不敢推翻）；如果过高，说明 AI 质量或阈值设定有问题。健康区间因场景而异，但"零推翻率"几乎总是危险信号。
8.3 第 29 章的通用指南
第 29 章提出的方向包括：系统审计、场景化测试、实时监控能力建设、问责框架定期评审。
其中"场景化测试"针对的是监督机制本身：不只是测 AI 会不会出错，还要测当 AI 出错时监督链是否真的能起作用。这类测试通常以演练形式进行——注入一个已知错误，观察告警是否触发、人是否收到、处置是否及时。
8.4 用户控制：R42
第 30.1 节（R42）要求提供用户控制能力。标准强调三个特性：
- 界面直观：控制项的位置、命名、状态反馈符合用户认知；
- 细粒度：能分别控制不同维度的行为（不是只有一个总开关）；
- 安全可验证：控制生效与否可以被确认，而不是"点了但不确定有没有用"。
"安全可验证"是最容易被忽略的一条。很多系统的"关闭"只是前端隐藏，后端仍在运行；或者关闭后没有状态回显。在安全相关场景，这等同于没有提供控制。
8.5 人工干预流程：R43
第 30.2 节（R43）要求建立人工干预流程，并引用 EU AI Act 第 14 条（人类监督）。标准对监督措施提出两项原则：与风险相称、配套文档与培训。
关于人机接口（HMI），标准列出五项能力方向：
- 正确理解系统的能力与局限；
- 正确理解输出含义与置信程度；
- 能识别异常与失效迹象；
- 能及时介入并采取行动；
- 能避免自动化偏见。
第五项是这一条的灵魂。自动化偏见（automation bias）指人倾向于过度信任自动化系统，在系统给出错误建议时仍然采纳。它的成因不是人的疏忽，而是系统设计让人失去了独立判断的依据——如果界面只给结论不给依据，人就只能信结论。
防范自动化偏见的常见设计手段包括：展示不确定性与备选方案、在低置信时主动要求人工确认、定期插入已知正确答案的"探针"以校准信任、保留独立的信息来源供操作者交叉验证。
💡 行业经验提示：行业里最有效的反自动化偏见手段是**"强制说明理由"**——要求操作者在采纳 AI 建议时选择一个理由码，在推翻时填写简短原因。这个动作会显著提升审核质量，同时产生的数据本身又是极好的监督有效性证据（可直接支撑 R43 与 R81）。