民间人工智能采购应验证什么？
验证确切发布的产品、完整的数据和身份路线、买方实际工作负载的质量、有意义的人工审核、安全且可恢复的操作、完整生命周期成本、合同支持和可行的退出。 本地模型仅回答托管问题。
寻求答案及其证据
自信的陈述不是证据。 记录供应商的答案、证明答案的工件、验证者、开放的例外情况以及必须再次审核的日期。
工作负载和决策边界
- 哪些具体任务、用户和业务流程在范围内？
- 哪些输入、输出、动作和用途是被禁止的？
- 输出错误、缺失、偏差或延迟会造成什么危害？
- 哪位负责人使用什么程序审查输出？
- 什么可衡量的结果支持继续、改变或停止的决定？
证据： 批准的用例声明、数据分类、风险负责人、审查程序和接受阈值。
产品、型号及数据路线
- 指定产品是否公开发布，经过验证的获取路径在哪里？
- 哪个型号、版本、许可证和更新源将运行该工作负载？
- 提示、文档、输出、历史记录、日志和备份在哪里传输和保存？
- 哪些供应商、客户和可选提供商服务接收内容或元数据？
- 是否可以在目标环境中禁用并验证所有外部路由？
证据： 发布记录、物料清单、数据流图、提供商列表、配置导出和观察的网络测试。
质量和人力监督
- 测试了哪些代表性、边缘、对抗性和滥用示例？
- 如何衡量事实支持、严重错误、拒绝和无支持的答案？
- 审稿人能否检查答案背后的来源、引文或原始输入？
- 评审者是否有时间、能力、权威和非 AI 后备？
- 哪个模型或提示更改会触发回归测试和重新批准？
证据： 版本化测试集、基线、错误分析、审阅者记录、升级路径和变更控制标准。
安全、操作和恢复
- 用户、管理员、API 密钥、范围、配额和撤销是如何控制的？
- 谁拥有 TLS、网络暴露、存储加密、秘密和强化？
- 哪些内容或元数据进入日志、遥测、监控和支持渠道？
- 备份、恢复、回滚、离线更新和灾难恢复如何测试？
- 适用哪些警报、事件、漏洞和支持终止流程？
证据： 架构和责任矩阵、访问测试、审计样本、运行手册、恢复结果和支持策略。
商业条款和退出
- 哪些用户、设备、节点、环境和商业用途需要License？
- 哪些基础设施、模型、监控、备份、支持、税收和人员成本被排除在外？
- 签订了哪些支持时间、响应目标、维护和升级权利？
- 合同结束时哪些内容可以导出、迁移、卸载或保留？
- 哪些续订、价格变更、终止、数据删除和过渡条款适用？
证据： 详细报价、许可和支持条款、假设、所有权图、出口测试和记录的退出计划。
可测试的要求
根据工作量和组织的政策调整这些条款。 用工件、测试或接受阈值替换模糊的形容词。
供应商应确定确切的建议产品和版本、生命周期状态、支持的平台和可验证的获取路径。 路线图组件应单独标记，并排除在当前能力评分之外。
供应商应记录本地、客户托管、供应商运营和可选第三方服务的每个内容和元数据路径，包括存储、保留和禁用。
提议的系统应在买方批准的、具有记录版本、阈值、严重错误分析和可重复回归方法的代表性测试集上进行评估。
买方应定义系统可能支持但不做出的决策。 操作程序应指定负责的审核员、升级、覆盖和非人工智能后备。
响应应分配身份、API 密钥、TLS、网络控制、模型、秘密、监控、审计、保留、备份、恢复、事件和更新的所有权。
报价应说明所有假设和排除情况。 合同应说明支持范围、续订和终止条款、可导出资产、删除责任和过渡协助。
证据缺失时暂停购买
路线图作为版本出售
屏幕截图、SKU、源存储库或保留商店名称显示为可用产品，无需经过验证的获取路径。
“私有”，无数据流
该提案表示本地或本地，但未标识许可、遥测、身份、更新、支持或可选提供商连接。
演示视为验证
仅显示选定的提示； 没有代表性的测试集、严重错误分析、版本记录或回归阈值。
未经授权的“人在循环中”
没有指定审阅者、审阅时间没有资金、来源证据不可用，或者该人无法推翻并停止该过程。
一控通用无处不在
假设一个产品或部署的一项功能跨每个应用程序、服务器、模型或组织服务，而没有特定于产品的证据。
以 TCO 形式呈现的不完整价格
该估算忽略了硬件或云基础设施、模型许可证、人员、监控、备份、支持、税收、迁移或退出工作。
从候选到受控使用的四个门
顺序比日历更重要。 在其所有者接受证据和例外情况之前，请勿进入下一阶段。
接受范围
业务和风险负责人批准工作负载、数据、禁止用途、负责任的审核员和可衡量的阈值。
技术证据已接受
产品、数据路径、访问、质量和基础设施测试通过了预期版本和配置。
操作演练
团队完成访问撤销、警报处理、备份、恢复、回滚、故障、事件和支持练习。
记录购买决定
审批者记录接受的限制、未解决的缺口、所有者、总成本、合同条款、回滚触发器和下次审核日期。
在联系销售之前核实公开事实
这些页面将公开版本、实施的控制、客户配置和已知限制分开。 然后，私人审查可以集中于确切的部署和未解答的问题。
评估团队的直接答案
我们应该从 RFI、RFP 还是试点开始？
当工作量或市场不清楚时，从简短的信息请求开始。 当需求和评分稳定时使用 RFP。 在生产承诺之前保留工作负载试点作为证据门。
本地部署是否足以批准系统？
否。它可以满足托管或数据传输要求，但准确性、权限、模型许可证、访问、监控、恢复、人工监督和法律适用性仍需要证据。
供应商认证是否使我们的使用合规？
否。认证或鉴证报告有明确的主体、体系、期限和范围。 查看该范围，然后分别评估您的工作负载、配置和操作义务。
提案应如何评分？
首先设置强制门，然后权衡工作负载质量、边界拟合、操作证据、可用性、成本和合同条款。 不要让高功能分数抵消失败的安全或数据要求。
合约是否应该命名模型？
记录评估的型号和版本，同时定义更换和更新的受控流程。 无限期冻结一个模型可能会产生不同的维护和安全风险。
Software Tailor 会回答我们的问卷吗？
是，对于已定义的产品和部署。 发送工作量、架构、截止日期和所需的证据。 我们将区分公开事实、客户控制的配置和需要私人审查的项目。