AI结果计价的验证机制与审计设计

按结果收费的讨论已经很多，但真正决定它能否落地的，不是定价模型本身，而是验证机制。一个“被解决的工单”从产生到进入账单，中间要经过计量、归因、确认三个环节，任何一个环节缺失，结果计价都会退化成一场关于口径的争论。

验证机制的第一层是数据源的独立性。如果计费所依据的数据完全由供应商自己的系统产生，采购方实际上无法确认这个结果是否真实发生。可行的做法是让验证锚点落在采购方可以独立读取的位置：业务系统里的工单状态变更、订单流水、通话记录。供应商可以定义“什么算解决”，但“是否真的解决”应当由采购方一侧的数据确认。这两件事分开，是审计设计的基本前提。

第二层是归因规则的显性化。在多数真实业务里，AI很少独立完成全流程，人工复核、既有系统流转都在贡献结果。归因规则必须在合同里写清楚，而不是留到结算时协商。常见做法有三种：只有AI端到端独立完成才计费；AI参与即按固定比例计费；按人工介入程度分档计费。三种方式没有优劣，但选择哪一种会直接改变供应商的行为动机。独立完成才计费会激励供应商收紧自动化边界，按参与计费则容易诱发“什么都算我一份”的扩张冲动。

第三层是审计的周期与成本。逐条验证最准确，但成本可能高于结果本身的价值；抽样审计成本可控，却需要接受一定的误差范围。设计上通常采用分层策略：对高价值、低频次的结果逐条核验，对高频低价值的结果按周期抽样，并约定可接受的偏差阈值。偏差超限时触发全量复核，而不是简单按比例扣款。这套机制的关键参数是验证成本与单笔结果价值的比值，比值越高，越应该走向抽样和事后审计。

审计设计里最容易被忽略的是争议处理路径。结果计价天然会产生对账分歧，合同需要预先约定：分歧由谁裁定、依据哪一侧的数据、在多长时间内完成复核、争议期间是否暂停计费。把这些写进条款，比事后争论“这个工单到底算不算解决”要省力得多。同时，负向结果的责任分配也应在同一套框架里处理——AI给出错误判断造成损失时，是按结果未达成处理，还是走独立的赔偿条款，两种路径的举证责任完全不同。

从治理角度看，验证机制会反向塑造供应商的能力建设。当计费依赖可审计的数据链路时，供应商必须把执行过程留下结构化痕迹，这本身就会推动系统从“给出答案”向“留下证据”演进。对采购方而言，评估一个结果计价方案时，与其先谈单价，不如先问三个问题：数据从哪里来、归因怎么切、分歧谁来裁。这三个问题答不清楚，单价的谈判基础就不成立。