> 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/ai-vendor-evaluation-checklist.md).

# AI 供应商评估清单 2027：签约前的七项检查

本文整理自 Duaer 文档站，围绕企业 AI 落地，说明签约前应如何以岗位需求为起点、以数据去向为硬门槛、用自有文档做测试，并兼顾集成、退出路径与上线后的运营能力。

## 为什么 AI 供应商评估需要重新设计

多数 AI 供应商评估从一场演示开始，而演示通常是为了好看而设计的。厂商展示整洁的界面，流利地回答几个问题，再拿出一个客户案例。采购委员会看完会觉得印象不错，于是签下试点合同。几个月后才发现，工具读不了企业的真实文档，数据条款含糊不清，或者想换掉它的成本比原合同还高。问题通常不在于厂商撒谎，而在于评估衡量的东西不对。一份有用的清单，应该让团队关注销售周期结束之后依然重要的事情。

传统软件采购主要比较功能、价格和安全认证，这些仍然重要，但 AI 产品还多出三层复杂性。第一，输出质量取决于你的数据和任务，厂商的基准测试对你的具体工作流帮助有限。第二，底层模型可能在没有通知的情况下变化，改变团队已经围绕其建立起来的流程。第三，许多 AI 产品会悄悄把数据发送给第三方模型提供商，真正的供应链比厂商的 logo 所显示的更长。

正因为如此，如果只用一张权重相同的评分表，往往会奖励包装精美的演示。更好的做法是把评估拆成若干阶段，每个阶段设定明确的通过条件，避免一个在基本要求上不合格的供应商，仅凭出色的演示就进入下一轮。

## 从岗位出发，而不是从功能清单出发

在打开厂商官网之前，先用一段话描述这个岗位的工作：谁会使用这个工具，他们从什么输入开始，需要什么输出，如何检查输出，出错时会发生什么。这段话应该是清单的第一项，因为之后的每一条标准都要以它为尺度来衡量。

很多团队跳过这一步，结果在与任务无关的功能上比较供应商。客服团队需要从政策文档中可靠地检索信息，并能清晰地转交给人工处理。法务团队需要精确引用到具体条款，并保留审计记录。两者可能都会被包装成「AI 助手」，但它们并不能互相替代。先写清岗位，再让每个供应商说明其产品如何处理这个具体工作。

## 检查数据去向与可见范围

对大多数企业来说，这是第一道硬性关口。请供应商以书面形式回答：客户数据存放在哪里，哪些地区和子处理方会接触这些数据，数据是否被用于训练共享模型，日志保留多久，删除流程如何运作。还要询问产品能否在一种让数据留在企业自有环境中的配置下运行，以及这种配置在能力和运维上需要付出什么代价。

要区分合同承诺与技术控制。「数据不会用于训练」这样的声明有用，但还应追问，由哪些控制措施来保证访问权限、加密和租户隔离。如果厂商无法清楚描述这些内容，即使产品其他方面表现很强，也值得记录下来，作为一个需要关注的信号。

## 用你自己的文档测试，而不是厂商的演示集

这是大多数清单最薄弱的环节。厂商的演示使用经过挑选的、结构清晰的内容，目的是展示产品的最佳状态。而企业的真实环境里有过时的 PDF、重复的文件、扫描的表格，以及相互矛盾的制度。只有使用自己的真实材料抽样，测试才有意义。

请从真实工作中提炼出三十到五十个贴近实际的问题，并附上合格人员会给出的标准答案，组成一套测试集。让每一家入围的供应商在相同条件下回答同一套问题，并从准确性、答案是否有来源依据，以及系统在不确定时是否承认而不是臆测这几个方面打分。一周后再测一次，看结果是否稳定。

这一步也是结构化工作空间能发挥作用的地方。团队可以在 Duaer 中搭建同一个工作流，比较每个候选产品如何处理相同的问题和相同的文档，这会比一份幻灯片具体得多。目的不是根据一次运行就选出赢家，而是让差异足够清晰，使委员会能够基于证据进行讨论。

