为什么一个简单的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% 内容