一个简单的AI功能，为何开十场会仍无法上线？丨FDE重新理解决策权

一个经历十场评审会仍难上线的AI项目，暴露了多部门风险管控下的决策困局，也促使FDE重新审视组织的决策逻辑。
核心内容：
1. 客服AI项目上线受阻的典型现场：十场评审会持续增加验证要求，最终使项目停滞
2. 多部门风险管控的真实矛盾：安全、法务等专业判断与冗余流程之间的冲突
3. 隐形决策困境：多方都有阻拦能力，却无人承担责任，项目风险由可见转为不可见

接下来这个场景，是从多种企业AI项目中提炼出来的综合现场。

一个客服Agent已经完成测试，抽样评测显示其回复草稿质量稳定。由于客服团队工单严重积压，业务部门一直等待它上线。

上线评审时，安全部门担忧调用过程泄露用户数据；法务担心Agent在回复中作出未获授权的承诺，例如随口答应退款期限；品牌团队害怕语气失控，在客诉情境中说错话；IT则担忧新组件影响主系统稳定。各部门派出的人员都具备专业判断，也确实看到了真实风险。

每轮评审至少都会增加一项验证要求，毕竟提出更多要求无须承担责任。
 到了第八场评审会，模型版本发生更新，先前完成的那批测试证据全部失效，只能重新验证。审批对象竟然在审批期间发生了变化。
 客服团队实在无法继续等待，几位组长开始在浏览器中自行使用外部工具处理工单。没有日志、没有审计，也没有任何治理，原本准备纳入管理的风险，就这样变成完全不可见的风险。

十场会议结束后，依然没有一场会议尝试回答以下三个问题：什么条件未满足时必须停止？哪些风险可以由某个人代表组织接受？争议到期后，最终究竟由谁决定？

首先要承认：多方参与并非官僚主义

遇到这种情形，人们最容易得出流程过重、会议太多、应该精简的结论。

但安全、法务、品牌与IT提出的担忧，都是实际存在的风险控制问题。一个Agent直接面向客户发言，确实可能泄露数据、作出具有法律效力的承诺或破坏品牌调性。排除这些部门并不会换来效率，只会换来一场迟早发生的事故。

更关键的是：在AI项目中，没有一个部门能够掌握全部事实。 业务了解客户需求，却不了解数据怎样在调用链路中流动；安全熟悉链路风险，却无法判断某句回复在法律上是否构成承诺；法务清楚承诺边界，却看不懂评测指标代表什么。风险跨越准确性、隐私、安全、合规、品牌及业务结果，每个人只掌握一部分拼图。

因此，让相关人员充分参与是正确的。在此前提下，组织常说的共识还不充分、风险信息仍不完整、再召集一轮相关方、再测试一轮大家就安心了，听起来都十分合理。

然而，无论信息增加多少，仍会留下不确定性；而在AI项目里，剩余的不确定性永远无法归零。泄露风险可以由可能降到极低，却不可能变为零；错误承诺的概率可以压到千分之一，却仍然不是零。如果组织默认必须等所有人放心后才能上线，这个标准就永远无法满足，等待也就成为不能自行终止的状态。

每个人都可以阻止推进，却无须给出结论

所有参会者都拥有一种模糊的、无须说明触发条件的阻拦能力——只需说一句我这边仍有顾虑，项目就无法继续。然而与此同时，没有任何人负有必须得出结论的义务。

两者叠加后，就形成了隐形的一票否决。没有人需要真的投出反对票，甚至不用明确表示反对；只要每个人都留下一点顾虑，决定就永远不会出现。

这种结构能够稳定存在，是因为对每位参与者而言都很理性。提出新要求没有成本，收益是证明自己尽到专业责任；宣布可以上线，则要承担事故发生后的责任，收益却只是别人的项目上线。在没有明确定义决定权的组织中，保留顾虑始终是个人层面的最优选择。

