采购团队拿到一份AI网关功能表，七个栏目全部标注“支持”；平台团队却无法确认策略是否能在真实请求中执行，安全团队也看不到脱敏与审计样例。采购AI网关前，功能名称必须转成正常、异常、恢复和退出证据，否则交付落差会被留到上线阶段。

采购证据：七项生产能力分别要求配置、运行、失败和退出材料，供应商演示只作为理解入口，不作为最终验收。

第一组能力决定能否可靠接入与路由

协议与模型接入要验证企业实际端点、字段、流式和错误语义，不以“兼容”二字代替测试。模型路由要验证静态规则、应用差异、后端健康、失败切换和策略回退，并保留命中原因。

采购问卷应要求候选方案说明哪些能力原生给予、哪些依赖集成、哪些由企业自行维护。模型数量只是目录规模，无法证明接口差异、版本更新与异常路径已经被治理。

身份、配额与数据保护需要联动

身份与权限要关联应用、用户或租户，避免共享密钥；配额与限流要说明超限时是拒绝、排队还是降级，并证明策略能够保护后端；数据保护则核对日志脱敏、内容处理、网络和存储边界。

三项能力要使用同一测试身份贯穿。若身份只在入口出现，后续日志和用量无法关联；若限流只按全局请求数，关键业务与普通任务无法区分；若为了审计保存完整敏感内容，又会形成新的风险。

审计观测和故障降级决定长期可运营性

审计与观测应回答谁在何时调用哪个模型、命中什么策略、结果如何、消耗多少、异常由哪层产生。故障降级则验证上游超时、限流、不可用和网关自身故障时，系统能否收敛影响，并让调用方取得明确结果。

生产能力不是功能存在，而是异常发生时仍能解释、控制和恢复。 降级可能改变输出或数据边界，必须配置适用范围和人工接管，不能只追求请求始终成功。

七项能力要经过同一条采购证据链

下图把需求条目经过配置、运行、异常和退出材料转成采购结论。七项能力分布在链路周围，避免每项各自演示却没有共同证据标准。

退出能力必须在合同和交付前确认

退出场景包括导出应用、模型、策略、用量和审计数据，撤销凭证，迁移接口，保留必要记录并停止旧入口。不能等到合同结束才发现配置无法导出、日志不可读或应用高度依赖专有SDK。

七项能力的概念边界可用 AI网关入口治理 校准；供应商尽调和长期服务责任可参考 AI平台采购评估 的通用方法。

七项能力可以按项目阶段分批采购，但必须明确哪些是当前硬门槛、哪些是后续扩展。任何被写入合同的能力都应有对应验收动作、证据格式和责任边界。

七项能力要进入同一份供应商澄清与验收矩阵

采购、平台和安全团队应共享一份矩阵：每一项能力对应业务场景、正常请求、失败请求、配置证据、运行证据、恢复动作、数据边界和责任主体。供应商可以标注原生、集成或定制，但不能只用“支持”作为回答。无法在POC展示的部分要说明后续验证条件。

矩阵还要区分本期硬门槛、可选能力和未来扩展。身份、路由、流量保护或审计如果属于上线前提，就必须在合同中有验收动作；高级成本分析或复杂策略可以分阶段，但应预留数据导出和接口，避免后续只能整体替换。

交付责任需要写到具体对象。供应方可能负责软件与实施，企业仍要负责业务身份、数据分类、审批流程和运行值守。若某项依赖第三方身份、日志或模型服务，也要明确故障升级和版本兼容由谁处理，防止三方互相等待。

验收完成后保留未顺利获得项和替代路线。关键项未满足时淘汰，不用总分稀释；非关键项可以限期补齐，但要设置复验窗口。该矩阵既支撑供应商比较，也能直接转成实施清单和最终交付记录。

七项能力对应的实施量不能藏在“定制支持”里

