译自 Dries Buytaert 博客原文：Responsibility follows control（2026 年 7 月 30 日）。

一个 AI 模型并不决定自己能访问哪些数据、能使用哪些工具、能不能不经批准就行动。这些决定由人在不同的环节做出。在上游，模型开发者训练和测试模型，并决定是否发布、如何发布。在下游，开发者把模型装进一个系统，把这个系统接到数据和工具上，并决定它提出的动作是否必须先经人审阅才能生效。

这些选择决定了危害是否有可能发生。所以当危害发生时，责任应该落在那些控制了相关选择的人身上。这份责任可以是共担的：模型开发者控制训练与发布，产品构建者控制权限与部署，用户控制蓄意滥用。

责任应当跟随有意义的控制。

关于开放权重（open-weight）AI 模型的争论，很多都缺了这条原则——它们往往把"决定发布模型"当成唯一算数的那个决定。

Axios 最近报道，美国官员曾考虑采取措施，限制美国公司使用中国的开放权重模型。开放权重模型会把训练好的参数公开出来，供他人下载、修改、并在自己的基础设施上运行，不必经过构建它的那家公司。

此后已有 230 多家公司和组织签署了一封业界公开信，为开放权重辩护。在批评者指责 Anthropic 支持禁止开放权重模型之后，Anthropic CEO Dario Amodei 发表声明否认这一立场。他把不具备危险能力的开放权重模型称为一种公共品，并支持对能力足够强的模型（无论开放还是闭源）强制做安全测试。

分歧的关键其实不在于开放权重是否会带来风险，而在于这些风险在什么时候足以构成限制发布的理由，以及限制究竟会提升安全性，还是主要把权力集中到最大的几家 AI 实验室手里。

我坚定站在开放权重这一边。我运行并比较过开放权重模型，也论证过数字主权取决于谁控制软件、而不是软件来自哪里，并且认为组织应该掌控自己的基础设施和数据，而不是依赖少数几家供应商。

我同时也认为，有重大后果的算法需要外部监督。十多年前我就主张过，我们最终会需要一个类似 FDA 的机构来管软件。更难的问题是：这种监督的责任该落在谁身上。

开放权重把控制权拆开了

对于 Anthropic、OpenAI 这类供应商提供的托管式闭源权重模型，供应商通常把权重保留在自己手里，控制客户如何访问模型，并决定何时更新托管服务。

开放权重可以把这些角色分开。一个组织创造并发布模型；像 Hugging Face 这样的仓库托管和分发权重；另一个团队可能对权重做微调；产品构建者把模型装进产品，并把它接到数据、工具和用户上。

每个团队控制的东西都不一样。正因为开放权重把控制权拆开了，"出了事谁负责"就变得更难回答。

模型开发者控制训练过程、能力测试、文档和发布决策。仓库控制它展示哪些关于模型来源的信息、对上传文件做哪些安全检查、提供并执行哪些访问限制。产品构建者控制最终系统能触达哪些数据和工具、哪些动作需要人工批准、以及记录哪些日志。

控制并不是唯一重要的东西，但它能指出：谁本来还有机会改变结果。当危害涉及 AI 时，多个行为体可能要为同一起事件负责，因为每个人控制的是不同的、本可以阻止它的机会。

开源示范了责任如何跟随控制

和开放权重模型一样，Drupal 的开源代码可以被复制和修改，不需要征得任何人同意。站点所有者可以用它传播错误信息，或者运营一个欺诈网站。站点所有者控制站点的内容和运营，也就为这些选择负责。Drupal 项目不会仅仅因为有人用了它的代码而要负责。

但 Drupal 项目控制着别的决定。当有人私下报告一个安全漏洞时，Drupal 安全团队按照协同披露政策处理：在修复准备好的过程中保持问题私有；一旦安全版本可用，团队发布公告并通知站点所有者升级。这个披露时机的选择，能让站点所有者有一个公平的机会保护自己。

同一个区分也适用于 AI。责任应当跟随每个行为体所控制的那部分决定。

产品把能力变成了权限

