外部AI服务悄悄改变以后，机构对客户的承诺是否也改变了？

《AI进入工作之后》· 第三季“当AI开始代表组织”· 第十一篇

一家企业在网站上承诺：AI助手只根据经过批准的知识库回答，重要问题会显示来源，超出范围时转给员工。系统上线时经过测试，表现符合要求。

三个月后，模型供应商更新了默认模型。检索服务也调整排序算法，安全过滤器更换版本，接口把最长上下文缩短。企业没有修改自己的代码，产品名称和网页说明都没有变化，但客户开始看到更肯定的回答、更少的引用，以及部分长文档被遗漏。

从供应商角度看，这可能只是持续改进；从企业角度看，服务行为已经偏离原先对客户的承诺。

机构不能把“我们没有改系统”当作没有变化。只要外部组件能够改变客户得到的答案，供应商变化就是机构产品变化，需要被发现、评估并在必要时重新授权。

客户购买的是稳定的服务边界，不是一个模型名称

客户通常不知道也不需要知道底层模型版本。他依赖的是企业对结果作出的承诺：资料范围、服务用途、响应时间、隐私处理、人工升级和错误补救。

供应商可能只承诺API可用率，却不保证回答风格、引用频率、拒绝边界或同一输入长期得到相似结果。企业若把技术服务级别协议直接当成客户服务保证，就会留下空白：基础设施“正常”，客户体验却已经实质变化。

因此，组织应把承诺拆成可观察指标。例如：回答必须来自指定资料；没有支持时应明确停止；重要事实显示可点击来源；特定主题必须转人工；不得调用未批准工具。这些指标才能在外部组件变化后重新测试。

一个AI工作流可能在七个地方变化

即使内部代码不动，行为仍可能由以下组件改变：

1. 基础模型：能力、拒绝、语言风格和上下文处理；
2. 系统指令：供应商默认提示或安全策略；
3. 知识检索：切分、索引、排序和返回数量；
4. 安全过滤：输入输出阻止和分类阈值；
5. 工具接口：参数、权限、超时和错误处理；
6. 数据与基础设施：区域、保留、日志和分包商；
7. 用户界面：引用、警告、人工转接和历史记录展示。

版本登记如果只保存模型名称，就无法重建客户当时使用的服务。完整版本应记录这七类组件的标识、配置和生效时间，以及供应商无法提供的未知部分。

英国国家网络安全中心关于安全运行与维护的指南要求监测系统行为、管理更新、记录日志并规划事件响应。英国国家网络安全中心：《Secure operation and maintenance》 对依赖外部AI的企业，这意味着监测不能止于自己的部署记录，也要关注供应链变化。

合同中的“可以随时更新”不能替代机构判断

云服务需要迭代，企业也不可能要求所有模型永远冻结。但采购合同和技术安排至少应处理：

• 哪些变化必须提前通知；
• 是否可以固定版本或延迟迁移；
• 旧版本支持和紧急回退时间；
• 数据使用、保留、区域与分包商变化；
• 日志、评测和事故信息可获得程度；
• 重大变化后供应商提供什么验证材料；
• 终止服务时数据和配置如何导出。

“供应商保留随时修改服务的权利”可能是标准条款，却不等于企业可以在高后果用例中被动接受每次修改。若供应商不能提供足够可见性、版本控制或回退能力，组织必须缩小用途、增加自己的控制，或选择不同服务。

ISO/IEC 42001把供应商、风险、变更、绩效评估和持续改进纳入AI管理体系。ISO：《ISO/IEC 42001—Artificial intelligence management systems》 采购AI不是买完一个组件，而是长期管理一个会变化的依赖关系。

不要等待供应商通知，主动检测行为漂移

供应商通知可能不完整，或者“非重大更新”对特定业务恰好很重大。组织需要自己的回归评测。

可以保留一组代表性任务：常见问题、边缘案例、无答案问题、敏感主题、不同语言、长文档、提示注入和人工升级。每次定期运行，比较：

• 事实正确与来源支持；
• 引用是否出现并指向正确版本；
• 拒绝和升级是否符合政策；
• 语气是否把建议写成承诺；
• 不同客户群体是否受到不同变化；
• 延迟、成本和失败模式。

评测不要求每次逐字相同。生成系统会变化，真正需要稳定的是制度边界。答案可以更自然，但不能悄悄获得批准退款的权限；检索可以更快，但不能开始使用未批准资料。

