智能体执行、员工审批、管理者负责时，责任怎样划分？用 RACI、否决权和签署记录明确边界

先看结果：480张发票都有“人工审批”，INV-882仍差点把未收货的¥85,920提前付掉

津岳工业的发票例外助手读取发票、采购订单、收货记录和供应商主数据，提出放行、暂停或查询建议。旧流程图只写“智能体执行，应付账款员工审批，财务经理负责”。审批页显示模型结论和一个绿色置信条，不显示采购单与收货单的差异；员工每天面对24张案例，唯一审批者在稳定状态下也只能仔细处理18张。团队仍把点击率96%当成“人在回路”。

发票INV-882金额¥286,400，采购订单允许分批收货，权威收货记录显示仅70%到货；智能体把供应商邮件“全部已发出”误当成全部收货，建议全额放行。未到货30%为¥286,400×30%=¥85,920。员工若只看结论就会批准。真正的系统控制应展示发票、采购单与收货单的版本、数量差异和动作对象，并让有付款权限的人在影响发生前决定。新页面因此默认暂停，复核人选择查询和暂存，付款没有发生。

团队为请求者与操作员、复核人与批准人、管理者与流程负责人、构建者与系统负责人、控制与运营五类角色各设计180个决策，共900项。旧说明下答对512项、关键错误184项、其他不完整204项；角色、权限和签署重构后答对826项、关键错误12项、其他不完整62项。826/900=91.78%不是系统准确率，而是人员在情境中选择正确负责人、动作和证据的比例。

六周480张实际案例最终454张首个决策正确，16张在影响前由复核人纠正，8张错误暂停补证后释放，2张保持状态未知并转人工；未经授权支付、重复支付和无回执释放为0。所有公司、角色、数据和结果均为虚构教学案例，不是财务控制或法律标准。本文的内部责任模型不能分配或排除适用法律责任，具体授权、雇佣、审计与财务制度由专业人员确定。

先区分五个概念：任务执行、业务决定、责任、问责与法律责任不是同一个词

智能体可以执行抽取和建议，但它不是组织中可被授权、追问理由、配置资源或承担后果的角色。执行负责表示完成工作；最终负责表示对该决策或结果最终答复并确保条件存在；权限表示能批准、拒绝、暂停或接受风险；问责还要求解释和改进；法律责任是适用法律概念，不能由RACI责任矩阵自行决定。

一项工作可能有多个执行者，但每个具体决策应有一个清楚的最终负责人。一个大流程不能只写一名高管最终负责，然后让具体案例无人拥有。最终负责人可以委派日常执行，却不能在委派后不再提供人员、数据、控制和监督。模型或供应商不能占据责任矩阵里的最终负责位置。

“共享责任”描述多方协作可以，但若没有逐决策拆分，会让事故时每个人都说自己只负责一部分。共享系统可靠性可由多个控制负责人贡献，付款放行、政策例外和扩量仍要有命名权限及范围。

责任模型还区分前瞻性与回顾性。上线前的职责是准备数据、规则、人员和控制；运行中的职责是作案例决策、监测和暂停；事故后的职责是恢复、解释、补救和改进。不能因为复核人对一张发票作错决定，就让他承担模型供应商管理；也不能因为经理不逐单点击，就免除其对长期超负荷的问责。

RACI不是处罚表。它让员工在任务发生前知道该做什么、能拒绝什么以及何时交接；事后调查仍以事实、能力、信息、权限和适用制度判断。用矩阵预先指定“出事背锅人”会让员工隐藏问题，并使系统性缺陷得不到修复。

先把责任落到具体业务决定：组织名单和四个字母都不能代替授权

从业务影响反向列决策，不从组织名单正向给每个人随便放一个RACI字母

先列出每个可能改变权利、资金、记录、外部通信或系统状态的决策：绑定供应商与发票、认定证据、计算差异、选择暂存、查询或放行、批准金额、执行支付、确认最终状态、处理争议、扩大范围、接受剩余风险、完成事件恢复。然后再问谁掌握事实、具备能力并拥有权限。

