企业私有化 AI 供应商怎么选？需求、RFP、PoC、数据边界、报价、合同、上线与退出验收清单

会议室里的演示往往很顺。供应商拿准备好的文档提问，模型几秒钟给出完整答案，界面也比内部系统漂亮。等企业把真实资料、真实权限和真实用户接进去，问题才陆续出现：扫描件识别不全，回答找不到出处，账号权限穿透，费用按调用量迅速上涨，模型升级后原来的效果又变了。企业采购私有化 AI，最终要拿到一套能长期运行、可以验收也可以退出的服务，演示只是起点。

采购目标写成业务结果

先说明要改善哪项工作，谁在使用，目前耗时、差错和成本是多少。比如客服查资料从十分钟降到两分钟，工程师能从受控文档中找到带出处的参数，或销售完成初稿后减少多少人工整理。只写“建设企业大模型平台”，供应商容易交付一套功能很多、实际没人用的系统。

别急着指定模型名称

模型更新很快，采购文件如果锁死某个品牌和版本，方案可能在合同执行期间就过时。更稳妥的写法是规定任务、数据边界、质量、响应时间、部署位置和可替换性，让供应商说明采用什么模型、为什么适合，以及版本变化后如何重新验证。

先决定买到哪一层

私有化 AI 可能只买模型许可，也可能包含算力、推理平台、知识库、权限连接、业务应用、实施和运维。采购团队要把各层责任拆开。模型能运行不代表文档能解析，知识库可检索不代表权限正确，应用上线也不代表内部人员具备接手能力。

自建、采购与混合方案各有代价

自建便于控制架构和节奏，但需要模型、数据、平台与运维能力；成品交付快，却可能受制于许可、接口和路线图；混合方案能保留关键数据与组件，也增加集成责任。立项阶段可以结合私有化 AI 算力项目立项清单核对资源和总成本，再选择采购边界。

组建能做决定的小团队

业务负责人定义任务与可接受错误，数据负责人确认资料和权限，技术人员评估架构与集成，安全和隐私人员检查风险，采购与法务处理报价和合同，运维人员判断交接后的工作量。每个角色都应在评分表里有明确项目，不能让技术演示替代业务和合规判断。

采购前先检查数据条件

英国政府的AI 采购指南建议在启动采购前评估数据可用性、治理和共享方式。企业也应先清点文档格式、语言、更新时间、重复内容、访问权限与责任人。资料本身混乱时，换模型通常只能生成更流畅的混乱答案。

需求分成硬门槛与评分项

数据不得离开指定环境、必须接入企业身份、生产凭据不得暴露，这些可以设为硬门槛。回答质量、管理体验、扩展速度和成本则适合评分。两类要求混在一起，容易出现安全底线被高分功能抵消，或非关键功能把真正合格的供应商挡在门外。

RFP 给出相同的业务背景

向候选供应商提供统一的问题说明、用户规模、数据类型、现有系统、预期流量、部署限制和验收方法。需要保密的部分可分阶段披露，并让各方在同一时间收到相同材料。只有输入条件一致，报价和方案才有可比性。

需求别写成某家产品说明书

前期交流常会带入某个供应商的术语、模块和架构。RFP 应回到输出与约束，允许不同技术路线作答。英国政府采购指南也强调从问题出发，并关注供应商锁定风险。若确有指定接口或基础设施，要说明它来自既有环境，而不是为了配合某个候选产品。

统一供应商答复格式

答复模块	供应商需要提交	企业核验方式
能力与边界	支持场景、限制、依赖和已知失败	测试集与现场问答
架构与数据	组件、数据流、部署位置、子处理方	架构评审与配置证据
安全与运维	身份、日志、漏洞、事件和升级流程	演练、报告与管理后台
实施与人员	里程碑、交付物、驻场和知识转移	履历、计划与样例文档
价格与退出	一次性、持续性、超量及迁出费用	统一工作量模型测算

把不确定项公开列出来

文档数量可能继续增长，用户规模可能只知道区间，某些老系统也未必有稳定接口。采购方应说明哪些数字已经核实，哪些只是估算，并要求供应商写出假设和价格敏感项。把不确定性藏起来，只会在变更单和延期里重新出现。

部署方式必须说清物理边界

“私有化”可能指客户机房、客户云账号、供应商专属租户，也可能只是共享平台中的逻辑隔离。要求方案画出模型、应用、向量库、对象存储、日志和管理平面所在位置，列明运维人员从哪里访问。合同与测试都应使用同一套边界定义。

