2025 年 9 月 29 日，加利福尼亚州州长加文·纽森（Gavin Newsom）签署了第 53 号参议院法案，即《前沿人工智能透明度法案》（TFAIA），使加州成为美国首个对计算密集度最高的人工智能系统开发商施加具有约束力的安全、透明度和事件报告义务的司法管辖区。该法律于 2026 年 1 月 1 日正式生效。在过去的六个月里，它在悄然重塑着最大的 AI 实验室以及不断增加的中层模型开发商记录风险、发布治理框架以及向监管机构简报灾难性风险情景的方式。
如果你的组织负责训练、微调或实质性修改基础模型，或者运营着其他开发商赖以生存的大型计算集群，那么 SB 53 现在就是你在美国需要了解的最具影响力的 AI 法律。本指南将详细介绍受监管对象、必须发布的内容、15 天关键事件报告机制的工作原理、适用的举报人义务，以及如何将该法令转化为可操作的合规计划。
SB 53 的实际监管范围
与各州不断扩展的就业 AI 法律（如纽约市 Local Law 144 或科罗拉多州 AI 法案）不同，SB 53 并不监管算法招聘工具、信用评分模型或租户筛选系统。它的目标是一个更狭窄的类别：在极高计算规模下训练的前沿基础模型，以及这些模型可能引发的灾难性风险情景。
该法律处于两种监管传统的交汇点。它借用了产品安全法的理念，即公司应发布风险评估并在事件发生时通知当局；同时借用了金融监管法的理念，即最大的市场参与者比小型参与者承担更沉重的披露负担。其结果是一个围绕两个阈值构建的分层机制。
10^26 FLOPs 计算阈值
SB 53 定义的“前沿模型”是指使用超过 10^26 次整数或浮点运算训练的基础模型，包括微调和后续修改所产生的累积计算量。该阈值有意与现已撤销的联邦第 14110 号行政命令的报告触发点以及欧盟《人工智能法案》的通用人工智能层级保持一致，因此大多数美国大型实验室已经知道自己是否跨过了这一门槛。
有时被忽视的一点是，该法令计算的是下游修改的累积计算量。如果你在一个接近阈值的基本模型基础上继续进行预训练、强化学习微调或权重合并，即使单次训练运行未超过 10^26 FLOPs，你也可能使衍生模型进入“前沿”状态。记录每一个基础模型、每一次微调、每一次蒸馏和每一次权重合并，并跟踪每一步消耗的 FLOPs，现在已成为一项必不可少的簿记规范。
大型前沿开发商的 5 亿美元营收阈值
“大型前沿开发商”是指在上一日历年内，其实体及关联公司的年度总营收超过 5 亿美元的前沿开发商。营收测试是合并计算的：母公司、子公司和受共同控制的关联公司均计算在内。一家融资 10 亿美元但实际年营收仅为 4000 万美元的小型 AI 初创公司不属于大型前沿开发商；而一家拥有小型 AI 部门且跨过 FLOPs 阈值的上市科技集团几乎肯定属于此类。
层级划分之所以重要，是因为大型前沿开发商承担着最沉重的义务：发布前沿人工智能框架、进行灾难性风险评估、每季度向加州紧急服务办公室（Cal OES）提交内部使用风险摘要，并维持匿名的内部举报渠道。小型前沿开发商（计算量超过阈值但营收低于阈值）仍必须发布透明度报告并报告关键安全事件，但不强制执行完整的框架机制。
你必须发布的内容：前沿人工智能框架
每家大型前沿开发商必须在其网站上发布前沿人工智能框架并保持更新。年度审查是强制性的，任何重大修改必须在变更后 30 天内触发更新。
一个合理的框架至少应涵盖：
- 灾难性风险阈值和评估方法。 开发商将哪些能力（如化学、生物、放射性、核武器协助；大规模关键基础设施攻击；自主代理失控情景）视为跨越了灾难性门槛？开发商在部署前将如何测试这些能力？
- 风险缓解策略。 具体的前部署缓解措施：拒绝服务训练、能力抑制、部署限制、监控访问、阶段性发布以及部署后监测。
- 第三方评估。 将由哪些外部红队、评估员和审计员对模型进行评估，以及如何采纳他们的发现？
- 未发布模型权重的网络安全协议。 内部威胁控制、硬件安全模块、网络分段和访问日志，以保护部署前的权重免遭窃取。
- 关键安全事件响应程序。 谁决定某个事件是否应报告，15 天倒计时如何启动，以及公司如何与 Cal OES 协调。
- 内部治理机制。 董事会层面的监督、人工智能安全官的角色、升级路径以及安全审查的节奏。
- 标准对齐。 明确映射到 NIST 人工智能风险管理框架（AI RMF 1.0）和 ISO/IEC 42001，该法令将这些视为基础基准。
该框架不是一份市场营销文档。它是一个面向监管机构的文件，总检察长可以用它来评估公司的公共承诺是否与其内部实践相符。以起草 SEC 风险因素披露或 SOC 2 系统说明同样的严谨性来对待它，才是正确的姿态。
每次部署前的透明度报告
每个前沿模型开发者——不仅仅是大型开发者——在部署新的或经过重大修改的前沿模型之前，都必须发布一份透明度报告。透明度报告是针对特定模型的文档，独立于框架，必须包括：
- 公司名称、网站以及安全问题的联系机制
- 模型的发布日期以及支持的语言和输出模态列表
- 预期用途和适用的使用限制
- 对于大型开发者，需提供灾难性风险评估摘要及结果，包括是否以及如何引入第三方评估员
“重大修改”包括主要的性能升级、新增模态以及训练数据组合的重大变化。补丁发布和常规的安全微调通常不需要新的透明度报告，但对于边界案例，应记录书面理由，以备总检察长随后询问未发布报告的原因。
15 天关键事件报告时钟
最令公司法务感到意外的合规负担是事件报告的时间表。前沿模型开发者必须在发现关键安全事件后的 15 天内通知加州紧急服务办公室 (Cal OES)，如果该事件对公共安全构成迫切威胁，则时间缩短为 24 小时。
该法令对关键安全事件的定义非常广泛：
- 未经授权访问或窃取未发布的模型权重
- 灾难性风险的具体化
- 开发者对已部署模型失去控制
- 打败安全防护措施的欺骗性或规避性模型行为
建立可辩护的内部流程意味着在事件发生前回答三个问题：
- 由谁决定？ 应指定一名管理人员（通常是首席 AI 安全官或指定的副手）有权启动报告时钟，并记录升级标准。
- 什么会触发时钟？ “发现”是触发点。内部文档应准确记录事件被发现的时间、发现者以及通过哪个监控系统发现的，因为 15 天的期限是从那一刻开始计算的。
- 报告如何传输？ Cal OES 为开发者提交的内容维持着一个机密的接收流程。报告团队应在发生任何实际事件之前，充分演练提交工作流——包括敏感技术细节的加密传输。
对于大型前沿模型开发者，义务不仅限于被动的事件报告。每三个月（或按照其他合理的计划），大型开发者必须向 Cal OES 提交一份源自内部使用其前沿模型的任何灾难性风险评估摘要。这种季度频率是 SB 53 所特有的，也是美国法律首次规定 AI 实验室必须向行政部门机构报告持续的内部使用风险调查结果。
举报人保护与匿名内部渠道
SB 53 在加州通用举报人制度的基础上，增加了一套专门针对 AI 的保护措施，适用于“相关员工”——即职责包括评估、管理或应对前沿模型灾难性损害风险的人员。
前沿模型开发者不得阻止相关员工向以下对象披露信息，也不得因其披露信息而对其实施报复：
- 加州总检察长
- 联邦监管机构
- 直接上级或有权调查的其他上级
- 职责包括风险评估的其他相关员工
受保护的披露涵盖：(a) 合理相信开发者的活动会因灾难性风险对公共健康或安全构成特定且重大的危险；(b) 合理相信开发者违反了 SB 53 本身。
大型前沿模型开发者还必须维持一个匿名内部报告渠道。法律要求：
- 允许相关员工提交关于灾难性风险担忧的匿名披露的工作流
- 每月向报告员工更新调查状态
- 每季度向管理人员和董事进行简报，总结披露情况和结果，且被指控有不当行为的具名个人应被排除在听取简报的受众之外
法院可以向在报复诉讼中获胜的原告判给律师费。关键在于，该法律转移了举证责任：当相关员工证明受保护的活动是导致不利行动的一个促成因素时，开发者承担证明该行动是出于独立的合法原因而发生的举证责任。
灾难性风险的定义
SB 53 的重心在于其对“灾难性风险”的定义。法律将其定义为一种可预见的重大风险，即前沿模型将通过以下三种因果机制之一，对导致 50 多人死亡或重伤，或导致超过 10 亿美元的财产损失或损坏做出实质性贡献：
- 武器协助。 对制造、部署或使用化学、生物、放射性或核武器，或造成同等伤害的网路武器做出实质性贡献。
- 不受控的有害行为。 模型在有限的人类监督下进行的、如果由人类实施则构成需要动机的严重犯罪的行为。
- 失去控制。 开发者对模型失去控制，导致其从事具有实质性危害的行为。
该定义划定了重要的排除项。基于已公开信息的风险、源于合法联邦活动的损害，以及模型贡献不具实质性的损害，均不属于此范畴。正是这一排除条款使得日常应用风险——如简历筛选中的偏见、幻觉产生的医疗建议、版权侵权——不会触发灾难性风险制度。这些损害是真实存在的，但它们由其他法律解决，而非 SB 53。
民事罚款与执法
加利福尼亚州总检察长拥有唯一的执法权。民事罚款最高可达每次违规 100 万美元，并根据行为的严重程度进行调整。SB 53 法案本身并未赋予私人诉权，但举报人报复保护条款可通过受害员工提起的民事诉讼独立执行。
在实践中，执法风险集中在以下三个领域：
- 阈值博弈。 如果公司通过调整训练运行，使其刚好低于 10^26 FLOPs，但交付的显然是具有前沿级能力的产品，将面临严厉审查。该法规关于“累积计算量”的表述使得这种策略非常脆弱。
- 框架缺陷。 如果一个框架仅列出了政策，而没有实施证据，那么与将每项承诺与运营资产、指定负责人和审计日志挂钩的框架相比，前者更容易受到攻击。
- 事故报告延迟。 错过 15 天的窗口期，或者错过 24 小时的紧急威胁窗口期，这类清晰且有据可查的违规行为，历来是监管机构严厉打击的对象。
制定 90 天实施计划
对于尚未建立 SB 53 合规计划的组织，以下顺序非常有效：
第 1 天至第 30 天：范围与差距分析。
- 编目每一个经过训练、微调、合并或进行重大修改的基础模型，并估算每个模型的累积计算量。
- 确定前一公历年度的合并营收（包括所有关联公司）是否超过 5 亿美元。
- 组建一个跨部门的人工智能安全与合规工作组，成员包括工程、安全、法务、公关和人力资源部门。
- 对照 NIST AI RMF 1.0 和 ISO/IEC 42001 梳理现行做法，识别差距。
第 31 天至第 60 天：起草与治理。
- 将前沿人工智能框架草拟为可公开发布的版本化文档。
- 构建灾难性风险评估方法论，包括能力评估、威胁建模，以及在危险领域判定模型具备前沿能力的准则。
- 建立未发布权重的网络安全控制措施，并记录访问日志和内部威胁监控。
- 建立匿名内部报告渠道，以及每月状态更新和季度董事会汇报的工作流程。
第 61 天至第 90 天：运营就绪。
- 进行桌面应急响应演习，模拟发现权重窃取事件和灾难性风险显现的情景，随后练习 15 天和 24 小时的报告流程。
- 对相关员工进行举报人权利和匿名渠道的使用培训。
- 为部署管线中的任何模型发布透明度报告，并注明其参考的前沿人工智能框架。
- 将向加州紧急事务办公室（Cal OES）提交季度灾难性风险摘要以及年度框架审查列入日程。
与其他人工智能及隐私监管体系的协调
SB 53 并非孤立存在。合规团队应将其与以下各项进行比对：
- NIST 人工智能风险管理框架（NIST AI RMF）：该法案明确引用了该框架，它提供了大部分实质性的治理架构。
- 欧盟人工智能法案（EU AI Act）的通用人工智能级别：两者的文档重合度很高，单一且协调的内部框架可以同时满足两者的要求。
- 科罗拉多州人工智能法案和德克萨斯州负责任人工智能治理法案：这些法律规定了部署者在处理高风险决策人工智能时的义务，可能适用于你的下游客户。
- 加州消费者隐私法案（CCPA）以及即将出台的加州隐私保护局关于自动化决策技术的规定：这些规定与模型部署有交叉，但在 SB 53 之外独立运行。
- 联邦人工智能安全研究所的自愿承诺以及任何未来的联邦优先立法：这些都可能改变合规基准。
在所有这些监管体系中，准确的合规记录和清晰的审计轨迹至关重要——支持财务报告的文档规范同样适用于人工智能治理报告。前沿人工智能框架、灾难性风险评估、事故日志和举报人调查记录应至少保存五年，并以能够经受住高管变动和企业重组的方式进行存储。
确保你的合规与财务记录随时可供审计
无论你是在发布前沿人工智能框架、安排季度 Cal OES 提交计划，还是准备应对总检察长的查询，其核心要求是一致的：清晰、经过版本控制且可审计的记录。人工智能原生团队在代码库中使用的那种纯文本、版本化方法，同样非常适合用于财务账目。Beancount.io 提供纯文本会计服务，让你对财务数据拥有完全的透明度和控制权——没有黑盒，没有供应商锁定，并提供与监管机构要求的治理规范自然匹配的清晰审计线索。免费开始使用，了解为什么开发者和财务专业人士都在转向纯文本会计。