有些决策缓慢，确实是因为数据不足、法定程序尚未完成或技术验证还没结束，这种必要的缓慢不应被消除。本文讨论的是另一种慢：信息其实已经足够，却没有人负有作出决定的义务。

一个违反直觉的参照：即使写清条件，模糊也不会消失

讲到这里，人们自然会想到：提前写明条件不就行了吗？预先设置红线、阈值和触发条件，届时直接按表执行，难道不能提高速度吗？

Anthropic公开了一份负责任扩展策略（Responsible Scaling Policy，简称RSP），当前已更新至v3.4（2026年7月生效）。其核心正是预设如果-那么条件：当模型能力越过某项阈值，就必须启用对应的更严格保障措施。

经过两年多实践后，它也承认：实践中的预设能力阈值，远比原先预计的更加模糊。 某些情况下，模型能力显然正在接近阈值，却很难判断它是否已经确定跨过，因为模型评估科学本身还不足以给出决定性答案。官方把这种状态称作模糊地带（zone of ambiguity）。

FDE据此得出的工程推论是：组织必须明确由谁在模糊中作出决定，并将判断依据保留下来。

既然指标无法自动回答全部问题，按表执行自然不可能覆盖所有情况。总会有某个时刻，数据已经摆上桌面，却不能自己给出结论。那时，组织要么安排明确的人作出决定，要么继续不停开会。

AI在这一过程中放大了什么

传统IT项目也需要上线评审，但AI在四个方面有所不同。

第一，无法等到风险归零。 传统软件验收具有确定性：功能是否按照规格实现，答案只有是或否。概率性系统没有这样的终点，只能判断错误率降到了多少。因此，再等等看会从谨慎变成能够无限延长的姿态，因为错误率似乎永远还可以再降低一点。

第二，Agent会直接执行动作，而非仅仅提供建议。 只输出建议的系统出错后，还有人可以兜底；直接回复客户或修改工单状态的Agent一旦出错，后果更难逆转。不可逆性越高，需要参与决策的部门越多，这种反应完全理性，却也同步增加了需要协调的权限数量。

第三，模型迭代快于审批周期，等待本身也在制造成本。 审批进行到一半时，模型版本已经更新，之前积累的测试证据随之失效。传统系统在审批期内保持静止，AI系统却并非如此。一旦审批周期超过迭代周期，正在审核的对象与最终准备上线的对象就不再相同。

第四，事实掌握在更多不同部门手中。 如前所述，没有人拥有完整拼图。因此，等待某个人独自想清楚在结构上行不通，必须建立接口来汇集分散的判断。

这四点共同导向一个结论：AI项目无法等到所有不确定性消失后再作决定。组织真正需要的并非更长的验证流程，而是一种即使不确定性仍然存在，也能合法、负责且可追溯地作出决定的机制。

FDE如何重新理解决策权

此前的文章「裁定接口设计：不是审批流程，是风险边界」讨论的是人与AI之间的判断交接，也就是什么时候应由人介入，什么时候可以让系统自行推进。本文讨论另一端：在组织内部，这项决定究竟交给谁。

FDE对决策权的理解如下：决策权并不等同于职位高低，而是一套绑定决策类型、影响范围与不可逆程度的权限结构。

同一个人可以直接决定低风险、可逆事项，却在高风险、不可逆事项中仅有建议权，这并不矛盾。权限应当跟随决策性质，而不是跟随职级。

具体需要拆分为五种权限，如果混在一起，就会产生前述隐形否决：

建议权：负责提供专业意见，但不能决定结果。绝大多数参与者都应该拥有这种权限，它并不低级，因为高质量输入是形成好决定的前提。

条件否决权：只有触发预先约定的红线时，才能直接阻断。重点是预先约定和可检验，例如用户身份证号将进入第三方接口，这是可以验证的事实，而不是主观感受。

临时止损权：这项权限用于处理未被预见的风险。AI风险中确有无法事先枚举的新问题；若全部否决条件都要提前写明，组织反而可能为了流程完整而压制真正的弱信号。因此，任何参与者发现重大且未预见的风险时，都可临时阻断，但必须说明依据、自动升级给最终决定人，并由最终决定人在限定时间内确认。

