企业官网建设流程全解析

上一篇我们把 ISO/PAS 8800 这份标准的定位和整体框架做了梳理，算是把“这张图”铺开了。今天这一篇，我想回到最容易被忽略、却最能决定你能不能把标准读进去的地方——术语。如果你刚接触 AI 安全，还没搞清“AI 元素”和“AI 系统”到底是什么关系，也不知道“验证”“确认”在 ISO 26262 语境下为啥不能混用，那这一篇就是专门给你写的。别急着翻后面的条款，先把“黑话”对齐，后面所有安全活动、评审、审计才聊得下去。

1. 为什么“黑话”必须先行——先从标准的整体逻辑说起

1.1 术语章节在标准里的“承重墙”作用

ISO/PAS 8800:2024《道路车辆 安全与人工智能》虽然是一份 PAS（Publicly Available Specification，公开可用规范），但它的结构完全可以看成一份功能安全标准的扩展版：范围、规范性引用、术语和定义、概念框架、安全活动要求、系统/元素级别的验证确认，一路铺下来。

很多人读这种标准喜欢直接从安全要求章节开始，觉得术语部分就是几张看起来“差不多”的解释，随便翻翻就行。这个想法非常危险。因为 ISO 系列标准天然是“定义驱动”的，后面每一个要求条款都会反复引用前面的术语。比如安全目标、安全要求、残余风险、验证、确认、AI 元素这些词，如果理解不一致，后面审查的时候就是各说各话。

我举个最实在例子：供应商跟你报方案，说“我们的感知模型已经过了验证，精度达到 99%”。结果上车一测，发现所谓“验证”只是拿训练集又跑了一遍，跑出来的指标当然好看，但对新场景没有任何参考意义。这就是“验证”（verification）和“确认”（validation）没对齐导致的典型事故。在 ISO 26262 和 ISO/PAS 8800 的体系里，验证是“有没有把东西做对”，确认是“做出来的东西是不是该有的东西”，两者阶段不同、证据不同、目的也不同。术语定义不统一，后面全是坑。

所以我把术语叫作标准的“承重墙”：它不直接给你技术参数，但所有技术要求都靠这些定义支撑。在这堵墙上打洞，整个结构都要出问题。

1.2 术语不齐的现实危害：从开发到仲裁都没法聊

可能有人觉得，术语不齐顶多是沟通不畅，过不了审核再改改文档就行。真不是这样。当一套安全标准被用于产品量产前的安全评估，乃至后续质量仲裁时，术语的边界就是责任的边界。

举几个我实际见到的画面：

• 算法团队说“这个模型在雨天表现不好”，安全部门问“这是故障还是性能局限？”两边吵了半天，才发现算法团队把“雨天表现不好”理解成“偶发噪声”，安全部门把它理解成“已识别的功能不足，需要进入危害分析和风险评估”。同一句话，两种含义，问题严重性完全不同。
• 项目经理在评审会上问“这版系统的残余风险是不是已经可接受了？”算法负责人回答“我们测试都没发现严重问题，所以可接受”。这两个“可接受”完全不是一回事。前者要求有明确的风险接受准则、有残余风险论证、有决策记录；后者只是“还没测出问题”。
• 供应商交付时写“模型已完成确认”，主机厂审查时发现他们做的只是常规测试，并没有按真实运行场景做确认。合同里的一个“确认”，让两边拉扯了两个月。

这种问题不是靠换一个认真的人就能解决的，它根子出在组织没有一套公共的术语基线。所以读 ISO/PAS 8800 时，很多人只盯着 ASIL、安全目标、感知模型那些“大词”，但我建议你真把第一遍精读的时间花在术语表上。有时候一个定义没吃透，后面所有场景分析都可能跑偏。

2. 核心术语拆解：AI 元素、安全状态、失效与故障

2.1 什么是“AI 元素”——先搞清楚边界在哪

ISO/PAS 8800 里有一个非常关键的概念：AI 元素（AI element）。它不是一个玄乎的哲学概念，而是安全分析和安全要求分配的基本单元。你可以把它理解成：在某个安全相关功能中，使用人工智能技术实现的那部分组件或子系统。

