定制 AI 开发如何避免供应商锁定？企业应该掌握的 7 类核心资产

一家企业花钱定制了一套 AI 系统，运行一年后想换模型、换开发团队，甚至想把系统迁移到自己的服务器上，却发现很多东西都拿不走。

源代码没有交付，系统接口没人说得清楚，AI 的业务规则全部保存在开发商的平台里，连历史任务和测试数据都无法完整导出。

这就是 AI Vendor Lock-In，也就是 AI 供应商锁定。

对于准备采购定制 AI 开发服务的企业来说，避免供应商锁定并不是要求所有技术都必须自己研发，而是要在项目开始前明确：哪些资产归企业掌握，哪些依赖第三方平台，未来更换供应商需要付出多少成本。

真正值得长期投入的 AI 系统，应该随着企业的发展持续迭代，而不是只能由最初的开发团队维护。

为什么 AI 供应商锁定不只是模型问题？

很多人谈 AI 供应商锁定，首先想到的是 OpenAI、Anthropic 或其他模型平台。

但对已经进入生产环境的企业来说，模型往往不是唯一需要考虑的部分。

假设一家传统 B2B 企业已经使用 CRM 和 ERP，找外部开发公司做了一套 AI 销售系统。

AI 可以自动查询客户历史、分析新线索、判断客户归属、准备跟进内容，并把获准信息更新回 CRM。

第一年使用顺利。第二年，企业希望换一个模型，或者更换系统维护商。

问题来了：

• 新团队能不能拿到原来的应用代码？
• CRM 和 ERP 的字段映射有没有文档？
• AI 使用的业务规则保存在哪里？
• 原来的评估测试集是否可以继续使用？
• 生产环境的部署权限属于谁？
• 历史任务、审批记录和运行数据能不能导出？
• 更换开发公司以后，系统还能不能继续运行？

这些问题比“能不能把 GPT 换成另一个模型”更加实际。

AWS 在 2026 年发布的企业 Agentic AI 架构文章中，专门讨论了如何在多个模型、框架和服务商并存的情况下保持技术灵活性。

对企业来说，真正需要解决的不是完全消除外部依赖，而是让不同技术模块的依赖关系清楚、可维护、可评估。

企业应该掌握哪 7 类 AI 核心资产？

在正式签订定制开发合同前，建议至少把下面七类资产的所有权、使用权、访问权和交接方式明确下来。

这里要特别区分一个概念。

企业不一定需要拥有所有第三方技术的知识产权。

例如使用商业大模型时，模型本身仍然受模型供应商的服务条款和许可约束。

但是，围绕企业自身业务建立的代码、规则、数据、工作流和运营资产，应当在合同中明确约定权利边界。

1. 应用源代码：不只是能拿到代码

企业采购定制 AI 应用时，应该明确新开发代码的知识产权或使用授权。

至少需要问：

• 代码归谁所有？
• 是否包含第三方许可组件？
• 企业能否访问约定的代码仓库？
• 能否授权另一家开发公司继续维护？
• 构建、测试、部署方法是否有文档？
• 维护合同结束以后如何交接？

需要注意的是，拿到源代码不代表新团队就能立即接手。

如果没有数据库说明、环境配置、接口文档和部署流程，下一家供应商仍然可能需要花大量时间重新理解系统。

所以更完整的交付不只是 Source Code（源代码），还应该包含 Documentation（技术文档）、Deployment Configuration（部署配置）和必要的系统维护说明。

2. 企业数据、知识库和 Agent 记忆

企业通常知道自己拥有 CRM、ERP 里的客户和订单数据。

但 AI 系统上线以后，还可能形成一批新的运营资产。

例如：

• 清洗后的企业文档；
• RAG（检索增强生成）知识库索引；
• Embeddings（向量表示）；
• 客户上下文映射；
• 历史对话；
• Agent 执行状态；
• 员工修正记录；
• 业务审批历史；
• Agent 长期记忆。

其中有些资产可以根据原始数据重新生成，有些则包含长期积累的操作经验。

比如一家企业的客服 Agent 已经运行了一年。

这一年里，员工不断纠正错误分类、修正客户匹配、拒绝不合理的操作建议。

这些反馈可以成为系统后续优化的重要依据。

如果它们全部存储在供应商的封闭平台中，而且企业没有获得相应导出权，那么更换供应商就可能意味着丢失部分运营积累。