每个决策卡记录触发条件、输入与来源、可选结果、不可接受结果、授权限制、需要咨询的人、签署与回执、处理时限、代理、申诉和停止方式。RACI只是摘要，决策卡才可实施。若团队无法确定D03的最终负责人，系统就保持暂停，不能让智能体填空。

组织名单随后映射到决策，用来发现空缺与重叠。两名经理都认为对方接受风险，或应付账款员工实际有放行按钮，表上却只写“提供咨询”，都是上线前的阻碍。名字随岗位变化，但角色与范围应保持稳定，并由身份与权限系统绑定人员分配。

填写完成的D03决策卡写成：触发条件为规则发现收货记录不匹配；输入为发票、采购订单、收货记录和供应商身份；可选暂停、查询、按政策部分处理或升级；禁止无回执全额放行；日常最终负责人为获委托的财务决策负责人；高于¥100,000的放行转高级授权；证据为最终决策记录和已支付或未支付回执；处理时限为两个工作小时；无法决定时保持暂停。

一项决策太宽时继续拆。例如“批准发票”至少包含认可证据、选择业务状态和授权现金动作；前两项可由应付账款复核人完成，第三项受金额委托限制。若只给整体一个A，界面容易把有暂停能力的人误配成能放行所有金额。

决策清单也列没有AI时的负责人。引入智能体不能创造原流程不存在的责任；若过去靠资深员工默契决定回执优先级，先把规则权限补齐。否则模型只是把隐性冲突变成高速、规模化冲突。

RACI只回答协作关系，还必须增加决策权、否决权、风险接受和紧急暂停四张表

RACI的四类角色——执行、最终负责、提供咨询和知悉——不能表达安全审核员能否否决、应付账款复核人可批多少金额、谁可在事件中立即终止，也不能表达某人能建议却不能批准。津岳为每个决策另附授权矩阵：批准、拒绝、否决、暂停、例外、接受风险，以及对应的金额、产品、地区和期限。

否决触发后，不是讨论意见中普通的一票，而是让系统保持安全状态，直到条件解决或由有权的正式路径裁定。安全控制可阻止跨供应商数据，付款控制可阻止无回执操作，专业领域负责人可阻止重大影响；高管的业务支持不能自动推翻所有专业否决。

暂停权限要比永久关闭权限更容易触发：发现重复付款、最终状态未知、权限漂移或模型版本没有通过回归测试时，值班角色立即撤掉产生影响的能力，随后由事件负责人决定何时恢复。没有即时暂停权的人不应被写成“负责监控”。

权限按最小范围授予：操作、金额、供应商类别、区域、时间、目的和案例条件。一个人可以暂停任何金额，因为暂停阻止影响，却只能放行≤¥100,000；高价值放行需要不同权限。系统从分配读取范围，不靠员工记得自己的授权表。

多个权限冲突时先执行安全否决，再由裁决路径处理。业务负责人可以接受延迟和业务成本，不能单独推翻安全或财务禁止；控制负责人也不能替业务决定系统是否值得继续。最终裁决记录每方授权与剩余风险，不用“大家共同同意”模糊。

风险接受有边界和期限。接受“试点中错误暂停可能增加”不等于接受重复付款；接受某供应商数据缺口需写群组、补偿控制和过期。实际结果超过容忍度时原接受自动失效并触发暂停。

智能体在责任模型里是受控组件，不是员工、审批人、风险所有者或可以被问责的主体

智能体应登记为系统组件，并记录负责人、目的、模型、提示词、检索、工具与策略版本、身份、允许的输入和操作、评估、监控及回退方式。它可以在流程图中作为执行节点，但责任矩阵中的人员或组织最终负责人仍然存在；界面不得用“智能体已批准”掩盖真正权限。

