Wiki Notes

Appearance

AI安全与合规专题 ​

版本：v1.1

最后更新：2026-07-08

适用对象：正在建设企业 AI 助手、知识库、Agent、审批与外呼系统，以及需要把“内容风险、数据风险、工具风险、审计要求、人工审批要求”系统化落地的产品、平台、安全、法务与合规同学

只要 AI 系统开始接触：

  • 真实用户
  • 真实企业数据
  • 真实外部工具
  • 真实业务动作

就不可能只追求“效果好”，还必须回答：

  • 模型会不会输出不该输出的内容
  • 会不会越权访问或泄露敏感信息
  • 会不会被 prompt injection 或恶意上下文带偏
  • 会不会执行不该执行的工具动作
  • 出问题后能不能审计、回放、止损和追责

这篇专题聚焦的是工程化、产品化语境里的安全与合规，而不是抽象口号。

1. 为什么 AI 安全与传统应用安全既相似又不同 ​

传统系统安全更常见的关注点是：

  • 身份认证
  • 授权
  • 输入校验
  • 审计日志
  • 漏洞修复

AI 系统也需要这些，但它额外引入了新的攻击面和治理难点：

  • 模型可能被输入或上下文诱导
  • 输出不是确定规则，而是概率生成
  • 检索、工具、记忆、文件都可能成为风险入口
  • “错误回答”会升级成“错误行动”

因此 AI 安全不是给传统 Web 系统再加一层 moderation，而是：

  • 重新把输入、上下文、模型、工具、输出、审计串成一条风险链

2. 安全与合规真正要守住的不是一个点，而是一条链 ​

更实用的理解方式通常是：

text
User / System Input
 -> Policy & Safety Checks
 -> Context Construction
 -> Retrieval / File Access
 -> Model Reasoning
 -> Tool Invocation
 -> Output Validation
 -> Human Review / Approval
 -> Logging / Audit / Retention

只要其中任一环设计失控，都会形成真实风险。

例如：

  • 输入没问题，但检索内容带注入
  • 输出看似正常，但引用了跨租户内容
  • 模型判断没错，但工具参数越权
  • 工具动作被批准了，但审计链缺失

所以这篇专题的核心不是“怎样让模型更听话”，而是：

  • 怎样把风险边界落实到系统机制里

3. AI 系统最常见的五类风险面 ​

3.1 内容风险 ​

例如：

  • 暴力、仇恨、色情、违法内容
  • 自伤、极端、误导类输出
  • 医疗、法律、金融等高风险领域的错误建议
  • 企业内部不允许的用语和表达

这类风险最容易被看见，但不代表它是唯一风险。

3.2 数据风险 ​

例如：

  • PII 泄露
  • 商业机密泄露
  • 跨租户内容串出
  • 日志、trace、缓存里落了敏感片段
  • 文档删除后检索侧仍可召回

3.3 Agent 与工具风险 ​

例如：

  • 模型调用了不该调用的工具
  • 给外部系统发送了不该发送的数据
  • 被 prompt injection 诱导做了越权操作
  • 对外执行了不可逆动作

3.4 治理与运营风险 ​

例如：

  • 没有人工审批机制
  • 没有回滚路径
  • 没有红队与回归机制
  • 没有 owner
  • 事故后无法判断根因

3.5 合规与责任风险 ​

例如：

  • 用户没有被告知 AI 参与
  • 数据保留与删除策略不清
  • 审计证据不完整
  • 法务、业务、安全之间责任边界不清

4. OpenAI 当前官方安全资料给出的一个共同信号 ​

根据 OpenAI 当前在 2026-07-08 可访问的：

  • Safety best practices
  • Safety checks
  • Safety in building agents
  • Guardrails and human review
  • Moderation
  • Your data / data controls

这些官方资料反复指向同一条主线：

  • 安全不是靠一句 system prompt
  • 要用多层防护、人工监督、对抗测试、数据控制和持续评测来共同实现

这意味着一个可上线的 AI 系统至少要具备：

  • 自动风险检查
  • 工具权限限制
  • 敏感数据控制
  • 审计和可追溯
  • 对高风险动作的人类批准

5. 为什么 AI 合规不能只理解成“法务要求” ​

很多团队听到“合规”会先想到法律条文，但真正落到工程里，合规通常体现为以下约束：

  • 用户是否被明确告知 AI 参与
  • 输入和输出是否涉及敏感数据
  • 数据是否可以被保存、保存多久、谁能看
  • 是否可以对高风险输出进行回放和解释
  • 是否能证明某个敏感动作经过了审批

