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 的"代码",其质量直接是安全属性
• 模型生命周期 — 架构/训练/验证/鲁棒性
• 集成 + V&V — 与系统集成,经 场景化验证 测覆盖
• 运行监控 — 部署后监 OOD/漂移/性能退化,反哺数据

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

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

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

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

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

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

场景:L2+ AEB 行人检测,TC397 AURIX + EyeQ5（AI 推理 SoC，ASIL B(D) SEooC）+ ARS540 77GHz 毫米波雷达,城市 / 高速混合 ODD。

AI pipeline:摄像头 ISP（20ms）→ EyeQ5 CNN inference（名义 28ms）→ plausibility monitor（TC397，确定性监控）→ AEB 决策。

Step 1: AI 安全需求派生

系统安全目标：HARA H1 = 行人漏检导致碰撞，S3/E4/C3 → ASIL D；FTTI = 300ms（从危险到 AEB 激活）。AI 组件分配安全需求：

• AIR-01：行人漏检率（FNR）在 ODD 内 ≤ 5%（正常光照/干燥路面）
• AIR-02：OOD 输入须可检测，且在判定为 OOD 后 2 个决策周期内触发降级（雷达单模式）
• AIR-03：AI 推理延迟 ≤ 30ms（占 FTTI 的 10%）

Step 2: 数据生命周期 — ODD 覆盖审计

训练集 500 万标注帧，ODD 子域覆盖矩阵（工程估算）：

雨天缺口（6% < 10%）用 GAN 合成雨纹增强补至 8.5%，并在验证集实测 SSIM ≥ 0.85 确认增强多样性。标注一致性 κ = 0.87 > 0.80 合格线 ✓。

Step 3: AI 安全属性量化

在独立测试集（场景级划分，无泄漏）测量：

关键核验：

• 雨天退化：(0.912−0.783)/0.912=0.129/0.912=14.1%，满足 ≤ 20% 判据（✓）
• 降级响应：plausibility monitor 判定后，2 个 EyeQ5 决策周期 × 25ms/周期 = 50ms ≤ FTTI/6（300ms/6=50ms）——边界满足
• 推理延迟：28ms < 30ms 要求，余量 6.7%（偏紧，见 C1）

Step 4: 运行监控配置（确定性安全层）

TC397 运行 plausibility monitor：

• 置信度门限：AI 输出 confidence < 0.60 → 触发 OOD flag
• OOD score 门限：EyeQ5 输出 OOD_score > 0.35 → 触发 OOD flag
• 速度一致性检查：AI 输出目标速度与雷达速度差 ΔV > 15 m/s（在 25ms 窗口内）→ plausibility fail
• 任一 flag 触发：切换至雷达单模式，2 个周期内完成；雷达单模式维持至 AI confidence 恢复且 > 0.65 连续 3 帧

监控自身为 ASIL D 等级软件，TC397 Lockstep 核运行，与 AI 推理物理隔离（MPU 保护边界）。

Step 5: AI 安全案例结构（GSN-style 论证链）

顶层目标 G1：AEB 行人检测 AI 组件在 ODD 内残余安全风险可接受。

• 策略 S1：按 AI pipeline 三段 + 运行监控分别论证。
  • G2：数据生命周期完整 → 证据：ODD 覆盖矩阵（Step 2，雨天缺口已增强闭合）+ κ=0.87 标注质量报告
  • G3：AI 安全属性充分 → 证据：AP/AUROC/降级时序（Step 3 测量结果）
  • G4：运行监控功能正确 → 证据：plausibility monitor ASIL D 验证 + OOD gate 测试报告（1000 场景）
  • G5：26262/8800/21448 接口完整 → 证据：EyeQ5 ASIL B(D) SEooC AoU 验证清单（AIR-03 延迟 AoU 28ms<30ms ✓）+ SOTIF Area 2 残余风险论证（仿真 4500 万 km + PG 250 万 km）

SOTIF Area 2 残余风险估算（工程估算，非精确值）：雨夜组合场景暴露率约 3.2% 运营时间；在增强后训练集下模拟 FIE（Functional Insufficiency Event）发生率 < $1.5\times 10^{-8}$/h，满足 GAMAB 基线（与参考系统对比不增加风险）。