为什么标准要专门定义“AI 元素”，而不是直接说“AI 系统”？因为在实际车辆架构里，AI 很少作为一个孤立的“系统”存在。自动驾驶功能往往是感知、预测、规划、控制等多个模块协同工作，其中一部分用传统规则算法实现，一部分用神经网络实现。只有把用 AI 实现的那部分单独切出来，才能精确分析它对整车安全目标的贡献和影响。

这个思想跟 ISO 26262 里的“元素”（element）概念是一脉相承的。ISO 26262 要求把“相关项”（item）拆成系统、组件、元素，逐层分配安全要求。AI 元素就是这种拆解在 AI 技术上的落地：你得能说清楚这个 AI 元素输入是什么、输出是什么、在什么条件下运行、发生什么表现会导致危险。说不清楚这些，安全分析就没法往下走。

另一个值得强调的点：AI 元素不单单指“神经网络模型”。它通常还包括数据预处理、后处理、推理环境、输入输出接口等。安全工程师跟算法团队核对时，如果只说“这个模型是 AI 元素”，那就把边界画窄了。输入图像分辨率一变、传感器标定一偏、预处理逻辑一换，AI 元素的行为就可能完全不同。所以标准里使用 AI 元素这个整体视角，就是提醒你别把模型从工程环境里单独拎出来讨论。

2.2 “失效”“故障”“功能不足”——字眼差异就是责任差异

在传统功能安全里，故障（fault）、失效（failure）是有严格递进关系的。故障是“系统或部件中的异常状态”，失效是“系统或部件不能执行要求功能的行为状态”。AI 出现后，情况又变得更复杂，因为 AI 的“失灵”很多时候不是硬件坏了，而是模型在某个分布下能力达不到预设水平。

ISO/PAS 8800 体系里特别值得注意的一个表述是“功能不足”（insufficient functionality / performance limitation）。什么意思呢？就是说，AI 模型在特定场景下没有输出系统设计时预期的性能。它可能不是崩溃，也不是计算错误，而是精度不够、响应不及时、边界情形识别不了。这种“不足”跟传统意义上的失效还不完全一样：传统失效是可以被明确判定为对或错的，而 AI 的能力不足往往是一个程度问题，需要定义性能阈值才能判定。

我做一个简单的对照，方便大家理解：

为什么这个区分很重要？因为安全目标的分配方式不同。如果问题被定性为“失效”，你就要走失效的缓解措施，比如降级、握手、安全状态切换；如果被定性为“功能不足”，你可能还需要回到数据层面，重新评估 ODD、补充训练数据、修改性能阈值。定性一偏，整个安全流程的方向就偏了。

2.3 安全不是“零事故”，而是“可接受的残余风险”

还有一个术语理解上的大坎：什么叫“安全”。外行很容易把“安全”理解成“绝对不出事”，但在工程标准里，安全从来没有绝对。ISO/PAS 8800 沿用了功能安全的经典逻辑，把安全定义为“不存在不可接受的风险”。这个表述最关键的是后半句——你得先定义什么叫“不可接受”，然后才有所谓“安全”。

这个概念在 AI 安全里尤其容易被误解。很多媒体说“自动驾驶不安全，因为它还会出错”，这就是用绝对安全的尺子在量一个不可能达到绝对安全水平的技术。我不否认 AI 存在大量需要解决的问题，但工程上的安全判断从来不是“会不会出错”，而是“出错后的风险是否可接受”“是否有合理的缓解机制”。

具体到 AI 元素上，这意味着两件事。第一，你必须在开发早期就定义清楚“可接受风险”的准则，例如每万小时失效概率上限、严重度、可规避性等。第二，你必须把残余风险论证纳入安全档案，而不是一句“AI 可能犯错所以不安全”就完事。术语不准带来的后果就是安全论证根本没有锚点。

3. 数据与分布的术语陷阱：训练集、验证集、测试集和漂移

3.1 三种数据集合别搞混：训练、验证、测试各管什么

