Wiki Notes

Appearance

安全治理 ​

版本：v1.2

最后更新：2026-07-08

这一组内容覆盖的是：AI 系统从安全、权限、审批、回滚、审计、值班到故障响应的完整治理链路。

它不是“额外加一层风控”的补丁，而是把高风险模型调用、工具调用、知识访问和系统变更纳入可解释、可审批、可追责、可回滚的运行机制。

1. 这一组内容主要解决什么 ​

AI 系统的安全问题，和传统 Web / 后端系统有相同部分，也有非常不一样的地方。除了普通鉴权、审计和发布安全，还会多出这些问题：

  • 模型可能被 prompt injection、越权工具调用和恶意输入带偏。
  • 检索上下文、工具结果和多租户知识可能引发数据泄露。
  • 高风险动作需要 guardrails、审批和人工 review，而不是只靠自然语言约束。
  • 模型、Prompt、路由和策略上线后，需要能灰度、回滚、演练和事故复盘。

OpenAI Safety best practices、Guardrails and human review、Safety in building agents 的官方资料，以及相关 guardrails 示例都在强调：真正有效的安全不是“让模型更听话”，而是把自动校验、权限边界、人工审核和追踪能力落到系统机制上。

2. 这组内容应该怎么读 ​

2.1 想先建立基础安全框架 ​

  1. AI安全与合规专题
  2. Guardrails与安全策略专题
  3. 企业权限模型专题
  4. 角色权限矩阵专题
  5. AI治理与审计专题

2.2 想补“审批、回滚、灰度”这条治理链 ​

  1. 安全审批策略案例专题
  2. 多阶段审批链专题
  3. 审批策略模拟专题
  4. 影子发布与灰度评估专题
  5. 系统回滚策略专题
  6. AI变更管理专题

2.3 想补“事故响应与长期运行”这条线 ​

  1. AI系统事故响应专题
  2. 故障演练与预案专题
  3. 安全回归测试专题
  4. 企业SLA与值班体系专题
  5. 企业AI组织协作专题

3. 这组专题可以怎么理解 ​

3.1 防护层 ​

这一层回答的是：危险输入怎么拦、危险输出怎么判、不同风险等级的任务怎么走不同处理路径。

3.2 权限层 ​

这一层更偏“谁能看什么、谁能做什么、在哪个租户边界内做、授权如何继承和审计”。

3.3 决策层 ​

OpenAI Guardrails and human review 当前官方定义很清楚：guardrails 负责自动校验，human review 负责批准或拒绝敏感动作。这个分层特别适合用来理解审批链设计，不要把“自动规则判定”和“真正的人类责任决策”混成一个黑盒。

3.4 运行层 ​

这一层更接近真实生产：策略改了怎么灰度，模型换了怎么回滚，事故来了怎么分级响应，值班团队怎么接住问题。

4. 安全治理里最该先建立的几个共识 ​

4.1 安全边界要落在系统机制上 ​

仅靠提示词里写“不要执行危险操作”，在高风险场景里通常是不够的。更稳的做法是把可调用工具、可访问知识、可执行动作、审批节点和输出校验做成显式机制。

4.2 guardrails 和审批不是一回事 ​

  • guardrails：自动检测、自动拦截、自动标记风险
  • 审批：对高后果动作做责任决策

把这两件事分开建模，系统会更容易解释，也更容易审计。

4.3 安全不是“阻断一切”，而是做风险分层 ​

很多团队安全策略失效，不是因为没加规则，而是因为所有请求都走一套规则。真实系统更适合按读写、租户、工具类型、资金风险、用户影响范围做分层，再决定是自动放行、二次确认、审批还是拒绝。

4.4 安全治理一定要和变更治理、演练和回滚接起来 ​

如果一个策略只会“拦”，不会灰度、不会演练、不会回滚，那它在事故里往往会成为新的问题来源。安全策略本身也应该被当成可发布、可验证、可回退的系统资产。

5. 企业里最常见的五个治理判断 ​

5.1 什么时候该用 guardrails，什么时候必须上人工审批 ​

OpenAI 当前 Guardrails and human review 已明确把两者分成不同控制：guardrails 适合自动校验输入、输出和工具结果；human review 更适合真正的批准决策。只要开始涉及外部副作用、客户权益、资金和高敏数据，通常就不该只靠 guardrails。

5.2 安全 review 应该拦哪一层 ​

更稳的设计通常至少同时考虑：

  • 输入层
  • 上下文层
  • 工具 / 动作层
  • 输出层
  • 变更发布层

如果只盯输入文本，很容易漏掉知识污染、工具越权和策略变更导致的问题。

5.3 回滚对象不该只看代码 ​

AI 系统里真正需要回滚的，往往还包括：

  • Prompt
  • 模型版本
  • 工具 schema
  • 审批规则
  • 检索 / 路由 / guardrail 策略

5.4 值班体系为什么一定要和安全告警绑定 ​

很多高风险问题不是“接口挂了”，而是：

  • 高风险动作误放行
  • 审批链卡住
  • 风险路由错误
  • 敏感数据触达范围异常

这类问题如果没有专门的升级和处置路径，往往不会被当成事故及时接住。

5.5 安全回归为什么要长期跑 ​

修过一次的问题如果不进回归集，后面随着模型、Prompt、工具和知识变化，很容易原样回来。

