SAFE RFC：OSAA 的航空式 AI 事件交换机制是一份开放草案，尚未成为系统

2026年8月4日，随着Black Hat USA在拉斯维加斯开幕，Linux基金会发布了面向共享AI发现交换（SAFE）工作组的征求意见稿——这项提案建议各组织将AI安全事件与未遂事件上报至一个保密的共享渠道，从中集体吸取经验，并发布基于失败案例推导出的防御性控制措施。Linux基金会在公告中表示，该初稿由来自思科、CrowdStrike、Hugging Face、NVIDIA和红帽等联盟成员的贡献者共同编写。同日，该文件通过Open Secure AI Alliance的GitHub仓库开放社区评审。该条目未描述任何实际危害：它是一份政策记录，以info严重性等级和A级置信度归档入库，其主题是一项流程而非一起事件。该记录的严重性等级、置信度评级和来源列表收录于AI事件档案，与同期归档的其他条目并列。

草案要求成员报告四件事，并且不要追问原因。

八月的文本少谈辞令，对触发条件则有明确规定。在“报告契约”（Reporting Compact）这一标题下，它要求成员同意——作为取得成员资格的一项条件——一旦得知或合理怀疑其运营的 AI 系统出现以下四种情形之一，即须报告事件：未经授权访问、利用、干扰、滥用或修改第三方系统；通过逃逸或绕过沙箱、网络、身份、策略或工具边界，造成第三方影响；未经所有者同意访问第三方机密信息；或在运营方已知或合理怀疑该活动属未经授权或超出批准范围之后，仍持续探测、访问或修改生产目标。

接着是那句起主要作用的句子：“意图并不决定一个事件是否应当报告。认为某个环境是模拟的，或许可以解释一起事件，但并不能免除报告义务。”这一条款读起来是针对这样一种情形：系统运行在其操作者认为是封闭测试环境的环境中，并把实际基础设施当作演练的一部分——操作者对环境的认知或许可以解释该事件，但并不能免除报告义务。该草案还要求成员报告险肇事件，而不仅是已造成确认损害的事件，并在30天内提交初步的控制失效分析。

时限：立即、72 小时、四个工作日、九十天

草案中的通报表是其中最具象的内容，而第一行根本不是期限：必须立即告知直接受影响的组织。所有期限都从成员知悉存在合理理由怀疑发生可报告事件的事实之时起算——而不是从调查结束之时起算。下表照录自8月4日草案；10月修订版保留了相同的时限。

其中三行涉及告知其他人，四行涉及告知 SAFE 本身。这一区分很重要，因为该框架明确不是一种披露制度：草案称，“这些时间表并不取代供应商的任何义务，包括通知受影响方和客户（通过现有协调漏洞披露最佳实践），以及适用合同和其他法律义务所要求的通知监管机构或执法部门的义务。”SAFE 增加的是一项对一个并非监管机构的实体的平行义务——以及一个三层披露模型，其中只有最后一层，即公共安全报告，才旨在被广泛共享。

八月有八个控制层，十月有十一个。

评审围绕运营栈展开，而非仅围绕模型本身展开。八月草案列出了八个层级，并对每一层各提出一个问题：模型是否识别不确定性和停止条件；授权和环境假设是否明确；分类器、审批和操作限制是否有效运行；凭证、权限和执行是否受到约束；隔离和数据边界是否经过独立验证；操作人员能否实时检测并中断；升级路径和关停程序是否清晰；云、评估、数据或工具合作伙伴是否使假定的控制措施失效。

10月修订版标注日期为2026年10月21日，并于次日提交至代码仓库，新增了三个层面：服务路径、提交时刻的授权，以及贯穿一系列操作的工作流编排。它还将评审转变为一种分级评估，仅允许四种答案——通过、不通过、证据不足、不适用——并在其变更日志中声明，这些发现并不构成对系统整体安全性或法律合规性的确立。这一递进过程值得作为一份记录来读：它描述了作者们逐渐学会担忧的是什么——不是模型表现是否合规，而是作出回答的模型是否就是被配置的那个模型；操作落地时权限是否仍然存在；以及整个操作序列是否始终未超出最初设定它的范围。

航空，但究竟是航空的哪一部分？

这份记录自身的表述框架——一个以 NASA 的 Aviation Safety Reporting System 为蓝本的系统——遵循的是 Linux Foundation 的公告，而不是草案。公告将 ASRS 描述为“一个自愿、保密的报告系统，旨在以让业界能够学习并改进的方式分析并应对飞行事故”。8 月草案和 10 月修订版均未在任何地方提到 ASRS；草案只表示，SAFE“应采用保密安全报告系统的最强特性”。这是一个虽小却具有实际后果的差异：公告设定了一项文本尚未承诺的预期。

这一类比在RFC流程内部本身也引发了评论。8月5日，一位以个人身份撰写的贡献者提交了一个早期的拉取请求，认为“ASRS类比缺少一个制度性要素”——ASRS之所以能在很大程度上奏效，是因为报告由NASA接收、处理和去标识化，“一个公共的、非监管且非商业的第三方——而不是作为监管者的FAA，也不是其运营正被报告的那些航空公司”。该拉取请求还借鉴了1998年的互联网治理进程，截至10月30日仍处于开放状态。SAFE的运营方能否扮演NASA的角色，仍是一个悬而未决的设计问题，而非已定型的特性：10月的文本将工作组置于联盟自身治理之下，并设有利益冲突披露、回避以及向联盟指导委员会申诉的渠道。

