> For the complete documentation index, see [llms.txt](https://doc.duaer.com/zh/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.duaer.com/zh/guides/vendor-lock-in-ai.md).

# 2027 年 AI 供应商锁定：如何识别并规避依赖风险

本文整理自 Duaer 文档站，围绕企业 AI 落地中的供应商锁定问题，说明锁定如何在模型接口、数据、提示词、编排和合同等层面悄然形成，并给出识别、规避与评估退出成本的可操作方法。

## 为什么 AI 供应商锁定是真正的痛点

过去两年，多数企业采用 AI 的速度都很快。团队先测试一个模型 API，试点跑通后，工具便在各个部门扩散开来。问题通常在之后才显现：合同续签时价格上涨，某个模型被弃用，或者原本合理的工作负载迁移计划，成本远超企业预期。AI 供应商锁定的真正痛点正在于此：合同本身未必糟糕，而是企业一旦想离开，就必须重建那些它以为自己已经拥有的东西。

## AI 锁定为何比软件锁定更难察觉

传统企业软件的锁定很常见，专有数据库、定制集成和许可条款都看得见。AI 锁定则更加隐蔽，因为依赖分散在团队很少记录的多个层面。一套在某个模型系列上效果很好的提示词，换到另一个模型上可能表现迥异。针对某家供应商输出风格建立的评估集，切换后可能失去参考价值。不同供应商生成的嵌入向量无法直接比较，因此基于它们构建的向量索引实际上已与该供应商绑定。

依赖也是逐步累积的。比如使用供应商专有的函数调用格式，或采用其托管的微调流水线，单独看每一个决定都合情合理。但叠加起来，就形成了一个迁移代价高昂的系统。大多数公司直到真正尝试迁移时，才会发现这一点。

## 锁定通常藏在哪些层面

与其按供应商名称来看，不如按层次来梳理锁定。一份实用的盘点通常覆盖五个层面。

第一是模型访问层，典型的锁定来源包括供应商专有 API、速率限制和专有 SDK。关键的可移植性问题是：我们能否通过同一接口调用第二个模型？

第二是数据与嵌入层，锁定来源包括向量索引、微调数据集，以及以供应商格式存储的日志。关键问题是：我们能否无损导出原始文档、切片和标注？

第三是提示词与评估层，锁定来源包括针对某个模型特性调优的提示词，以及包含供应商生成答案的评估集。关键问题是：测试用例和评分规则是否由我们自己掌握？

第四是编排层，锁定来源包括建立在单一平台上的智能体工作流、工具定义和记忆机制。关键问题是：另一个团队能否仅凭我们的文档重建这套流程？

第五是商业条款层，锁定来源包括用量承诺、自动续约、价格变更条款和弃用窗口期。关键问题是：模型或价格变化前，我们能提前多久得到通知？

第四和第五层最容易被忽视。采购评审通常聚焦单价，而离开的成本往往藏在工作流设计和合同措辞之中。

## 三个常见误区

第一个误区是认为多云或多模型就意味着没有锁定。如果每个应用都被硬编码到某一供应商的 API 和提示词风格上，同时使用两家供应商也无济于事。基础设施层面的冗余，并不等同于应用层面的可移植性。

第二个误区是认为开源模型可以消除锁定。开放权重确实降低了对单一模型许可的依赖，但并没有消除对推理服务栈、特定硬件配置，或只熟悉某一工具路径的团队的依赖。开放不等于可移植。

第三个误区是认为切换只是更换一个 API 密钥。实际上，切换需要重新运行评估、调整提示词、统一输出格式、重新测试护栏，并确认合规和数据处理条款仍然成立。API 密钥只是其中最小的一部分工作。

## 在不过度设计的前提下实现可移植性

目标不是避免一切依赖，那既不现实也没有价值。目标是让依赖变得可见、可定价。三项设计选择能解决大部分问题。

第一，在应用与模型供应商之间放置一层轻量的内部接口。这不必是庞大的框架，可以是一个小型服务：统一请求格式，将输入和输出记录到企业自有存储中，并映射供应商特定的参数。关键在于，应用团队调用的是你们自己的接口，而不是直接调用供应商 SDK。

第二，拥有最重要的资产：源文档、切片规则、评估数据集、标注样本和提示词版本。把它们存放在自己可以控制的格式中。如果供应商保留了你们的微调数据，或只能通过专有格式导出，那么你们其实并不真正拥有让系统运转起来的核心资产。

第三，把可移植性写进合同。有用的条款包括以开放格式完整导出数据、模型弃用前的最短通知期、对价格上涨设置上限或审查触发条件，以及在服务条款发生实质变化时的终止权。这些条款很少能完全消除风险，但能把模糊的依赖转化为可以谈判的依赖。

如果团队正在比较多家供应商，可以用同一份清单以一致的方式评估每个候选方。你可以直接在 Duaer 中建立这类结构化评审，包括层级盘点和合同检查清单，https://www.duaer.com，让评估过程可重复，而不是只存在于某个人的电子表格里。

## 如何衡量退出成本，以及本周可以做什么

只有清楚知道离开一家供应商需要付出多少代价，这段合作关系才可控。一个简单的方法是进行退出演练：选择一个生产环境工作流，估算把它迁移到第二个模型或平台需要多长时间。统计工程工时、评估工作量、重新训练或重新调整提示词的工作、并行运行的过渡期以及对业务的干扰。再把这一数字与该供应商的年度支出进行比较。

结果很少是精确的数字，但这项练习很有价值。如果估算的退出成本是年度合同金额的许多倍，说明存在实质性依赖，需要主动管理；如果很小，风险可控，可以把精力放在其他问题上。每当主要依赖发生变化时，比如出现新的模型版本，或基于某项专有功能构建了新的工作流，都应重复一次演练。你还可以跟踪一个简单的依赖评分，记录有多少系统直接调用该供应商、多少系统依赖专有功能、多少系统具备已记录的备用方案。趋势比绝对分数更有参考价值。

如果某个已投入生产的 AI 应用，可以先花一个小时做一次锁定评审。列出应用与供应商发生接触的每一处：API 调用、SDK 导入、嵌入存储、微调数据、提示词文件和合同条款。把每一项标记为可移植、部分可移植或已锁定。然后挑选业务影响最大的一个已锁定项，写下一个具体的降低依赖步骤，例如把提示词迁移到受版本控制的文件中，或在评估集中加入一个备用模型。并且把清单分享给负责合同的团队，而不只是工程师。

如果正在评估某个 AI 平台，可以在 https://www.duaer.com 注册试用，在签订多年期承诺之前，用真实工作流测试自己的可移植性清单。借助试用确认哪些内容可以导出、接口的实际表现如何，以及在你们的环境中真实的切换成本是多少。

AI 供应商锁定并不能靠选对品牌来避免，而是要通过拥有自己的数据、评估体系和接口来管理，并在真正需要之前，就把退出路径写进合同。

## 常见问题

### 如何判断我们现有的 AI 系统是否已经被供应商锁定？

可以从模型访问、数据与嵌入、提示词与评估、编排以及商业条款五个层面逐一盘点。对每一项问三个问题：能否通过统一接口调用第二个模型？能否无损导出数据和测试用例？另一个团队能否仅凭文档重建流程？如果多数回答是否定的，说明依赖已经较深。

### 更换 AI 模型供应商的实际成本通常有多高？

切换成本远不止更换 API 密钥。通常还包括重新运行评估、调整提示词、统一输出格式、重新测试安全护栏、确认合规与数据处理条款，以及并行运行的过渡期。建议选择一个生产工作流做退出演练，估算工程工时和业务干扰，再与年度合同金额对比，从而得出可参考的量级判断。

### 合同中应该写哪些条款来降低 AI 供应商锁定风险？

常见的有效条款包括：以开放格式完整导出数据的权利，模型弃用前的最短通知期，对价格上涨设置上限或审查触发条件，以及在服务条款发生实质变化时的终止权。这些条款不能完全消除风险，但可以把模糊的依赖变为可以协商的依赖。