迈向评估前沿AI安全防护措施以防范生物滥用的统一标准

迈向评估生物滥用前沿人工智能防护措施的通用标准 布瓦纳·苏达什兰，卢卡·里热蒂 执行摘要 前沿人工智能开发者越来越依赖安全措施来限制其模型的生物滥用风险。然而，目前尚无公认的方法来判断这些安全措施是否有效，如何在不同模型和部署中进行比较，或随着模型能力的提升应如何加强这些措施。本报告提出了七项建议以应对该问题，并勾勒了一个更全面的框架，可用于创建评估安全措施的标准。 我们提出了七项建议，围绕四个原则进行组织： 1.企业间可比性。报告针对通用基准的防护性能，需按生物风险类别细分，并标明对良性提示的误报率。统一报告防护鲁棒性——包括防护措施被绕过的难易程度，以及模型被绕过时的表现（建议1-2）。 需考虑部署环境。应针对每个主要的部署配置报告安全防护的充分性，而不是针对每个模型报告一次，因为同一个模型在不同访问层级和平台上可能会提供不同的安全防护措施（建议3）。 3.将安全措施视为动态。明确说明在能力层级中，随着生物提升的增加，安全要求如何得到加强。报告在出现新发现时，如何重新评估和更新安全措施的充分性（建议4-5）。 4.保留合法科学用途。随着模型科学能力的提升，为经过审核的研究人员引入可信访问程序。若模型级限制有所放宽，则应配套实施补偿性监管（建议6-7）。 这些建议可以立即采取行动，但它们并非评估保障措施充分性的完整路线图。目前的评估主要关注模型层面的保障措施，并未涵盖保障措施堆栈的所有部分，包括访问控制和部署后监控。我们概述了一个初步框架，旨在弥补这一差距，明确评估者在评估整个堆栈的保障措施时需要回答的问题。我们还勾勒了如何将这些维度的结果整合为复合的“保障级别”，为判断部署的保障措施是否足以应对不同威胁行为者提供依据。 此项工作代表其作者的观点，而非该组织的观点，且不构成法律建议。GovAI技术报告已收到广泛反馈，但尚未经过正式同行评审。 迈向评估生物滥用前沿人工智能防护措施的通用标准 1GovAI2OpenAI布瓦纳·苏达珊1，卢卡·里吉埃蒂2 引言 评估其有效性的方法仍远未成熟。有害生物输出。尽管公司正在采用和改进这些旨在防止用户引发有害生物输出的工具，但部署时仍配备安全措施：技术措施被部署以排除其模型可能为试图进行生物武器开发的初学者提供实质性帮助的可能性。因此，这些模型可能被用于具有重大军民两用潜力的领域。2026年国际人工智能安全报告，包括OpenAI、Anthropic和谷歌DeepMind在内的主要前沿人工智能公司报告称，他们无法排除其模型可能为试图进行生物武器开发的初学者提供实质性帮助的可能性。2025年，包括具有重大军民两用潜力的领域在内，前沿人工智能模型正变得越来越强大。 与模型权重安全等相邻领域不同（Nevo 等人，2024），目前尚无用于评估滥用防护性能的标准框架。虽然能力评估已趋同于使用公共基准（Epoch，2026）和报告（McCaslin 等人，2025），但防护评估相比之下则不够成熟，且更难评估其充分性（Clymer 等人，2025）。开发者报告称，他们使用不同的指标、方法和威胁模型来评估防护措施——例如拒绝基准和红队演练。有些仅提供防护性能的定性描述，而另一些则发布部分定量结果。此外，防护措施在不同部署中的差异也加剧了这一问题。同一模型可能通过第一方或第三方产品提供，并跨越不同访问层级，而这些层级的內容限制、监管和数据保留实践在当前公开报告中很少被区分开来。3 结果是形成了一整套无法进行有意义的审查或比较的评估。 这种缺乏标准化留下了几个重要问题悬而未决。不同模型或部署之间的安全防护性能如何比较？针对特定类型的威胁行为者，哪些安全防护措施是足够的？随着模型能力的提升，甚至在同一能力级别内，安全防护措施应该如何调整？没有这些问题的答案，就难以评估安全防护措施的有效性，也难以比较不同部署选择所实现的风险降低程度。 与此同时，前沿模型在有益的科学应用中正变得越来越有用（Kusumegi等人，2025；Ren等人，2025）。我们需要一种更系统的部署和评估保障措施的方法——这种方法既能体现伤害预防，也能反映过度限制合法使用的成本。 在本报告中，我们提出了七项建议，旨在改进开发者评估和报告生物滥用防护措施性能的方式（见表1）。落实这些建议需要两大转变。首先，开发者应像报告能力一样严格地报告防护措施。其次，第三方生态系统——包括人工智能安全研究所（AISIs）、评估者和标准制定机构——需要为防护措施评估建立专门能力，这包括超越标准能力评估的专业知识。 云服务提供商的实施角色仍然是一个悬而未决的问题，特别是在部署方面。上下文或访问条件会改变有效的保护堆栈。 表1中的建议可以立即采取行动，并会改进当前实践。然而，它们并非评估保障充分性的完整路线图。对保障性能的成熟评估还要求对当前发展不足或很少报告的保障堆栈部分进行评估规程——例如，衡量未授权用户获取模型访问权限所需的对抗性努力程度、滥用行为在检测前可持续的时间，或发现漏洞后修复的速度。 为阐明成熟的安全保障性能评估应具备何种形态，我们提出一个初步的框架，该框架分为三个层级：访问（谁可以使用该模型）、推理（该模型如何处理有害或双重用途查询）以及平台（如何事后检测和应对滥用行为）。目前大多数安全保障评估侧重于推理层级，导致访问和平台层级相对未得到充分关注（图1）。除我们提出的短期建议外，该框架还识别了评估者为实现跨安全保障全栈评估性能所需回答的一系列更广泛的问题。我们亦勾勒了如何将这些维度的结果整合为复合的“安全保障级别”。这些级别可根据其防护的目标威胁行为者进行校准，从而提供一种判断针对特定部署是否已部署足够安全保障的方式。 跨公司应可进行安全评估比较 1. 对标公共基准进行安全防护性能报告 安全评估有多种形式。在这些形式中，拒绝基准——它评估模型在固定测试集上拒绝有害或违反政策的提示的速率——是衡量安全性能的少数现有定量指标之一。因此，它们为标准化跨公司报告提供了一个有用的起点。 前沿人工智能公司通常仅根据专有的内部基准报告总体拒绝率，且不按生物风险类别细分结果。这会隐藏滥用防护中的盲点：如果一个模型拒绝提供细菌制剂合成路线的细节，而另一个模型拒绝提供病毒制剂的细节，那么在它们之间切换的用户可能不会遇到任何有意义的障碍（图2）。更标准化的报告将使评估人员能够发现这些问题。 应维护安全漏洞，但公共信息披露应审慎进行，以避免为有害输出指明路径（FMF，2025）。 图2 | 总拒绝率掩盖了哪些主题被涵盖 一个需要补充考虑的因素是安全措施对合法使用的影响：模型是否错误地拒绝良性的科学请求。孤立地看，高拒绝率并不能表明安全措施成功；必须将其与误报率进行权衡。 SecureBio最近开发的BioTIER基准测试是正确的方向，它将提示分类到三个生物风险集中（SecureBio，2026年）。该基准测试区分了应该回答的良性生物提示（BioTIER-permit）和应该拒绝的提示（BioTIER-refuse）。在拒绝类别中，其中一部分提示被额外标记为选择性制剂内容，这意味着它们涉及受监管机构高度关注的生物制剂或毒素。将BioTIER应用于单个前沿模型，说明了聚合报告会隐藏的提示处理差异（图3）。 源：SecureBio 图3 | 前沿模型在安全防护性能上存在显著差异。BioTIER基准测试（SecureBio，最后更新于2026年4月）。所有三个指标得分越高越好。拒绝准确率衡量模型拒绝被标记为双重用途或高风险的生物提示的频率；良性提示准确率衡量模型回答被标记为合法生物学问题的提示的频率。 在双重用途提示方面，Claude Opus 4.6 在 BioTIER-refuse 子集上 95% 的时间里拒绝，而 Gemini 3.1 Pro 仅拒绝 49%。在涵盖涉及最重要病原体和毒素的提示的 Select Agent 子集上，这一差距虽然缩小但仍然存在（99% 对 65%）。此基准测试还揭示了一种安全性与有用性之间的权衡：Gemini 3.1 Pro 几乎完美的良性提示准确率反映了一个在拒绝潜在有害提示方面率也远低的模型，而Claude 强大的拒绝性能则伴随着降低参与合法生物学问题的意愿。不同的开发者可以合理地做出不同的选择，但这些选择应该是可见的，以便评估者能够识别整个行业在安全防护覆盖方面的差距。 公开报告也可能产生声誉激励。证明A公司能够阻止威胁，可能会对B公司施加压力使其也采取相同措施，从而支持整个行业在安全方面的“争先创优”。同样地，正如BioTIER 9有助于规范拒绝报告一样，也需要针对其他安全措施采取类似的举措。与此同时，仅仅依赖公共基准可能会存在过度拟合或对已知提示数据集进行适应的风险。 建议一：前沿开发者应针对共享基准（例如BioTIER）报告安全性能。应与其他模型评估一同公布每个生物风险类别的拒绝率或滥用检测率，包括良性提示上的假阳性率。敏感底层信息应仅向可信评估者和人工智能安全研究所（AISIs）提供，以避免信息风险（FMF，2025）。共享基准应定期更新，并由AISIs和第三方评估者维护的保留或私有基准进行补充。 2. 规范安全稳健性评估报告 大多数已发布的模型安全评估主要衡量能力：一个模型（通常安全性降低）能为特定威胁行为者提供多少提升。而衡量安全措施性能的评估则少得多：干预措施如何有效阻止这种提升使威胁行为者受益。即使供应商披露更详细的内部评估，其结果也难以进行比较。 安全防护的有效性不仅取决于安全防护在常规使用中能否阻止有害请求，还取决于它们能否抵御蓄意的规避尝试。然而，目前的公开披露很少报告关于安全防护抵御生物滥用能力的标准化数据。例如，OpenAI、Anthropic 和 Google DeepMind 都描述了近期生物风险模型“专家红队测试”的结果（见表2）。但所报告的测试回答了不同的问题：Anthropic 和 Google DeepMind 主要评估能力提升；OpenAI 评估对抗条件下的安全防护失效情况。这些披露在描述的评估条件上也有所不同，例如红队测试人员的专业水平、滥用场景以及时间或尝试预算。它们报告的结果指标范围从定性的能力提升描述到成功越狱的计数。因此，这些报告无法用于比较不同供应商的安全防护鲁棒性，也无法用于判断其针对特定威胁模型的充分性。 能力评估的最佳实践已有所阐述（McCaslin等人，2025），但安全评估的等效指导尚不存在。此类指导还应考虑用于评估的模型设置14——包括所提供的脚手架、工具和提示——这些因素可能实质性改变测得的能力和显现的安全稳健性。 建议二：该机构应实施并标准化安全防护能力的报告，例如通过红队评估。至少，前沿开发者应采用统一的防护评估分类体系，并以基线披露标准报告结果。最终，直接比较需要在不同评估类型中就共享测试场景达成一致。 一个分类体系将有助于区分目前被归为同一宽泛标签下的评估，例如“专家红队演练”。至少，当提供方进行衡量时，应当明确。 – 能力提升（模型能帮助用户做什么以及能做多少）– 安全防护的鲁棒性（安全防护措施是否可以被绕过以及需要付出多大努力），或– 端到端风险评估（在特定访问路径下，能力和安全防护措施如何相互作用） 应建立一项基础披露标准，要求开发者报告那些有助于清晰解释和比较的变量：红队测试人员画像、模型设置和访问条件（例如提供了哪些脚手架；评估中启用了哪些或禁用了哪些安全措施）、时间或尝试预算、提取策略以及成功标准（例如什么被视为一次成功的越狱¹⁵）。在可能的情况下，应报告定量的结果指标。 安全评估应考虑部署环境 3. 针对不同模型配置报告安全防护充分性 前沿人工智能公司将在不同场景部署模型。同一个底层模型可能被用于消费者或企业聊天机器人（例如ChatGPT），通过第一方 开发者工具或API（例如Claude Code、OpenAI API），或通过第三方云平台（例如Microsoft Azure、Amazon Bedrock、Google Vertex AI）。现在