资本行动前如何审计 AI 声明

一个精美的演示并不能证明一门生意的存在，它只能证明有人准备了一个精美的演示。懂得如何审计 AI 声明，意味着拒绝把一次受控的交互混淆为技术能力、客户价值或可行的运营模式。

这个区分之所以重要，是因为 AI 公司往往是分层出售的。第一层是一个引人入胜的结果：更少的客服工单、更快的核保、自动化的研究、自主的运营。第二层是一个技术故事：专有模型、代理式工作流、微调、检索、集成。第三层通常在资金到位之后才被发现，那就是部署的现实：脆弱的边缘情形、隐藏在幕后的人工干预、不清晰的单位经济性，以及那些喜欢演示胜过真正需要产品的客户。

AI 可以创造真实的价值，也可以让普通软件在短时间内看起来超凡脱俗。创始人和投资者需要一套审计方法，在路线图、采购决策或投资意向书把乐观变成一笔昂贵的承诺之前，把这两种可能性区分开来。

从声明入手，而非架构

大多数尽职调查之所以出错，是因为接受了公司的叙事框架。创始人说这个系统“自动处理理赔”，对话立刻转向模型选型、检索质量和集成。这些问题确实重要，但它们不是首先要问的问题。

首先，要界定产品实际声称能做什么。它是起草一份建议、完成一个工作流、做出一个决策，还是取代一个现有的岗位？所承诺的好处是速度、准确性、成本降低、收入增长、风险降低，还是因为克制显然已经离场而“以上皆是”？

只有当一个声明足够具体、具体到可能失败时，它才是可审计的。“为企业提供 AI 驱动的智能”无法被测试，因为它在运营层面上没有任何意义。“对于某类特定文档，将首轮文档审查时间缩短 40%，同时将异常率保持在约定阈值以下”则可以被测试。

请公司用一句话陈述其声明，其中包含四个要素：用户、工作流、可衡量的结果，以及边界条件。边界条件包括数据质量、人工审查要求、数据量、延迟、受监管的用例，以及集成依赖。如果这个声明在这种精确程度下崩塌，那不是一个信息表达问题，而是一个证据问题。

如何对照部署现实审计 AI 声明

审计的核心问题很简单：当这个系统遭遇真实客户环境中那些混乱、不完整、对抗性的，或者仅仅是枯燥的条件时，会发生什么？

一次演示通常包含精心挑选的输入、一个已知的任务、一个配合的用户，以及一个随时准备介入的操作员。生产环境则包含相互矛盾的源材料、权限问题、陈旧的数据、异常的请求、采购约束、变更管理，以及一个悄无声息的事实：很多人不会仅仅因为某个软件存在就去使用它。

请求查看从原始输入到业务成果的完整工作流，不是屏幕录制，不是模型基准测试，而是真实的流程序列：数据到达、系统处理、用户根据输出采取行动、发生异常、有人纠正、而这个纠正会或不会改变未来的表现。

相关的问题很直白：

• 有多少百分比的任务是在没有人工干预的情况下完成的？
• 有多少百分比需要审查、纠正或升级处理？
• 哪些故障被自动捕获，哪些会到达用户？
• 在不同的客户数据集上，而不仅仅是最好的数据集上，表现如何变化？
• 在推理、检索、监控、支持和人工兜底之后，每个已完成任务的成本是多少？

不要接受没有分布的平均值。一个平均准确率数字可能掩盖了这样一个系统：它在常规案例上运行得非常漂亮，却恰恰在客户风险敞口最大的地方失败。一个能处理 85% 简单工单的模型也许是有用的。而一家声称自己已经消除了某个客服职能的公司，其举证责任则截然不同。

自主性也是同理。“代理”常常是对某个工作流的慷慨标签，而那个工作流不过是让模型从一份预先批准的简短行动菜单中做选择。这也许仍然具有商业价值，但它不是自主运营，而这个区分会影响风险、人员配置、实施时间和价格。

索取无法排练的证据

最好的证据难以摆拍，也昂贵到难以伪造。一个具有可衡量使用量、留存率和工作流成果的真实客户部署，比一段优雅的技术解释更有分量。一个在生产环境中运行的、有名有姓的集成，比一张堆满 logo 的幻灯片更重要。一个在初始试点之后扩大使用量的客户群，比一千次热情洋溢的探索性通话更能说明问题。

对于早期公司，证据会是不完整的，这很正常。问题在于，公司是否清楚它已经证明了什么、尚未证明什么，以及为了让业务成立必须成真的是什么。

请索取与公司发展阶段相符的底层材料：

