你没读的那份「使用政策」，才是真正的AI合同
采购团队盯着前沿模型的能力和价格谈判，真正框定边界的，是供应商单独撰写、并可在签约后随时执行的政策文件。
这是每笔AI交易里没人愿意大声念出来的部分。能力先演示，价格再拉锯，安全问卷逐项填完，然后有人把一个网址贴进主协议——那个网址指向的，是供应商单方撰写、可按自己的节奏随时修订的政策文件。你没有参与谈判，却要全盘继承，而它足以在签字墨迹干透很久之后，继续约束一套已经上线的部署。
所以要像对手一样逐条读合同：每一条款，都要问它能在供应商最糟糕的一天里，对你做什么。能力和价格本来就会被反复审视，但有四条条款很少被认真对待，合在一起却决定了你的暴露程度——供应商的政策禁止什么；供应商何时可以断供；模型究竟运行在哪里；你写下的治理措辞在审计面前是否站得住。本文逐一拆解，最后给出应该摆上谈判桌的问题，以及听到哪些回答就该终止这笔交易。
授权使用一个前沿模型，你到底在同意什么？
前沿实验室的企业合同做的，远不止授权一个模型。它会通过引用条款，把供应商自己的政策整体并入协议，并保留暂停服务的权利。OpenAI的商业条款就写明了明确的暂停条款：只要OpenAI合理认为存在安全风险、法律或监管要求，或客户违反其政策，即可暂停访问权限。而这些政策——包括使用政策本身——正是通过同一份合同被并入进来的，于是一份供应商可以单方修改的文件，就此成为你这笔交易的有效条款。就我们对市场的观察，这种做法是常态，而非例外。可接受使用政策不是小字条款，它编码的是供应商的风险偏好，而不是你的，却决定着你的部署被允许做什么。
这份「单方」到底有多单方，取决于你谈判时争取到了什么。有议价能力的买家，有时能争取到变更通知期、既有用例的祖父条款，或是在政策发生重大不利变更时的退出权。但大多数买家什么都没争取，原样接受了链接进来的政策，直到试点聊天机器人升级为触碰生产系统的智能体时，才第一次摸到边界。那正是一个用例开始逼近红线的时刻——原本只盯着能力和价格做采购的买家，这才发现真正具有约束力的条款，是一份从未被尽职调查过的政策页面。
供应商与政府意见相左时，你的模型会怎样？
自从前沿模型进入国防与政府项目，这就不再是一个抽象问题。各大实验室发布的使用政策会单方面排除某些用途——Anthropic的使用政策就限制了监控等类别以及部分执法场景的应用，而供应商能否在强势客户面前守住这条线，恰恰是供应商规则与政府诉求可能正面相撞的地方。与该供应商签约的普通商业客户，在这场博弈里没有发言权，却要承受它的结果。政策一旦收紧，你被允许的用途就跟着收紧；供应商一旦在压力下让步，你依赖的模型可能在很短的预警期内就变了性格。我们认为，这才是前沿模型交易里真正的交易对手风险，而它完全落在价格条款之外。
对亚太地区的买家来说，压力从不止一个方向来。欧盟《人工智能法案》的效力延伸到欧盟境外：第2(1)(c)条明确将义务扩展到第三国的提供者和部署者，只要其AI系统产出的结果在欧盟境内被使用，参见该法案条文——这意味着一家亚洲公司只要服务欧盟用户，即便自身并不在欧盟运营，也可能被纳入其适用范围。供应链层面的思路，英国NCSC的供应链安全指南提供了一个可参照的样本：把关键软件依赖当作需要指定责任人和退出方案去管理的对象，而不是想当然地假设它会一直可靠；一个产品离不开的前沿模型，正属于这一类依赖。公共部门买家面对的是更严格的版本——以英国政府的AI采购指南为例，它要求买家规划整个生命周期，而这背后的方向，与亚太区不少监管思路是相通的：新加坡的《人工智能治理示范框架》同样强调问责与全流程风险管理，越来越要求买家能够证明，一旦失去某个供应商，业务仍能存续。
模型应该运行在你自己的信任边界之内吗？
一个好的流程会最先问、却往往最后才被问到的问题是：模型究竟运行在哪里。它能不能落在你自己的信任边界之内——开放权重、本地部署，必要时甚至物理隔离——还是只能以一次次请求的形式，存在于别人的云端？你自己托管的模型，不会因供应商改变主意而受影响，也不会因为有人向供应商施压而被牵连；你租用的模型，两种风险都要承担。
自托管是一层隔离，不是一张免死金牌，这个限度要说清楚。开放权重模型依然附带许可条款，可能限制商业用途或高风险场景，下载了权重不代表你摆脱了条款约束。最强的开源模型往往落后于最领先的闭源模型，选择韧性有时要以牺牲能力为代价。而且你要接手原本由供应商承担的安全加固、补丁维护和评估工作。这笔交易是真实存在的权衡，但对受监管、涉密或需要主权可控的业务来说，天平通常会倒向「掌控权」，这也是我们在讨论安全智能体系统设计时反复强调的原则：问题从来不只是模型能做什么，而是激励一旦发生变化，控制权究竟握在谁手里。
「人工监督」到底能约束供应商什么？
还有一种更隐蔽的失败，它就藏在那些让买家最放心的承诺里。「人工监督」「人在环路」——这些说法在评审时无一例外都会顺利过关，因为每个人都在点头，脑子里想的却是不同的画面。有人把「人在环路」理解为每一次关键操作都要有人审批，有人理解为一份每周扫一眼的仪表盘。同一句话，松紧程度天差地别，而这个落差往往要到事故发生时才会浮出水面——那是你能了解到这句话到底买到了什么的最糟时机。
把每一句承诺，都拆解成一项你能在审计中被判定「合格」或「不合格」的具体控制项。NIST的人工智能风险管理框架把方法说得很直白：界定并区分人类与AI各自的角色，记录监督流程，识别第三方控制点，并采用客观、可复现的测试与验证方法。在签字之前，把每一句笼统的承诺都变成一项具体、可测试的控制。如果「监督」写不成一项可能被判不合格的检查项，它就只是装饰。我们在人工可控的AI实践一文中提出的也是同一个观点：承担分量的是机制，而不是措辞。
哪些问题真正能拦下一笔糟糕的AI交易？
尽职调查的价值，取决于你愿不愿意为某个答案掉头离场。按顺序把下面这些问题摆到供应商面前，斜体标注的回答，应该让这场谈判终止，或者至少在签字前先转交法务。每一条，都对应着你合同里已经存在的某项条款。
- 这份合同并入了你的哪些政策？未经我同意，你能否修改它们？这是在测试「引用并入」条款。该走开的回答：全部并入，由我方自行决定随时修改，发布即生效。
- 你在什么条件下可以暂停或限制一个已上线的部署？会提前多久通知？有没有整改期？这是在把暂停条款说清楚。该走开的回答：立即执行，由我方自行裁量，不予通知，不给整改机会。
- 如果你修改使用政策导致我的用例无法继续，我能否获得通知，并带着我的数据体面退出？这是在为条款变更与退出权定价。该走开的回答：重大不利变更不设退出条款，且只有我方享有随意终止权。
- 这套系统能否运行在我自己的信任边界内——私有云、本地部署，甚至物理隔离——还是只能用你的云？这一条决定了你在上述所有风险面前的暴露程度。该走开的回答：只提供区域内的纯API调用，不提供任何隔离选项，而你的业务恰恰涉及监管、涉密或主权数据。
- 我的数据在哪里被处理？经过哪些分包处理方？在什么样的法律强制下可能被披露？这是在摸清司法管辖与分包链条。该走开的回答：拒绝披露分包处理方名单，也不承诺处理数据的地理区域。
- 把「人工监督」写成一项我能在审计中拿去检验的具体控制项。逐次审批和每周看一眼仪表盘，是完全不同的两件事。该走开的回答：监督内容由我方自行决定实施方式，我方不作任何承诺。
- 在你弃用或大幅调整我已经验证过的模型版本之前，会提前多久通知？模型更迭可能让你之前的验证工作一夜作废。该走开的回答：弃用节奏由我方决定，重新验证的成本由你承担。
这些都不是什么高深的要求，只是把你手上那份合同，带着供应商最糟糕的一天，重新大声读一遍。
真正的合同，活在签字页几乎不会提及的四个地方：它链接出去的那些政策，访问权限可能被切断的那一刻，模型实际运行的那片云，以及从未被写成可测试条款的治理措辞。按这个顺序做尽职调查，你买到的就是一段可以问责的供应商关系；跳过它们，你买到的就是一份压力之下退不出的依赖。如果想把这份纪律嵌进采购流程本身，而不是事后补救，我们的技术战略团队正是从这里开始的。
常见问题
AI供应商尽职调查清单，除了能力和价格，还应该覆盖哪些内容？
除了能力和价格，还应覆盖可接受使用政策，以及供应商变更或暂停访问权限的权利；部署架构，也就是模型能否运行在你自己的信任边界内；以及「人工监督」之类治理措辞的精确、可审计含义——这些都应该在签字前厘清，而不是等到事故发生时才去弄清楚。
供应商能否切断我已经付费使用的模型访问权限？
通常可以。并入供应商政策的企业协议，大多保留了在违反政策、触发法律要求或出现安全紧急情况时暂停或限制访问的权利，OpenAI的商业条款就是如此。你可以尝试谈判变更通知期或退出条款，而自托管或开放权重方案，是目前最主要的结构性防护手段，但同样附带许可与运维方面的限制。
为什么「人在环路」这种说法常常引发AI合同纠纷？
因为它没有明确定义。同一句话，双方可以理解为逐次人工审批，也可以理解为偶尔的监控扫视，这种歧义往往要等到出现故障时才会显形。参照NIST人工智能风险管理框架的思路，提前把它转化为有记录、可审计的具体控制项，歧义自然消失。
相关阅读
- Ubuntu 26.04 LTS的coreutils依赖名没变，代码已经换了作者
- 主权溢价：企业争的不是更快的AI，而是不会被随时掐断的准入权
- 商业秘密官司的胜负,早在辞呈递交前就已写定:一桩鸡肉公司积案的启示
- Security & Trust
本文由 Abyshire 专有编辑系统的 AI 编辑角色撰写，并经我们的团队审核。