也就是说，合规在系统里往往会变成：

  • UI 交互要求
  • 数据保留与删除规则
  • 权限模型
  • 审计字段
  • 人机协同流程

没有这些工程约束，合规很难真正生效。

6. Prompt injection 为什么必须被看作系统级风险 ​

很多人把 prompt injection 理解成“模型被带偏”，但真实风险远不止回答质量下降。

更严重的情况是：

  • 模型读取到恶意文档内容
  • 被诱导忽略系统策略
  • 被诱导泄露上下文里的敏感数据
  • 被诱导调用高风险工具
  • 被诱导把不可信内容当作可信事实

所以 prompt injection 的本质是：

  • 外部输入试图修改系统行为边界

这就是为什么 OpenAI 当前 Safety in building agents 文档会明确强调：

  • 检测 jailbreak attempts
  • 对输入做 PII redaction
  • 保持工具审批开启

7. 数据安全必须按“完整数据路径”来设计 ​

很多团队会问：

  • “模型厂商安不安全？”

但更应该问的是：

  • 我们的数据到底经过了哪些地方

一条真实数据路径往往包括：

  • 用户输入
  • 网关
  • 提示词拼装层
  • 检索系统
  • 向量索引
  • 工具参数
  • 模型请求日志
  • trace
  • 评测样例
  • 审批单

其中任何一个环节都可能成为数据暴露点。

所以数据安全评估至少要回答：

  • 哪些字段会入日志
  • 哪些字段会进缓存
  • 哪些字段会进检索和评测
  • 哪些副本会长期保留
  • 删除请求如何传播到这些副本

8. Agent 场景为什么要比普通问答更保守 ​

普通问答的典型后果通常是：

  • 给出错误信息

Agent 场景的典型后果则可能升级成：

  • 错发消息
  • 错删记录
  • 错调审批
  • 错调用第三方 API
  • 错误触达用户

因此 Agent 系统最重要的安全原则通常是：

  • 最小权限
  • 显式工具白名单
  • 参数校验
  • 高风险动作人工确认
  • 全链路审计
  • 可回滚与可暂停

这也是为什么 AI 安全不能只停留在“输出审查”。

9. AI 安全基线应该包含哪些控制面 ​

更成熟的企业系统通常会分成六个控制面：

9.1 输入控制面 ​

关注：

  • 用户输入是否合法
  • 是否含 PII、越权请求、jailbreak、恶意载荷

9.2 上下文控制面 ​

关注：

  • 检索内容、文件、网页、历史记忆是否污染上下文
  • 上下文是否混入越权内容

9.3 工具控制面 ​

关注：

  • 工具能否被调用
  • 参数是否合法
  • 工具是否有最小权限

9.4 输出控制面 ​

关注：

  • 内容是否违反安全策略
  • 输出是否满足结构约束
  • 是否需要拒答、降级、转人工

9.5 行动控制面 ​

关注：

  • 是否允许真的执行动作
  • 哪些动作必须审批
  • 哪些动作需要二次确认

9.6 审计控制面 ​

关注：

  • 谁触发了什么
  • 系统为什么放行或拒绝
  • 哪个策略、哪个模型、哪个版本生效

10. 企业里最实用的“最小安全框架” ​

如果团队还在早期，建议至少先做下面这些最小动作：

  1. 输入与输出都做安全检查，而不是只盯一侧。
  2. 对敏感字段做脱敏与日志保护。
  3. 对工具调用定义白名单、角色边界和参数校验。
  4. 对高风险动作启用人工确认或审批链。
  5. 给关键请求保留 trace 与审计字段。
  6. 把红队样例与历史事故样例纳入安全回归集。

这六条不一定足够，但通常是“从 Demo 进入生产”最值的起步线。

11. 合规落地最容易忽略的四件事 ​

11.1 告知与同意 ​

需要明确：

  • 用户是否知道当前是 AI 在参与
  • 某些敏感处理是否需要显式同意

11.2 数据分类分级 ​

至少区分：

  • 公共数据
  • 内部数据
  • 敏感数据
  • 极高敏感数据

不同级别应该对应不同的：

  • 存储
  • 检索
  • 审批
  • 审计

11.3 保留与删除 ​

需要明确：

  • 输入保存多久
  • 输出保存多久
  • traces 保存多久
  • 评测样例是否留存
  • 删除请求如何联动