协议接入可能需要客户端适配，模型路由需要维护目录和规则，身份权限需要连接现有认证系统，配额限流依赖业务分级，数据保护和审计还要接入企业日志与制度。供应方应为每项列出开箱配置、标准集成、定制开发和企业自担工作，并说明版本升级后哪些接口需要重新验证。

采购预算除软件外，还应覆盖联调环境、测试样本、策略初始化、日志存储、培训、运行交接和故障演练。不能确定的人天和费用保持待评估，但工作对象必须列出。若关键能力只能依靠脚本或管理员人工操作，评审需要记录执行频率、双人复核和误操作回退，而不是仍标记为完整自动化。

合同验收建议把七项能力分别映射到正常请求、失败请求和恢复动作。身份与数据保护不顺利获得属于硬风险；路由、限流或审计缺少可查询证据，也不能由其他项目加分抵消。条件接受的能力要限制应用和时间，并约定补交材料与复测责任。

退出场景应纳入最终一项联合演练：导出策略和应用映射，停止一个测试应用的旧凭证，将其切回替代入口，再核对用量与审计记录。供应商需要说明停止服务后的数据交付和删除责任，企业则确认内部系统与人员能够接管。这样七项能力才贯穿采购、实施和退出全周期。

最终供应商澄清还要列出版本与许可边界：哪些能力属于当前交付，哪些需要额外组件或服务，升级后配置和日志能否保持兼容。无法在合同前确认的内容保留为待验证，不用未来路线图替代本期采购证据。

下一步建议

把七项能力做成一页供应商问卷，为每项写一个真实场景和一个失败场景。要求候选方案提交配置、日志、指标、恢复和退出样例，再选择关键项进入POC。采购结论应标明原生、集成、定制和企业自担责任，避免“支持”成为唯一答案。

常见问题

七项能力是否都必须一次采购？

不一定一次全部实施，但应在架构与合同层看清边界。企业可以根据当前模型数量、应用范围、数据敏感度和团队能力分阶段建设，例如先完成身份、路由、限流和审计，再扩展成本与高级策略。阶段化不等于忽略未来迁移和数据接口。

采购文件应区分本期硬门槛、可选能力和后续扩展，并为硬门槛定义验收动作。若某项暂不采购，也要说明谁承担相应风险。这样可以控制范围，又不会因早期架构封闭造成二次替换。

阶段采购仍要保留完整架构边界。当前不采购的能力需注明风险承担者、未来接口和触发条件；硬门槛则对应明确场景、证据和复验窗口，避免“后续支持”在合同中变成无法验收的空白。

厂商演示能否替代POC证据？

不能完全替代。演示有助于理解对象和操作流程，但通常使用理想数据、管理员身份和正常路径，无法证明企业真实客户端、权限、限流、上游异常、日志脱敏和恢复动作。采购结论需要在约定环境中使用双方认可的场景。

若项目风险较低，可以缩小POC范围，但仍要保留至少一个真实调用、一个越权或超限、一个上游异常和一次配置导出。演示材料可作为补充说明，不能单独支撑生产能力与合同验收。

演示之后至少复跑真实客户端、越权或超限、上游异常和配置导出。每次保留请求结果、配置与日志，由应用、安全、平台分别签认。范围较小可以减少场景，不能删掉与生产责任直接相关的失败证据。

开源AI网关如何评估长期责任？

评估开源方案时，要把软件许可、社区版本、升级、漏洞响应、构建镜像、配置迁移、兼容测试、监控和故障值守逐项分配给内部团队或服务商。开源可给予灵活性，但不会自动消除这些工作，也不能用下载成功证明生产支持。

POC除了功能，还应执行一次升级或配置迁移模拟，检查文档、回退和数据导出。采购服务时明确服务商负责的版本和响应边界；完全自建时则评估人员与交接能力。结论应围绕责任，而不是开源或商业标签本身。

开源采购需要把许可、构建、升级、漏洞响应、兼容回归、监控和夜间值守逐项分配。由服务商承担的内容写入服务范围，由内部承担的内容进入人员与交接计划；责任无人接手时，即使功能可用也应暂缓。