算力报价要绑定负载

同样一台服务器，在不同模型精度、并发、上下文长度和批处理策略下，实际吞吐差距很大。供应商需按企业测试负载说明设备型号、显存、节点数、冗余、功耗和扩容方式，同时给出模型与推理参数。只比较服务器总价，无法判断每次有效回答的成本。

用户和流量模型不能省

统计注册用户、日活、高峰并发、平均输入输出、文件上传、批量任务和响应目标。在线问答、文档处理和模型评测最好分开估算。生产容量还要留出故障和升级空间，调度规则可参考企业 AI 工作负载调度清单。

PoC 不是免费咨询

概念验证要有负责人、预算、周期、数据范围、产出归属和结束条件。供应商为赢单投入多少人员，企业也应提供对应的业务与数据支持。没有约定的 PoC 容易无限加需求，最后留下一个无法进入生产的演示环境。

所有候选方使用同一测试包

准备统一的文档样本、问题集、用户角色、接口数据和资源上限。供应商可以调优，但要记录模型、提示词、检索参数、人工加工和测试时间。若一家使用真实资料和限定算力，另一家使用自选样例和云端大模型，两组结果没有比较意义。

测试集要覆盖平常与难题

常见问题决定日常价值，边界样本暴露系统上限。测试包应包含短文档、长文档、扫描件、表格、版本冲突、无答案问题、过期文件、同名实体和权限不同的用户。保留一部分供应商未见过的封闭样本，防止针对题库过度调优。

先写评分规则再看结果

采购方应在测试前确定正确、部分正确、错误和拒答的判定方法，写清证据不足时如何扣分。人工评审至少由两名了解业务的人独立完成，分歧再讨论。看到演示结果后临时调整权重，会让主观偏好披上量化外衣。

准确率不是唯一指标

NIST 的AI 测试、评估、验证与确认资料强调指标和场景之间的关系。企业可同时测任务完成率、事实正确性、引用有效率、权限违规、拒答质量、人工修改时间、首字延迟、完整响应时间、稳定性和单次有效任务成本。

用权重反映真实风险

评分维度	参考权重	一票否决示例
业务效果	30%	关键任务无法达到最低正确率
数据与权限	20%	越权返回或数据流向不明
安全与合规	15%	生产凭据暴露或无法响应事件
架构与运维	15%	无备份恢复或版本回滚能力
实施与服务	10%	关键人员和交付责任不明确
总成本与退出	10%	无法导出企业数据和配置

低频严重错误单独统计

平均分可能掩盖少量高后果问题。把权限穿透、捏造关键参数、泄露个人信息、执行错误动作和无法恢复等事件单列，规定最大允许次数。涉及客户权益、生产安全或财务决定时，一次严重错误也可能足以停止上线。

无答案时看它怎么处理

高质量系统不必回答每个问题。测试资料中故意放入没有依据、超出权限和含糊不清的问题，观察系统会拒答、追问、提示不确定，还是编造完整答案。供应商要说明阈值如何调整，拒答增加后对业务效率有什么影响。

引用要能回到原文

知识问答不能只显示文件名。点击引用应打开正确版本、正确页码或段落，用户无权访问原文时也不能借引用看到内容。抽查答案、引用与检索片段三者是否一致，并测试文件更新、删除和权限变化后索引多久同步。

中文文档处理要现场验证

合同、说明书和扫描图常含表格、印章、页眉、双栏和中英文混排。要求供应商在企业样本上展示解析结果，不要只看纯文本 PDF。记录丢页、错列、数字识别和章节切分错误，这些问题会直接影响后续检索与回答。

权限测试从反例开始

准备普通员工、部门主管、外包人员和管理员等账号，让他们搜索同一关键词。检查系统是否只返回各自有权查看的文档、片段、标题与引用。管理员后台、缓存、导出和日志也要测，权限控制不能只停在聊天界面。

提示词注入纳入采购测试

在网页、文档和检索资料中放入要求模型忽略规则、泄露提示词或调用外部工具的指令，观察系统怎样隔离内容与控制指令。供应商应说明过滤、权限、输出检查和事件记录，不应把“模型已经做过安全对齐”当成完整答案。

动作型 Agent 提高验收门槛

能发邮件、写工单、查客户资料或修改系统的 Agent，需要验证调用身份、工具白名单、参数校验、人工确认、幂等、超时、补偿和审计。每个动作都要知道由谁授权、对什么对象生效。详细项目可对照Agent 工具调用验收清单。