给智能体拟人化岗位名称会改变人的行为：员工容易认为它比自己更专业、经理把容量削掉、事故时把根因写成“智能体犯错”。产品文案使用“系统建议”“候选动作”，显示限制和负责人；员工仍需作独立决策。

供应商可以对服务时限、安全或合同义务负责，但不能因此成为本组织发票付款的最终负责人。供应商提供证据和配合事件处置的义务进入系统负责人职责，业务授权仍由部署组织控制。

智能体输出拆成观察、推断、建议和操作请求。发票金额是带来源的观察；“已全部收货”是对邮件的推断；放行是建议；调用支付接口才是操作请求。界面与日志保留这四层，防止员工把流畅的推断当成权威事实，也便于事故时判断错误来自来源、推断、规则还是实际操作。

模型置信度不映射业务权限。即使0.99也不能覆盖回执，低置信度也不必让所有案例升级；路由依据证据、规则、后果和状态未知。组织可以隐藏没有校准价值的分数，改为显示实质性分歧和需要人回答的问题。

智能体无法作出具有组织承诺的“道歉、保证赔付、接受风险”决定。它可以起草文字，但最终发送者与决策负责人必须明确；产品不得把模型第一人称的“我批准”写成系统状态。运行记录使用组件编号，而不是虚构员工姓名。

人工审批要成为真正的控制：看得懂、来得及、拒绝得了，还必须签对具体对象

复核人只有在影响前看到准确对象、证据差异和替代选项，且能拒绝时才算有效人类控制

有效复核要回答六个问题：我在决定什么；对象、金额和接收方是什么；哪些证据和版本支持；系统哪里不确定；可选动作和后果是什么；拒绝与升级是否真实可用。只显示模型结论、分数和“同意”按钮，会让人锚定在系统建议上并机械盖章。

复核发生在付款指令之前，不能付款后抽样再称“人工在环”。对低风险批量三方完全匹配可由确定性规则直通，但这属于自动化设计和相应控制，不应伪装成每笔人工审批；例外则提供足够时间和信息。

复核人修改模型金额后需要重新运行规则与差异，签署最终对象，不签原候选项。任何数据版本、接收方、金额或操作改变使签署失效，避免一张批准被复用于不同付款。

复核流程按顺序先看身份与权威来源，再看差异和规则，最后才看模型解释，降低自动化锚定。系统可在部分抽样中先隐藏候选项，让复核人独立选状态，比较分歧；若显示模型后错误接受率上升，改界面、训练或收窄任务，而不是要求人“更谨慎”。

复核人必须能打开原始发票、采购单和收货单，不能被迫相信截取后的摘要；来源不可用时就暂停。页面提供原因代码与自由说明，但不以固定下拉选项替代复杂案例。正确拒绝、系统缺陷和容量不足都有独立路径，不能全部归为“人工改写”。

抽样复核适合可逆、低后果且其余案例有强确定性控制的路径；每笔都可能造成重大支付时，不能只抽5%再称有人工控制。组织明确哪些案例自动、逐笔复核或事后抽样，并分别记录决策负责人。

签署记录不是一个姓名和时间戳：必须绑定范围、证据、决定、条件、有效期与剩余风险

签署对象以一条完整决策记录保存，包含用例、案例、角色分配、输入引用和版本、模型与规则版本、拟议操作与最终操作、差异、授权策略、条件、时间、有效期、下游接收方和回执。签署是可复核的业务决策，不是免责条款。

签署服务在服务器验证分配、职责分离、金额和过期；前端隐藏按钮不够。高价值放行需第二名有权者时，两人签不同角色和决策，不是同一账号连续点两次。代理签署保留委托人、代理人、理由和期限。

“我已阅读AI输出并承担责任”的通用复选框没有对象、证据和权限，不能形成有效控制。记录也不应保存无关个人信息；保留期按财务、审计、隐私和事件需要由组织确定。