风险接受权：有权代表组织接受剩余风险。这往往是最缺少的环节。很多项目停滞并非因为分析不足，而是无人愿意具名表示这部分风险由我承担。

最终决定权：即使信息并不完美，也必须作出选择。这里的必须代表义务，而不是特权。

五种权限拆分后，还必须守住一条边界，否则整套方案会退化为指定一位大领导拍板：

最终决定权必须绑定明确的风险承接责任。不能让人拥有决定权却不承担相应责任，也不能让承担结果的人完全没有参与决定的权利。

需要注意的是，这并不意味着全部责任都由同一个人承担。现实组织中，最终决定人、风险所有者、业务结果负责人和法律责任主体很可能并非同一人，强行合并反而会造成新的权责错误。真正需要保证的是这条链不存在断口：每项被接受的风险都有具名承接者，每个承担后果的人也都有进入决策的通道。

共识能够提升执行质量，却不能被用作逃避最终决定的机制。

决策接口表：把最终拍板的接口设计清楚

FDE不应替组织作决定，因为这样既不合适，也无法持续。FDE真正要做的是设计作出决定的接口，而这张表就是具体交付物。

表中包括决策对象、必须提供信息的角色，以及每个角色能够否决的具体条件；还包括风险接受人、最终决定人、决定截止时间、超时预设状态，以及保存决定与依据的位置。

它与普通审批流程图的区别，来自背后的以下规则。

第一，否决权必须对应可检验条件。 能明确写出触发条件的，登记为条件否决权；虽然写不出、但确实存在担忧的，则使用临时止损通道，可以叫停，但要提供依据并自动升级。这样是为了消除我担心所以永远不上线这种既不说明理由、也不承担后果的中间状态。

第二，必须区分信息会议与决策会议。 风险接受人一栏为空时，会议仍然可以举行，但只能是风险识别会或信息澄清会，目的在于识别风险并确定归属，不能被当作正式决策会议。许多项目把信息会误认为决策会，只完成了风险识别，却以为已经作出决定。

第三，超时后的默认状态必须匹配可逆性、影响范围和风险等级。 低风险、可逆且范围较小的事项，超时后可以进入限时试点或自动升级；高风险、不可逆且影响外部主体的事项，超时必须默认不放行，或者返回安全模式。绝不能因为审批延迟，就让高风险功能自动取得上线资格。

第四，明确使用时点： 在功能进入上线评审前建立该表；范围或风险等级变化时重新审查；真正发生争议时按表执行，而不是临时开会讨论究竟谁有决定权。争议出现的一刻应该执行规则，而不是临时制定规则。

写在最后

一个AI功能经历十场会议仍无法上线，往往不是参与者太多，也不是大家不够专业。情况恰好相反，每个人都很专业，各自顾虑也都成立。真正的问题是组织从未区分谁负责提供意见、谁能在何种条件下否决、谁有权接受剩余风险，以及最终谁必须作出决定。

结果是每个人都获得了模糊的阻拦权，却无人承担清晰的决断义务。

让所有人的意见被听见，并不意味着必须获得所有人的同意。 既让每个人的专业意见以明确方式进入决策，又确保决定最终能够发生，这两项目标并不冲突。

即使权限已经厘清，更棘手的僵局仍可能出现：安全要求必须加密，却会使响应慢一倍；业务要求快速响应，否则客户会离开；法务要求数据不能出境，就意味着整套方案需要更换。这时没有人越权或拖延，各部门要求单独看都正确且有依据。当不同的正确要求正面冲突时，组织究竟凭什么决定牺牲哪一方？

感谢你读到最后。如果内容有所启发，欢迎随手点赞、在看和转发；想第一时间收到推送，也可以为我加上星标⭐，我们下期再见。

登录查看剩余 70% 内容