看供应商交证据的能力

安全问卷上的“支持”不能直接计分。要求提供配置截图、审计报告范围、渗透测试摘要、漏洞修复时限、恢复演练记录和实际导出样例。证据应对应本次产品、版本和部署方式，集团其他产品的认证不能自动覆盖当前方案。

软件与模型供应链都要盘点

NCSC 的安全 AI 开发指南要求关注模型、数据、库、框架和外部 API 等供应链组件。采购时应取得主要组件、来源、版本、许可、更新渠道和重大依赖清单，并约定供应商变化时的通知和复核。

第三方风险进入统一评估

NIST AI RMF 的实施手册把第三方模型、数据和软件纳入风险映射。企业应审查供应商测试结果、路线图、服务条款、更新计划和历史事件，同时判断双方风险容忍度是否一致。采购品牌知名度不能替代这些材料。

数据用途要写到合同里

合同需说明提示词、上传文件、检索片段、输出、反馈和日志是否用于训练、优化或人工支持，默认保留多久，企业能否关闭、导出和删除。若供应商使用子处理方，还要列明地点、数据类型、变更通知和企业的异议处理方式。

测试数据也受同样约束

PoC 常被误认为非生产环境，从而放松数据管理。即使系统尚未上线，真实客户资料和内部文档仍可能进入供应商环境。优先使用脱敏或合成数据；确需真实样本时，限定人员、环境、传输、留存和销毁，并在试验结束后验证删除。

租户隔离要做实测

让供应商说明计算、存储、向量索引、缓存、密钥与日志如何隔离。条件允许时，使用两个测试租户放入不同标记数据，检查搜索、管理接口、备份和支持通道是否串用。专属租户也要确认底层共享组件和运维权限。

密钥由企业控制

数据库口令、模型 API 密钥、证书和服务账号不应写在代码、镜像或交付文档里。确认秘密存储位置、访问审批、轮换、吊销与泄露响应。企业现有规范可结合配置和密钥管理清单验收。

日志既用于审计也需要保护

要求记录登录、模型与版本、知识源变化、策略命中、管理员操作、工具调用和异常，但不要默认长期保存所有提示词正文。企业应掌握日志字段、访问角色、脱敏、导出和销毁规则，并测试供应商停服时是否还能取得必要记录。

SLA 应覆盖业务任务

系统可访问不代表回答可用。除可用率外，SLA 可约定高峰响应、索引更新、严重漏洞修复、数据删除、事件通知、关键故障恢复和技术支持时限。每项指标写明测量位置、排除条件、报告频率与未达标处理，避免供应商单方面统计。

模型升级需要变更门禁

基础模型、嵌入模型、排序器和安全策略变化，都可能影响效果。要求供应商提前通知重大变更，在回归集上复测，保留版本记录和回滚方案。云服务无法固定版本时，至少要约定变化监测、影响说明和企业停止使用的权利。

报价放进统一成本模型

一次性许可、服务器、实施、接口改造、数据整理、迁移、培训、年度支持、模型升级和扩容都要计入。按 token、调用、用户或算力计费的项目，用同一组业务量计算三年情景，不要把低用量首年报价与自建全生命周期成本直接比较。

把超量和隐性费用问清

需要单列高峰扩容、存储增长、日志保留、备份、跨区流量、模型切换、额外环境、定制开发、驻场和退出支持价格。供应商若以“按实际发生”回应，应给出计量单位、单价、上限与审批方式。无法预测的费用要进入风险准备金。

避免用 PoC 价格判断长期成本

试验阶段数据少、用户少，供应商也可能投入售前资源。正式环境加入冗余、监控、安全和支持后，成本结构会改变。报价评审应使用生产规模与增长情景，并把免费期结束、折扣到期和许可证升级写入模型。

知识产权分别约定

区分企业原始数据、整理后的知识库、提示词模板、评测集、定制代码、配置、模型微调成果和生成内容。明确双方可以做什么、合同结束后还能保留什么。仅写“知识产权归甲方”太笼统，遇到供应商既有组件时很难执行。

验收不要只放在项目末尾

把架构、数据准备、PoC、试点、生产和交接设为不同里程碑，每阶段都有输入、产出、测试和签字人。前一阶段未通过时，不自动进入下一阶段。分段验收能尽早暴露数据与权限问题，也便于按交付证据付款。

付款节点跟可验证成果绑定