进了数据这一环节，术语混乱程度会直接上升。多数算法工程师对“训练集”“验证集”“测试集”的区分非常清楚，但功能安全工程师和项目管理者往往并不清楚。结果就是在安全评审会上，大家在一个看似“常识”的概念上浪费大量时间。

简单梳理一下：

• 训练集（training data）：用于更新模型参数。模型在训练集上拟合得越好，不代表在新数据上表现越好，因为可能过拟合。
• 验证集（validation data）：用于模型选择和超参数调整。它参与模型开发决策，但不能用来证明最终性能。
• 测试集（test data）：用于评估最终模型的泛化性能。测试集应该是开发阶段没有参与训练和超参数选择的数据，它才是安全评估时相对可信的参考。

这个区分放到安全标准里，分量极重。因为 ISO/PAS 8800 这类标准非常关注“数据是否足够、是否独立、是否代表目标运行环境”。你如果拿训练集和验证集的指标去支持安全论证，审计人员大概率会直接打回。更隐蔽的问题在于，很多团队在数据清洗和增强阶段会无意中发生信息泄漏（比如把测试集图片做过增强后又参与训练），导致测试指标虚高。这种问题在术语定义阶段就会被带到项目流程里，不早做约束后面很难回头。

我做数据评审时特别在意一件事：测试集是否为“独立留存样本”。这里的“独立”，不仅指样本没有参与训练，还要求采样过程没有污染。如果数据增强、清洗、去重等操作发生在测试集划分之前，那么这个测试集的安全性评价就打折了。所以我要提醒一句，团队在立项时就应该把“数据版本”和“数据用途”写进安全计划，而不是等模型训完了再补一个测试说明。

3.2 分布漂移、概念漂移与 ODD：影响评估的关键词

AI 上车之后，数据不会停在那里不动。车辆每天在不同道路、不同天气、不同交通流中运行，数据分布一直在变。ISO/PAS 8800 和 AI 安全相关的标准里，最常见的词就是“分布漂移”（distribution shift）和 ODD（Operational Design Domain，操作设计域）。

分布漂移可以通俗地理解成“模型之前见过的输入长那样，现在环境变了，输入长这样了”。比如训练时用的摄像头是 A 品牌，量产时换了 B 品牌；训练数据集中在城市白天，量产时却跑到了北方的冬季傍晚。模型内在的逻辑可能没变，但输入数据的统计特征变了，性能就会掉。

概念漂移则更隐蔽：输入特征没怎么变，但输入与输出之间的映射关系变了。举一个和自动驾驶相关的例子：一个区域把某个路口的右转规则调整了，模型还按照旧规则学习到的映射做预测，就会出错。输入图还是那张图，但“正确输出”变了。这就是概念漂移。

ODD 这个术语解决了“模型在什么范围内保证性能”的问题。标准思路是：一个 AI 安全功能应该被限定在明确的 ODD 内运行，并在超出 ODD 时触发安全措施。换句话说，我们不是在要求 AI 在所有条件下都完美，而是要求它“在其承诺的运行边界内满足性能”，并在边界外被检测出来。

这里有一个团队协作层面的经验：ODD 不能只写在产品规格书的“设计适用范围”里，还必须成为功能安全和验证策略的一部分。测试场景要覆盖 ODD 的边界和边界外样本；运行监控要检测分布漂移指标；一旦漂移超阈值，就要触发再验证或者更新。只有把 ODD 跟数据指标、安全阈值绑在一起，术语才不会变成空话。

3.3 “关键事件”这个概念为什么绕不开

ISO/PAS 8800 在场景分析和安全评估里经常用到“关键事件”（critical event）这个概念。关键事件可以理解成：可能导致伤害的事件或事件链中的一个节点。它不是某个单一的“错误输出”，而是从环境状态、感知结果、决策行为到车辆状态的完整链条中，那个最可能把系统推向危害的点。

为什么这个概念重要？因为你不捕捉关键事件，安全分析就只能停留在“模型准确率 99%”这种没有工程意义的层面。真正要问的是：在什么场景下、什么样的输入组合中，模型发生某种输出，导致车辆进入危险状态？这需要对关键事件做系统性的识别和分类。

