跳到正文
深圳 · 大湾区 · 地球

企业 AI 合规的答案在设计里:让模型只能提议,落笔必须有人签字

合规评审很少败在模型质量上,它败在方案里说不清这套系统一个人也不看的时候能做什么。只能提议、不能落笔的设计,从结构上关掉了这个问题。

6 分钟阅读1,398
AI AdoptionEnterprise暂无译文。

风控真正卡住的问题,从来不是模型准不准

我参加过不少这类评审,通常坐在一位法务或风控负责人旁边,他面前是一份 AI 方案,被要求表态。会开一个小时,议题十几个,最后几乎都是同一个问题的变体:这东西在没有人看着的时候,自己能做什么。

答案诚实的时候会很快就散会——什么也做不了,凡是要落进公司系统的改动,都需要一个具名的人签字。答案含糊的时候,收尾通常是一个熟悉的请求:请补一份合规策略文档。而那份文档屋子里没人写得出,因为要写的东西不在文档里,在设计里。

把系统设计成只能提议、不能落笔,绝大多数 AI 合规焦虑会当场失去附着点——因为需要人签字的系统,风险类别从「系统会不会做错事」换成了「记录能不能追到人」。

风控怕的三件事,只有一件跟模型有关

  • 收不回来的动作。 系统在有人发现之前把消息发了、把钱付了、把申报交了、把记录删了,而撤销需要对方配合。
  • 追不到作者的记录。 系统里躺着一条改动,没人能说清谁批的、依据什么、当时眼前有什么。
  • 出了边界的输入。 客户、人事或合同数据离开公司边界进了 prompt,没人能说清去了哪、留了多久。

只有第一条是模型能力问题。后两条是记账问题,而「只能提议」这条设计用一行日志同时回答了后两条。

「只能提议」必须做成结构,不能做成承诺

写在制度里的「模型不得直接写数据库」是一个承诺;一个没有写权限的数据库凭据是事实。这两样东西在遇到上线日期时的存活率不一样。

落到实现上是三件事。模型只返回一个动议对象:目标记录、建议改动、用到的证据、置信信号、有效期,以及产生它的那次运行的 id。一个独立的提交服务——公司里唯一持有写凭据的组件——只接受「动议加具名操作人」,别的输入一律拒收。审计日志把两件事记成两行不同类型:提议行是机器写的,提交行是人写的。

第三件最容易做错。模型对自己决策的说明不是证据,它只是另一段生成的文本;审计链一旦依赖模型解释自己,你建的就是一套会自己写不在场证明的系统。这套实现细节在把落笔权限收敛到单一提交服务的写法里有完整清单。

两种设计在审计那一刻的差别

动作类型能自主落笔的设计只能提议的设计审计时看到什么
限额内退款模型调用支付 API模型提议金额并引用条款,由人放款动议、所引条款、批准人 id、时间戳
开发票或税务申报模型直接提交模型组装并校验,由具名的人提交组装日志、校验失败项、提交人 id
删除或合并记录模型按规则执行模型标出候选,由人合并候选清单、合并决定、操作人 id

右列就是全部论点。只能提议的设计里,审计问「这条改动谁批的」,拿到的是一个名字;能自主落笔的设计里,同一个问题拿到一个 run id。

分级只看两条:能不能撤销,一次动到多少条记录。草稿错了不花钱;付款、监管申报、删除,或者任何一次影响超过个位数的改动,都该站在签名后面。这张写入路径表画出来是一个下午的活,而它恰好就是风控真正在要的那份文件(写入路径分级是我为企业做方案时的第一个交付物)。

这道闸门一年花多少钱

算术摆在这里,假设也写出来,换成你自己的数就行。一天 300 条动议、单条 90 秒读完,是 7.5 小时复核工时;乘 250 个工作日约 1875 小时,按全成本年薪 30 万元、每年 250 个工作日乘 7 小时有效工时折出的约 170 元每小时计,一年约 32 万元。

日动议量单条复核耗时每日复核工时折合全职年复核成本
300 条90 秒7.5 小时约 1.1 人约 32 万元
2,000 条90 秒50 小时约 7 人约 213 万元
2,000 条,七成一键确认、三成完整复核15 秒 / 90 秒约 21 小时约 3 人约 89 万元

分层不是省事的说法,是唯一让闸门活得下去的机制。这笔钱开工之前就能算出来,不像模型质量要等上线才知道。

这道闸门不解决什么

数据出边界。 只能提议对 prompt 里进了什么、哪家供应商处理、留存多久、是否用于训练,一句话都没说,这些靠合同条款和数据流图回答。带人事或健康数据的 prompt,这套设计一点都不改变答案。

人成了控制点。 风险没有被删掉,只是集中到了复核人身上。欧盟 AI Act 第 14 条对人类监督的要求,大意是监督方要能推翻或撤销输出、也能决定不用这套系统——它描述的正是这种设计,而不是人不会犯错。复核人是要被测试的控制措施,不是可以假定的。

闸门会被磨掉。 要求取消签字的压力大概在第四个月出现,通常包装成性能诉求,表面上还挺有道理。把写入路径分级写进设计文档,取消一道闸门就变成一件需要有人签字的事,而不是某个 sprint 里悄悄发生的默认值。同时盯一个数:推翻率,也就是复核人改判断或驳回的比例。橡皮图章式的复核在日志里和认真复核长得一模一样,而几千条下来推翻率贴在零附近,说明这不是复核,是签字。自动放过的那部分,公布抽样比例,「每周抽 5%,有记录」比「全部都审」更让审计信服。

让风控签字,要的是六份东西

都很便宜,而它们不存在的本身就是发现。

  1. 一张表,列出模型能够到的每一条写入路径,以及哪几条有人把关。要表,不要一句话。
  2. 模型运行环境持有的凭据及其权限范围。「只读、单库、没有写角色」是答案,「应用服务账号」不是。
  3. 动议行和提交行上的审计字段,外加试点里一条真实样例。
  4. 到目前为止的推翻率,以及自动放过部分采用的抽样比例。
  5. prompt 的数据流图,含供应商的留存与训练条款。
  6. 设计文档里写明「谁有权批准拆掉一道闸门」的那一行。

合规问题剥到最后一层

问题从来不是模型值不值得信任,而是这套系统允不允许它自己动手。结构上回答掉——模型提议、人落笔、两件事用不同作者记两行——本该烧掉一个季度的评审通常变成一次会,剩下的都是数据处理上的常规工作,你们公司本来就会做。先要那张写入路径表和一条真实的动议记录;这两样对得上设计,剩下的会开时间多半会花在别的事情上。

继续阅读

更多「AI 落地」

准备构建一套系统?[ 预约会议 ]