一句话总结：UL 3115（Proposed First Edition，2026-07-31）没有把"模型漂移"当成一个运维话题，而是拆成三件事：谁负责发现（Clause 18.7 的运行时监控）、发现之后做什么（Clause 18.7.3 的阈值三动作）、变更之后重新证明什么（Clause 18.2.4、18.4.3、18.6.4 三处再验证触发）。本文把六处相关条款串成一条闭环，包括功能适应性的界定条件与暂停、撤回、回滚的批准权限。
漂移从哪来，为什么传统配置管理管不住
Clause 18.7.1 把原因说得很平实：即便一个验证充分的模型，在部署后也可能因为数据分布变化、运行环境变化或模型内部状态变化而退化或出现不可预期行为。Clause 18.3.2 b) 进一步点明其中一类——概念漂移，即环境变化导致的性能下降。
为什么不能靠传统配置管理？Clause 16.2 给的对比最清楚：传统功能安全系统是确定性的、透明的、易于理解的；AI 系统是非确定性的、概率性的、不透明的、数据依赖的、自适应的。配置管理的假设是"同样的输入得到同样的输出"，AI 系统恰恰打破这个假设。
Clause 46.2 补了另一半：AI 系统可能表现出非确定性、自适应与涌现行为，这些特性提高了"明确谁对决策、失效、非预期后果与纠正措施负责"的重要性。所以漂移管理的落点不只是技术监控，还有责任归属。
三处"变更后必须重验"的条款
这三处散在不同章节，口径高度一致，说明是刻意设计：
| 条款 | 触发条件 | 要重做什么 |
|---|---|---|
| 18.2.4 b) | 模型变更后 | 重新验证，并据分类重新确定可接受失效率、部署后监控需求 |
| 18.4.3 d) | 模型、数据或部署场景重大变更；以及生命周期内的定期评审 | 更新 AI 特有失效分析 |
| 18.6.4 c) | 模型、数据或环境显著变化 | 重做验证 |
三者合起来就是一条规则：任何被记录为"重大"的变更，都要连带重做失效分析与验证。实务上的难点不在条文字面，而在"重大"的判定门槛由谁定、定在哪。Clause 15.9.1（R18）正好补上这一环——它要求提供方对功能适应性做界定、控制与验证，也就是把"什么算允许的变化"提前写死。
功能适应性：先界定，再控制，最后验证
R18 覆盖的对象比很多人想的宽：不只是"模型会自己学习"，还包括"能适应动态环境""能基于实时数据重训""能自动调整决策阈值"。第三项把线上调阈值也纳进来了。
Clause 15.9.2 给了三条落地指引：
| 指引 | 要求 |
|---|---|
| a) 界定范围与条件 | 明确允许适配的范围与触发条件，条款举例事件触发的模型切换 |
| b) 设防负向强化 | 防止不安全行为被反馈回路强化，条款举例认知偏差被固化 |
| c) 可验证可追溯 | 任何自适应行为都要可验证、可追溯 |
- 的实际价值在于它把"变更分级"变成了合规动作：允许适配的范围与条件写清楚之后，"这次改动算不算重大变更"就有依据可查，不必每次临时争论。b) 则针对一个具体风险场景——模型上线后按用户点击反馈继续训练，短期指标好看，长期把偏置固化，这在 Clause 22.2.2 的公平性语境里同样是问题。
监测指标与阈值怎么定
Clause 11.2.1 是技术支柱里的监控要求，Clause 18.7.3 是功能安全语境下的监控要求，两者要一起看。
Clause 11.2.1 f) 要求按 AI 产品的风险画像定义可接受性能指标的阈值；g) 要求建立监控系统随时间跟踪指标并识别显著偏离。指标族按模型类型分：回归类用 MAE、MSE、RMSE、R²、调整 R²；分类类用准确率、精确率、召回率、F1、AUC-ROC、混淆矩阵。
Clause 18.7.3 c) 补了功能安全侧的检测清单，监控系统要能检测三类：性能退化（准确率下降、漏报增多）、数据漂移与概念漂移、输入输出异常行为或模型置信度崩塌。
第三类是 AI 特有的。传统系统没有"置信度"这个可崩塌的量，而置信度崩塌往往早于准确率下降出现，是最好的早期信号。Clause 18.7.4 b) 给了三种可用方法：统计漂移检测（EDDM、DDM）、基于置信度的阈值、看门狗与心跳信号。
关于监控基础设施本身，Clause 18.7.3 e) 有一条硬要求：监控基础设施要与被监控的 AI 系统独立或冗余，以保证监控自身失效时仍有安全保障。用同一套推理服务既跑模型又算漂移指标，这条就过不了。