如何在规模化之前降低AI部署风险

演示不是部署。它是一场受控的表演，通常配以干净的输入、耐心的操作者，以及完全没有那些定义真实工作的权限、交接、异常和问责。要降低AI部署风险，创始人和资本配置者需要停止把模型能力当作业务就绪的证明。

这种区别正是大多数计划失败之处。技术可能令人印象深刻。所提议的工作流程甚至可能合情合理。但如果没有人确定错误由谁负责、当置信度下降时会发生什么、单位经济效益能否在实际使用中存活，或者终端用户为什么要改变行为，那么这个项目就还没准备好规模化。它只准备好生成一份幻灯片。

部署风险始于演示的终点

AI部署很少因为模型无法给出答案而崩溃。它们崩溃是因为答案进入了一个从未围绕概率性输出而设计的运营环境。

一名客服人员可以用解决时长、升级率、客户满意度和合规性来衡量。一个起草回复的AI助手引出了一个更棘手的问题：当它信心满满地编造出一条政策、遗漏一个账户条件，或者发出一个技术上准确却造成商业问题的答案时，谁该负责？“人在回路中”并不是一个控制方案。它往往只是一种委婉的说法，意思是没有人定义过这个回路。

同样的模式出现在企业采购中。买家会问某个系统是否使用了正确的模型、是否支持检索，或者是否有一个精美的管理面板。这些都是有效的问题，但并不完整。更有价值的问题是：这个系统是否有一个界限明确的任务、它的失败模式是否可见、员工是否会真正使用它，以及买家能否在不依赖供应商所提供的热情的情况下证明其价值。

对投资者而言，这就是一家拥有引人注目能力的公司与一家能够成为可信基础设施的公司之间的差距。前者可能会快速融资。后者才是能够赢得续约的那一个。

从决策出发，而非从模型出发

浪费AI预算最快的方式，就是从工具选择这项工作开始。“我们应该用哪个模型？”往往为时过早。首先要确定这个系统将影响的决策或行动、对此负责的用户，以及出错的代价。

有些工作非常适合AI，因为错误代价低廉、输出易于审核，而且速度能创造可衡量的价值。起草内部研究摘要、对低风险文档进行分类，或者提示可能的下一步，都可以归入这一类。另一些工作则承担着重大的法律、财务、安全或关系后果。这并不意味着AI无法使用。它意味着部署需要更严格的边界和一套不同的经济论证。

一份实用的产品简报应当用平实的语言回答四个问题：

• 具体改变的是哪项工作？
• 良好的结果是什么样子，又将如何衡量？
• 哪些错误是不可接受的，由谁来处理？
• 什么样的证据能够证明超出初始范围进行扩展是合理的？

如果一个团队回答不出这些问题，只能说“模型会变得更好”，那么它并没有定义出一个产品。它定义的只是一种希望。

在改变工作流程之前先衡量它

团队经常声称某个工作流程缓慢、昂贵或不一致，却从未衡量过其中任何一项。然后他们部署了AI，并根据一些轶事般的惊喜宣布成功。那不过是换了套服装的演示催眠。

先建立一个基准：数量、完成时间、返工、错误率、升级模式、人工成本、收入影响，以及在相关情况下的用户满意度。并非每个指标都值得同等看重。一个每项任务节省五分钟却让异常处理翻倍的系统并不高效。一个提升了吞吐量却摧毁了与最高价值客户之间信任的系统算不上胜利。

基准还能防止一个常见的商业错误：在买家需要的是一个具体业务成果时，去兜售“生产力”。创始人应当能够解释他们的产品如何影响服务成本、转化率、留存率、风险敞口或周期时间。含糊的时间节省很少足以经受住预算审查。

用分阶段的证据来降低AI部署风险

答案不是设计一个为期六个月、旨在回避做出决定的试点。漫长的试点往往变成组织的摆设：贵到无法忽视，模糊到无法扩展，而在政治上又太有用以至于无法叫停。

相反，要围绕证据关卡来分阶段部署。每个阶段都应在暴露更多用户、数据或预算之前，解决一个明确的不确定性。

