AI时代功能安全重做：从确定性失效到不确定性共存的转型

干了十多年功能安全我最近越来越有一个感觉这个行业正被AI顶到墙角但顶着顶着反而把一条新路踩出来了。过去我们谈ASIL等级、安全目标、FTTI、冗余架构前提是系统的行为可以用逻辑、时序和故障树说清楚现在一辆智能汽车、一套工业AI系统里深度学习模型、大模型推理、AI Agent接连进场连系统自己都解释不了某些输出是怎么来的我们这些做安全的人却还要为它的失效负责。这件事绕不过去也躲不开所以我把这个系列命名为“重做一遍”——不是推翻重来而是把过去十年我们熟悉的思路放到AI场景里重新捋一遍。这个“上篇”先讲认知为什么传统功能安全会在AI时代失灵新的安全体系要从哪里长出来。下篇再聊工具链、标准落地和具体案例。如果你正在做智能驾驶、AI辅助编程、AI应用开发或者你的团队已经被老板要求“给AI做一套安全方案”这篇文章应该能帮你少走不少弯路。1. 为什么功能安全在AI时代必须重做一遍1.1 传统安全分析链条断在“AI模型”上传统功能安全能成立靠的是一个非常朴素的假设系统的每个生效链路都是确定性的工程师可以把需求拆到足够细把失效模式枚举到足够全然后针对每种失效设计对应的检测机制。一辆车刹车失灵可能是因为传感器信号错误、线束断掉、控制器输出异常这些都是可以建模、可以注入、可以测试的故障。于是ISO 26262才会有一套完整的HARA分析、ASIL等级划分、安全机制设计与验证流程。但AI模型进来以后这条链路断了一截。假设你用一个基于深度学习的视觉感知模块做行人识别模型没有“断线故障”它可能只是在一个奇怪的天气、一个被遮挡的角度下没有输出正确的边界框。这不是传统意义上的硬件失效也不是软件逻辑错误而是“性能不足”或者“能力边界之外”的行为。你有没有发现传统HARA分析里最擅长的“失效模式清单”忽然没法填了你没法枚举一个神经网络所有可能犯错的形态。这就像你以前管理一支纪律严明的队伍每个人都有自己的岗位说明出了问题你能找到是谁违规现在却来了一批“创作型”员工他们大多数时候表现很好但偶尔会给出你完全无法预测的反应而你又不能因为他们偶尔失常就把整个部门停摆。这不是说AI不该用而是说过去那套建立在“行为可预测”之上的安全分析方法必须补上一套面向不确定性的新方法。1.2 风险场景从有限变成无限做功能安全的人对“场景”都不陌生。传统做法里有一项重要工作叫“场景分析”列出这个系统会在哪些条件下运行哪些条件可能导致危险然后针对这些场景定义安全目标。过去这条路还能走通因为场景数量是有限的。一个转向系统你可能分析几十个使用场景就差不多了。但到了智能驾驶场景数量彻底失控。开放道路上有不同的天气、光照、交通参与者、道路施工、突发异常这些条件组合起来几乎是天文数字。更麻烦的是AI系统处理能力再强也总会有它没见过的长尾场景。99.9%的时间都稳如老狗偏偏剩下那0.1%才是事故真正发生的地方。工业领域同样如此。最近我在帮一个做PLC的企业做评估他们已经尝试用大模型辅助生成控制代码。传统PLC代码安全审查可以一行一行看因为每一行逻辑都是工程师写的但AI生成的代码呢你让它生成一百个功能块它可能九十九个都正确唯一那个有问题的功能块恰好对应了一个极其冷门的工艺工况。这种“冷门工况”组合出来的场景靠人工枚举是永远覆盖不完的。所以“场景无限”这件事不只是数量变多而是从根本上改变了安全验证的方式。过去是“我们列完场景证明我覆盖了”现在必须变成“我们不知道全部场景所以要设计一套在未知场景下也能兜底的安全机制”。1.3 标准在更新但方法学还没跟上很多朋友会问标准不是越来越多了吗ISO 26262讨论了机器学习相关话题ISO 21448专门解决预期功能安全ISO/IEC 23894也讲了AI风险管理怎么还说方法没跟上标准给了方向但离落地还有很大距离。ISO 26262说到底还是一个基于V模型的确定性开发范式它对机器学习模型的训练数据、模型验证、在线监控这些环节只是开了口子没有给出具体的操作指南。ISO 21448解决的是“没有故障但功能不足导致危险”这确实贴近AI感知问题但它的方法论依然偏重场景列举和验证策略对“数据漂移怎么监测”“模型版本如何做安全回归”这类实际问题仍然需要从业者自己去摸索。ISO/IEC 23894更像是一份AI风险管理的地图告诉我们有哪些山头要走但路还是要自己修。这就是我说“值得重做一遍”的原因标准框架已经承认了AI带来的新问题但真正能指导一线工程师做安全分析的详细方法还处在行业自己拼杀、自己沉淀的阶段。谁能先把这套方法跑通谁就在下一轮竞争中占了先手。2. AI时代功能安全需要重构的五个关键点2.1 安全目标从“规则推导”变成“场景挖掘”传统安全目标怎么来的从一个功能失效的危害出发通过HARA分析推导出安全目标比如“当车辆速度高于30km/h时AEB功能不能漏报正前方行人”。道理没问题但落到AI系统上最大的变化在于你很难一开始就把该防的场景穷举干净。你定义了一个“正前方行人”的目标但实际危险可能出现在行人被车辆部分遮挡、行人穿着全黑衣服夜间过马路、行人突然从静止车辆后方跑出等更细的场景里。这些场景不是靠几个人坐在会议室里头脑风暴能想全的。我团队现在的习惯是“用数据挖掘场景再用场景反推安全目标”。先拉取大量自然驾驶数据、事故数据、边缘场景数据用聚类算法把相似场景归并再用安全工程师的判断去筛选哪些场景需要变成安全目标。这个过程里传统HARA的“AT”表格依然有用但它的输入不再只靠专家经验而是靠数据挖掘和仿真生成的候选场景。换句话说安全目标不是“想”出来的而是“挖”出来的。做AI功能安全如果还只会开一场HARA研讨会就算完成任务项目后面大概率要返工。2.2 安全从软件属性升级为架构属性过去我们设计安全机制常常是围绕某个ECU或某个软件模块展开的传感器坏了有自检控制器坏了有看门狗。到了AI系统这些局部机制依然需要但远远不够。深度学习模型没有明确的“失效模式”你没法给它写一个完美的自检程序就像你没法让一个员工自己发现自己什么时候会突然犯傻。这时候真正的安全保证必须来自架构层面。我常跟团队说一句话不要指望AI永不犯错要假设AI一定会犯错然后让系统在它犯错时仍然安全。这句话落到架构设计上就是两个关键词隔离和冗余。隔离是指不能把AI模型放在不可替代的核心安全链路上。冗余是指除了AI主路径之外要有一条独立的安全监控或降级路径。比如自动驾驶在感知层可以用视觉AI做主要目标识别同时用毫米波雷达数据和基于规则的目标验证模块做交叉检查。决策层也一样AI负责规划流畅的行驶策略但旁边有一个独立的安全监控器用简化的规则模型判断AI的决策是否越过了安全边界。一旦越界立即触发降级或最小风险状态。这套思想并不玄乎本质上跟传统安全里的“故障容错”一致只是现在容错的“错”不再是某个硬件坏了而是AI模型输出了一个不合理的结果。把这个逻辑想清楚再去看架构设计就知道该怎么画框图了。2.3 数据和模型版本是新的安全证据传统功能安全项目有一个很重要的交付物叫“安全案例”里面装满了需求追溯矩阵、设计文档、测试报告、评审记录。考官审计的时候你要能拿出证据证明“我说安全是有依据的”。到了AI时代证据清单里必须多出一类东西数据层面的证据和模型层面的证据。数据证据包括训练数据的来源、采集条件、标注质量、数据分布覆盖度。模型证据包括评估指标、在不同子集上的表现、对输入扰动的鲁棒性分析、模型版本变更记录。我经常把这个组合称为“模型安全护照”一个模型要进入量产必须带着这本护照过安全评审。有一次我们评审一个感知模型算法团队说指标很好mAP到了0.92行人检测召回率也不错。但安全团队把测试集按“白天/夜晚/雨雾/逆光”拆开一看发现夜间雨天的召回率掉了近20个百分点。安全工程师当场就拍桌子了因为自动驾驶在晚上下雨遇到行人的场景就算不是最高频也绝不该是性能洼地。后来算法团队重新补了夜间雨天数据、调整了模型才通过评审。这就是数据证据的价值只看一个总指标永远发现不了安全问题。安全评审必须学会“拆数据”把模型指标拆到场景维度、条件维度去看。2.4 AI Agent和生成式AI改变交互边界这两年AI Agent特别火很多团队已经在尝试让大模型不止于聊天而是真正去调用工具、修改代码、操作业务系统。这事听起来很酷但对功能安全来说是个需要高度警惕的新变量。传统软件交互是“输入固定输出可枚举”比如用户点了保存按钮程序执行保存逻辑。AI Agent却可以在一次会话里自主拆解目标、调用多个工具、甚至中途改变执行路径。它面对的“输入”不是一条指令而是一整个上下文里面可能藏有恶意指令、错误前提、上下文污染。这些问题反映到安全分析里你会发现原来的失效模式列表根本不够用。我的建议是对AI Agent的安全管理优先做“权限隔离”和“行为边界”控制。不要给Agent一把万能钥匙让它能访问所有系统。给它一个受限的工具集把高风险操作和不可逆操作单独拎出来必须走人工审批。同时为Agent的每一步关键动作设计审计日志出了问题至少能回溯。这个思路和安全里的最小权限原则、纵深防御原则完全同源。AI Agent再聪明也必须在清晰的边界内运行。功能安全不是要限制AI的能力而是确保它的一切能力都被约束在一个“出了问题也能交代”的框架里。2.5 人机协作的安全边界重新变得重要前几年大家讨论自动驾驶最喜欢问的一个问题是“什么时候人能放手”。但到了AI渗透到各个行业的今天这个问题其实变成了更普遍的形式人类把任务交给AI时交接边界在哪里谁对最终结果负责功能安全领域有个概念叫“安全相关的人为因素”过去主要研究驾驶员、操作员会不会疲劳、误操作。AI时代人机协作的边界变得更加动态。比如L2辅助驾驶系统可以长时间自己开但需要驾驶员保持监控并在必要时接管。这里面最危险的不是AI完全失控而是AI和人都以为对方在看路。我自己见过一个很典型的案例某个项目里AI辅助编程工具帮工程师生成了控制逻辑工程师因为太信任工具的产出没有仔细审查例外分支结果一个异常工况处理被漏掉了。后来做安全复盘的时候我们发现真正的问题不是AI写错了代码而是“AI生成代码 工程师过度信任”这个组合让本来应该有的质量关卡失效了。所以在AI项目里做功能安全必须把人机协作流程本身当成安全分析对象。要明确什么时候人的判断是必需的什么时候AI的输出必须被人复核什么时候可以放权。把这个边界写清楚写进SOP比给AI加一百个技术限制更有用。3. 实操路径在新项目里落地AI功能安全3.1 第一步先划边界哪些功能允许AI介入接到一个新项目我通常不会一上来就谈模型选型或数据指标而是先拉着产品、算法、系统、安全团队开一场“边界会议”。会议的核心议题只有一个这个系统里哪些功能允许AI介入介入到什么程度。为什么要先做这一步因为AI的性质决定了它只适合用在“非完全安全关键”或者“有强兜底”的场景。如果你让AI直接承担一个没有冗余的安全功能那你不管后面怎么做验证都很难给安全评审一个让人信服的交代。与其后面返工不如在前面就把边界划清楚。我们常用一张“AI能力边界表”来落地这件事功能模块是否允许AI介入AI参与程度推荐安全策略环境感知允许高负责目标识别多传感器交叉验证 感知监控驾驶决策允许中负责策略建议规则安全监控器 最小风险状态制动执行不允许无保留独立机械/逻辑备份代码生成允许但需审查低生成初稿强制人工评审 自动化静态检查边界表定下来之后后面所有安全活动都以它为前提。算法团队知道了哪些功能必须“做到安全里”系统团队知道了哪些地方必须“额外加保险”。3.2 感知模型的SOTIF安全分析怎么开场边界划完之后接下来最重要的是对感知类AI模型做SOTIF预期功能安全分析。很多人问第一步干什么我的回答是先定义运行设计域也就是ODD。你说的“这模型很安全”是在什么条件下安全晴天、城市道路、车速不高于60km/h还是得加上“有车道线、无施工、无极端天气”这些前提ODD定义得越清后面的安全分析就越实在。定义好ODD再按这样一个顺序往下走第一步识别“已知不安全场景”。把历史事故、路测报告、公开数据里出现过的、和你的感知功能强相关的场景全部拉出来整理成清单。这是安全分析的传统工夫AI时代依然需要。第二步识别“潜在不安全场景”和“未知不安全场景”。这一步靠的是场景挖掘和专项测试。我们通常会设计一批“边缘场景测试集”覆盖遮挡、逆光、雨雾、夜间、异形车辆等条件看模型在哪些条件下性能显著下降。与其空想模型会不会出错不如直接拿数据说话。第三步为每个风险场景定义“性能触发条件”。比如“行人检测输出的置信度低于0.7”或者“目标轨迹预测的误差超过1.5米”。这些条件不是随便拍的而是通过仿真、场地测试和实际路采数据标定出来的。第四步把性能触发条件连接到安全机制。一旦触发系统要做降级、重新规划或安全停车这就是前面说的“最小风险状态”。SOTIF分析和功能安全机制设计到这里才算接上头。我跟过太多项目团队容易在第二步就卡住因为“未知场景”听起来很虚。破局的办法就一句话别试图找完所有未知场景先把你已知的高风险场景做透做出防御性设计你就已经比大多数项目安全了。3.3 用安全监控层兜底设计一个最小冗余闭环很多智能系统做安全设计时喜欢把所有东西都堆在AI模型上让模型更准、更鲁棒、更能抗干扰。方向没错但依赖模型自身的进步来保证安全就像把全部存款都买了同一只股票风险太集中了。我更愿意在设计阶段就放进一个独立的“安全监控层”。一个最简单也最实用的架构是这样的主路径感知模型输出目标信息 → 决策模型输出控制指令 → 执行器执行。这是AI负责“干活”的部分。监控路径一个独立的、基于规则和物理模型的安全监控模块同时接收感知结果和控制指令不断检查两个问题这个控制指令在当前车速、当前距离下是否安全感知输出是否明显违背物理常识比如目标位置跳变、速度瞬间不连续一旦监控模块发现异常立刻触发降级或安全接管。这个监控模块不需要很智能它的最大优势恰恰是“简单、可解释、可验证”这种特性让它可以接受功能安全标准里最高级别的审查。在功能安全里这条路叫“独立安全监控”和你签合同要请一个不相干的第三方审计是一个道理。别让AI既当运动员又当裁判员。关于时间预算我建议在项目初期就做一个简单的FTTI故障容错时间间隔估算。比如一辆车以80km/h行驶检测到前方静止障碍物距离100米要避免碰撞留给系统反应的时间大约就是4.5秒。感知模型推理200毫秒、决策模型推理100毫秒、执行机构响应300毫秒加一起600毫秒左右那安全监控的检查周期就得设置在几百毫秒以内而且要给执行留出足够的余量。这种算法不需要高级工程师但需要每个人心里都有这根弦。3.4 安全档案与可追溯性AI项目管理的新习惯传统汽车功能安全做得好不好审计的时候一目了然需求能不能追溯到设计设计能不能追溯到测试测试能不能追溯到用例。AI项目如果也按这个思路做事情就会清晰很多。我们现在的做法是为每一个AI感知或决策模块建立一份“AI安全档案”内容至少包括模型版本与训练数据版本精确到具体的commit号使用的训练数据分布、采集环境、标注规范模型评估结果按场景维度和条件维度拆分的关键指标专项安全测试报告包括边缘场景、鲁棒性测试、对抗样本测试已知风险清单包括模型在哪些场景下性能不足建议的安全机制是什么变更记录任何一次模型迭代都要附带安全回归结论。有了这份档案每次评审就不再是“猜模型行不行”而是“看证据够不够”。曾经有个项目在发布前换了一版更“准”的模型准确率涨了但某个低概率场景的漏检率也涨了。如果没有安全档案里的专项测试这个风险很容易就被“整体指标变好”给掩盖了。后来我们靠着档案里的逐场景对比表硬是在发布前把这个问题拦了下来。这件事做起来不复杂难的是坚持。只要数据团队、算法团队、安全团队都把“留痕”当作日常而不是发布前补作业AI功能安全就没有想象中那么不可控。4. 实操中容易踩的坑与排查技巧4.1 “先把AI做出来再补安全文档”是最贵的坑我在项目评审里听到最多的一句话是“我们先把功能跑通安全文档后面再补。”这句话乍一听很务实实际上是个隐形炸弹。AI系统的安全属性不是后期能“补”出来的它长在数据和设计里。你后期可以补一份报告但你补不了已经发生的数据质量缺陷也补不了已经定型的不可控架构。就像你请人盖了一栋楼盖完再让结构工程师做抗震验收他最多给你出一份整改意见不可能改变已经浇进混凝土里的钢筋布局。所以AI项目启动的第一天安全团队就要在场哪怕只是先参与数据采集规范和数据质量评审。4.2 总指标好看并不能说明系统安全这是一个反复出现的误区我甚至觉得要把它当成一条行业教训来传。一个模型mAP高、准确率高只能说明它平均表现好但安全事故恰恰是长尾场景里的“极端个例”不是平均。指标越高越要警觉它是不是被大量简单场景撑起来的困难场景有没有被平均掉在这方面我建议团队做两个习惯动作。第一所有关键指标必须按场景、环境、光照、目标类型拆分查看不允许只看一个总表。第二每个模型版本发布前安全团队指定一个“红队测试集”里面全是被标记为高风险但不容易被常规评测覆盖的样本模型必须在这个测试集上达到安全阈值才可以放行。4.3 功能安全工程师和算法工程师互相听不懂这个沟通断层在很多项目里都是隐患。安全工程师问“这个模型的失效模式有哪些”算法工程师回答“它的loss收敛了准确性很高”。两边各说各话做了半天评审实际没有产生任何安全价值。后来我学到一个比较见效的办法让算法工程师和安全工程师一起做“事故场景复盘”。挑几个典型的事故案例或者高危险场景让算法工程师解释为什么模型可能会在这个场景下失效再由安全工程师翻译成安全分析里的DFMEA条目。一旦做上两三次两边就自然建立起一套共同语言。这里的关键是别让安全团队坐在办公室里空想AI风险也别让算法团队埋头调参不管边界。工程上的事只有在工程现场才能真正对齐。4.4 一个实测有效的排查流程最后分享一个我自己在AI安全事故/安全事件排查时反复使用的流程很多项目团队拿过去改了改就能直接用第一步事件复现。用同样的输入数据重新跑一遍模型确认问题是随机扰动还是稳定可复现。如果可复现直接把复现用例存进回归测试集。第二步数据归属。判断出问题的输入是否落在已定义的ODD之内。如果在ODD之外这属于ODD边界管理问题如果在ODD之内则属于模型性能不达标性质更严重。第三步安全机制检查。回看监控层和降级机制有没有及时触发。如果没触发优先排查监控层的阈值设置、采样频率、判断逻辑哪里出了问题如果触发了但结果仍然危险要反思冗余设计的深度是否不够。第四步日志追溯。检查当时模型输出的置信度、中间特征、决策日志定位是在哪一层出现的偏差。没有日志就靠回忆复盘在AI时代基本等于没法做安全分析。第五步更新安全档案。无论事件最终结论是什么都要把案例、原因、处置措施更新到安全档案中并且把相关测试样本加入回归集。这是我唯一强调“必须做”的步骤因为它决定团队会不会在同一条沟里翻两次。这套流程一开始会比较费时间尤其第一次做要到处找数据、补日志。但坚持跑过几个项目之后它就会变成团队的本能反应而且每一轮复盘沉淀出来的测试样本都会成为下一版模型安全筛选的宝贵弹药。做了这么多年安全我越来越觉得AI时代的功能安全不是把旧标准翻译成新口诀而是要像第一次接触HARA分析那样重新认真对待不确定性。传统安全教会我们的是“把已知故障管住”AI安全则要求我们同时学会“与未知的不确定性共存”。如果非要我用一句话总结这段重做一遍的心得那就是安全验证不能等模型训练完才开始从数据采集阶段就要介入。这也是我这个系列想传递的第一件事。关于工具链怎么选、具体标准条款怎么落地、下篇要展开的案例我后面找时间专门写。AI功能安全这个题目说大很大说小也小——它无非是在轰轰烈烈的智能化浪潮里把“这事儿要是出错了怎么办”想清楚。能把这个问题想清楚的人无论做什么行业大概都能走得更稳。