签署服务在签署前重新读取权限和对象版本，防止页面打开后数据变化；签后生成不可变的决策编号，下游付款只能引用该编号一次。付款金额、银行账户或供应商发生变化时，策略拒绝旧签署并要求新的决策记录；不能由调用方只传入一个“已批准”的真假值。

批量签署仅在每个对象满足相同确定条件、复核人能看到异常列表且策略允许时使用。签署记录仍逐对象生成，任何一个异常从批量移出；“全部批准 480”不是效率功能。批量大小、复核时长和拒绝率进入监测。

签署理由采用“事实、规则、决定”的写法，例如“收货记录为70%，POL-PAY-12要求暂停；已开查询单Q-991”，不接受“智能体建议”或“看起来正确”。模板帮助保持一致，但复核人可以补充冲突。签署页面应怎样展示法律和内部含义，由专业负责人确定，不用夸张免责声明恐吓员工。

管理者的最终负责不是替员工逐单审批，而是确保流程、人员、权限、目标和停止机制成立

流程经理对允许范围、基线、人员配置、处理时限、权限委托、培训、复核质量、例外放行、事件和持续价值负责。若每天有24个例外，而只有一人能认真看18个，经理不能仍要求当日100%处理完，再把盲目审批归因于员工。

480个案例分布在20个工作日，平均每天24件；若每件有效复核约6分钟，共需144分钟。两名复核人各安排72分钟平均负荷，并为高峰和复杂案例留出余量；旧方案单人每天18件的稳定上限无法支撑24件。平均数仍不足以证明峰值容量，试点还要看每小时到达量与第90百分位等待时间。

经理也要保护异议。复核人因暂停影响付款及时率，不应被惩罚；例外放行必须由有权角色写明理由。若业务指标与控制冲突，经理应调整处理时限、适用案例群或资源，不能口头要求“灵活处理”。

容量模型使用到达分布而不只看平均数。每天平均24件，不代表周一不会集中到40件；每件标准例外需要6分钟，合同或主数据冲突可能需要20分钟。团队按案例组合估算第90百分位工作量，并计入休假、培训和异常缓冲，设置队列上限；超过上限就自动缩小AI适用范围或延后低优先级事项，不能减少证据要求。

经理每周抽查复核理由与例外放行，而不是只看吞吐量。若同一复核人接受率99%、每单只用20秒，先检查案例组合和界面；若正确暂停很多，则追查数据或供应商问题。管理者的签署表示“资源和放行门槛已经满足”，不是对未来所有案例一次性免责。

问责也包括停止没有价值的系统。若智能体只节省30秒，却增加复杂签署、错误阻断和支持成本，经理有责任改用规则或人工；已经投入预算不能成为继续使用的理由。业务收益与控制成本必须放在同一项决策中展示。

责任必须穿透组织和系统：建设者、咨询者、否决者与代理人各有不同边界

构建者和系统负责人负责控制正确运行，但不能单独证明业务决定正确或接受其后果

构建者实现数据结构、来源链、身份、策略、界面、日志、防重复执行、回执、监控和回滚；产品或系统负责人最终负责发布包、运行可靠性、依赖和缺陷响应。业务或领域负责人定义正确的最终状态与规则，独立复核人负责验证。代码测试通过不等于这张发票就应该付款。

构建者发现需求无法实现可靠回执时应拒绝放行，而不是在文档写“财务负责核对”。同样，业务负责人不能要求工程师在规则冲突时自行选择合同解释。双方在接口处各自交证据。

供应商更新模型、管理员改策略或ERP接口变化会使技术证据失效，系统负责人阻止部署并通知用例负责人。业务负责人决定缩范围或人工，构建者不凭模型回归分独自扩量。

技术负责人提供服务目标、依赖清单、值班人员和人工回退方案。模型不可用时可回到人工提取；支付或收货记录服务状态未知时必须停止并对账。若回退方案的权限更宽或证据更少，责任模型就要按更高风险设计，不能在故障时临时省略签署。