我见过不少团队把“关键事件”等同于“模型预测错误”，这其实是窄化了。一个预测错误如果不影响安全目标，那在功能安全语境下可能根本不算关键事件；反过来，一个整体上“准确率很高”的模型，可能因为对某个低概率高风险场景的失效而成为关键风险源。所以，关键事件要跟安全目标挂钩，而不是跟模型准确率挂钩。

4. 生命周期视角的术语：开发、运行、更新，一个都不能少

4.1 开发阶段与运行阶段不是按“上线”一刀切的

AI 模型的特殊性在于，它不像传统电子元件那样“开发完、装上车、跑到报废”，它的行为在生命周期内可能持续变化。因此 ISO/PAS 8800 在描述安全活动时，往往会区分开发阶段、运行监测阶段和更新阶段。

开发阶段主要的安全活动是：定义安全要求、收集数据、训练模型、验证确认、形成安全论证。这些活动相对容易理解，跟传统 V 模型流程有相似之处。但 AI 不一样的地方在于：运行阶段的监测数据会反过来暴露开发阶段没发现的问题。比如某个误识别只在高纬度地区长隧道里出现，开发时可能根本没覆盖到。

所以我会建议团队把“运行监测”当作开发阶段的延续。标准里对数据监测、性能监测、触发更新的要求，本质上是承认了“AI 模型无法在开发期穷尽所有场景”这个前提。如果项目团队还把 AI 当成“写完就固化”的软件，那生命周期术语用起来就会很别扭。

4.2 模型更新、再验证与配置管理

模型更新是个特别容易被“黑话”糊弄过去的环节。算法团队说“我们做了个小的微调，不影响安全”，这句话如果不落到术语层面，安全部门根本没法评估。什么叫“不影响安全”？你要拿出证据，这个微调改了哪些数据、哪些网络层、重新验证过哪些场景、对安全相关的性能指标是否产生变化，最后还要经过配置管理记录。

在 ISO 26262 体系里，配置管理和变更管理本身就是功能安全的重要组成部分。到了 AI 这里，模型版本、训练数据版本、预处理配置、测试场景版本这些都应该纳入配置管理。模型更新不是简单“记一个版本号”，而是在安全档案里留下一条可追踪的变更链。

我在实际项目里看到的一个典型问题：模型 A 测试时表现良好，但因为数据标注出了些错，团队重新清洗数据并微调出模型 B，B 在测试集上表现也还行，团队就直接替代了 A。结果到了整车的集成测试阶段，大家拿不出“B 与 A 相比，对安全目标的影响是否一致”的分析材料。如果一开始就把“更新”当成安全事件来处理，而不是当成普通迭代，这种问题完全可以避免。

5. 与 ISO 26262 等体系的术语关系——别把标准读成孤岛

5.1 安全目标、危险事件与 AI 安全要求怎么接上

ISO/PAS 8800 不是凭空设立的，它跟 ISO 26262 有明确的衔接关系。ISO 26262 定义了功能安全的整体框架，包括危害分析和风险评估（HARA）、安全目标、ASIL 等级、功能安全要求、系统设计、验证确认。ISO/PAS 8800 则在“AI 用于安全相关功能”的场景下，提供了更具体的要求和指导。

所以你看标准原文时，会反复看到“安全目标”“ASIL”“安全要求”“验证”这些术语。它们不是简单地借来用，而是要求 AI 相关活动也要嵌到 ISO 26262 的层级体系里。举一个最小例子：系统层面的安全目标是“避免车辆在非预期情况下越过车道边界”，那 AI 感知元素可能就要分配到“在 ODD 内正确识别可行驶区域”的要求，规划元素分配到“在感知异常时执行最小风险策略”的要求。这一层层分解，靠的就是共同术语。

这里我特别想提醒读标准的朋友：ISO/PAS 8800 并没有说“AI 可以取代功能安全”，而是说“AI 需要在功能安全的框架下运行”。所以如果你发现某个团队的文档里，大谈模型结构、训练技巧，但完全找不到与安全目标、ASIL、安全要求的映射关系，那这份文档大概率不符合标准的精神。

5.2 与其他标准文件的关系：UL 4600、EU AI 法案、国内标准