## 提交前检查集成与退出路径，并关注上线后的运营

每个 AI 供应商都会说产品能与你的系统集成，真正有用的问题是怎么集成。询问哪些连接器是原生支持的，哪些需要定制开发，由谁来维护，以及源系统的 API 变化时会发生什么。要求供应商提供一份书面清单，列出试点将接触的系统以及所需权限。最小权限原则很容易承诺，却很难长期维持，因此要检查权限是如何授予和收回的。

退出规划同样重要。询问如何以可用的格式导出你的提示词、工作流、知识索引、评估结果和日志；询问内容能否迁移到另一个平台，而无需重新编写。一家让退出变得困难的供应商未必是个坏选择，但你应该把这种难度计入决策成本。关于 AI 技术栈中依赖如何逐步形成、以及应留意哪些信号，可以参考我们的指南 [AI 供应商锁定指南](https://doc.duaer.com/zh/guides/vendor-lock-in-ai/)。

试点是受控环境，生产环境则不是。清单还应包括上线后厂商提供什么：回答质量的监控、检索质量下降时的告警、故障复盘流程，以及模型变更的通知机制。询问底层模型多久更新一次，能否锁定版本，以及在更新推送给用户之前如何进行回归测试。

售后条款也很关键。明确事故的响应时间，谁对到达客户手中的错误答案负责，以及随着用量增长，按量计费会如何变化。许多合同在试点规模下看起来合理，到了生产规模就变得昂贵，因此应要求厂商提供三种用量水平下的成本模型，而不是只给一个报价。

如果供应商是咨询或转型服务伙伴，而非软件提供商，标准则应转向交付能力和知识转移。我们的指南 [企业 AI 转型服务选型指南](https://doc.duaer.com/zh/guides/enterprise-ai-transformation-services-2027/) 对这一情形有更深入的说明。

## 给供应商打分并记录理由，然后本周就行动

最后，把调研结果转化为一张简单的评分表。以岗位描述为锚点，将数据处理和集成作为门槛而非分数，并基于你自己的测试集为输出质量打分。记录每家供应商通过或未通过每道门槛的原因。书面理由比一个数字更有价值，因为当情况变化时，例如出台新法规或发布新模型，委员会可以据此重新审视决定。

行动建议：选一个即将进行的 AI 采购项目，用一段话写出它的岗位描述。然后从真实的工单、文档或请求中整理出三十个问题组成测试集，把同一份问题清单和同样的样本文件发给每一家入围的供应商。在下一轮演示之前，请每家供应商提供书面的数据处理条款和退出流程。你可以在 Duaer 中运行这一流程，让团队在投入预算之前，基于相同的材料比较候选产品。可以先访问 https://www.duaer.com 注册试用，看看这套工作流是否适合你们的评估。

好的 AI 供应商评估清单，不是为了预测哪款产品能在演示中打动人，而是为了看清签约一年之后，哪款产品仍然能正常工作、保持合规，并且依然可以被替换。

## 常见问题

### AI 供应商评估应该重点看哪些指标？

建议先以岗位需求为基准，把数据去向、访问控制和退出路径作为必须通过的门槛；通过门槛后，再用自有测试集评估准确性、答案的来源依据以及系统在不确定时是否诚实。功能清单和价格可以作为次要参考。

### 为什么不能只根据厂商的演示来决定采购？

演示使用的是经过挑选的理想化内容，无法反映企业真实文档中的过时文件、重复材料和相互矛盾的制度。用自己的真实样本在相同条件下测试，并隔一段时间复测，才能判断结果是否稳定。

### 如何判断 AI 供应商是否存在锁定风险？

可以询问提示词、工作流、知识索引、评估结果和日志能否以可用格式导出，内容能否迁移到其他平台而无需重写，以及模型版本能否锁定。把迁移成本计入决策，比事后才发现退出困难要好得多。