Oliver Wyman 在2026 年关于 Agentic AI 供应商锁定的分析中，特别提到了 Agent Memory（智能体记忆）和业务上下文带来的迁移难度。

因此，企业应该提前明确：

哪些数据需要保留，哪些可以导出，哪些需要按规定删除，以及数据导出后的格式是否能够继续使用。

3. CRM、ERP 和 API 集成：最容易被忽视的资产

对于传统企业来说，定制 AI 项目真正复杂的部分，经常不是模型，而是系统集成。

例如企业同时使用：

• Salesforce 管理客户；
• ERP 管理订单和账款；
• 老数据库保存运营信息；
• 内部门户处理审批。

AI 系统需要在这些软件之间完成业务操作。

这时，真正重要的技术资产包括：

• CRM 字段映射；
• ERP 数据结构；
• API 接口定义；
• 系统认证方式；
• 权限规则；
• 数据校验；
• 异常重试；
• 防重复写入；
• 数据冲突处理。

比如 Agent 判断一条销售机会应该进入下一个阶段。

它需要知道应该修改哪个 CRM 字段、满足什么业务规则、哪些字段需要人工审批，以及写入失败以后怎么恢复。

这些逻辑不应该只存在于某个工程师的个人经验里。

更适合的方式是建立清楚的接口文档，并尽可能使用受支持、可维护的系统接口。

OpenAPI Specification 就是一种用于描述 HTTP API 的标准化接口规范，可以帮助不同开发团队理解接口的能力和调用方式。

不过，采用 OpenAPI 并不意味着完全没有供应商锁定。身份认证、业务映射、数据权限和特殊系统逻辑仍然需要独立文档。

ZenAI 的AI 系统集成服务重点处理的就是这一层：在现有 CRM、ERP、数据库和 API 之间明确权威数据源、字段映射、读写权限、审批机制和故障恢复流程。

4. AI 工作流、Prompt 和业务规则

很多企业会把 AI 系统理解为一个模型加一个聊天界面。

但真正的业务系统通常还包含大量规则。

例如销售 Agent 可能需要根据：

• 客户所在地；
• 历史合作情况；
• 订单金额；
• 销售区域；
• 当前客户负责人；
• 企业特殊审批政策；

来决定下一步动作。

这些逻辑可能保存在代码、Prompt（提示词）、工作流配置或者 Agent 编排平台里。

如果开发公司没有把它们整理清楚，更换团队时就容易出现一个问题：

系统可以运行，但没人知道它为什么这样运行。

所以采购时应该明确：

业务规则如何管理，谁能修改，是否有版本记录，以及开发团队是否会交付相关文档。

从长期来看，这些规则属于企业运营知识的一部分，不能只关注模型代码本身。

5. Evaluation：未来更换模型时最重要的依据

假设企业现在使用模型 A。

半年以后，市场上出现一个更适合业务的模型 B。

开发人员告诉你：

“技术上可以更换。”

但企业应该如何判断换完以后不会影响现有流程？

这时就需要 Evaluation Dataset（评估测试集）。

它可以包含：

• 真实业务输入；
• 预期处理结果；
• CRM 字段更新规则；
• 禁止执行的动作；
• 异常情况；
• 人工审批条件；
• 系统失败场景；
• 业务验收标准。

例如销售 Agent 更换模型以后，仍然需要正确处理重复客户、销售区域归属和受保护字段。

如果没有以前的测试集，每次换模型都可能需要重新建立一套判断标准。

因此，评估资产不应该只在项目上线前使用一次。

它还应该服务于后续版本升级、模型迁移和供应商交接。

这也是为什么模型可迁移性不能只看“是否支持多个模型”，还需要测试不同模型在真实业务流程中的表现。

6. 服务器、部署环境和监控系统

有些企业虽然能够拿到应用代码，但生产环境长期由外部开发商完全管理。

这种合作模式本身没有问题。

真正需要确认的是：如果未来改变维护方式，企业能不能按照合同完成交接。

例如：

• Cloud Account（云账户）归谁管理；
• 服务器访问权限如何分配；
• 部署配置是否有文档；
• 数据备份存放在哪里；
• Monitoring Dashboard（监控看板）能否交接；
• 故障处理流程是否可复用；
• 核心第三方服务依赖有没有清单。