模型负责生成输出。而智能体是一个软件系统，它用模型朝某个目标推进，通常通过调用工具、执行动作来实现。构建和配置这个智能体的人，决定了它能访问什么、能执行哪些动作、什么时候需要人来批准。

在 Claude Code 这类编程智能体里，模型可以生成一条数据库命令。这条命令能不能跑，取决于智能体提供的工具和权限，也取决于计算机、网络和数据库允许的访问范围。

一个内容管理智能体可以提议删掉一篇文章。内容管理系统（CMS）决定这个智能体是否有权限删除、删除是否可逆、以及这个动作是否被记录。

权限、隔离、审计日志、速率限制、人工批准和回滚，这些都不只是工程细节。它们决定了在"危害仍然可以被阻止"的那个点上，谁握着控制权。这也是 AI 治理正在成为产品架构核心部分的原因。

在每一个控制点上监管 AI

判断"事后由谁负责"相对容易，即使答案并不显然。更难的问题是：在危害发生之前，政府应该要求什么。

如果控制权和责任分散在多个行为体身上，政府规则也应该分散到他们身上。这不是新想法。我们早就是这样监管很多技术的。

十多年前，当我主张需要一个类似 FDA 的机构来管软件时，脑子里想的是药品审批。现在我不再认为那是正确的模型。FDA 是把一种药批准给一个或多个特定用途，而一个通用模型可能被用于许多不同的目的。

汽车是更好的类比。政府设定安全标准，厂商认证自己的车符合标准。另外，司机必须先通过政府规定的考试，才能拿到驾照。

这个分层还延伸到汽车和司机之外。各州为司机设定法定血液酒精上限，并要求酒吧持有可以被吊销的执照。在很多州，酒吧还可能因为给明显醉酒的人上酒、而此人后来造成伤害，被判定承担责任。

每一条规则都对准了控制某项特定决定的行为体。合在一起，它们为所有人降低了风险。我会对 AI 采取同样的分层做法。

阻止一个模型发布是强得多的手段，应该极少使用。对开放权重模型来说，这意味着阻止开发者公开权重；对闭源模型来说，可能是阻止供应商提供访问。

只有在"产品里的防护措施 + 使用规则"无法及时阻止严重危险时，我才会支持这么做。下面这个"两问测试"只适用于这个极端手段，不适用于一般的 AI 监管。

阻止发布需要非同寻常的证据

限制开放权重发布的最强论据是：它实际上是不可逆的。权重一旦公开，开发者无法收回每一份副本，无法监控模型如何被使用，也无法确保它的防护措施仍然在位。

如果某个模型让灾难性危害变得容易得多，那么它的发布可能就是任何人还能有意义地控制它的最后一刻。我说的"灾难性"，指的是大规模伤亡或同等量级的系统性危害，而不是普通的产品故障、欺诈或滥用。

截至 2026 年 7 月，我还没有看到公开证据表明有开放权重模型越过了这道门槛。话虽如此，我相信这只是时间问题，这也是我仍然认为会有实质性监管到来的原因。

在阻止一个模型发布之前，政府应当有明确证据，证明下面两个问题的答案都是"是"：

• 发布这个模型，是否会让灾难性危害变得容易得多？要把它和闭源模型、以及人们已经能获得的其他工具做比较。
• 阻止它的发布，是否会有意义地降低那种危险？限制不应只是把访问转移到另一个国家或另一条分发渠道。

默认开放，责任分散

所以我今天的落点是什么？我会默认允许发布，并把义务放在控制权已经存在的地方：模型创造者对测试和发布决策负责，分发方对来源和文件完整性负责，产品构建者对权限和部署负责，用户对蓄意滥用负责。

这个做法也保护竞争。一套只有最大的几家实验室才满足得了的监管制度，可能只是保护它们免于竞争，而未必让任何人更安全。它还可能把组织推向依赖少数几家供应商，去使用它们无法检视的基础设施。

开放权重并不消灭控制权，它把控制权分散开来，从而使"出了事谁负责"更难回答。监管应当跟随这种结构：在每个行为体仍能阻止危害的那个点上给它设定义务；只有当发布会让灾难性危害实质性变容易、而限制会实质性降低危险时，才阻断发布。