AI采购立项受理：将业务需求转化为可审查的需求
在寻源事件开始前，明确需求、约束、利益相关方、数据输入和审批责任归属。
AI采购立项受理：将业务需求转化为可审查的需求
简要回答
AI采购立项受理是一个受控步骤，它将“我们需要一个AI供应商”之类的请求，转化为可审查的业务问题、使用边界、证据包、数据计划、风险分类、利益相关方地图、验收标准和审批记录。它发生在接触供应商或发布RFP之前，而不是在供应商选择过程中。
在已指定责任人的情况下，只有当其批准了需求、AI适用性、数据访问、风险级别、可测试需求和评估计划后，才能发布寻源事件。这个前端关口是规范化采购流程的一部分，而不是行政形式。
六部分CLEAR受理框架
使用 CLEAR——Context、Limits、Evidence、Accountabilities 和 Release——防止AI采购请求沦为功能愿望清单。
1. Context：定义需求，而不是预设AI方案
记录：
- 运营问题及受影响用户
- 当前业务量、周期时间、成本、错误、返工、投诉和服务水平
- 期望结果及其衡量方式
- 不采取行动的后果
- 非AI替代方案，包括流程重设计、基于规则的自动化、现有工具和人工改进
例如，“购买一个AI合同工具”并不是充分的需求陈述。可审查的陈述应是：“在保留法务对偏离条款最终裁量权的前提下，减少品类经理查找已批准后备条款所花费的时间。”
英国政府的AI procurement guidance同样建议，在接触市场之前先定义问题而不是预设解决方案，并评估相关数据是否存在。
2. Limits：建立允许和禁止的用途
明确用户、工作流、地点、人群、决策、集成和渠道。然后写出明确的排除项。
一个合同支持系统可能被允许检索条款、总结差异并起草问题；但可能被禁止接受条款、发送对供应商的承诺，或在未经审查的情况下更改已批准的操作手册。
还应记录隐私、安全、无障碍、记录管理、预算、进度、托管、身份、集成和保留方面的约束。预期用途和部署环境是NIST AI Risk Management Framework的核心内容。
3. Evidence：区分事实、推断和决策
每次受理以及后续评估都应区分：
| 证据类别 | 示例 | 必需记录 |
|---|---|---|
| 已观察证据 | 已签署合同、发票、已验证故障、已审查结果 | 来源、日期、沿袭、质量和访问权 |
| 模型推断 | 风险评分、分类、预测、摘要或生成式响应 | 模型/版本、配置、输入、输出、不确定性和局限性 |
| 人工判断 | 审批、例外、解释或风险接受 | 决策者、权限、理由、证据和日期 |
这种区分有助于支持可复现测试，并帮助识别故障究竟来自源数据、模型行为还是下游决策。但仅凭这一点，并不能确定责任归属，也不能证明输出一定正确。
4. Accountabilities：将利益相关方映射到具体决策
应包括业务负责人、预期用户、受影响群体、采购、法务、隐私、安全、数据、架构、财务、记录管理、无障碍、风险，以及在相关情况下的劳动代表。
不要写“法务审批”。应明确对特定决策负责的角色，例如：“区域隐私官批准将支持工单记录用于评估。”审批责任人必须有权接受风险或阻止流程推进。
5. Release：让需求可测试
在发布前，定义基线和目标指标、测试场景、重要子群体、容差、失败阈值、覆盖程序、回退处理、监控、变更控制、可移植性和退出要求。
结果应能顺畅衔接更广泛的AI采购规划，并且如果后续进入供应商沟通，也能衔接受治理的AI谈判准备工作。
必需的内部和外部数据输入
内部输入
- 需求证据： 业务量、流程时间、服务水平、错误、返工、投诉、申诉、成本和已知失效模式
- 运行环境： 用户角色、权限、决策权、受影响人群、语言、无障碍需求、峰值负载和故障后果
- 企业约束： 政策、风险偏好、隐私分类、记录保留计划、安全架构、集成、预算、人员配置和截止日期
- 数据就绪度： 清单、字典、来源、沿袭、采集方法、法律依据、质量、完整性、时效性、代表性、许可和保留限制
- 评估资产： 具有代表性的场景，以及在可行情况下，投标方无法获得的独立测试集
- 供应商历史： 合同、价格、事件、故障、既往试点、切换成本和数据权利限制
外部输入
- 适用法律、法规、采购政策和标准
- 市场替代方案，包括可信的非AI选项
- 供应商架构、系统卡或模型卡、版本历史和依赖项清单
- 训练、微调和评估数据的说明，但应受合法知识产权限制约束
- 独立基准和与场景相关的测试结果
- 安全报告、事件历史、分包处理方、托管服务商、基础模型和开源依赖
- 定价单位、业务量假设、价格调整机制和生命周期成本情景
- 输入、输出、衍生工件和微调组件的所有权及允许用途
- 可移植格式、API、导出程序、迁移支持和退出费用
- 在适当情况下，来自用户、领域专家、员工代表和受影响群体的反馈
机器学习、生成式AI和代理式工作流分别适用于何处
机器学习可用于对受理请求进行分类、预测需求、检测重复项或分配初步风险指标。它需要带标签的历史结果、具有代表性的运营数据、稳定的定义和验证数据。其局限包括漂移、嵌入式历史偏差、在代表性不足条件下表现较弱，以及具有误导性的总体准确率。
生成式AI可用于总结附件、起草需求问题、识别缺失字段，并将业务语言转换为结构化初稿。它需要已批准的源文件、检索权限、提示词和模型版本记录，以及有依据的评估示例。它可能生成缺乏支持的陈述、遗漏约束，或给出不一致的答案。NIST Generative AI Profile强调来源追踪、供应商风险、监控、事件处理和回退安排。
代理式工作流可请求补充缺失信息、路由审查、对照政策比较响应，并跨系统准备审批材料。它们还额外需要权限映射、工具边界、状态和动作日志、停止条件以及回滚程序。代理不得仅因路由条件满足，就发布RFP、授予数据访问、接受风险、选择供应商或作出承诺。
人工决策与审批关口
以下生命周期关口应由指定人员审批：
- 问题： 业务负责人确认基线和期望结果。
- AI适用性： 架构或AI治理团队确认，相较于更简单的替代方案，使用AI是合理的。
- 数据授权： 数据所有者以及隐私或法务职能批准用途、访问、共享和保留。
- 风险分类： 风险责任人判断该用途是否具有重大影响、涉及安全，或属于其他高风险情形。
- 寻源发布： 采购和业务负责人确认需求可衡量，且没有不必要地偏向特定供应商。
- 授标与部署： 获授权责任人接受证据、例外情况、安全态势和剩余风险。
- 重大变更： 变更审批权人批准新的模型、用途、数据集、提供方或自主级别。
- 暂停或退役： 获授权人员可以停止运行、启动回退处理并批准最终数据处置。
只有当审查人员具备足够的能力、时间、信息、独立性和权限时，人工审查才是有意义的。
可执行的AI采购立项受理模板
将以下内容复制到你的受理系统中：
- 问题与基线： 当前发生了什么，业务量、成本、速度和错误水平分别是多少？
- 结果： 需要什么可衡量的结果，谁会受益，谁可能受损？
- 已考虑替代方案： 为什么不选择流程变更、现有软件、规则方案或不采取行动？
- 允许的AI角色： 起草、排序、检测、预测、建议还是执行？
- 禁止用途： 系统绝不能决定、发送、保留或更改什么？
- 数据： 来源、权利、敏感性、质量、代表性、保留和独立测试情况如何？
- 证据标签： 事实、模型推断和人工决策将在记录和界面中如何呈现？
- 验收标准： 指标、子群体、延迟、安全、失败阈值和覆盖要求是什么？
- 生命周期控制： 监控、事件、版本变更、可移植性、回退和处置如何安排？
- 审批责任人： 谁批准问题、数据、风险、发布、授标、部署和变更？
- 未决缺口： 哪些假设仍未解决，谁必须在何时之前解决？
谈判场景：受理如何改变商业对话
某业务部门申请一项面向400名用户、每用户每月60美元的生成式AI服务：年费用288,000美元。受理后发现，只有120名用户需要每周访问，而280名用户只是偶尔使用。受理还识别出每年200万页文档、48小时导出窗口要求，以及禁止使用买方数据进行训练的限制。
采购团队现在可以谈判一个混合方案，而不是接受仅按席位计费的锚定方案：120个完整席位、面向偶发用户的按使用量计费访问、明确的页面额度、封顶超额定价、删除证明、重大模型变更前的回归测试，以及定价明确的迁移支持。此时，当团队将这些已批准的事实和约束转化为供应商问题、交换条件包和底线时，Negotiations.AI 可能会发挥作用——但该平台不应虚构需求数据，也不应批准例外。关于准备机制，请参见AI Negotiation Platform: What Procurement Teams Need Before Supplier Meetings。
可练习的AI提示词
- “将这份需求陈述转化为可衡量结果，并标记缺乏支持的假设。”
- “将所附受理材料区分为已观察证据、模型推断和人工判断。”
- “识别缺失的数据权利、测试、监控、可移植性和变更控制要求。”
- “仅基于已批准的受理事实起草五个供应商问题；凡需人工验证之处请标记。”
局限性
AI采购立项受理无法证明某个产品一定适用，无法消除历史数据中的偏差，也无法将不成熟的指标变成可靠的验收标准。供应商基准未必适用于买方场景，平均准确率可能掩盖子群体失效，而解释也不能证明正确性。
独立评估比仅由供应商进行测试更有力，但也无法覆盖所有真实世界条件。监控可能发现新出现的问题，却不能防止所有损害；同时，提供方、模型、API和安全过滤器的变化也可能在授标后改变行为。应记录不确定性和证据缺口，而不是将其伪装成需求。
来源
- NIST AI Risk Management Framework 1.0
- NIST Generative Artificial Intelligence Profile
- UK Government Guidelines for AI Procurement
- OMB M-25-22: Driving Efficient Acquisition of Artificial Intelligence in Government
- Regulation (EU) 2024/1689—the EU AI Act
延伸阅读
- ISO/IEC 42001:2023—AI management systems
- U.S. GAO: Artificial Intelligence Acquisitions
- FAR Subpart 27.4—Rights in Data and Copyrights
常见问题
AI采购立项受理是否等同于供应商评估？
不是。受理定义了开展可辩护评估所需的问题、边界、证据、数据、风险和权限。只有在寻源发布之后，供应商评分才会开始。
当所请求的数据尚未准备好时，应如何处理？
暂停、缩小或重新设计该用例。指定责任人，在要求供应商承诺性能之前，先解决来源、质量、权利、代表性或测试数据缺口。
采购方是否应接受供应商的标准基准？
应将其视为外部证据，而不是适用性的证明。应针对买方可控场景、相关人群、运行条件和失败成本进行测试。
AI能否自动批准低风险受理？
AI可以对请求进行分类和路由，但风险分类和寻源发布仍应由指定人员承担责任。自动化应保留证据、适用规则、模型版本、覆盖记录和最终决策。
免责声明：本文提供一般性采购信息，不构成法律、财务、安全或监管建议。