AI同行评审若要落地，关键不在于“让竞争对手试用一次模型”，而在于把外部测试嵌入发布前后的安全治理流程。同行评审应被定义为一种受控的外部行为审计：模型公司开放限定版本和接口权限，由其他公司、独立安全机构或专业红队在隔离环境中进行测试，并形成可复现、可追踪的风险证据。
第一步是明确评审边界。测试对象应包含具体模型版本、可调用能力和工具权限，不能只提供一个无法确认版本的笼统接口。对于具备代码执行、联网搜索、文件处理或自动调用工具能力的模型，如果测试环境关闭这些能力，结论就只能覆盖纯文本交互，不能代表真实部署风险。接口访问频率、数据范围、外部网络权限和日志留存方式，也应在测试前约定。
第二步是建立分层测试，而不是简单收集几个越狱案例。评审至少应覆盖有害内容生成、隐私泄露、敏感信息推断、恶意代码和工具滥用、事实错误、多轮对话风险累积，以及智能体权限扩大等问题。同时，应检验不同语言、行业场景和用户群体下的表现差异。外部团队的核心价值，是引入不同的攻击路径和业务假设，而不是重复模型方已有的自动化测试。
测试结果必须能够复现。输入、输出、模型版本、系统提示、工具权限、时间戳和复现条件，都应被纳入记录。报告不宜只给出一个“安全评分”，而应说明问题类型、触发条件、影响范围、修复状态和复测结果。这样才能区分模型本身、外围应用与测试环境造成的风险。
受控开放与责任闭环
OpenAI与Anthropic曾开展相互开放API的联合安全评估，说明竞争公司之间可以建立有限范围的协作通道，但这类合作不能直接等同于成熟行业标准。真正可持续的机制，还需要预先约定数据脱敏、商业机密保护、严重漏洞通报、分级披露和争议处理规则。
API开放也不等于完全独立。模型提供方仍可能控制系统提示、内容过滤、访问频率和返回结果，外部团队通常无法直接观察训练数据、模型权重或后台审核机制。因此，同行评审只能增加独立验证，不能替代模型方测试、企业上线审批和运行中的异常监测。
对企业而言，最实际的做法是把同行评审转化为供应商审查要求：确认评估对应的模型版本，查看可复现证据，核对未覆盖范围，并在合同中约定版本变更、重大漏洞通报、数据隔离和事件响应责任。2026年9月这一方向仍主要体现为治理倡议，尚不能视为已经生效的行业制度；安全机制的可信度，最终取决于边界、证据与责任是否形成闭环。