Wiki Notes

Appearance

AI治理与审计专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：需要给企业 AI 产品、RAG、Agent、审批助手和自动化流程建立治理框架、审计留痕与责任分工的产品、架构、平台、安全与合规同学

很多团队会把治理理解成：

  • 写几条规范
  • 补一套审批表
  • 保留一点日志

但在企业 AI 场景里，真正的治理通常要回答的是更难的一组问题：

  • 谁批准了这个能力上线
  • 哪些数据被允许进入模型
  • 哪些高风险动作被执行了
  • 哪些请求触发了人工审批
  • 哪个租户、哪个用户、哪个工具参与了这次决策
  • 事故发生后能不能完整复盘到责任链路

根据 2026-07-08 可访问的 NIST AI RMF / AI RMF Playbook、OpenAI Your data / Safety best practices / Production best practices / Building agents 等官方资料，可以先抓住一个核心共识：

  • AI 治理不是在系统外面再套一层流程，而是把风险识别、访问控制、人工介入、日志留痕、异常响应和持续整改一起做成系统能力。

1. 什么是 AI 治理 ​

更实用的理解通常是：

  • 让 AI 系统在组织里可控、可追责、可解释、可运营的一整套机制

它不是单点功能，而是跨多个层面的组合：

  • 风险分类
  • 数据边界
  • 权限边界
  • 工具执行边界
  • 人工审批
  • 审计留痕
  • 事故复盘
  • 持续整改

1.1 为什么“治理”不能只理解成文档制度 ​

制度当然重要，但如果制度不能投射到系统行为里，最后常见的情况是：

  • 文档里写得很严
  • 线上系统还是照样越界

所以成熟治理至少要做到：

  • 组织规则能映射到系统控制
  • 系统控制能留下审计证据
  • 审计证据能反过来驱动改进

1.2 NIST AI RMF 为什么适合作为治理底层框架 ​

NIST 当前 AI RMF 用四个核心函数来组织治理思路：

  • Govern
  • Map
  • Measure
  • Manage

把它翻译成更适合企业 AI 的语言，大致可以理解为：

  • Govern：谁负责、按什么规则负责
  • Map：系统会影响哪些人、数据、流程和风险场景
  • Measure：如何验证风险被看见、被量化
  • Manage：如何持续控制、调整、响应和复盘

2. 为什么 AI 治理比传统软件治理更难 ​

传统系统里，很多风险边界相对固定：

  • 哪个接口能调
  • 哪张表能查
  • 哪个角色能改数据

但在 AI 系统里，风险往往会通过“中间层”放大：

  • 模型会把不该拼接的上下文拼进去
  • 检索会把不该命中的知识召回
  • 工具会把看似合理但未经批准的动作执行掉
  • 多轮会话会把上一轮敏感状态带入下一轮
  • Agent handoff 会把不该共享的中间结果交给其他环节

2.1 AI 风险不是只有“答错” ​

很多真实治理问题并不是质量问题，而是：

  • 决策不透明
  • 数据来源不清
  • 权限边界不清
  • 行为不可回放
  • 自动化动作不可回滚

2.2 AI 系统里的“可观察”不等于“可追责” ​

很多团队已经做了 tracing，但 tracing 更偏：

  • 技术链路

而治理与审计更偏：

  • 责任链路

两者都需要，但不能互相替代。

3. AI 治理到底要管哪些对象 ​

很多团队最开始只盯模型本身，实际上治理对象至少有六类。

3.1 模型与推理行为 ​

例如：

  • 模型版本
  • 路由策略
  • 推理预算
  • Structured Outputs
  • 工具调用行为

3.2 数据与知识 ​

例如：

  • 哪类数据允许进入模型
  • 哪类数据只允许检索不允许外显
  • 哪类知识必须脱敏后再使用
  • 知识版本、失效与回滚策略

3.3 工具与动作 ​

例如：

  • 哪些工具允许调用
  • 哪些动作必须审批
  • 哪些工具只能读不能写
  • 哪些操作不可自动化执行

3.4 用户与租户 ​

例如：

  • 身份
  • 角色
  • 租户边界
  • 部门隔离
  • 会话状态边界

3.5 日志与审计证据 ​

例如：

  • 请求轨迹
  • 工具调用记录
  • 审批动作
  • 策略命中记录
  • 最终执行结果

3.6 异常与整改 ​

例如：

  • 审计发现
  • 红队发现
  • 线上事故
  • 纠错闭环
  • 回归评测

4. 审计最少要记录什么 ​

更可用的审计体系，至少建议记录下面这些对象。

4.1 请求主体 ​