第一，用有代表性的输入来测试技术可行性，而不是手工精选的样本。要包含那些糟糕的情况：不完整的记录、相互矛盾的源材料、含糊的请求、异常的格式，以及对抗性行为。如果产品依赖检索，就检查检索到了什么以及是否充分。如果它会采取行动，就测试权限边界和回滚路径。

第二，与一小群每天从事这项工作的用户一起测试工作流程的契合度。产品负责人应当观察用户在哪里犹豫、覆盖输出、创建旁路流程，或者悄悄回到旧系统。采用数据告诉你发生了什么。观察通常能告诉你为什么。

第三，测试商业可行性。在现实的数量和现实的行为下计算使用成本，包括重试、更长的提示、峰值需求、监控、支持和人工审核。许多AI产品在有限的试点中拥有诱人的毛利率，因为它们由低使用量和创始人的介入所补贴。当客户真正采用产品时，那些利润率可能会变成虚构。

最后，测试运营归属。指定负责评估质量、处理事故、批准变更以及决定何时应限制某项功能的人员或职能。如果归属分散在产品、安全、法务和运营之间，却没有一个决策者，那么这项部署就是由日程邀请来治理的。

控制机制应与失败的后果相匹配

并非每个AI应用都需要同样的控制栈。为低风险的起草工作过度构建控制会扼杀速度和采用。为受监管或高后果的工作构建不足则会制造一个伪装成创新的责任隐患。

正确的做法是相称性。高影响的决策需要清晰的来源可追溯性、受约束的行动、升级规则、可审计性以及持续的评估。较低风险的辅助或许只需更简单的监控、抽样和用户反馈机制。要点不是消除错误。人类系统从未达到过那个标准。要点是让错误可被检测、可被控制，并且在经济上可以容忍。

这也是创始人需要保持思想上诚实的地方。一个每项输出都依赖人工审核者的产品或许仍然有价值，但它应当被作为决策支持来销售，而不是自主的自动化。这种定位没有什么可羞愧的。承诺替代劳动力却交付一个让审核者排队更快的产品，才是相当可耻的。

隐藏的风险是组织性的，而非技术性的

一个技术上健全的部署仍然可能失败，因为客户还没有决定围绕它要改变什么。员工可能担心绩效监控或失业。管理者可能不信任他们无法解释的输出。安全团队可能来得太晚，因为数据实践从未被记录在案而叫停项目。销售可能承诺了产品尚未落实的功能。

这些不是要在上线后再处理的“变更管理”细节。它们是产品需求。一份部署计划应当明确培训、用户权限、反馈途径、升级覆盖，以及当系统出错时的政策。它还应当确定对业务成果负责的高管，而不仅仅是对技术预算负责的人。

对于评估一项创业投资的投资者来说，这是一个尽职调查信号。要问这家公司能否在不含糊其辞的情况下描述其买家的实施顺序。它能否解释谁来配置产品、实现价值需要多长时间、需要哪些数据、集成在哪里失败，以及在最初的兴奋过后是什么导致了流失？一个有答案的创始人很可能亲眼见过实际的工作。一个只有架构图的创始人可能还有更多工作要做。

只有在经济效益和信任成立之后才扩展

扩展不是成功试点的奖励。它是一种新的运营状态。更多的用户会带来更多的边缘情况、更高的推理成本、更不一致的数据，以及对支持和治理更强的要求。对十个设计合作伙伴有效的系统，对500个没有被创始人辅导过的普通用户可能会失败。

当三个条件成立时再扩展：工作流程产生可衡量的业务成果、系统的错误特征已被理解并得到管理，以及经济效益随着使用而改善而非恶化。如果其中缺了一项，那么既不要扩大推广，也不要扩大承诺。

市场需要的不是更少的AI部署。它需要的是更少建立在一厢情愿的核算、无名的负责人以及被误认为证据的演示之上的部署。能够长久存续的团队，将是那些愿意做出更狭窄的承诺、毫不留情地衡量它，并赢得扩展权利的团队。

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

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

开始藤架领导力诊断 →

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