2 篇博文 含有标签「ai-procurement」

你共享驱动器上那份签署了 14 个月的 AI 供应商合同是根据 SaaS 模板起草的。它保证了正常运行时间，指定了安全联系人，并将责任上限设定为 12 个月的费用。但对于你的提示词是否会被喂进下一次训练运行，当你依赖的模型被悄悄换成更小的变体时会发生什么，或者当监管机构询问时你的推理日志存放在哪个地区，它却只字未提。起草它的律师利用他们掌握的词汇量完成了一项称职的工作。但这些词汇量比现在的覆盖范围落后了一个世代。

采购团队仍在为错误的合同进行优化。标准的 MSA（主服务协议）打的是 2010 年代的战争——停机补偿、漏洞通知窗口、进入源代码仓库的知识产权赔偿。AI 供应商关系有着不同的攻击面，而最重要的条款往往在现有模板中连个标题都没有。如果一个团队任由去年的采购指南来处理今年的供应商技术栈，那么他们正在签字放弃一年内就会需要的筹码。

我合作过的一个采购团队花了 11 周时间，对照一份 312 行的 RFP（征求建议书）电子表格给 4 家 LLM 供应商打分。他们谈妥了 99.9% 的正常运行时间 (uptime)、每 1K 输入 token 0.0008 美元的价格、SOC 2 Type II 认证，以及一份光鲜亮丽的基准测试 PDF——该文件显示他们选中的供应商在 MMLU 上领先 2.3 分。合同在周五签署。随后的周二，供应商悄然发布了一个模型更新，该团队构建的客服代理开始将大约 14% 的退款请求路由到错误的队列。正常运行时间 SLA 得到了遵守。基准测试得分没有变化。采购流程完全按照设计运行，而系统依然坏了。

这就是 AI 采购鸿沟。企业采购用于管理软件风险的工具——功能清单、正常运行时间保证、安全问卷、样本基准测试——都是为输出可重现的系统而构建的。这些工具都无法衡量真正决定 AI 供应商是否能持续为你工作的因素：由供应商控制而你无法控制的随机表面的行为稳定性。