放行包把决策清单映射到接口：D03由复核界面和签署控制，D04由支付策略控制，D05由收货记录和对账控制。测试报告指出每项由哪个控制保障及已知差距；业务负责人据此决定范围。一个笼统的“测试通过”不能让管理者看见责任断点。

工程缺陷工单也有严重程度和影响查询。发现签署记录可以被重复使用后，系统负责人先禁用放行路径、查询所有使用同一决策编号的付款，再开始修复；不能等到下一个开发周期。技术负责人没有业务赔付权限，但负责向事件负责人提供准确的影响范围。

数据、领域和控制角色的咨询不能变成“发过邮件”，关键条件需要明确同意或否决

RACI中的“提供咨询”经常被弱化为抄送邮件。对于供应商主数据、收货记录的权威性、税务或合同例外、安全和隐私等关键条件，记录必须写明需要对方作什么判断、应在多久内响应，以及未响应时进入什么安全状态；沉默不算同意。咨询角色可以预先批准低风险模板中的通用规则，不必逐个案例参加。

独立控制角色不替一线拥有每笔决策，也不与构建者共同承担上线业绩指标。它测试设计、权限、签署、抽样和例外放行，可以要求整改或按授权行使否决权；若其参与了建设，就另派复核人处理独立验证。

咨询意见冲突由预定裁决权解决，记录事实、不同观点、最终决策和过期。项目负责人不能挑选最宽松意见，也不能把争议交模型总结成“共识”。

咨询角色的回复必须结构化：批准条件、拒绝、需要的证据或“超出我的职权范围”，并写清范围与有效期。若对方只提供建议，就不能把它伪装成批准；若其授权确实包含否决权，就在授权矩阵中明确。这样邮件内容不会被智能体错误摘要成“同意”。

数据或领域负责人制定的通用规则可以减少逐个案例咨询。例如，“收货记录系统R是标准产品的权威来源”经批准后由规则执行；只有遇到系统R与召回系统冲突时才咨询。预授权有版本和边界，来源变化后自动失效。咨询角色的价值是定义可复用事实，不是成为永远排队的人工接口。

知悉也有时点：供应商在受到影响后获知，管理者每周获知，控制人员在发生例外放行时获知，事件负责人则要即时获知。把所有人实时抄送会淹没关键信号；漏通知又会妨碍申诉和恢复。决策卡应写具体事件和渠道，而不是只填一个“知悉”字母。

否决权必须连接即时技术动作：发现无回执、跨供应商或重复支付时可以真正停

否决条件包含跨供应商或跨租户、银行主数据冲突、重复候选项、回执缺失、金额越限、签署失效、支付状态未知、身份异常和关键评估指标退化。触发后，支付能力被策略拒绝，案例进入有负责人接管的状态；不能只发告警却让同一路径继续。

例外放行不是删除否决。适用时由更高或不同权限签署单个案例的例外，写明补偿控制和有效期；某些禁止项没有普通例外。例外放行率升高，说明规则、数据、工作压力或规避行为可能有问题，经理应按原因抽查。

紧急停止开关演练包含撤智能体身份、停队列、保留待处理案例、查询已提交付款和转人工；只关闭聊天界面而后台执行器继续，不算停止。值班人员有权限且知道何时使用。

分离职责防止一个人提出、修改证据、批准和执行同一高影响动作

最基本的职责分离是：候选项生产者不能拥有最终权限；发票或供应商主数据修改者不能立即独自批准受影响的付款；构建者不能独立验证自己建设的高影响放行功能；风险接受者与项目收益负责人存在利益冲突时，要引入第二层复核。小组织无法完全分离时，可以使用金额上限、双人审批、延迟执行、抽查和外部复核等补偿控制。

身份与权限系统和签署服务必须强制执行职责分离，培训提醒并不够。一个人拥有两个合法角色时，要按当前案例检查冲突；他可以在普通案例兼任，但修改供应商银行账户后，该案例自动需要其他审批人。

