马斯克提议AI巨头发布前交叉测试：同行评审能否成为模型安全新防线？

【软盟资讯·新闻导读】2026年9月15日，马斯克在All-In峰会上提出，AI公司可在模型正式发布前开放接口，接受同行交叉测试。该建议把安全评估从企业内部流程推向竞争者之间的相互审查，但目前仍属于个人倡议，不能等同于已经落地的行业制度。

从内部测评走向同行交叉评审

传统大模型发布前的安全测试，主要由模型开发商自行完成。企业内部团队掌握模型架构、训练数据和系统配置，能够进行大规模自动化测试，但也可能受到组织目标、发布时间表和评估方法的影响。

马斯克此次提出的方向，是让AI巨头在模型发布前向其他公司开放受控API，由外部同行进行测试。这种“模型交叉测试”并不意味着公开模型权重，也不等同于把全部内部数据交给竞争对手，而更接近在隔离环境中提供有限访问权限，由第三方或竞争公司检验模型在安全、滥用和可靠性方面的表现。

需要明确的是，目前能够确认的重点是：马斯克提出了这一建议。它并不代表已经形成AI行业共识，也不能表述为一套已经生效的国际监管制度。建议最终能否转化为常规机制，还取决于参与者是否愿意承担接口开放、信息披露和责任追踪成本。

已有合作案例提供了可参考的起点

在此之前，OpenAI与Anthropic曾相互开放API，开展联合安全评估。这类合作说明，竞争关系并不必然排斥有限范围内的安全测试。不同公司拥有不同的模型架构、训练方法和红队经验，相互测试有机会发现内部团队不容易观察到的问题。

不过，已有合作案例与马斯克提出的广泛同行评审仍有区别。

一方面，联合评估通常需要双方事先约定测试范围、数据处理方式、问题披露规则和保密条款。另一方面，合作案例往往具有明确的参与主体和项目边界，不能直接推导出所有AI公司都会在发布前互相开放API。

因此，OpenAI与Anthropic的合作更适合作为机制样本，而不是已经成熟的行业标准。它证明了技术上可以建立受控评估通道，但没有自动解决竞争利益、责任归属和结果公开等问题。

一次完整的交叉测试可能如何进行

如果把同行评审落实为企业可执行流程，至少需要包括以下环节。

1. 明确测试边界

模型提供方需要确定开放的是哪个版本、哪些能力和哪些工具权限。测试环境可以与生产环境隔离，并限制调用频率、数据范围、插件权限和外部网络访问。

对于具备代码执行、联网搜索、文件处理或自动调用工具能力的模型，是否开放这些权限，会直接影响测试结论。只测试纯文本问答，可能无法覆盖智能体在真实业务中的风险。

2. 设计分层红队测试

同行评审不应只依赖几个常见的越狱提示词，而应覆盖多个风险维度，例如：

• 有害内容生成与安全边界绕过；
• 隐私泄露、敏感信息推断和训练数据记忆；
• 网络攻击、恶意代码和工具滥用；
• 对事实的错误陈述、过度自信和引用失真；
• 多轮对话中的风险累积；
• 智能体执行任务时的权限扩大和错误操作；
• 不同语言、行业场景和用户群体下的表现差异。

外部团队的价值，不只是“找出更多漏洞”，还包括提出不同于模型开发方的攻击路径和业务使用假设。

3. 记录可复现证据

测试结果应包含输入、输出、模型版本、系统提示、工具权限、时间戳和复现条件。否则，模型提供方即使确认问题，也难以判断风险是否来自模型本身、外围应用还是测试环境。

对于企业采购而言，单一的“安全评分”并不充分。更有价值的是问题类型、触发条件、影响范围、修复状态和复测结果。

4. 设置分级披露机制

并非所有发现都适合立即公开。涉及严重漏洞的报告，应先交给模型提供方进行修复或缓解；低风险问题则可以在不暴露攻击细节的前提下进行汇总披露。

理想情况下，参与者应事先约定披露时间、争议处理、研究者署名和商业机密保护规则。没有这些安排，测试方可能担心被指责为竞争攻击，模型方也可能担心评估结果影响市场声誉。

API开放并不等于真正独立

交叉测试最容易被忽视的限制，是API本身并不是模型的完整复制品。模型提供方可以控制版本、系统提示、内容过滤、访问频率和返回结果。测试环境与用户真实使用环境存在差异时，评估结果就可能出现偏差。

此外，API调用通常只能观察输入和输出，无法直接观察训练数据、内部安全分类器、模型权重或后台人工审核机制。外部测试可以验证系统表现，却不能完全解释风险来源。

这意味着同行评审更接近“外部行为审计”，而不是对模型全部安全属性的独立证明。企业在解读报告时，应同时关注测试条件和未覆盖范围，避免把一份评测结论当成模型安全的永久保证。

标准、数据与责任仍是主要难题

评测标准难以统一

不同公司可能采用不同的风险分类、攻击样本和通过阈值。一个团队认为可以接受的误报率，可能无法满足金融、医疗、政务或网络安全场景的要求。

如果没有共同的评测协议，企业很难横向比较不同模型。若标准过于统一，又可能压缩针对具体行业和应用环境的测试空间。

测试数据存在泄露风险

红队数据可能包含恶意代码、个人信息、未公开漏洞和高风险提示词。跨公司共享这些数据，需要明确脱敏、留存、访问和销毁规则。测试数据一旦扩散，也可能被反向利用。

责任边界并不会自动清晰

如果外部测试发现模型存在风险，模型提供方、评测方、部署企业和最终用户分别承担什么责任，需要根据具体使用方式判断。模型方可能负责修复基础能力问题，部署方则仍需负责权限控制、人工审核和业务流程设计。

因此，交叉测试不能替代企业自身的上线审批。它最多是供应商安全证明之外的一层独立验证。

企业选型可以借鉴什么

对于准备采购或部署大模型的企业，同行评审思路可以转化为第三方评测清单。

首先，要求供应商说明模型版本、更新机制、API权限和安全测试覆盖范围。企业需要知道评估针对的是哪个版本，而不是接受一份没有时间和版本信息的笼统认证。

其次，优先查看可复现的测试证据，包括风险类别、测试环境、失败案例、修复记录和复测结果。无法披露细节时，供应商至少应说明限制原因和替代性验证方式。

再次，在合同中约定重大漏洞通报、版本变更通知、数据隔离、日志留存和事件响应责任。尤其是使用智能体或外部工具时，应限制模型直接执行高风险操作，并设置人工确认和最小权限机制。

最后，企业可以引入独立安全机构、行业实验室或专业红队开展补充测试。第三方评测不必追求一次覆盖所有风险，而应围绕实际业务流程持续进行，包括上线前测试、版本升级复测和运行中的异常监测。

【软盟观察】

马斯克提出的同行交叉测试，真正值得关注的并不是“竞争对手是否愿意互相检查”这一表面冲突，而是AI安全责任是否会从单个模型厂商内部，逐步扩展到更广泛的外部验证体系。对企业而言，外部评审能够增加信息来源，降低只看供应商自报指标的风险；对模型公司而言，开放受控API也可能带来漏洞暴露、商业机密泄露和声誉受损压力。更现实的路径，或许不是立即建立统一的全球制度，而是从有限范围、隔离环境、明确保密和分级披露开始。现阶段，这一建议仍应被视为值得验证的治理方向，而不是已经形成的行业共识。