独立报道得出了第二个更为狭窄的区分。Infosecurity Magazine 在8月6日的报道中指出，Linux Foundation 的文章并未具体提及 AI 智能体——智能体（agentic）这一框架属于 NVIDIA 的配套文章，该文主张"AI 智能体不只是一个模型。它是一个系统"，并列举了联盟成员贡献的测试框架、沙箱、防护栏和评估工具。若按字面理解，草案中的触发条件针对的是系统在授权范围之外行事；而若按字面理解，公告的卖点则是关于智能体。

评论者关于由谁承担成本的说法

针对现有草案文本已公开的最具体反对意见之一，来自联盟的一位创始成员，而不是外部批评者。Avondale.AI 创始人兼首席技术官 Stephen Sargent 于8月7日通过电子邮件提交了一份立场声明——文件称 Linux Foundation 的法务团队就在这一天确认了该声明——并于8月9日将其公开发表。他开篇先支持这一使命，随后论证该协议没有按组织规模做可扩展性区分：“RFC 没有区分拥有5万名员工的组织和一个小型团队。”在他看来，一份耗时四个工作日的报告加上保全的取证数据包，可能占用的员工时间超过小型运营者所能腾出的时间；他建议采用分层框架，在规模阈值以下默认采用保密报告以及延迟发布或匿名发布。

第二个反对意见涉及的是披露而非截止期限：他认为，对小型运营者而言，“公开披露本身就是一种执法形式”，因为大公司的报告只是一个脚注，而小公司的报告却会成为头条新闻；他因此请求将低于某一规模阈值的默认做法设为去标识化报告。第三个意见涉及的是审查框架而非时限：八层模型假定企业团队是分隔设置的，因此在单人部署中“运营者包办一切”，缺失的一层就会被解读为控制失效，而实际上这只是一种不同的运营模式。他的第四点意见针对的是“最低互操作性与保证实践”这一措辞，他将其解读为一条从自愿报告通向事实上的强制性工具的道路。该立场声明是一位成员的观点，由该成员发布。Linux 基金会的 8 月 4 日公告早于该声明，且并未回应这一问题。一份后续的拉取请求于 10 月 5 日提交，至 10 月 30 日仍处于开放状态，它为没有安全运营中心（SOC）的运营者提出了一份证据模板——这既是对该关切已被采纳的承认，也是一个候选方案而非已采用的修复措施，其作者声明该模板“并不确立 SAFE 的采用或法律充分性”。

8月4日至10月30日之间发生了什么变化？

这个代码仓库的历史是关于 RFC 实际产出了什么的最佳现存记录，而且它比新闻报道所暗示的更清晰易读。首批提交出现在 8 月 3 日；草案和一份扩充后的 readme 于 8 月 4 日 00:14 和 00:19 UTC 被提交。随后该仓库沉寂了十周。10 月 14 日，该联盟添加了一份章程和一个成员文件，并重写了 readme，使该仓库成为 SAFE 工作组的所在地；当天的临时主席记录为 NVIDIA 的 Paul DiOrio 和 Red Hat 的 Josh Boyer。10 月 21 日，该工作组发布了 SAFE v1，其变更日志的第一条是，文本“从 SAFE 的描述中移除了‘proposed’”，并将其确定为一个已成立的 Alliance 工作组。

关于这一状态，有两点值得分开来看。该代码仓库的 readme 目前写有这样一句：“状态：已批准——由指导委员会批准”，这是公开记录中最接近批准声明的内容；而同一仓库中的章程却仍写着“制定中。SAFE 章程在获得指导委员会批准后将在此发布。”变更日志把十月的那份文本标注为“SAFE v1”，并描述了它改动了什么，却没有说明是谁批准的、经过何种表决、在什么日期批准。读者若想弄清楚 SAFE 现在究竟是一项已获批准的规范，还是一个治理章程尚未成文的工作组，从这些文件里得不到明确的答案。

什么是已确立的，什么不是

• 已确立：Shared AI Findings Exchange 的征求意见稿于 2026 年 8 月 4 日发布——Linux Foundation 将其公告日期定于该日——其中被列为贡献者的组织有 Cisco、CrowdStrike、Hugging Face、NVIDIA 和 Red Hat，它们与“Open Secure AI Alliance 的其他成员”一同具名。

• 已确定：草案包含一份带有四项触发条件的报告契约、一张从即时到 90 天的通知时间表、一份证据保全清单、一个分层审查框架，以及一个三级披露模型。全文已在仓库中公开，其历史记录也一并公开。

• 已确认，但仅有来源归属：该联盟的规模——“超过120个组织”——是NVIDIA自己的数据，仅在《Infosecurity Magazine》8月6日的报道中被重复引用。在已查阅的所有报道中，均未发现独立的成员资格审计，而该仓库的成员文件列出的只有两名贡献者和两名临时主席，并非120个组织。

• 尚未证实：有人已根据该契约提交报告。10月30日的公开记录显示了提交、拉取请求和议题；它并未显示事件报告、试点、首例、评论截止日期、投票规则或批准日期。该框架将成员作为成员资格条件而“同意”承担的一项义务加以描述，这与任何人迄今已履行的义务并不相同。

• 有争议的问题：在没有中立的公共运营方的情况下，ASRS 的对比是否依然成立——有人在一份公开的拉取请求中对此提出反对；报告负担对小规模运营方而言是否成比例——一位创始成员的立场声明中对此提出反对；以及该框架中有多少内容属于智能体专属、多少属于通用 AI 安全——Linux Foundation 的文本与 NVIDIA 的文本对这一区分有不同的划定。

这些都不能使记录出错，而且档案的 A 级评级按其自身标准是站得住脚的：原始文件在出版了什麼、何时出版以及由谁出版这些问题上彼此一致，而且草案可供完整阅读。评级无法承载的，恰恰是读者最想知道的事——该机制是否有效。对此无论正反都没有证据，因为该机制尚未有过案例。