分离逻辑检查事实关系，不只职位名称。申请人与审批人账号不同但同一人控制两个服务账户，仍不独立；同一经理的直接业绩压力不必自动禁止，但高风险风险接受需更高层或独立挑战。组织按规模和后果设置补偿，不机械追求角色数量。

小团队无法双人覆盖所有时间时，可收窄金额、只在工作时段执行、增加24小时延迟和次日独立抽样；紧急案例走明确权限。补偿控制写在决策卡并测试，不能用“我们人少”删除责任。

紧急代理人不共享账号。委托分配写清范围、金额、开始与结束时间、委托人、审批人和通知对象，到期自动撤销；代理人不能继续把权限转授给他人。代理期间的决策仍可追溯到实际操作的人。

人工容量和能力是责任模型的前置条件：没有时间、信息或技能的人不能被写成控制

每类复核都要估算到达量、服务时间、复杂度、班次和峰值，并设置最大队列。标准的三方匹配不强迫人工点击；真正的例外交给合格复核人。所需能力包括读懂采购单与收货单、识别模型锚定、使用保留与查询功能、报告事件和理解权限，不要求人人掌握模型内部原理。

能力验证使用真实形态的案例，而不是通识证书。关键题包括部分收货、重复发票、供应商银行变更、超时或状态未知，以及经理施压；任何可能造成错误付款的题都必须通过。岗位、规则或范围发生变化时要重新验证。

人员状态与身份权限联动：培训通过但分配过期，仍不授权；休假代理人只获得更小的短期范围；连续90天未作高价值决策，需要做一次简短复核。经理不能借同事账号处理积压。资格记录只保存必要结果、版本和范围，不无限记录学习行为。

支持路径包括快速询问规则、报告系统缺陷、紧急暂停和申诉，分别有负责人和处理时限。复核人不是一线技术支持；如果页面打不开先找服务台，若来源冲突则找数据负责人。清楚的路径让人把时间用在决策，而不是组织协调。

界面也应降低认知负担：先展示实质性差异和权限，不用绿色分数诱导；随机抽取一部分隐藏模型建议测自动化偏见；复核人可查看原证据并报告系统缺陷。责任不能靠个人意志抵抗坏设计。

事件、验证和运行监测要检查责任是否真实存在，而不只是文档是否齐全

事件发生后按因果链分配修复责任，不用“谁最后点了按钮”结束复盘

若错误付款发生，调查候选项为何出错、来源和规则为何放行、界面提供了什么、复核人是否有信息、时间与权限、经理如何配置容量和激励、支付服务是否验证、监控何时发现，以及怎样补救受影响的供应商。最后点击的人可能有责任，但不是唯一根因。

复盘要区分无责学习与适用的纪律或法律调查：既不预先承诺任何人都没有后果，也不把系统缺陷掩盖为个人粗心。组织保存证据、保护报告渠道，并由有权角色决定通知、恢复和后续处置。

补救措施必须写入负责人、日期和验证测试；如果结论只是“加强培训”，就必须证明问题确实是知识缺口，而不是权限、界面、容量或规则。重复事故触发范围缩小、权限变化或停用智能体。

受影响供应商的更正与争议处理，不等于内部复盘已经完成。支付运营确认资金最终状态，业务或合同授权人处理沟通与补偿，事件负责人协调时间线，法律或专业角色判断适用要求；模型或复核人不能私自承诺。所有外部影响都要有回执和负责人。

复盘既检查“预期控制为何没工作”，也检查责任表是否现实：最终负责人是否知道自己的职责，执行者是否有相应权限，咨询角色是否及时回复，知悉角色是否收到可采取行动的信息，暂停是否真的能执行。只更新RACI文档却不改权限不算整改；修了代码但容量仍不足也不算闭环。

责任映射工作坊用一张真实案例逐个签决策，不在会议上给整条泳道贴满字母

