KeelBase ← Home GitHub

为什么 AI 写数据要先分级？R0-R5 工具风险模型

上一篇讲了「Runtime over Prompt：为什么 System Prompt 不是安全边界」——安全边界要落在 Tool 真正执行之前。这一篇往深一层：边界既然落在执行路径上，Runtime 凭什么判断一个 Tool 该不该放行？

AI 真正让企业犹豫的，往往不是「读」，而是「写」——查客户可以，改客户呢？发邮件呢？删数据呢？

一、读和写，风险不对称

AI 读数据出错了，是「看错了」——改回来即可，损失有限。

AI 写数据出错了，是「改坏了」——订单金额改错、客户资料覆盖、邮件发给了不该发的人，很多是不可逆或代价高昂的。

所以企业对 AI 的态度，通常从「让它查」到「让它做」之间有一道坎。这道坎的本质是：对不同风险的操作，企业要不要用同一套策略对待？

显然不要。查客户可以自动，改合同必须人批，删数据根本不该允许。

这就是「工具风险分级」要解决的问题：先给每个 AI 操作定一个风险等级，再按等级决定执行策略，而不是一刀切「全部自动」或「全部人审」。

二、R0-R5：一套可落地的分级

把 AI 工具按风险从低到高分成六级，每级对应一种执行策略：

关键设计点：

• 读自动，写确认，高风险阻断——低风险自动化提升效率，高风险人工把关，不可逆直接拦死。
• 显式声明优先，未声明按语义派生——工具声明了风险级就按声明；没声明时，写操作默认 R3（需确认）、读操作默认 R1（自动）。漏声明不意味着「放行」，而是「保守确认」。
• 策略可覆盖——治理层可以在运行时覆盖单个工具的启用与确认要求，实时生效。

这套分级的好处是：它把「敢不敢让 AI 做事」从感觉变成规则。业务方不用逐个判断，只需要按风险级定策略。

三、分级怎么在运行时落地

分级本身只是纸面规则，真正让企业放心的是它在运行时的强制力。一条完整的执行链：

工具声明风险级（R0-R5）→ 权限检查（行级数据范围：本人 / 组织）→ 策略门控（R5 阻断 / R3-R4 确认 / R0-R2 自动）→ 人工确认（确认了才执行，拒绝则不执行）→ 执行写操作 → 副作用登记（可撤销）+ 审计入链

以开源项目 KeelBase 的实现为例，这套链是可验证的。

仓库（境内访问建议用 Gitee 镜像）：

• GitHub：https://github.com/rain6fish/KeelBase
• Gitee：https://gitee.com/rain6fish/KeelBase

• 工具声明：每个 AI 工具带 riskLevel，MCP 出口把风险级透出到工具声明（_meta.keelbase）——外部客户端调用前即可见。
• 门控：R5 直接阻断（响应明确告知「该操作已被安全策略阻断」），R3/R4 返回确认标记，人工批准后才执行。
• 审计：每次执行都落审计哈希链；被拒绝的调用同样留痕（授权拒绝写 isError=true + 拒绝理由清单），可追溯、防篡改。
• 撤销：AI 创建的副作用登记后可撤销（含跨系统补偿）。

协议合规认证套件锁定这套语义。实跑 Server-NestJS/scripts/verify-protocol-conformance.mjs 的输出：

─ 工具风险分级（协议 §4）─
  ✓ RISK_STRATEGY 表与语料一致
  ✓ R1（读）→ auto / 无需确认
  ✓ R3（业务敏感写）→ confirmation / 需确认
  ✓ R4（高影响）→ human_approval / 需确认
  ✓ R5（不可逆/外部）→ block / 阻断
  ✓ 派生规则：未声明写工具 → R3 confirmation
  ✓ 派生规则：未声明读工具 → R1 auto

═══ Conformance 结果：34/34 通过（0s）═══

篡改、越级、确认绕过都会在这里被拒。

结语

AI 写数据不是不能做，而是要分级、要确认、要可追。把「敢不敢让 AI 做事」变成一套可执行的规则，企业才敢把 AI 从「助手」升级成「干活的」。

如果你也在做 Agent，可以拿自己的系统对三个问题：

1. 工具清单里，有没有「写操作」是没有任何执行策略的——能调就执行
2. 没声明风险的工具，默认是放行，还是保守确认
3. 高风险操作被拦住时，是模型自己回了一句「我不能」，还是执行层真的拒了

第三个问题最关键。如果答案是「模型自己拒绝的」，那这道边界还停在 Prompt 层，没落到执行路径上。

如果你发现某种工具分级或门控方式可以绕过，欢迎直接提 Issue（GitHub 或 Gitee 都行）——我更想看到失败案例，而不是只有成功案例。