企业没有必要因为担心供应商锁定，就立即建立一支完整的内部运维团队。

可以继续使用外部托管和维护服务。

但“选择让供应商维护”和“只能让这一家供应商维护”，是两回事。

7. 上线后的运营知识与交接资料

AI 系统并不是上线以后就不会变化。

模型会升级，API 会调整，企业业务规则也会变化。

如果原开发团队已经维护系统一年，期间解决了大量问题，那么这些经验同样应该进入知识交接范围。

例如：

• 系统架构说明；
• 已知问题；
• 故障处理手册；
• 历史重要变更；
• 接口依赖；
• 测试说明；
• 监控配置；
• 维护责任；
• 新团队培训资料。

这些交付内容可以帮助后续团队更快接手。

采购定制 AI 服务时，合同应该约定什么？

英国政府的《AI 采购指南》专门提出，应在采购过程中考虑黑箱系统、技术标准以及供应商锁定风险。

对于企业定制 AI 项目，可以将以下事项作为采购检查框架。

具体权利和合同条款仍需要由相关法务与采购人员确认。

技术上的重点，则是把“系统以后可以交接”变成明确、可验收的交付事项。

如果企业正在准备正式采购，也可以参考 ZenAI 已有的《企业 AI 实施 SOW 应该包含什么？》，提前明确工作范围、交付物、验收和支持责任。

怎么实际测试 AI 系统有没有被供应商锁定？

判断一套定制 AI 是否容易迁移，最有效的办法之一是做一次小范围测试。

不需要等到真正决定更换供应商时才发现问题。

测试一：替换一个 AI 模型

选择一批有代表性的真实业务测试案例，让替代模型完成相同任务。

比较：

• 任务完成情况；
• 回答质量；
• Tool 调用；
• 权限规则；
• 响应时间；
• 成本；
• 最终业务结果。

重点不是两个模型输出完全一致，而是能否达到相同的业务验收标准。

测试二：复现一个系统集成

例如选择 CRM 查询接口。

根据交付的接口文档和配置说明，在独立测试环境中重新建立连接。

如果必须依赖原开发团队口头解释才能完成，说明技术文档还有不足。

测试三：验证部署与恢复

确认授权团队能否根据约定的代码、配置和部署说明恢复应用。

这一步可以检查：

• 是否缺少核心配置；
• 是否存在隐藏依赖；
• 是否需要额外账号；
• 是否有未记录的外部服务；
• 备份能否正确恢复。

测试四：导出业务与运营数据

按照合同约定，测试业务数据、工作流记录和获准保存的 Agent 运行历史能否导出。

同时要检查安全、隐私和保留期限要求。

测试五：让其他工程师接手一个小修改

例如：

• 调整审批阈值；
• 修改 CRM 字段映射；
• 更新一个业务路由规则；
• 重新运行回归测试。

如果新的工程人员能够依据文档完成修改，说明系统具备一定的可维护性。

这类测试并不能证明未来迁移完全没有成本，但可以提前发现影响长期控制权的问题。

一个真实业务场景：AI 销售系统未来需要换模型

假设一家企业希望自动化部分销售线索处理。

原来的流程是：

新询盘
→ 员工查询 CRM
→ 检查客户历史
→ 判断线索质量
→ 分配负责人
→ 准备跟进
→ 更新 CRM

定制 AI 开发后，部分环节可以由 Agent 完成。

但企业还需要保留原有的客户归属、业务审批和数据更新规则。

一年以后，如果需要更换底层模型，理想的项目结构应该允许企业保留：

• CRM 集成；
• 数据映射；
• 业务规则；
• 人工审批；
• 任务系统；
• 评估测试集；
• 监控流程。

然后针对新模型重新测试和调整 AI 部分。

当然，模型更换可能仍然需要修改 Prompt、Tool 调用或者性能参数。

但不应该因为换一个模型，就必须重新开发全部 CRM 工作流。

这也是企业采购定制 AI 时，需要在架构层提前考虑的问题。

ZenAI 如何承接这类定制 AI 项目？

ZenAI 的定制 AI 开发业务主要围绕企业已有工作流程、内部数据、权限要求和现有系统展开。

ZenAI 定制 AI 开发服务覆盖应用架构、模型选型、数据管道、API 开发、评估测试、生产部署以及上线后的持续迭代。

相比只关注单个模型，ZenAI 更关注 AI 应用周围完整的软件工程体系。