11.4 责任与 owner ​

要回答：

  • 谁定义策略
  • 谁批准高风险动作
  • 谁维护回归集
  • 谁在事故中有最终 owner 身份

12. 风险分层比“一刀切规则”更适合真实生产 ​

很多团队安全策略失效，不是因为没有规则，而是因为：

  • 所有请求都走同一套规则

更实用的做法通常是按风险分层：

  • 只读 vs 可写
  • 内部数据 vs 外部用户数据
  • 低影响输出 vs 高影响行动
  • 非敏感工具 vs 高风险工具

不同层级对应不同处理方式：

  • 自动通过
  • 自动拦截
  • 二次确认
  • 人工审批
  • 直接禁止

这种分层会比“所有请求一律拦”更稳定，也更可运营。

13. AI 安全设计不应该只盯文本，还要盯动作和副作用 ​

一个常见误区是把安全问题简化成：

  • 是否生成违规内容

但真实企业最常见的事故往往是：

  • 发送了错误对象
  • 用了错误工具
  • 对外暴露了内部内容
  • 审批链被绕过
  • 日志里落了敏感数据

所以更完整的安全判断应该至少覆盖：

  • 文本内容是否合规
  • 上下文来源是否可信
  • 工具调用是否有权限
  • 动作执行是否经过审批
  • 副作用是否可追溯

14. 审计为什么在 AI 系统里尤其关键 ​

AI 系统比传统规则系统更需要审计，因为它的行为更动态。

审计至少要回答：

  • 用户输入了什么
  • 哪些上下文被拼进去了
  • 使用了哪个模型、哪个 Prompt、哪个策略版本
  • 调了什么工具
  • 为什么被放行、拒绝、转人工
  • 最终执行了什么动作

建议至少保留这些字段：

  • request_id
  • user_id / tenant_id
  • policy_version
  • prompt_version
  • model_id
  • tool_name
  • approval_state
  • risk_level
  • trace_id

这样在事故发生时，团队才能真正追责和复盘。

15. NIST AI RMF 和 OWASP 给了哪些实用启发 ​

根据当前可访问的 NIST AI RMF / Playbook 与 OWASP GenAI Security Project 资料：

  • NIST 强调 Govern / Map / Measure / Manage 四个函数共同构成风险治理
  • OWASP 持续把 prompt injection、数据泄露、工具滥用、agentic threats 作为重点风险项

把这两类资料翻成工程语言，大致可以得到：

  • 没有治理 owner，就没有长期安全
  • 没有可测量指标，安全策略会逐渐失真
  • 没有红队、回归和发布门禁，防线一定会退化
  • 没有对 agentic workflows 的专门建模，工具风险会被严重低估

16. 最值得长期跟踪的安全指标 ​

建议至少跟踪：

16.1 风险触发类 ​

  • moderation 命中率
  • jailbreak / prompt injection 检出率
  • guardrail 触发率

16.2 审批运行类 ​

  • 人工审批触发率
  • 审批超时率
  • 审批绕过率

16.3 数据风险类 ​

  • 敏感内容误召回率
  • 跨租户误召回率
  • trace / log 敏感数据落盘率

16.4 运营稳定类 ​

  • 安全回归失败率
  • 历史高风险样例复发率
  • 安全变更后的告警波动

17. 企业最常见的反模式 ​

  • 把安全理解成上线前一次性审查
  • 只做输入 moderation，不做上下文、工具和输出控制
  • 只做文本安全，不做动作安全
  • 工具权限过大
  • 高风险动作没有人工审批
  • 没有回滚、回放和审计
  • 日志、trace、评测样例不做敏感控制
  • 事故发生后只修 Prompt，不修系统机制

18. 建议的落地顺序 ​

第一阶段：先立边界 ​

至少明确：

  • 高风险任务有哪些
  • 高风险工具有哪些
  • 哪些数据属于敏感数据

第二阶段：再立控制面 ​

至少做：

  • 输入检查
  • 输出检查
  • 工具权限和审批
  • 审计记录

第三阶段：再立回归闭环 ​

至少做：

  • 红队样例
  • 安全回归集
  • 发布门禁
  • 事故回流

第四阶段：最后再做组织与流程治理 ​

包括：

  • owner
  • SLA
  • 值班
  • 审批协作

19. 推荐搭配阅读 ​

20. 重点官方资源 ​

以下资源已按 2026-07-08 复核可访问：