一个客服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功能开十场会还上不了线，通常不是因为参与的人太多，也不是因为大家不够专业。恰恰相反，每个人都很专业，每个人的顾虑都成立。问题在于，组织从来没有区分过：谁在提供意见，谁能在什么条件下否决，谁有权接受剩余风险，以及最后，谁必须做出决定。
于是每个人都拿到了一点模糊的阻拦权力，没有人承担明确的决断义务。
所有人都被听见，不等于所有人都要同意。 让每个人的专业意见以确定的方式进入决定，同时让决定真的能够发生——这两件事不冲突。
不过，就算权限已经分清楚了，还有一种更难的僵局在等着：安全说必须加密，那会让响应慢一倍；业务说响应必须快，否则客户会走；法务说数据不能出境，那意味着换掉整个方案。这一次没有人越权，也没有人拖延，每个部门的要求单独看都完全正确，而且都有依据。当正确和正确直接撞在一起，组织要靠什么决定，这次到底牺牲哪一边？