NIST AI风险管理框架强调持续测量、监测和风险响应，而不是只在上线前评估。NIST AI Resource Center：《AI RMF Core》 供应商漂移说明“通过一次测试”不能永久授权一个外部组件。

按客户承诺，而不是供应商版本号，给变化分级

组织可以把变化分成三类。

操作性变化不改变承诺，例如性能优化且行为测试保持稳定。可以记录后继续运行。

重要变化影响准确、引用、拒绝、成本或客户路径，但仍在批准用途内。需要回归测试、业务所有者确认，可能需要更新说明。

实质变化改变资料用途、权限、客户待遇、人工升级、安全或法律风险。它应被视为新部署，重新开展影响评估和批准，在完成前限制或暂停使用。

分类不能由供应商单方面决定。“小版本更新”可能使某一行业术语理解退化；“新功能”可能默认开启外部工具。业务影响是机构自己的判断。

变化发生后，旧结果是否需要重新检查？

供应商更新不仅影响未来回答。如果新版本揭示旧模型存在系统性错误，组织还要判断过去哪些客户结果可能受影响。反之，如果新版本本身产生错误，需要找出从生效到停止期间的所有相关输出。

这要求将客户结果与完整工作流版本连接。没有版本血缘，组织只能知道“某天使用过供应商服务”，不能识别哪些回答由哪个配置产生。

重新检查应按后果排序：内部草稿可以不回溯；已经决定价格、资格、投诉或安全行动的输出需要更严格评估。发现受影响者后，应按照第十篇所讨论的撤回和补救方式处理，而不是只恢复旧模型。

客户需要知道的是服务边界变化，而不是每次技术更新

把所有供应商发布说明转发给客户没有帮助。客户需要知道会改变其选择和信赖的变化，例如：资料使用方式改变、回答不再含引用、人工支持减少、系统开始作出新类型决定，或原有结果需要复核。

通知应说明何时生效、影响什么、客户是否需要采取行动，以及怎样提出问题。企业不能在隐私政策或服务条款中悄悄更新一行，然后假定客户理解实际服务已经不同。

另一方面，细小性能更新无需制造通知疲劳。关键是建立清楚门槛，并由业务、风险和客户责任共同判断，而不是只由技术团队看接口是否仍能调用。

澳大利亚AI伦理原则中的透明度、可靠性与安全、可争议性和责任同样适用于服务变化。澳大利亚工业、科学与资源部：《Australia’s AI Ethics Principles》 透明度的对象不是每一个参数，而是对人有意义的系统能力与限制。

没有退出能力，就没有真正的供应商治理

企业可能发现供应商变化不可接受，却无法迁移：提示词、评测数据、知识索引、日志和工具接口都与单一平台绑定。此时合同上可以终止，运营上却没有选择。

退出计划应在采用时建立，而不是事故后才开始。至少包括：可导出的知识和记录、供应商无关的评测集、接口适配层、替代人工流程、迁移测试和旧数据删除证明。

业务还需要“降级模式”。当高级模型不可用时，系统可以只提供静态搜索、限制到低风险问题或转人工，而不是在未经评估的备用模型上维持全部功能。

退出并不要求随时无成本更换，而是让组织能够在承诺与供应商行为冲突时真正选择停止。没有这种选择，客户承诺最终由供应商路线图决定。

结论：供应商可以改变组件，机构必须维护承诺

外部AI服务持续变化并非异常，而是产品现实。问题在于，机构是否有能力把这些变化翻译成自己的风险、服务和责任判断。

最终原则是：

任何能够改变客户所见事实、引用、权限、待遇或人工路径的供应商更新，都应被视为机构服务的潜在变化；组织必须通过完整版本记录、独立回归评测、分级批准、客户通知门槛和可行退出方案来维护原有承诺。

企业可以外包模型、托管和工具，却不能把“我们向客户提供什么”外包成一个自己看不见的变量。供应商负责改变产品，机构仍负责决定改变后的产品是否还能以自己的名字继续运行。

主要资料

• 英国国家网络安全中心：Secure operation and maintenance
• ISO：ISO/IEC 42001—Artificial intelligence management systems
• NIST AI Resource Center：AI RMF Core
• 澳大利亚工业、科学与资源部：Australia’s AI Ethics Principles

继续阅读：浏览《AI进入工作之后》系列文章