ISO/PAS 8800 AI 安全深度 — 三标准分工 / 数据+模型双生命周期 / AI 安全案例

传统安全把功能拆成可枚举的失效模式来分析;AI 的行为由数据决定、是黑盒、面对开放世界,这套方法直接套不上。三标准因此分工:

8800 不替代前两者,而是补 AI 这一块 + 接口:AI 的性能不足风险经 8800 的方法识别后,仍走 SOTIF 的残余风险论证框架。

AI 安全不是训练完测一下,而是一条贯穿需求→数据→模型→集成→运行的生命周期,集成进系统安全 V:

• AI 安全需求 — 从系统/整车安全需求派生 AI 组件的安全需求(如"行人漏检率 < X""OOD 必须可检")
• AI pipeline 拆段 — 8800 把 AI 元件拆成 pre-processing → model → post-processing 三段,安全要贯穿整条通路(不只看模型 inference)——后处理的 plausibility/约束正是"安全不全压 AI"的落点
• 数据生命周期 — 数据是 AI 的"代码",其质量直接是安全属性(§3)
• 模型生命周期 — 架构/训练/验证/鲁棒性(§4)
• 集成 + V&V — 与系统集成,经 场景化验证 测覆盖
• 运行监控 — 部署后监 OOD/漂移/性能退化,反哺数据(§5)

双生命周期(数据 + 模型)是 8800 区别于传统软件安全的核心:数据被当作一等安全制品来管。

AI 的行为由数据决定,所以数据的安全要点是 8800 的重头:

• 完整性 / 代表性 — 数据集要覆盖目标 ODD 的工况分布;缺口 = 安全盲区(对应 SOTIF Area 3 的未知)
• 标注质量 — 标注错误/偏差直接进模型;须标注规程 + 复核 + 一致性度量
• 数据集独立划分 — 训练/验证/测试集必须独立(同一场景/序列不能跨集泄漏),否则"测试通过"是数据泄漏的假象(同 场景化验证 的训练≠验证独立底线)
• 偏差与公平 — 类别/场景/人群分布偏差 → 长尾失效(夜间/雨雾/特定人群漏检)
• 数据漂移监控 — 部署后真实分布漂离训练分布 → 性能退化,须运行期监 + 再训

数据缺口/偏差是 AI 安全的头号根因——这正是把"完整性论证"提到与代码验证同级的原因。

模型侧除了精度,更要保安全属性。8800 关注的 AI 安全属性:

• 鲁棒性(robustness) — 对噪声/扰动/天气/传感退化稳定;对对抗样本有抵抗;鲁棒性测试含 OOD 检测(遇分布外输入能自知不确定 → 触发降级,而非自信地错)
• 泛化(generalizability) — 在 ODD 内、训练分布外仍可接受;避免过拟合到数据集特性
• 可控性(controllability) — AI 输出可被外层(确定性监控/安全态)接管或约束,这是"安全不全压 AI"的属性基础
• 可解释 / 透明(explainability) — 能给出决策依据,便于安全分析、调试与论证(纯黑盒难做安全案例)
• 可监控(monitorability) — 运行期可观测置信度/OOD 信号,供安全监控用

(注:8800 明确命名的核心属性是 robustness / generalizability / explainability / controllability;OOD 检测是鲁棒性测试下的手段,这里单列只为强调。)

度量这些属性(鲁棒性指标、OOD AUROC、覆盖度)替代了传统的"失效率"——因为 AI 没有传统意义的恒定失效率,只有"在什么分布下表现如何"。

AI 性能不足是统计性的、消不干净,所以和 SOTIF 一样落到论证残余风险可接受:

• AI 安全案例(assurance argument) — 用结构化论证(GSN/UL 4600 风格)把"AI 组件的安全属性 + 数据完整性 + 验证证据 → 残余风险可接受"串成证据链
• 运行监控(runtime monitoring) — 部署后监 OOD/置信度/性能,安全监控器在 AI 不可信时触发降级/冗余/安全态(AI 不独自承担安全,外面套一层确定性监控)
• field feedback 闭环 — 现场捞 corner-case/漂移 → 回灌数据 → 再训 → 再验证,与 场景化验证 的 fleet 影子模式同一引擎
• 架构兜底 — 安全不全压在 AI 上:用确定性安全监控 + 冗余通道(如 doer/checker 架构),把 AI 的不确定性约束在可控范围

核心:AI 安全 = AI 自身属性 + 外层确定性监控 + 论证,不是"把 AI 训得足够好"单点保证。

8800 不是孤立的,它和 21448、场景化验证咬合:

• AI 性能不足 → SOTIF Area 2/3 — 8800 识别的 AI 不足,经 SOTIF 的 Area 分类 + 残余风险论证
• AI 验证 → 场景化 — AI 组件的覆盖靠 场景化验证(逻辑场景参数化 + corner-case + 仿真),数据完整性 = 场景空间覆盖
• 监管 — 中国 L3 准入 / UNECE WP.29 对感知 AI 的安全证据链要求,正把 8800 类方法纳入

一句话:8800 管"AI 这个零件怎么算安全",21448 管"含 AI 的功能整体残余风险",场景化验证是二者共用的验证引擎。

AI 安全翻车几乎都在"用传统方法硬套 AI"和"全压在模型精度上":

• 传统 FMEA/FTA 硬套黑盒 — AI 失效模式难枚举,要补数据/分布视角(完整性、OOD),不能只列器件失效
• 测试集泄漏 → 假通过 — 训练/验证/测试不独立,"测试 99%"是泄漏假象;必须场景/序列级隔离
• 只追精度不管 OOD — 高精度模型遇 OOD 自信地错最危险;必须 OOD 可检 + 触发降级
• 安全全压在 AI 上 — AI 统计性不可信,必须外层确定性监控 + 冗余兜底(doer/checker)
• 数据完整性无论证 — 数据缺口 = 安全盲区,完整性/代表性要像代码覆盖一样论证