AI 安全的术语世界里，ISO/PAS 8800 之外还有不少“邻居”。比如 UL 4600 是关于自动驾驶产品安全的评估标准，它更强调安全案例（safety case）的构建，没有完全采用 ISO 26262 的 ASIL 体系。再比如欧盟《人工智能法案》使用了“高风险人工智能系统”等法律色彩更浓的术语，角度更偏产品合规和基本权利保护。

这些标准体系虽然都谈 AI 安全，但术语并不完全互通。我遇到过一个团队，把欧盟《人工智能法案》里“风险”的定义直接套到 ISO 26262 的 HARA 里，结果评审老师问“这里的风险有没有明确的概率与严重度组合？”团队答不上来——因为欧盟法案是合规框架，不追求量化概率。

我的态度是：ISO/PAS 8800 的优势在于它能跟 ISO 26262 的功能安全语言顺畅衔接。如果你的产品是要走功能安全路线、要跟整车厂的开发流程对接，那 ISO/PAS 8800 是最合适的“桥”。但如果产品更偏产品合规、伦理评估、监管报备，那也要同时学习其他来源的术语。重要的是，任何跨体系交流时，都要先声明“我这里所说的风险/安全/验证，采用哪个定义”。

5.3 为什么每个术语必须注明出处

从业这么多年，一个我心里越来越清楚的原则是：讨论 AI 安全，说“哪个词”远不如说“谁定义的词”重要。同一个“风险”，ISO 26262 强调的是危害事件发生概率和伤害严重度的组合；项目团队日常说的风险可能是“项目延期风险”；监管文件里的风险可能是指对基本权利的潜在侵害。这不是谁对谁错的问题，而是语境不同、度量方式不同。

所以无论是内部文档、评审纪要还是供应商接口协议，我都建议在关键术语第一次出现时标注来源：这里是采用 ISO 26262 的定义，还是 ISO/PAS 8800 的定义，还是公司内部项目管理定义。这样做听着繁琐，但能避免大量“鸡同鸭讲”。

6. 实战建议与高频误区：把术语真正用起来

6.1 常见误区速查与纠正

下面这些误区是我在各类 AI 安全评审中反复遇到的，专门整理出来，大家可以对照自查。

6.2 团队落地术语管理的实操清单

如果想让团队真正把术语用起来，我建议按下面这几步走，每一步都不复杂，但需要耐心。

第一步，建立“术语表即代码”的意识。把 ISO/PAS 8800 和 ISO 26262 中与本项目相关的术语整理成一张表，放进项目 Wiki 或者文档库，作为团队公共参考。这不是为了应付审核，而是让新人也站在统一起跑线上。

第二步，在评审会模板里嵌入术语定义检查项。比如需求评审模板中要求：安全目标是否引用 ISO 26262 的原始定义？AI 相关安全要求是否落到 AI 元素层面？验证/确认活动是否分别列出？模板一变，习惯才会变。

第三步，在供应商接口协议里明确术语约定。如果外部供应商交付材料中使用了“验证”“确认”等词，要求标注对应标准定义。不要觉得繁琐，这反而是把质量关口前移。

第四步，做一次内部术语对齐会。这个会不一定讲标准，而是让算法、安全、测试、项目管理几个角色分别用大白话解释几个核心术语。通常开到一半就会发现：大家理解差异比想象中更大。早点暴露，比后面出问题再对齐好得多。

最后，我再分享一个非常小但管用的经验：在每个安全相关文档的“定义”章节里，不要写一堆自定义名词，直接引用标准术语并标注来源。标准术语在审计时天然有权威性，自定义名词只会增加沟通负担。我自己写安全案例时，几乎只在不得不描述内部特定模块时才会新增术语，而且一定在首次出现时给出明确限定。

ISO/PAS 8800 的术语表篇幅不长，但它是一份标准里最不该跳过的地方。读懂定义，不意味着你能立刻解决所有 AI 安全难题；但读不懂定义，你连难题在哪里都精确描述不出来。把“黑话”对齐了，后面该谈技术谈技术，该谈管理谈管理，每一句讨论才有落点。