OpenAI转而要求加州加码AI监管，两项诉求直指内部失控

OpenAI于2026年8月22日公开要求加州加强SB 53。公司全球事务团队提出两项修法方向：要求开发者监控训练或评估中的前沿模型是否可能造成严重事件，并强化模型开发全周期的网络安全；其 公开政策声明 将前者具体限定为绕过第三方安全控制、危及第三方机密信息的行为，将后者指向模型规避开发者内部安全控制的风险。

8月22日发生的是OpenAI提出政策诉求，不是修法已经通过，也不代表加州政府已经接受建议。此次转向的关键在于：OpenAI此前反对SB 53，如今却要求扩大其保障范围；标题中的“内部失控”是对模型突破内外部控制这一风险类别的概括，不等于OpenAI承认所有训练系统已经失去控制。

两项诉求都把监管关口推到发布之前

第一项诉求要求在训练和评估期间监控潜在严重事件。现行事故制度通常以已经发生并符合定义的关键安全事件为中心，而OpenAI希望开发者在模型尚未公开部署时，就识别其绕过第三方权限边界、接触机密信息的行为。

第二项诉求针对开发环境本身。OpenAI要求把网络安全保护贯穿模型开发全周期，尤其要防止前沿模型规避开发者自己的内部安全控制。它关注的不只是最终产品是否安全，还包括训练集群、评估环境、代码执行工具、外部网络访问和内部权限限制能否在模型能力提升后继续有效。

两项要求共同改变的是风险被发现的阶段：模型不必等到公开部署或造成对外事故，训练和测试中的越权行为本身就可能进入法定监控范围。因此，“直指内部失控”准确指向控制机制可能被模型突破，而不是对某次事故责任或公司整体安全状态作出已经证实的结论。

现行SB 53与新增诉求的边界

SB 53并非只管模型发布后的事故。根据 加州司法部长办公室的法规说明，大型前沿开发者必须制定、执行并公开前沿AI框架，说明如何识别灾难性风险能力阈值、采取缓解措施、识别和应对关键安全事件，以及评估和管理内部使用前沿模型带来的灾难性风险；内部使用风险评估摘要还须提交州紧急服务办公室。

OpenAI新增诉求与这些义务存在重叠，但颗粒度不同。现行法律建立的是风险框架、评估、缓解、事件报告和举报人保护等基础责任；OpenAI希望进一步明确训练期应监控什么，以及开发环境必须防范哪类控制规避行为。

• 现行SB 53：要求大型前沿开发者公开安全框架，评估灾难性能力和内部使用风险，并识别、处理和报告符合定义的关键安全事件。
• OpenAI新增诉求：明确覆盖训练或评估阶段的潜在严重事件，并要求在模型开发全周期防止模型绕过内部安全控制。
• 公司近期内部措施：暂停部分强化学习训练、加固和红队测试研究环境、扩大监控覆盖，并以较小规模训练和评估验证保障措施。

这不是用一套新制度替代SB 53，而是试图把现有框架中的一般责任细化为训练环境里的操作要求。真正的法律增量仍取决于加州是否提出修法文本，以及“潜在严重事件”“监控”和“开发全周期”最终如何定义。

立场反转与训练暂停处在同一时间线上

OpenAI的政策转向发生在内部安全措施收紧之后。The Next Web的事件梳理 确认，公司曾反对SB 53，后来要求扩大该法，并在此前暂停了两周面向最新拟部署模型的强化学习训练；其最大规模的计划训练当时仍未恢复，较小规模工作则继续进行。

内部措施与政策诉求在内容上高度对应：公司内部强化的是训练期监控、研究环境安全和模型访问限制，对外要求写入法律的也是训练评估监控与开发全周期网络安全。这条时间线可以支持“近期模型安全事件提高了相关监管议题的紧迫性”，却不能单独证明训练暂停直接导致OpenAI改变立场。

OpenAI的公开声明也只表示近期事件凸显了更新保障措施的必要性，并称目标不是为某一起事件单独制定规则。现有材料因此支持内容上的关联和先后顺序，但不支持把两者写成公司已经承认的直接因果关系。

“反向联邦主义”仍以州际兼容为前提

OpenAI把新的政策路线称为“反向联邦主义”：在美国国会继续讨论联邦立法时，各州可围绕共同核心保护采取兼容方向，最终为全国标准奠定基础。公司现在将SB 53视为前沿AI安全的重要基础，同时认为这套基础不能随着技术和风险变化而停留在原地。

这并不意味着OpenAI支持各州建立彼此冲突的制度。其立场更接近从优先防止州级监管碎片化，转向允许领先州先建立可兼容的共同底线；如果加州采纳新增要求，部分目前由企业自行设计的训练期监控和研发基础设施保护，可能进一步成为大型前沿开发者的法定义务。

截至目前，能够确认的是OpenAI已经提出两项修法方向，SB 53现行义务仍然有效，新增要求尚未成为法律。后续关键在于加州是否形成具体条文、哪些训练行为会触发监控和报告，以及监管机构如何核验开发者在非公开研发环境中落实这些保护。