影响一：审批看证据
预算审批从「有没有规划」转向「有没有验证」。为什么：试点成本低、结论可比，管理层更愿意为通过评测的场景追加投入。怎么做：立项材料附上小样本测试结果与失败案例，明确本次投入要回答的问题，而不是只写预期收益。
影响二：供应商看运营
评估维度从产品功能扩展到交付与运营能力，包括知识更新、问题响应与退出支持。怎么做：在评分表里给运维与交接单独设权重，要求提供同类场景的交付清单；边界：交付清单由供应商提供，真实性需通过访谈或试用核对。
影响三：推理进科目
调用与推理支出开始作为独立运营科目被跟踪，与软件许可费分开管理。为什么重要：这类支出随用量波动，混在项目费里无法预测。怎么做：给每个场景设用量台账与月度预算，超限触发复核而非自动追加。
影响四：数据治理前置
项目启动阶段就要确认数据可用性、权限与质量，否则模型效果无从谈起。怎么做：立项前完成数据清单盘点，标注来源、更新频率与责任人；缺数据的场景先补数据，不要靠模型能力硬撑，否则试点结论会失真。
影响五：三方共管
业务定任务与验收，技术定架构与集成，合规定数据与标识，三方缺一不可。怎么做：在项目确认单里写明三方职责与决策节点，争议事项留升级路径；边界：合规结论由客户方法务与合规负责人确认。
适用与不适用
适合谁
- 正在立项或复评 AI 项目的业务负责人
- 需要重排预算科目与归集规则的财务团队
- 跨部门协作中职责与决策权不清的项目组
不适合谁
- 只做个人效率工具、不涉及组织流程的团队
典型场景
某零售企业上线智能选品助手，第一版由技术部门单独推进，业务未参与验收，上线后无人使用。复盘后改为三方共管：业务定选品任务与验收指标，技术负责接口与权限，合规确认会员数据处理方式，并在确认单上约定决策节点。第二版按周复盘使用率与接管情况。
可执行步骤
- 立项材料附上小样本测试结果、失败案例，并写清本次要验证的问题。
- 供应商评分表加入运维、交接与退出支持的权重，并注明评分依据。
- 为每个场景建立用量台账与月度预算上限，交由业务负责人确认后执行。
- 启动前完成数据清单盘点，逐项标注来源、责任人与更新频率并签字。
- 在确认单中写明业务、技术、合规三方职责、决策节点与争议处理方式。
常见坑
- 立项只写预期收益，没有任何验证结果，评审时无法回答「凭什么信」，预算很难批下来。
- 供应商评分只看功能演示，交付后无人维护知识库，效果半年内快速衰减，续约时无据可依。
- 推理支出混在项目费里，用量上涨时无人预警，季度末集中超支，财务只能被动追加预算。
- 数据可用性没核就开工，模型效果差，团队误以为是模型选型问题，反复换模型，白白消耗预算。
自检与验收清单
- 立项材料是否包含小样本测试结果与失败案例
- 供应商评分表是否包含运维、交接与退出支持权重
- 每个场景是否建立独立用量台账与月度预算上限
- 数据清单是否标注来源、更新频率与责任人姓名
- 三方职责与决策节点是否写入项目确认单并可查
常见问题
三方共管会不会拖慢项目？
前期会多两次会议，但能减少后期返工与推诿。可行做法是把三方介入点固定在立项、数据交接与验收三个节点，中间过程由项目经理推进，避免每次决策都全员到场。
推理支出应该算 IT 费用还是业务费用？
按受益场景归属更合理：由场景所属业务承担，IT 负责计量与披露。这样业务能看到自己的用量与成本，避免公共池子里的支出无人负责。具体科目设置以客户方财务制度为准。
数据治理前置要做到什么程度？
至少做到三件事：知道数据在哪、谁能用、多久更新一次。不必一开始就做全量治理，按场景圈定范围即可；范围外的数据先不动，避免治理工作拖垮项目节奏，后续再逐步扩展。