一万个热门模型中,仅15个提供安全文档:英国开源AI安全报告说了什么

报告要览｜第002期

当一个模型可以下载、修改和部署时，我们通常会把它视为更加开放。但对使用者来说，能够获得模型权重，并不意味着能够知道模型从何而来、使用了什么数据、经历过哪些微调，也不意味着能够判断其中是否存在已知漏洞。

2026年9月7日，英国数字、文化、媒体与体育部发布研究报告《开源软件与人工智能网络安全文献研究》（A Study of Cybersecurity Literature on Open-Source Software and AI）。报告由Srinidhi Vasudevan、Anna Piazza、Guru Krishna Ramakrishnan和Guido Conaldi撰写，系统梳理了开源软件与开源人工智能的安全证据，并对Hugging Face和GitHub上的相关材料进行了分析。

先说明报告的性质：这是一份英国政府委托的研究与分析报告，不是法律、政策文件或强制性标准。报告提出的是政策建议，不能理解为英国已经建立了新的开源AI监管制度。

一项醒目的发现：一万个模型中只有15个提供安全相关内容

报告最值得关注的数据来自对模型和代码平台的分析。

在Hugging Face下载量最高、采用宽松开源许可的1万个模型中，研究人员首先通过关键词筛选出218个可能涉及安全问题的模型，进一步核查后发现，只有15个模型的模型卡包含安全相关内容，占比不足0.2%。

这并不意味着其余9985个模型都不安全，也不能据此比较不同模型的风险高低。它说明的是，绝大多数热门模型没有提供足以帮助使用者开展安全判断的基本信息。

GitHub分析呈现出相似问题。研究人员检查了约2000个同时涉及人工智能和安全关键词的项目，其中只有131个包含与AI功能和安全实践有关的实质性内容。报告据此认为，在受监管领域，模型使用者往往难以仅凭现有文档判断一个开源AI组件是否适合部署。

在文献部分，研究团队从8个数据库检索到14,561条记录，经过筛选后纳入43项高相关研究。报告发现，既有研究更多关注模型部署后的对抗攻击、入侵检测和鲁棒性，却较少讨论模型在发布前如何训练、训练数据来自哪里、权重如何分发，以及模型应当提供哪些安全文档。

换句话说，当前研究已经积累了不少“模型受到攻击后怎么办”的知识，但对“模型以什么条件进入供应链”关注不足。

开放权重，不等于完整的开源AI

报告认为，治理开源AI首先面临定义问题。

传统开源软件主要围绕源代码展开，但人工智能系统还包括训练数据、模型权重、训练流程、微调记录和推理工具。只公开其中一项，并不能保证其他环节可以被审查。

报告归纳了三种常见理解：第一种以源代码是否开放为中心；第二种把可以下载模型参数视为开放；第三种则从供应链出发，考察代码、数据、权重和工具等整个开发链条。前两种便于操作，但都可能遗漏决定模型行为的重要信息；第三种覆盖更完整，目前却缺少成熟的制度和文档标准。

报告特别讨论了开放源代码促进会发布的《开源人工智能定义1.0》。按照这一定义，完整的开源AI不仅要提供代码和模型参数，还应提供足以理解和重现训练过程的数据资料。

基于这一标准，报告认为，一些通常被称为“开源”的模型实际上属于开放权重或部分开放系统。这里的重点不是否定开放权重的价值，而是提醒政策制定者：不同程度的开放会产生不同的安全条件，不宜用“开源”这一标签统一处理。

为什么传统软件安全方法还不够

开源软件已经形成了一套相对成熟的安全方法，例如依赖项扫描、漏洞披露、安全开发和软件物料清单。

软件物料清单类似一张“成分表”，用于记录一个软件产品包含哪些组件和依赖。当某个组件出现漏洞时，使用者可以迅速判断哪些系统受到影响。

开源AI沿用了大量开源软件基础设施，因此同样面对依赖混淆、恶意软件包、维护者账户被接管等供应链风险。但AI系统还增加了传统代码审查难以覆盖的问题：训练数据可能遭到污染，模型权重可能被篡改，微调过程可能引入新的脆弱性，模型发布后也可能缺乏可核验的来源信息。

这意味着，只检查代码是否安全并不够。即使代码没有明显问题，模型的训练数据、权重来源和后续修改过程仍可能影响最终行为。

报告提出了哪些建议

报告提出四个优先方向。

第一，建立可操作的分类体系。

政策制定者需要区分完整开源、开放权重和部分开放系统，并根据实际公开的内容配置相应义务。这样可以避免把所有带有“开源”标签的系统视为同一种治理对象。

第二，推进来源追踪和安全文档标准。

报告建议在软件物料清单的基础上发展人工智能物料清单，记录训练数据来源、模型谱系、微调历史、配置设置和已知漏洞。它的作用不是判断一个模型是否绝对安全，而是让采购者、部署者和审计人员知道自己正在使用什么。

第三，加强模型和代码分发平台的治理。

Hugging Face和GitHub已经提供模型卡、安全公告等工具，但相关信息主要依靠开发者自愿填写。报告建议政府与平台运营者讨论最低文档要求、贡献者核验和模型完整性验证；如果自愿措施长期不能改善信息缺口，再考虑公共采购条件、行业指引或监管要求。

第四，参与国际标准制定。

报告建议英国通过ISO/IEC JTC 1/SC 42、ETSI等渠道参与人工智能安全标准讨论，推动安全设计和来源透明等要求逐步形成国际共识。

需要强调的是，这四项内容仍是研究报告提出的建议，不是已经生效的法律义务。

报告也承认，目前的证据还不足以证明任何现有策略已经能够覆盖开源软件和开源AI的全部安全风险；部分安全工具虽然具有技术价值，但其能否在整个生态层面减少事故，仍缺少充分的实证研究。

真正的问题不是“要不要开放”

这份报告没有把开放与风险简单对立起来。

开放可以支持检查、复现和创新，但前提是使用者能够获得与安全判断有关的信息。如果只提供模型权重，却不说明训练数据、修改历史和已知漏洞，“开放”本身并不能转化为可审计性。

因此，报告真正提出的问题是：当模型以公共基础设施和供应链组件的方式被广泛使用时，谁负责记录它的来源，谁验证文件的真实性，谁向下游使用者说明风险，又由谁在模型发生变化后更新这些信息？

“一万个模型中只有15个提供安全相关内容”不是对开源AI安全性的最终结论，而是一个文档缺口的信号。它表明，开源AI治理正在从“是否允许开放”进一步转向“开放到什么程度、能否追溯、是否足以审计”。

只有当这些信息能够稳定生成、持续更新并被下游使用者核验时，开放才不仅意味着可以下载，也意味着可以理解和负责任地使用。

材料信息

• 报告名称：A Study of Cybersecurity Literature on Open-Source Software and AI
• 发布机构：英国数字、文化、媒体与体育部
• 发布日期：2026年9月7日
• 作者：Srinidhi Vasudevan、Anna Piazza、Guru Krishna Ramakrishnan、Guido Conaldi
• 材料性质：政府委托研究与分析报告