第三方模型与供应商风险：要问的是"什么可以不通知你就变"。
标准的 AI 供应商问卷会问：模型安全吗、训练过程负责任吗、厂商有没有认证。这三个问题几乎都无从作答，而且没有一个能预测你的下一次事故。真正能预测的那个问题更窄，也几乎从没人问：这家供应商可以不通知我就改动什么，而我又要怎么才会发现？悄悄换掉的模型版本、新加的子处理方、被安静修订的留存条款——这三种变化能在一夜之间让你的评测结果、你的数据保护备案和你的事故说明同时失效，而它们恰好也是你真能拿到合同答案的那三件事。
你的供应链比你的供应商清单长。
采购通常只登记一家供应商：模型提供方。而一个已部署的智能体，典型地依赖五到六个彼此独立的第三方，每一个都能在你脚下发生变化，其中大部分从未走过评审——因为没人把它们归类为供应商。
- 模型提供方——以及另算一份的、真正托管推理的那一方。同一个开放权重模型由两家托管，就是两个不同的系统：量化不同、服务栈不同、延迟与拒答行为也不同。见推理供应商。
- 网关或路由层，如果你用了的话——它坐在每一条提示词和每一次补全的必经之路上，因而双向都看得见全部内容。
- 智能体能调用的每一个工具服务器。一个第三方 MCP 服务器是拿着你的凭据运行、并把文本送回你模型上下文里的代码。它是一个握有生产访问权的供应商，也是最有可能被某位工程师在一个下午里加进来的那一个。
- 嵌入与重排序模型，替换它们会悄无声息地作废一份你也许花了一周才建好的索引。
- 评测栈——包括那个给你的输出打分的模型。评判模型一变，你的质量指标就变，而你会把它读成"我的智能体变了"。
有个只需一小时的有用练习：把每一个满足下列之一的外部方列出来——(a) 接收你的数据，(b) 返回会进入某个模型上下文的文本，(c) 能代表你执行动作。多数团队第一次做这件事时，会在 (b) 和 (c) 两类里找出两到四个压根不在供应商台账上的第三方。这个缺口本身就是结论——它之后的一切都只是排优先级。
决定你的评测还算不算数的三条条款。
供应商问卷的大部分内容在签约时是无法证伪的。而这三条是具体的、可检验的，并且直接决定你验证过的那个系统，还是不是下个月在跑的那个系统。
- 模型版本稳定性。你能钉住一个确切的模型版本，还是你的端点解析到一个会移动的别名？如果它会动：你能提前多久收到通知、被钉住的快照能活多久、以及"同一个版本"是只覆盖权重，还是也覆盖系统提示词、安全过滤器和采样默认值的改动？一个会静默向前滚动的别名，意味着你的评测结果会在一个由供应商选定、且不会告诉你的日期上过期。这与模型弃用与迁移里讨论的是同一份敞口，只是从合同这一侧看过去。
- 子处理方变更。还有谁碰这些数据，以及这份名单变化时会发生什么？标准做法是提前通知并附带异议权；常见的现实是网站上有个页面在无声地更新。如果你自己的合规备案逐一列举了子处理方，那么一次未经通告的新增，会在你什么都没做的情况下让你失去合规状态。
- 留存与训练用途。提示词和补全会被保留多久、谁能读、是否会被用于改进服务、以及这些能否被单方面更改？请注意：滥用监测的留存，常常与"我们不拿你的数据训练"这句头条宣称分开切割，而且通常是两者中更长的那个。这一条最常见的情形是——条款里写得准确，销售对话里说得不准确。见数据治理。
把答案写成三个日期和三个时长，而不是写成散文。"支持钉住快照、弃用至少提前六个月通知、子处理方提前 30 天通知并有异议权、提示词留存 30 天、滥用监测留存 12 个月、不用于训练"是一个你能据以行动的风险状态。"该供应商致力于负责任的 AI"不是。
一纸认证说明了什么，又没说明什么。
认证值得收集，也值得被精确理解——因为"它证明了什么"和"人们以为它证明了什么"之间的那条缝，正是虚假安心的住处。
- SOC 2 Type II 证明的是：特定的控制措施在一段时期内确实在运行。它是关于一家公司运营纪律的真实证据——访问控制、变更管理、监控。它对模型行为、输出质量、以及你下周调用的模型是不是你测过的那个，什么都没说。
- ISO/IEC 42001 认证的是一套 AI 管理体系：该组织有一套管理 AI 风险的成文流程。是流程，不是结果。它是"内部有人负责"的有意义信号，对任何具体模型则是无意义的信号。
- 模型卡与系统卡是三者中最有用、也最缺乏标准化的材料。读它是为了看评测了什么、在什么数据上评测的——然后注意到：那些评测是对孤立状态下的模型跑的，而你要把它部署进一个带工具、带不可信输入的循环里，那是一个失败模式不同的另一个系统。
- 监管身份是唯一会把义务转移到你头上的那一项。在欧盟《AI 法案》这类制度下，把别人的模型集成进你的产品，并不会把他们的合规转移给你；你会作为部署者取得属于自己的义务，而在某些配置下你还会继承提供者的义务。见面向智能体的欧盟 AI 法案。
务实的读法是：认证告诉你这家供应商是不是一家正经运作的公司——这对"要不要签"确实有用。它对你真正在管理的那份风险什么都没说，而那份风险是：组件的行为变了，你的系统悄悄不再做你验证过的那件事。
要证据，不要保证。
把那些无从作答的问题换成一份有具体交付物的简短索要清单。这里的每一项，一家称职的供应商都能在一周内拿出来；而供应商对"被这样问"的反应本身，就是信号。
- 模型端点最近十二个月的变更日志。不是路线图——是历史。行为改动了多少次？客户是在改动之前还是之后被告知的？
- 弃用记录。过去两年退役了哪些版本、客户实际拿到了多长的通知期——而不是政策上承诺了多长。
- 事故历史与状态页归档。可用性你自己就能查；你要读的是披露的质量。含糊的事后说明，是你自己那次故障时会拿到什么的预告片。
- 书面的数据流向答复：请求会途经哪些区域、存在哪里，其中哪些可配置、哪些是固定的。这关乎数据驻留，而且常常与营销页面暗示的不一样。
- 一个具名联系人和一条带时限的升级路径。没有响应时限承诺的"企业支持"就是个邮件列表。
索要的力度要与敞口相称。一个接收客户数据并执行动作的模型提供方，值得上面全部。一个你自己跑的开放权重模型，在这个意义上根本没有供应商风险——你换来的是运维负担，那是一笔不同、而且往往更划算的交易，也正是自建还是采购在问的问题。对每一家供应商都跑同一份问卷，正是供应商评审变成人人都学会绕道的表演的方式。
无论供应商承诺什么，都归你自己的那些控制。
合同条款分配的是事后的责任。下面这四项改变的是真实发生的事，而且没有一项需要供应商配合。
- 钉住版本，并把一次版本升级当作一次发布。如果提供方支持钉住快照，就用它，并让切换到新快照走与代码变更同样的评审。如果不支持，这个事实要白纸黑字进你的风险台账，因为它意味着你生产系统的一部分挂在别人的发版节奏上。
- 让一切走同一个出口。一个你自己掌控的网关，恰恰给了你原本想通过合同拿到的变更检测能力：按模型分的请求日志、让新版本与旧版本影子对跑的能力，以及一个可以切换供应商的单点。这与可观测性里的 collector 是同一个论证——它把一家供应商从编译进你各个服务里的依赖，变成一行配置。
- 每检测到一次供应商侧变更就重跑评测，并且首先要让变更可被检测：在每一条 trace 上记录模型标识符和任何版本头。没有这一步，行为漂移抵达时的形态是一次无从解释的质量回归，然后有人会花一周把它归因到自己改的那句提示词上。见评估驱动的智能体开发。
- 让第二家供应商热到足以当真。不一定要有实时流量——但提示词要可移植、评测集要能对两边都跑，并且要有一份真有人执行过一次的成文切换流程。没演练过的故障切换是计划，不是控制。
工具服务器适用同样的处理，只是绳子更短：钉住版本、禁止自动更新、凭据严格收窄到那台服务器所需、并审查它送回上下文里的内容。安全机制在智能体供应链安全和 MCP 安全反模式里；治理层面的要点很简单：工具服务器就是供应商，理应和其他供应商一起进台账。
出事时谁来回答。
最后一个治理问题其实与供应商无关。当一个建在第三方模型上的智能体伤害了某位客户，客户找的是你，监管找的是你，而供应商的服务条款——几乎必定免除模型输出责任，并把赔偿上限压在若干个月的费用——对这两场对话都帮不上忙。就假定责任落在你身上并据此设计；你几乎总会是对的，而那些例外值得它们所需要的那份具体法律意见。
- 按供应商指定问责人，而不是按系统。必须有人负责"注意到某个供应商变了"。见问责与角色。
- 让你的审计轨迹不依赖供应商。如果重建事发经过需要提供方的日志，你就无法按自己的时间线重建它——而监管的时间线是不可商量的。
- 专门演练"供应商引发的事故"。多数事故预案都假定过错在己方。真正值得演的那一场是：模型变了、质量掉了、供应商还没承认。谁来决定回滚，回滚到哪里？
如果这一页你只做一件事，那就把每一次模型调用放到一个你自己掌控的网关背后，并在每一条 trace 上记录确切的模型标识符。这一项改动同时给了你版本钉定、变更检测、供应商可移植性，以及你本来要向供应商索要的那份证据——而且无论你有没有从采购那儿拿到好答案，它都成立。问卷值得发；真正保护你的是网关，而且与问卷不同，它在合同签完之后仍然继续工作。