• 评估设计，包括测试集、成功标准、基线和已知的失败模式。
• 产品遥测数据，展示激活、重复使用、完成率、升级情况和实现价值所需的时间。
• 客户证据，展示用户是否改变了行为，以及买家是续约、扩展，还是仅仅容忍了一次试点。
• 单位经济性，将模型和基础设施成本，与实施、支持和所需的人工运营分开。

警惕那些在技术上真实、但在商业上无关的证据。一个强劲的基准结果，并不能证明买家会改变某个工作流。一次成功的概念验证，并不能证明可重复的部署。一份已签署的合同，并不能证明采用，尤其当客户尚未到达那个节点：续约成为对价值的判断，而不是一次礼貌的推迟。

在相信 ROI 之前审查基线

AI 的 ROI 声明常常因为一个无人检视过的基线而被夸大。供应商可能把它的系统与一个缓慢的人工流程作比较，而客户其实可以用更好的工作流软件、改进的搜索、更干净的数据或一个有针对性的规则引擎，就获得大部分成果。

这并不意味着这个 AI 产品毫无价值，它只是改变了比较的对象。正确的问题不是“AI 能做到这个吗？”，而是“相比这个买家可用的其他方案，这种方法是否能带来实质上更好的经济性或成果？”

让公司识别出现有的方法、其当前成本、其错误率，以及替换它的真实实施负担。要把安全审查、数据准备、集成工作、培训、流程重新设计和高管注意力的成本都算进去。这些成本有一个恼人的习惯：它们总在供应商的 ROI 计算器已经宣布胜利之后才冒出来。

然后测试反事实假设。如果把模型拿掉，产品里还会剩下什么价值？有时答案是一个工作流层、一项专有数据资产、一个分发渠道或一个集成足迹，这些可以是持久的优势。有时答案是围绕着商品化模型访问的一个赏心悦目的界面。这未必是致命的，但它应该影响估值和预期。

审计数据与控制平面

当一家公司说它的优势在于数据时，要问它是否拥有这些数据、是否有权使用、能否持续访问，以及能否把这些数据转化为更好的产品表现。“我们与客户数据集成”不是护城河，它往往是一个带着安全审查的销售依赖关系。

审查数据是如何分区的、保留了什么、敏感输入是如何处理的，以及客户可以如何审计输出。对于受监管或高后果的工作流，可追溯性不是一个功能请求，它是产品的一部分。如果一个决策无法被重建、质疑或纠正，那么这家公司就是在出售速度，同时悄悄把风险转移给它的客户。

还要审查控制平面：权限、护栏、监控、兜底行为、版本管理和事件响应。这些要素很少成为演示素材，因为它们在视觉上并不激动人心，但它们往往正是一个 AI 功能与可部署基础设施之间的区别。

把商业验证当作技术验证

一家公司可以拥有令人印象深刻的技术，却仍然是一笔糟糕的投资或产品押注。如果部署需要数月的定制服务、一个由创始人主导的销售流程，以及英雄般的客户成功干预，那么这个产品也许还不是一个可规模化的产品。它也许是一家附带了软件的、有能力的咨询公司。

如果这种模式被诚实地定价和配置人员，那它并不丢人。麻烦始于当服务密集型的交付被呈现为软件般的利润率，或者当试点收入被呈现为可重复的 ARR 时。

查看销售周期长度、买家归属、实施时间、总留存率、扩展行为，以及收入在设计合作伙伴中的集中度。要问买家是否有一条预算科目、用户是否切身感受到痛点，以及产品所解决的问题是否紧迫到足以熬过预算审查。一场需要动用季度创新预算的技术胜利，与嵌入式的运营基础设施并不是一回事。

创始人应该在投资者动手之前，先对自己做这样的审计。它能磨砺定位、暴露产品缺口，并防止公司构建一个其交付组织无法支撑的销售叙事。投资者也应该这么做，因为资本不会改善一个薄弱的声明，它只会给这个薄弱的声明更多的续航时间。

重点不是惩罚野心，也不是要求一个早期团队拿出成熟公司的证据，而是让信心与验证相匹配。值得支持的公司通常能告诉你它们的系统会在哪里出问题、运营成本是多少，以及客户必须做什么才能让它成功。这种坦诚不是缺乏愿景，它通常是演示背后确有真材实料的第一个迹象。

您的领导方式在哪里有效，又在哪里正在消耗公司？

这个博客讨论的多数问题，最终都回到创始人如何经营公司这一点上。藤架领导力诊断把它拆成六个维度共24道行为锚定题：约12分钟，即时出结果，自助版免费。

开始藤架领导力诊断 →

想了解兼职高管或顾问合作？预约探索性通话 →