一句话总结：UL 3115（Proposed First Edition，2026-07-31）的 Clause 16–18 把 IEC 61508 的功能安全生命周期搬到 AI 上，要求先用 AUL、SWTC、EU AI Act 风险类别三层分类定级，再用扩展过的 HARA 找出 AI 特有危害，然后走 FSC/TSC 与 V 模型。这一节共 7 条编号要求（R23~R29），是三支柱里唯一直接管"出错会伤人"的部分——定级错了，后面所有验证深度都会跟着错。
边界与两个概念
先说边界，因为这决定你该找谁配合。Clause 16.5 的注给得很明确：这一节只覆盖 AI 系统的算法；任何 AI 相关硬件元件与非 AI 功能的功能安全评估，由终端产品标准的要求覆盖。所以 AI 感知模块的算法归 UL 3115，同一模块的电路板归纵向标准。
再说为什么需要单独一节。Clause 16.2 对比得很直接：传统功能安全系统通常是确定性的、透明的、易于理解的；AI 系统尤其是机器学习系统是非确定性的、概率性的、不透明的、数据依赖的、自适应的。这五个差异不是程度差别，是性质差别——所以不能拿传统功能安全的验证思路硬套。
Clause 17.2 给了两个贯穿全节的概念：
| 概念 | 回答什么 | 内容（Clause 17.2） |
|---|---|---|
| FSC 功能安全概念 | 要防什么 | 由 HARA 导出安全目标，含系统级与 AI 特有危害（误分类、检测漏报、对抗行为） |
| TSC 技术安全概念 | 怎么防 | 把目标转成架构级要求与约束，如冗余、运行时监控、降级回退策略 |
这两者之后由 V 模型串起来：每个规格步骤都有对应的验证步骤，全程保持可追溯（Clause 17.3）。Clause 17.4 补了一条传统功能安全里不常见的要求——生命周期要支持部署后的持续验证与监控，因为 AI 会随时间退化，也可能遇到没见过的输入。
三层分类定级
Clause 18.2.1 的开场句是这一节的逻辑起点：施加于 AI 系统的安全要求，应与其在系统中的角色、功能、用途和风险等级成比例。比例怎么定？用三套分类同时看。