要回答：

  • 谁发起了请求
  • 属于哪个租户或部门
  • 使用了什么身份上下文

4.2 模型与工作流上下文 ​

要回答：

  • 用了哪个模型
  • 走了哪个工作流版本
  • 是否启用了工具调用
  • 是否启用了结构化输出

4.3 数据与知识使用情况 ​

要回答：

  • 命中了哪些知识来源
  • 用了哪些文档版本
  • 是否使用了敏感数据
  • 是否命中了权限过滤

4.4 工具与动作执行情况 ​

要回答：

  • 调用了哪些工具
  • 参数是否经过校验
  • 哪些动作被阻断
  • 哪些动作进入审批
  • 哪些动作最终真的执行

4.5 风险与控制命中情况 ​

要回答：

  • 命中了哪些 guardrails
  • 命中了哪些 deny / allow 规则
  • 是否触发人工审批
  • 是否走了降级路径

4.6 结果与后果 ​

要回答：

  • 最终输出了什么
  • 是否写回了外部系统
  • 是否失败
  • 失败后如何收口

对于高风险链路，建议再额外保留：

  • trace_id
  • request_id
  • approval_id
  • policy_version
  • tool_call_id
  • content_version
  • release_batch_id

5. 审计和 tracing 到底是什么关系 ​

这两个词很容易混在一起，但不完全相同。

5.1 tracing 更偏技术链路 ​

它更适合回答：

  • 请求是怎么流过系统的
  • 哪一步慢了
  • 哪一步失败了
  • 哪个工具报错了

5.2 audit 更偏责任与合规链路 ​

它更适合回答：

  • 谁批准了这次动作
  • 为什么允许这么做
  • 哪个策略版本生效了
  • 哪个租户的数据被访问了
  • 出事后谁来复盘

5.3 企业里更好的做法是二者打通 ​

更成熟的系统通常会把：

  • trace
  • audit log
  • approval log
  • policy hit log

通过统一 ID 串起来。

这样做的价值是：

  • 运维能看技术链路
  • 合规能看责任链路
  • 事故复盘能把两者拼回同一条时间线

6. 一个更实用的治理分层 ​

比起把治理理解成“一个部门的工作”，更适合落地的方式通常是按层拆解。

6.1 策略层 ​

回答的是：

  • 哪些场景允许用 AI
  • 哪些数据禁止进入模型
  • 哪些高风险动作必须人工确认
  • 哪些租户或业务域需要更强控制

6.2 控制层 ​

回答的是：

  • 规则如何被系统执行

常见控制包括：

  • 权限校验
  • 检索过滤
  • tool allowlist / denylist
  • guardrails
  • approval gate
  • 限流与隔离

6.3 记录层 ​

回答的是：

  • 证据怎么留下

常见对象包括：

  • traces
  • 审计日志
  • 审批记录
  • 策略命中记录
  • 失败样例

6.4 运营层 ​

回答的是：

  • 系统如何被持续 review

常见动作包括：

  • 权限抽样核查
  • 高风险请求抽检
  • 安全 review
  • 事故复盘
  • 整改跟踪

6.5 整改层 ​

很多团队会漏掉这一层。

真正成熟的治理必须回答：

  • 发现问题后，谁改
  • 改完如何验证
  • 如何避免同类问题再来

7. 高风险动作为什么必须进审计链 ​

尤其是下面这些动作，不应该只依赖“系统大概没问题”：

  • 对外发送
  • 删除
  • 导出高敏数据
  • 修改权限
  • 触发生产配置变更
  • 触发财务或法务相关动作

OpenAI 当前关于构建 agent 与安全实践的文档都反复强调：

  • 对破坏性操作、认证流程和难以回滚的动作保留 human-in-the-loop

这个原则对企业内部 Agent 同样适用。

7.1 高风险动作的最小治理要求 ​

至少建议具备：

  • 明确的工具权限
  • 明确的审批门禁
  • 完整的参数记录
  • 明确的幂等与回滚策略
  • 事后可回放证据

7.2 审计不只是“记下来”，还要能解释 ​

真正需要保留的不是一句：

  • 已执行

而是至少能还原：

  • 谁请求的
  • 为什么允许
  • 当时看到了什么上下文
  • 哪个规则命中了
  • 哪个审批人确认了

8. 数据治理为什么必须进入 AI 治理 ​

很多企业 AI 项目出问题，并不是因为模型答错，而是因为：

  • 不该进来的数据进来了
  • 该脱敏的数据没脱敏
  • 权限收缩后历史知识仍可见
  • 共享租户之间发生了隐性泄漏

