第 11 章 · 从数据治理，到行动治理

一笔理赔进入系统，材料齐全，保单有效，金额也在正常范围内。

模型建议通过。

如果屏幕上只显示这条建议，审核员还能复核证据；如果系统直接发起支付，几秒钟以后钱已经离开账户。同一句判断，因为后面接的动作不同，风险完全变了。

做过数据治理的人很容易从熟悉的问题开始：数据从哪里来，质量是否可靠，口径是否一致，过程能不能追溯。这些问题一个也不能少。

只是，行动系统还要多问一句：就算它算对了，是否也有权这样做？

数据治理管不到动作的终点

一条成熟的数据管道，通常关心来源、转换、质量、口径和血缘。

原始保单来自哪个系统，客户身份是否重复，日期格式是否统一，理赔金额经过哪些规则计算，报表里的数字能不能追到原始记录。出错以后，工程师可以重跑任务、修复字段、回补数据。

这些能力是行动治理的地基。输入不可信，任何自动决策都只是把错误加速。

可数据管道的主要产物仍然是数据。即使日报算错，多数时候还能更正、重发和解释。Agent 调用了外部工具，后果可能已经进入现实：保单被拒，订单被取消，设备被停机，客户收到通知，资金完成划转。

行动不总能重跑。有些错误可以撤销，有些只能补偿，有些会留下无法消除的关系和合规损失。

因此，治理对象要从“这条数据是否正确”扩大为“这个动作是否应该在此刻、以这种权限执行”。

先让它在影子里工作

面对高风险流程，最稳妥的第一步通常不是自动执行。

系统先读取生产环境中允许读取的数据，生成判断和拟执行动作，但不真正写回。原来的工作人员照常处理，项目组在后台比较两套结果。

这就是影子运行。

它能暴露离线测试看不到的问题：旺季数据分布变了，某种单据只在一家分支机构出现，规则之间发生冲突，员工实际使用的判断依据从未写进文档。

影子运行也有局限。系统没有真的进入流程，无法完全观察用户会不会依赖它、动作会不会触发下游连锁反应。它适合验证判断，不等于已经验证了生产执行。

所以权限应当分级释放。

先只读，再建议；建议稳定以后，可以让系统准备动作，由人确认；风险可控的部分再自动执行。这里的重点不是把“人在回路”设成永久保险丝，而是用真实证据决定哪些权限可以放开。

有些动作始终需要人工批准。大额赔付、改变客户权益、停用关键设备，不该因为模型平均表现很好就取消责任人。

评估集要装进现场的麻烦

模型评估常被压缩成一个准确率。

对行动系统，这个数字太粗。

把一笔应当人工复核的理赔误判为直接通过，与把一份普通材料转给人工，代价并不相同。系统在证据不足时主动停下，也许降低了自动化率，却提高了整体安全性。

评估集需要覆盖正常样本、边界样本、罕见例外和故意干扰。还要按动作后果分类，而不是把所有错误平均掉。

生产运行以后，新的失败应当回到评估集。某类扫描件总被漏读，某种订单状态导致重复改单，某种措辞让客户误以为已经赔付，这些都不能只作为一次工单关闭。

评估集记录系统在已知问题上的表现，生产反馈则不断改写“已知问题”的边界。

NIST 的 AI 风险管理框架把治理、情境识别、测量和管理放在一个持续过程里。它提醒项目团队，风险评估不是上线前填完的一张表，而是系统运行期间的工作。

限额、审批与最小权限

不是所有正确动作都该无限执行。

系统可以给一位客户发送补件通知，不代表它可以一小时发送十万条；可以调整一张订单，不代表它可以跨地区批量改单；可以查到某项敏感信息，也不代表生成回复时应该把它带出去。

行动边界至少要回答几个问题：

单次动作的金额、数量和影响范围是多少；
一段时间内允许执行多少次；
哪些对象、字段和工具能够访问；
什么条件下必须升级给人工；
谁可以批准，批准是否有时效。

最小权限在这里不是安全团队的口号。权限给得越宽，Agent 越容易完成任务，也越容易把一次判断错误放大成批量事故。

审批也不能只是“点一下同意”。如果审批人看不到证据、建议理由和预期后果，人工环节只是把责任形式化地转给了另一个人。

熔断之后，还要能够回放

系统总会遇到设计外的情况。

关键不在于承诺永不出错，而在于多快发现、能否停止、能否还原。

熔断条件要在上线前约定。连续失败达到多少次，某类错误率超过什么阈值，外部系统返回什么异常，单日影响金额到多大，系统必须自动降级或停止。

停下来以后，团队要能回答发生了什么。

当时读取了哪些数据，使用了哪个模型和提示版本，调用了什么工具，参数是什么，返回了什么，哪位用户批准过。缺少这些记录，复盘就会退化成翻日志和猜测。

回放并不意味着重新执行动作。它首先是用当时的上下文重现决策路径，判断故障来自数据、模型、规则、权限还是外部系统。对于不可逆动作，还要事先设计补偿流程，而不是事后寻找“撤销”按钮。

治理不是把自动化冻住

治理最容易走向两个极端。

一端相信模型能力足够强，可以尽快全自动；另一端因为害怕风险，让每一步都由人复核，结果用户比原来更忙。

可行的做法是按后果而不是按技术新旧分层。

整理材料、查找依据、生成草稿，通常可以较早自动化；改变客户权益、修改核心记录、触发资金和设备动作，需要更强的证据、审批和限额。随着评估与运行记录积累，某些边界可以逐步调整。

跨境电商追讨也遵循同样原则。系统可以整理平台扣款依据、生成申诉材料；如果要直接提交申诉、承诺事实或接受和解条件，权限就该重新分级。这个旁例与理赔不同，却没有逃出行动治理的共同问题。

数据管道担心的是算错。行动系统还要担心一件更难处理的事：它做错时，现实已经被改变。

这套治理要求很重。放进基础完善的企业尚且不轻松，到了数据、流程和权限仍有缺口的现场，FDE 往往要一边补地基，一边交付应用。最后一章就去看这笔中国式的账。

本章资料

场景说明：本章理赔、订单、设备与客户通知均为用于解释治理原则的复合场景，不对应真实客户或真实资金记录。