合同签署、设备到货、系统部署、业务验收和稳定运行可对应不同比例。每个节点引用具体交付物和合格标准，不以“完成开发”“平台可用”这种模糊表述结算。尾款应覆盖文档、账号、源码或配置、培训、退出材料与遗留问题关闭。

项目合同补齐 AI 特有条款

范围、里程碑、验收、源码、账号和退出仍是基础，可参考企业官网项目合同清单。AI 项目还要增加模型和数据来源、性能漂移、版本变更、训练用途、评测复现、人工监督与高风险输出责任。

把供应商团队写进承诺

售前演示人员未必负责实施。要求列出项目经理、架构、模型、数据、安全和运维人员及投入方式，关键人员变更需提前通知并提供同等能力替代。涉及分包时，企业应知道分包范围、地点、人员和供应商的最终责任。

交接从第一天准备

架构图、数据字典、部署步骤、配置基线、接口、运维手册、测试集和已知问题应随项目持续更新。不要等上线前一周再补文档。企业人员要实际完成一次部署、升级、备份恢复和故障定位，听过培训课不等于具备接管能力。

生产上线设独立门槛

PoC 通过只证明方案在有限条件下可行。生产前还要检查容量、身份、权限、监控、备份、恢复、漏洞、事件响应、用户支持和回滚。业务负责人确认使用方式与人工复核，安全和运维确认风险可接受，采购再释放对应款项。

上线后保留回归测试

将 PoC 题库、权限反例和高风险样本整理成版本化回归集。模型、提示词、文档解析或检索参数变化后自动或定期复测。NIST 的AI 资源中心收录了测试、评估、验证与确认资料，可用来完善企业自己的证据体系。

事件响应需要双方演练

模拟敏感数据误传、模型服务中断、越权回答、供应链漏洞和管理员账号失陷。验证谁先发现、如何停用、怎样保留证据、多久通知业务与受影响方，以及供应商能否提供日志和修复。合同里的联系电话要在演练中真正接通。

退出方案在签约前谈

约定数据、文档、向量索引、提示词、评测集、日志和配置的导出格式、时间与费用，列明删除证明、账号吊销、密钥轮换和许可证终止。关键场景还应有替代模型或降级流程。等关系破裂后再谈迁出，企业的议价能力已经很低。

用一次迁出小测验验真

在试点阶段导出一小批知识条目、配置和日志，由企业或第三方尝试恢复到独立环境。记录缺失字段、专有格式、工具依赖和人工工作量。供应商口头承诺“随时可迁移”，只有经过这次测试才有成本依据。

警惕几类采购信号

供应商不愿说明数据流和子处理方，只展示自选样例，拒绝固定测试条件，把所有错误归因于提示词，不提供版本与回滚机制，或把导出接口列为未来路线图，都会增加项目风险。报价显著偏低时，也要核对是否遗漏实施、算力、运维和正式许可。

验收表必须能直接签字

验收对象	合格证据	常见假通过
业务效果	封闭测试集达到预定分数并留存明细	现场问几个顺手问题
数据权限	多角色反例测试无越权且引用可追溯	只看管理员演示
性能容量	目标并发与长时压力测试达标	单用户响应很快
安全运维	漏洞、备份、恢复和事件演练有记录	提交一份功能清单
交付接管	企业人员独立完成部署、升级与恢复	供应商代操作后签字
退出迁移	样本导出、恢复与删除测试成功	合同写有“支持导出”

一个可执行的九十天节奏

首月完成问题定义、数据盘点、采购边界和 RFP，候选方用统一格式答复。第二个月在受控环境运行 PoC，封闭测试集由企业保管，同时完成架构、安全、合同和成本评审。第三个月只让达标方案进入试点，执行权限、压力、恢复、事件和迁出测试，再决定生产采购。

最终核对十二件事

签约前确认：业务结果可量化；采购层级和双方责任清楚；数据可用且有权限；候选方输入条件一致；PoC 指标提前锁定；严重错误单列；生产容量经过测算；训练、保留与子处理方写入合同；模型升级需要复测；三年成本可解释；交付文档和人员明确；迁出与删除已经做过样本验证。

采购质量最后落在证据上

企业选私有化 AI 供应商，最容易被界面、模型参数和一次性演示带偏。把需求、测试、合同、付款和退出都系在同一组业务证据上，采购团队才能知道系统解决了什么问题，风险由谁承担，后续变化怎样重新验收。若需要结合官网知识、内部资料与权限设计采购范围，可从凯乐丰 Colorfun 私有 AI 服务了解交付边界，再用本清单组织供应商比选。