OpenAI 当前 Your data 与数据控制相关资料明确强调：

  • 数据保留与使用边界本身就是治理对象

8.1 数据进入模型前就该有分类 ​

至少应该区分：

  • 可直接进入模型的数据
  • 只允许检索、不允许外显的数据
  • 必须先脱敏或摘要的数据
  • 禁止进入模型的数据

8.2 知识库治理和数据治理不能分开看 ​

因为知识链路里常见风险包括：

  • 源文档权限改变了，但索引没变
  • 已失效文档仍然主命中
  • 引用落到不该暴露的段落

所以数据治理必须下沉到：

  • source
  • parsing
  • chunk
  • index
  • serving

整条链路。

9. 治理怎么和产品节奏兼容 ​

治理不是为了拖慢项目，而是为了避免项目失控。

更好的做法通常不是一刀切，而是按风险级别提升治理深度。

9.1 低风险场景 ​

可以更快推进，但仍建议具备：

  • 最小日志
  • 最小权限边界
  • 基本回归

9.2 中风险场景 ​

建议增加：

  • 风险评审
  • 样例回归
  • 工具白名单
  • 更完整日志

9.3 高风险场景 ​

建议增加：

  • 人工审批
  • 强审计
  • 隔离环境
  • 明确回滚
  • 上线观察窗口

一句话理解：

  • 治理不是统一变重，而是随着风险和自动化程度上升而分层加深。

10. 治理成熟度可以怎么判断 ​

下面这些问题可以作为快速自查。

10.1 风险识别是否成体系 ​

例如：

  • 是否定义高风险场景
  • 是否定义高敏数据
  • 是否定义高风险动作

10.2 控制是否真的下沉到系统 ​

例如：

  • 是否有检索过滤
  • 是否有工具权限
  • 是否有审批门禁
  • 是否有 deny / allow 策略

10.3 证据是否足够支持复盘 ​

例如：

  • 能不能按 trace_id 重建一次高风险请求
  • 能不能知道使用了哪些知识与工具
  • 能不能知道为什么放行

10.4 整改是否闭环 ​

例如：

  • 事故后是否有 owner
  • 是否有整改项
  • 是否回流到回归集

如果最后这一步做不到，通常说明治理还停留在“看见问题”，还没进入“系统变好”。

11. 更适合企业的最小治理清单 ​

如果团队刚开始补治理，建议至少先补齐这 8 件事：

  1. 定义高风险 AI 使用场景
  2. 定义数据进入模型的边界
  3. 定义高风险动作审批门禁
  4. 定义统一审计字段
  5. 定义模型、工具、知识和审批对象的版本绑定
  6. 定义高风险链路的回滚和人工接管方式
  7. 定义事故复盘与整改责任
  8. 定义周期性 review 与抽样机制

这套最小清单不算重，但已经能挡住很多真实事故。

12. 治理、权限、多租户分别是什么关系 ​

可以把三者看成一条从外到内的链：

12.1 AI 治理 ​

回答：

  • 整个系统怎样可控、可追责、可运营

12.2 权限模型 ​

回答：

  • 哪些主体能看什么、调什么、做什么

12.3 多租户架构 ​

回答：

  • 不同租户、部门和业务域之间如何稳定隔离

换句话说：

  • 治理定义框架
  • 权限定义决策
  • 多租户负责把隔离真正落到架构和运行时

13. 常见反模式 ​

13.1 只做制度，不做系统控制 ​

结果是：

  • 文档很全
  • 线上没有真正执行

13.2 只有 tracing，没有 audit owner ​

出了问题能看到链路，但找不到：

  • 谁负责
  • 谁批准
  • 谁应该整改

13.3 只审模型，不审知识和工具 ​

但很多真实风险恰恰来自：

  • 知识越界
  • 工具越权
  • 自动化动作无回滚

13.4 高风险动作没有单独证据链 ​

最后只留下“执行成功”，却没有：

  • 审批记录
  • 参数快照
  • 风险命中记录

13.5 出现问题后没有整改回流 ​

治理如果不和纠错闭环、回归评测挂钩，就只会变成一次次口头总结。

14. 推荐搭配阅读 ​

15. 重点官方资源 ​

16. 落地检查清单 ​

  • 是否定义了高风险场景与高风险动作
  • 是否定义了数据进入模型的边界
  • 是否定义了统一审计字段与对象版本
  • 是否能把 trace、审批和审计串成一条证据链
  • 是否有高风险动作的人类在环
  • 是否有事故复盘和整改责任归属
  • 是否把治理要求下沉到权限、知识、工具和发布链路