法律是通过人与制度发挥作用的
AI 系统并非置身于日常问责机制之外。开发者、部署者、供应商、企业高管、公共机构与用户,都在就训练、访问权限、系统集成与应对方式做出各种决策。法律可以分配相应义务、要求提供证据、创设救济途径,并授权监管机构进行干预。其成效如何,取决于适用范围、执法能力、技术层面的专业性,以及相关义务是否真正触及了那个实际有能力防止伤害发生的行为体。
监管本身,并不天然比公众压力更快速或更可靠,而自愿性的实践,也并非天然就毫无用处。规则制定与诉讼程序可能十分缓慢;标准制定与政府采购或许能更早行动起来,但也可能缺乏民主问责机制。一套持久有效的策略,理应把具有强制力的底线要求,与灵活的技术层面落地实施及公众监督结合起来。
让规则与生命周期相匹配
一项训练规则,或许会要求对异常庞大或能力异常强大的研发项目进行报告、安全防护或评估。一项模型权重规则,或许会在盗用或不加限制的复制会造成严重风险的情况下,施加保护或受控发布方面的要求。一项部署规则,能够规范一项已托管服务的用户、安全保障措施与事故监测机制。一项推理或使用规则,则能够限制某项应用在就业、医疗、信贷、基础设施或武器领域中的具体用途。
这些规则并不能相互替代。禁止一项部署行为,并不能抹去相应的模型权重。一个基于训练算力设定的阈值,可能会遗漏一个借助工具或推理阶段算力得到增强的、规模较小的模型。一项针对具体应用的规则,或许能够保护受影响的人群,却未必会对一般性的研究活动加以规制。良好的法律,理应明确指出行为体、管控面、触发相应行动的证据标准,以及救济方式。
当前的格局,已不再「只是自愿性质」
欧盟《AI 法案》创设了具有强制力的义务。通用 AI 提供者的相应义务,已于 2025 年 8 月 2 日开始生效,包括技术文档、面向下游提供者的信息披露、版权政策,以及训练内容摘要。被归类为具有系统性风险的模型,其提供者还需承担额外的评估、风险缓释、事故报告与网络安全方面的义务(欧盟委员会通用 AI 义务概述)。AI 办公室相应的执法权限,已于 2026 年 8 月 2 日开始生效(欧盟执法框架)。
在美国,第 14110 号行政命令已于 2025 年 1 月被废止,因此,相关文章不应把其中的报告制度描述为当前有效的联邦政策(2025 年行政命令)。美国的联邦政策依然分散在既有各机构、行业专门立法、政府采购、出口管制与各州规则之中,而不是一部统一的、全面的 AI 成文法。
加利福尼亚州颁布了 SB 53 法案,要求受覆盖的大型前沿开发企业公布相应框架、处理灾难性风险阈值与相应的风险缓释措施、报告特定事故,并保护受保护的举报人(加州司法部长关于 SB 53 的指导意见)。纽约州的 RAISE 法案及其 2026 年的章节修正案,则新增了针对前沿模型的透明度与报告要求;官方法案记录显示,该章节修正案已于 2026 年 3 月签署生效(纽约州参议院 S8828 法案)。这些法律的适用范围,均比一项全面的安全保障承诺要窄得多,但它们足以驳斥「针对前沿模型、具有强制力的治理体系并不存在」这一说法。
责任归属与救济机制
责任归属机制,能够让本可避免的伤害付出高昂代价,但那种把全部成本都分配给「最有能力承担的一方」的口号式说法,依然留下了不少棘手的问题。一位开发者可能掌控着训练过程与安全保障措施;一家医院或雇主掌控的是使用情境与人工复核环节;一个下游供应商掌控的是微调过程;而一名恶意用户则可能违反每一项规则。责任完全可能是共担的。
行之有效的制度,应当明确注意义务的标准、妥善保存证据、让受到伤害的人能够获得解释或对决定提出异议,并避免为可预见的滥用行为提供一揽子豁免。与此同时,无限责任也可能抑制有益的开放研究,或让市场集中在少数几家能够负担相应保险的企业手中。安全港条款,能够在不沦为「打勾即可免责」的前提下,奖励那些有据可查的测试行为与迅速的事故应对。
救济方式应当与伤害本身相匹配:赔偿、纠正、删除、禁令、产品召回、许可限制、民事罚款,或针对故意不当行为的刑事追责。高风险系统同样需要快速的行政申诉渠道,因为数年之久的诉讼程序,根本无法挽回一次被错过的福利机会,或一项紧急的医疗决策。
政府采购能够创设运营层面的标准
各国政府与大型企业,可以在采购之前就要求相应的保护措施。美国管理与预算办公室(OMB)针对联邦 AI 采购发布的指导意见,要求开展跨职能规划、性能监测、对数据与知识产权的考量,以及与影响程度相称的风险管理(OMB M-25-22)。
一份有力的合同,应当明确规定:
- 获批使用的模型,以及供应商是否可以自动对其进行更换;
- 相关的部署前测试,以及独立评估的访问渠道;
- 审计日志、文档记录、数据留存与隐私保护;
- 数据泄露与 AI 事故的通报期限;
- 工具权限与人工审批节点;
- 回滚、暂停、身份凭证撤销,以及安全退役处理;
- 数据导出、互操作性,以及过渡阶段的协助;
- 分包商与云服务方面的依赖关系;
- 当性能或安全保障措施出现失效时的救济方式。
采购层面的相关条件,能够在整个市场中扩散开来,因为供应商往往会将同一套能力复用于多个客户。但如果这些要求含糊不清、带有专有性质,或成本过高不成比例,也可能反过来巩固既有巨头的地位。开放标准、共享的测试资源,以及按规模递增的相应义务,有助于规模较小的供应商参与竞争。
审计需要访问权限与相应后果作为支撑
一项审计的质量,取决于其覆盖范围。仅凭书面材料的审阅,无法验证系统在真实世界中的实际行为。审计人员需要获得相关的实际部署配置、文档记录、日志、已知事故信息,以及测试各种可信失灵情形的权限。独立性、专业能力、利益冲突披露,以及对敏感信息的保护,都同样重要。
审计发现,应当与整改期限、部署限制、后续跟进测试,以及与风险相称的公开摘要相互衔接。出于安全或隐私方面的考量,一份完整的保密报告或许是必要的,但保密性本身,不应让一家企业得以宣称自己「已经过审计」,却不说明究竟审查了什么内容。
监管机构同样需要技术人员与安全的访问渠道。要求提交没有任何机构能够真正解读的报告,只会制造出一种「合规表演」。对受监管实体收取的相应费用,如果结构设计得当、能够维护机构本身的独立性,便可以用来支持相应的监督工作。
反垄断政策存在一种真实的安全层面取舍
芯片、云服务、数据、分发渠道与基础模型领域的集中化,可能会造成供应商锁定、共享的故障点,以及私营部门的政治权力。美国联邦贸易委员会(FTC)2025 年针对云服务与 AI 合作关系的研究发现,算力与人才的获取、切换成本、排他性安排,以及敏感信息共享,均构成竞争层面的隐忧(FTC 工作人员报告)。
更充分的竞争,能够降低依赖程度,并让用户得以离开不安全的供应商。但它同时也可能加剧发布节奏上的竞赛、让保护不善的权重存储库大量增加,并让协调一致的安全保障措施变得更加困难。一家规模庞大的单一供应商,或许会在安全方面投入更多资源,但同时也会造成一个灾难性的单点故障。因此,反垄断政策应当致力于保护市场的可竞争性、互操作性、劳动力流动性,以及对基本投入品的获取渠道,而不应想当然地假定市场结构越大或越小就自动更为安全。
竞争对手之间围绕安全议题展开的协调——共享的事故报告格式、基准测试方法,或安全情报信息——可能是有益的,但也可能掩盖排他性行为或价格协调行为。美国司法部与联邦贸易委员会已于 2026 年就竞争对手之间的协作寻求最新的公众指导意见,并明确将算法定价与信息共享纳入其中(DOJ/FTC 意见征询)。清晰的规则,能够在维护竞争的同时,允许真正意义上的安全合作得以进行。
事故应对与紧急权力
各类组织理应承担保存日志、通报相关主管机构与受影响方、遏制伤害,并在各类依赖关系中展开协作的法律义务。监管机构则需要具备分级授权的权力:要求提供信息、要求采取风险缓释措施、限制某项功能,或在证据表明存在紧迫危险时下令暂停运行。
紧急措施本身需要正当程序作为保障。它们应当明确决策者、触发门槛、适用范围、持续期限、审查机制,以及恢复运行的相应条件。一种笼统的、无限期的「AI 全面关停」,既在技术上站不住脚,也与负责任的政府治理格格不入。
切实可行的结论
法律层面的杠杆,当其具体明确时最为有力。它把「要负起责任」这句话,转化为附着在训练、模型权重、部署、推理、采购与高影响力用途之上的具体义务。它为受影响的人群提供救济渠道,也为运营方赋予了明确的权力,使其能够开展审计、撤销权限、回滚系统,并对事故做出应对。
没有哪一个司法辖区已经彻底解决了 AI 治理这一课题。但截至 2026 年 9 月,欧盟及美国各州具有强制力的前沿模型相关义务、联邦采购规则、竞争执法,以及行业专门立法,已经提供了真实可用的工具。当前的任务,是不断改善这些工具的证据基础、互操作性、执行力度与民主合法性——而不是把这整个领域简单地描述为「自愿性承诺」与「戏剧化对抗」之间的一道选择题。