工作坊准备业务案例、当前追踪记录、身份权限、策略、任务分配以及事件和例外放行样本。引导员从最终影响向前追问每个决策：谁实际执行、谁能批准、谁能否决、失败时谁来停止、证据在哪里、无人值守时怎么办。参与者包括一线员工、经理、数据或领域负责人、构建者、运营和独立控制人员。

每张决策由最终负责人确认“我接受此职责且有资源”，执行者演示操作，控制人员验证权限，运营人员演示失败恢复。只在幻灯片写名字但本人没有参加，不能放行。无法确定负责人时，记录“负责人待定”、临时安全状态和发起人的截止日期；智能体保持建议模式或关闭会产生实际影响的能力。

工作坊后的可复制模板包含决策编号、目的与影响、输入与来源、选项、四类责任、权限与否决、职责分离、签署、处理时限与容量、事件、变更和退役。团队用正常、边界、代理和事故四张案例复跑，确保矩阵不是只适用于INV-882。

结果通过身份权限差异检查、工作流配置和运行手册落地：新增或撤销用户组、更新策略和签署模式、配置告警和值班人员。一个月后抽取10个实际回执，把责任表与生产记录逐项比对；若实际执行者或负责人不同，先修权限和流程或重新确认责任，不能改文档迁就漂移。

完整走例：INV-882从错误放行候选到暂停，六个角色各自留下不同证据

智能体读取¥286,400的发票、采购单第5版和供应商邮件，提取“全部已发出”并建议放行；确定性规则查询收货记录R-771第2版，发现只到货70%。系统负责人的策略网关产生“收货记录不匹配”结果，复核界面显示¥85,920未收货差额。应付账款复核人有保留和查询权，但没有高额放行权，因此签署暂停并开出查询单Q-991。

若次日新收货记录显示100%到货，旧暂停签署不会自动变成放行；新证据使旧决策记录失效，系统重新运行规则，并由拥有相应金额权限的人签署。付款成功后，支付回执关联发票、金额、银行账户和账簿；超时先查询，不直接重试。

对照案例是一张¥8,200、采购单、收货单和发票完全匹配的标准发票。组织可在规则明确、供应商身份可靠、重复检测和收货记录齐全的前提下自动处理，或使用较轻的复核；不应为了展示“人负责”而让员工机械点击。责任控制的强度应与影响和不确定性相称。

用900个角色决策和权限负面测试验证责任设计：会背RACI不等于系统真能阻止越权

五类角色各有180个情境，覆盖正常、边界、冲突、代理、事件和变更。旧版答对512项、关键错误184项、其他不完整204项；新版答对826项、关键错误12项、其他不完整62项，三类均合计900。关键错误包括越权放行、把沉默视为同意、无回执重试、同一人自批和无法暂停。

技术测试用真实身份尝试超金额放行、使用过期签署、修改对象后复用签署、自批、代理权限过期、绕过界面直接调用接口、重复调用和在状态未知时重试；预期结果是拒绝操作并记录命中的规则。正向测试也要通过，防止控制过严让所有合法付款停摆。

剩余12个关键错误要逐项修复，或限制相关人员与适用范围，不能因为91.78%的总体正确率就放行所有角色。角色测试衡量的是责任判断，系统评估与业务结果要另行测量，不能用一个数字替代。

运行监测既看错误影响，也看责任漂移：权限、例外放行、队列和签署行为会随压力变化

仪表盘按决策和角色显示符合条件的案例、批准、拒绝、查询、例外放行、签署失效、自批拒绝、队列、复核时长、错误暂停、事件和状态未知。分母是可作决策的案例，不按登录人数计算。

每季度把RACI责任矩阵与身份权限、工作流、值班人员、岗位变更和真实回执对账。经理离职、工作外包、规则变更、新工具和规模扩大都会触发复核；旧版责任文档不更新，会让实际权限逐渐漂移。