6. 哪些系统分界线最容易被忽略 ​

6.1 安全策略和业务策略会互相影响 ​

更严格的 guardrail、审批或限流可能降低风险，但也可能显著影响通过率、时延和人工负载，所以不能只从单一维度评估。

6.2 数据治理和权限治理不能拆开看 ​

OpenAI 当前 Data controls 说明平台侧日志和应用状态有不同留存路径；应用自己的 trace、缓存、向量索引、工具快照往往也会累积敏感信息。所以“谁能看什么”和“哪些数据会被存下来”必须同时设计。

6.3 安全问题经常先表现为运行异常 ​

例如：

  • 审批超时率升高
  • guardrail 触发率异常
  • 人工接管暴增
  • 某类工具被异常频繁调用

这些指标往往比“是否真的发生事故”更早给出预警。

7. 当前官方资料最值得先建立的四个治理判断 ​

按 2026-07-08 复核可访问的 OpenAI、NIST 和 Anthropic 官方资料，比较值得先建立的治理判断有这些：

7.1 moderation、safety checks、guardrails、human review 不是同一层控制 ​

OpenAI 当前官方资料其实把几层控制对象分得很清楚：

  • Moderation：更偏对有害文本与图像内容做分类识别
  • Safety checks：更偏平台与使用方式如何通过安全评估、避免违规
  • Guardrails and human review：更偏在运行流里决定 continue、pause 还是 stop
  • Safety in building agents：更偏工具、MCP、PII、审批和执行安全设计

这四层如果混成一句“我们已经做了安全”，系统很容易出现两个误判：

  • 以为加了内容审核，就等于高风险动作也安全了
  • 以为有 guardrails，就不再需要真正的人类批准决策

更稳的理解通常是：

  • moderation 负责内容风险识别
  • safety checks 负责平台与政策合规边界
  • guardrails 负责自动校验和自动阻断
  • human review 负责高后果动作的责任决策

7.2 NIST 的价值不是“再多一份理论”，而是把治理接回组织控制面 ​

NIST AI RMF 和 Playbook 的 Govern / Manage 当前都在强调同一件事：

  • AI 风险治理不能孤立存在，而要接回组织现有治理、风险管理、数据治理和变更管理机制

这对企业里的直接启发通常是：

  • 安全策略不该只挂在某个模型团队名下
  • 风险分层、批准责任、留痕口径、第三方模型与工具追踪，都应该进入正式治理对象

也就是说，安全治理不只是“把接口拦住”，还要回答：

  • 谁定义风险容忍度
  • 谁批准变更
  • 谁对外部模型、MCP server、第三方工具承担准入责任
  • 触发风险后由哪个值班和升级体系接住

7.3 只要有真实世界后果，就不该跳过人工确认 ​

Anthropic 当前关于 computer use 的官方文档有一个非常实用的提醒：

  • 对会产生有意义真实世界后果的决策，应要求人类确认

这个原则不只适用于 computer use，本质上也适用于很多企业 AI 场景：

  • 发消息
  • 改数据
  • 提交审批
  • 触发工单
  • 对客户权益、资金或权限产生影响的动作

更务实的做法通常是把“是否需要人工确认”当成动作分类的一部分，而不是事后再补。

7.4 数据留存路径和访问权限必须一起设计 ​

OpenAI 当前 Data controls 资料明确说明平台侧不同功能存在不同的数据控制与留存边界；而企业自己的：

  • trace
  • 缓存
  • 向量索引
  • 审批快照
  • 工具参数与结果

往往还会形成第二套留存体系。

所以真正需要一起设计的其实是两件事：

  1. 哪些数据会被存下来。
  2. 存下来以后谁能看、谁能导出、谁能删。

如果这两件事拆开做，系统很容易在“权限看起来没问题”的前提下，通过 trace、缓存或索引旁路泄露敏感信息。

8. 安全治理里最容易漏掉的四个控制对象 ​

8.1 发布对象 ​

很多团队只盯代码版本，但真实影响安全边界的往往还包括：

  • Prompt / system 指令
  • 模型与路由策略
  • 工具 schema
  • 检索与过滤配置
  • 审批与风险路由规则

这些对象如果不冻结，安全回滚就很容易只回了一半。

8.2 审计证据对象 ​

很多系统会记录“这次被拦了”或“这次通过了”，但没有留下：

  • 当时触发的是哪条规则
  • 审批看到的是什么对象快照
  • 最终执行的是哪一版参数

如果证据对象不完整，后面很难做真正复盘。

8.3 领先指标对象 ​

安全事故真正爆发前，通常更早出现的是：

  • guardrail 触发率异常
  • 高风险动作审批量暴涨
  • 审批超时率升高
  • 人工接管率飙升
  • 某类工具调用量异常

这些对象如果不进日常监控，团队就会总在事故已经造成影响后才知道出事。

8.4 第三方能力对象 ​

一旦系统开始接：

  • 第三方模型
  • MCP server
  • 外部 SaaS connectors
  • 浏览器 / shell / computer-use 类工具

风险对象就不再只是“我们自己的代码”。更稳的做法通常是把这些能力的：

  • 准入
  • 权限
  • 留痕
  • 人工确认
  • 退场与禁用路径

都当成正式治理对象。

9. 推荐搭配阅读 ​

10. 重点官方资料 ​

以下入口在 2026-07-08 检查时可访问：