📘 本文件为本笔记系列正文第 3 部分。主文件（前序与总览）含全系列索引：UL 3115 AI人工智能产品安全评估大纲学习笔记（前序） - 概述与总览
第六章：AI 功能安全【引述依据：16–18】
6.1 为什么这一章最难，也最值得先读
功能安全（Functional Safety）的经典定义是"由电气/电子/可编程电子安全相关系统执行的功能所带来的风险降低"。它关注的不是产品会不会坏，而是当系统承担了"防止伤害"的职责时，这个职责履行得够不够可靠。
传统功能安全建立在三个假设上：规格可以完整写清楚、失效可以被穷举、行为是确定的。AI 系统把这三个假设全打破了，于是产生了整份标准里最尖锐的一处张力：我们既要用 AI 来提升安全能力（例如视觉检测比人眼更早发现异常），又要证明这个 AI 本身是可信的。
第 16 章（Overview）没有回避这个张力，而是把它拆成了可以操作的问题：承认 AI 的不确定性，然后用分类分级 + 危害分析 + 需求分解 + 独立验证 + 运行监控五道工序，把不确定性框在可接受范围内。
💡 行业经验提示：读这一章建议先放下"AI 能不能做安全功能"的争论。行业实践已给出共识：AI 可以做安全功能，但不能单独承担安全功能——必须有独立的监视、限幅或回退路径。所以真正的设计问题是"AI 与保障机制如何分工"，而不是"要不要用 AI"。
6.2 AI 与传统确定性软件的五个差异（16.2）
第 16.2 节列出 AI 系统的特性，可以归纳为五个差异，每一个都直接对应一项工程约束：
| 差异 | AI 的表现 | 对功能安全的直接后果 |
|---|---|---|
| 非确定性 | 同一输入多次推理可能给出不同结果 | 传统"重复测试即证明"的验证逻辑失效 |
| 概率性 | 输出是置信分布而非确定值 | 合格判定必须引入置信水平与统计显著性 |
| 不透明性 | 内部决策路径难以逐行解释 | 无法用代码审查证明正确性 |
| 数据依赖 | 行为由训练数据塑造 | 需求无法只写在规格书里，必须写进数据规格 |
| 自适应性 | 在线学习或持续更新会改变行为 | 出厂验证结论会随时间失效，必须持续再验证 |
这五点合起来说明一件事：AI 功能安全的验证对象不是"代码"，而是"代码 + 数据 + 运行环境"的组合。因此第 18.6 节特别强调：模型、数据或环境发生显著变化时，V&V 必须重做。
6.3 与外部功能安全标准的关系（16.4）
第 16.4 节把 UL 3115 接入既有的功能安全标准族，分工如下：
| 标准 | 提供什么 | 在 AI 场景下的局限 |
|---|---|---|
| IEC 61508 系列 | 安全生命周期、SIL 概念、V 模型框架 | 面向确定性系统，缺 AI 特定危害分析 |
| ISO 26262 | 汽车领域的具体化（ASIL、HARA 流程） | 领域限定，方法可移植但术语需转换 |
| ISO/IEC TR 5469 | AI 功能安全的专门技术报告 | 指导性为主，判据需结合产品标准 |
| ISO/IEC TS 22440 | AI 系统功能安全的技术规范 | 与具体产品落地仍有距离 |
| ISO/PAS 8800 | 道路车辆 AI 安全，提出 AI-HARA | 领域限定 |
| EU AI Act | 法规层面的风险分级与义务 | 法律义务，非工程判据 |
读这张表要注意：UL 3115 不是"引用即等同"。它做的是"借用方法 + 建立自己的判据"，所以最终还是回到 R23–R29 这七条上。
6.4 一条极重要的边界说明（16.5）
第 16.5 节的 NOTE 明确：本章的要求只覆盖 AI 系统相关的算法层，硬件与非 AI 功能仍由终端产品标准覆盖。
这条说明的实际意义非常大。它意味着在认证时，"AI 部分的安全"与"设备部分的安全"是两条并行的证据链，需要分别举证、最后在系统层面合并。行业内常见的错误是：用 AI 模型的测试报告去回应"设备安全"问题，或者反过来用设备型式试验报告去证明"AI 决策可靠"——两者都不成立。
6.5 FSC 与 TSC：把"要防什么"和"怎么防"分开（17.2）
第 17.2 节引入两个核心概念，它们的区分是理解全章的关键：
- FSC（Functional Safety Concept，功能安全概念） 回答 "what"：系统需要实现哪些安全目标、在什么条件下进入什么安全状态；
- TSC（Technical Safety Concept，技术安全概念） 回答 "how"：用哪些技术机制来实现这些安全目标。