员工和受影响供应商都有报告和争议渠道，案例可以追溯到人类决策与系统证据。监测不用于无边界地评估员工性格；数据用途、访问、保留和申诉按组织制度明确。

指标以发现责任断点为目的，不建立个人“服从智能体”排行榜。某审核员暂存较多，可能因为分到复杂供应商；某管理员例外放行较多，可能因为一条坏规则。比较前要按案例组合、权限和时间展开。只有结合样本追踪、原因和结果，才能决定应该改善人员能力、数据、系统还是资源。

仪表盘同时保留无人认领问题、过期委托和最终负责人缺席天数。控制问题不能在会议上“已知”却没有负责人；超过处理时限时自动升级到发起人，并缩小相关影响范围。责任可见性包括谁尚未行动，而不只是谁完成了签署。

变更、代理和退役都必须重新落责任：获批旧版本不能替新智能体、新负责人或新权限背书

变更清单包含模型、规则、数据来源、工具动作、金额、地区、供应商群、自动化级别、复核界面、人员配置、权限和供应商。清单与注册表不一致就阻断；新增自动支付尤其需要重新进行责任映射、价值衡量、风险管理和授权决策。

退役时停止生成新候选项，处理现有队列，查询未完成付款，撤销智能体和复核人权限，保存必要的财务与决策记录，按政策删除提供商工作区并通知使用者。负责经理签署退役完成，但各控制负责人仍要提供证据；一个总勾选不能代替这些证明。

无人接任最终负责人的用例进入暂停状态，不能因为系统仍能运行就继续。责任模型的价值之一，就是让负责人离职成为可检测的运行事件。

交接包含待决事项、例外、例外放行、事件、容量、已知差距、下一次复核和停止权限演练；新的最终负责人不能只收到一份RACI文档。原负责人离开前要与新负责人共同签署范围，系统在生效时间切换分配；交接失败就保持暂停或人工模式，不让智能体依赖历史权限继续执行。

变更后按角色定向通知：复核人知道页面与权限变化，经理知道容量和风险，运营知道怎样对账，控制人员知道新增了哪些测试。一次全员邮件不能证明理解；关键角色要用一张边界案例验证。运行30天后复查实际签署与例外放行，再决定是否正式关闭旧修订版。

交付人工问责包：先选一个真实影响，写清谁能说“可以”、谁能说“不行”、谁必须停

来源边界：NIST AI RMF Core的治理 2.1—2.3用于清楚角色、训练和领导责任，治理 3.2用于区分人机配置和监督；NIST Appendix A用于不同生命周期参与者任务，附录 C用于人机角色、偏见、表现差异与信息呈现限制。OECD 问责原则用于执行者按角色/情境/行动能力承担全生命周期问责、可追溯性和风险管理，并明确问责、责任、法律责任概念相关但不同。Microsoft Learn的Power Platform RACI页面只作为R/A/C/I定义、每项一个A和持续更新的产品生态实例；ISO/IEC 42001官方概览用于管理体系、责任和持续改进背景。本文不分配法律责任。来源核验于2026-07-22，NIST页面注明AI RMF 1.0正在修订。

• NIST AI RMF Core
• NIST Appendix A：Descriptions of AI Actor Tasks
• NIST Appendix C：AI Risk Management and Human-AI Interaction
• OECD AI Principle：Accountability
• Microsoft Learn：Define roles and responsibilities
• ISO/IEC 42001:2023：AI Management Systems

今天选一个智能体可能造成的真实影响，例如付款、发信、修改客户管理系统或关闭工单。不要只写“业务负责”，而是列出候选项、批准、执行、对账、暂停、例外和事故七个决策；为每个决策填写唯一的最终负责人、实际执行者、必须咨询的人、授权限制和回执。再用一个越权账号、一个过期签署和一个状态未知的操作做负面测试。任何一项找不到负责人、没有时间复核或无法真正阻断，就先保持建议或人工模式。