例如：

• 业务流程与需求梳理；
• 定制 AI 应用架构；
• 模型选型和集成；
• 企业知识库与数据管道；
• CRM、ERP 和内部系统连接；
• 用户权限和人工审批；
• 业务测试集与验收标准；
• 生产部署和监控；
• 技术文档与后续运维安排。

对于没有完整内部 AI 工程团队的传统企业、成熟企业和业务部门，这种交付模式可以把 AI 应用开发、系统集成和生产运营放在同一套项目中统筹。

在涉及长期资产控制和交接时，ZenAI 的服务框架也将知识产权、代码、支持范围、文档和交接安排纳入前期评估范围。

具体的所有权、许可与交接方式，则应在正式项目范围和合同中约定清楚。

这有利于企业在引入外部开发能力的同时，建立对自身 AI 项目的长期管理机制。

选择定制 AI 开发公司前，可以问这 12 个问题

1. 定制开发的源代码归谁所有？
2. 系统用了哪些第三方软件和模型？
3. AI 应用会部署在哪里？
4. 企业是否拥有约定的代码仓库访问权限？
5. CRM、ERP 和 API 集成是否有完整文档？
6. 以后更换模型需要修改哪些部分？
7. 业务规则和审批策略由谁管理？
8. 测试集和验收标准会不会交付？
9. 数据和重要操作历史是否可以导出？
10. 维护合同终止以后，监控和部署如何交接？
11. 新开发团队能否拿到必要的技术资料？
12. 是否有明确的迁移和过渡方案？

这些问题不一定需要老板或业务负责人亲自解决技术细节。

但在选择 AI 开发合作伙伴时，至少应该确认开发商能够清楚回答，并将关键事项写进交付范围。

最后怎么判断？

企业避免 AI 供应商锁定，并不意味着所有东西都要自己开发。

真正重要的是，提前明确什么必须由企业掌握。

对于一套定制 AI 应用来说，最值得关注的通常是：

源代码、企业数据、系统集成、业务规则、评估资产、部署环境和技术文档。

同时还要区分：

哪些资产属于企业，哪些通过第三方授权使用，哪些由外部供应商持续维护。

对于已经有 CRM、ERP、旧系统和专有数据的企业来说，这些问题应当在定制 AI 项目开始时就纳入架构和采购讨论。

项目能否上线固然重要。

但当模型升级、业务扩展或者合作伙伴变化时，企业能否继续维护和升级这套系统，同样值得关注。

如果企业正在规划定制 AI 应用，可以通过 ZenAI 的定制 AI 开发服务，在正式开发前梳理应用架构、现有系统、评估要求、部署方案与后续交接责任。

常见问题

什么是 AI 供应商锁定？

AI 供应商锁定是指企业使用某一家 AI 模型平台、开发公司或软件服务后，由于代码、数据、系统接口、业务规则或运营资产高度依赖该供应商，导致更换服务商需要付出较高成本。

企业如何避免定制 AI 开发中的供应商锁定？

应提前明确源代码权利、企业数据访问与导出、系统接口文档、AI 工作流规则、评估测试集、部署配置和后续交接安排，并在项目验收前验证关键资产是否可以按照约定交付。

企业采购定制 AI 后，源代码一定归企业吗？

不一定。需要根据具体开发合同以及第三方软件许可判断。建议在签约前明确新增开发代码、已有组件以及第三方依赖的所有权和使用权。

企业以后可以更换 AI 大模型吗？

很多项目可以，但迁移难度取决于原有架构。不同模型可能在 Prompt、Tool 调用、数据检索、性能和成本上存在差异，因此需要重新评估。

AI 模型锁定和开发商锁定有什么区别？

模型锁定主要指对特定模型或推理平台的依赖。开发商锁定则涉及源代码、系统集成、部署、维护和运营知识等方面。企业可能同时遇到两种问题。

定制 AI 项目交接应该包含哪些内容？

可根据合同约定交付源代码、系统架构、接口说明、部署配置、测试资产、故障处理文档、运营说明和必要的过渡支持。

没有内部 AI 团队的企业如何保持项目控制权？

企业可以指定内部业务负责人，明确代码、数据和部署权限，要求适当的技术文档，并与外部实施团队约定长期维护和交接机制。不需要先建立完整 AI 工程部门，才能开始规划这些控制措施。