企业 AI 安全治理，怎样管住资料、权限、输出和关键动作

企业 AI 系统的安全治理：四类特有风险

企业 AI 项目在安全评审这一关卡住，通常不是因为没做信息安全，而是因为用传统信息安全的清单去查一个 AI 系统，查不出它特有的问题。

传统清单查的是：谁能登录、数据传输加不加密、日志留不留、有没有备份。这些当然都要做，但 AI 系统还有四类它独有的风险，传统清单里一条都没有。

（下面的分类参考了 OWASP 针对大语言模型应用发布的风险清单，owasp.org，读者可自行核验完整版本。）

---

风险一：提示注入

是什么：用户输入的内容里，混进了试图改变系统行为的指令。

举个无害的例子说明原理：系统被设定为"只回答产品问题"，而用户在提问里附上一段文字，试图让系统忽略原有设定。如果系统把用户输入和系统指令混在同一个通道里处理，它可能真的会照做。

为什么传统清单查不出来：这不是代码漏洞，不是权限配置错误，是输入内容本身成了指令。传统的输入校验（防 SQL 注入那一套）针对的是特殊字符和语法，而这里的"攻击载荷"就是普通的自然语言。

防护的三条判据：

1. 系统指令和用户输入是不是分离的通道——混在一起是最大的问题

2. 系统有没有"不该做的事"的硬约束，且这个约束不在可被输入影响的位置

3. 有没有输出侧的检查——即使指令被绕过，输出层能不能拦住不该出现的内容

特别注意间接来源：如果系统会读取外部文档、网页或邮件内容，那些内容也是"输入"。从检索结果里带进来的指令，和用户直接输入的一样危险，而且更隐蔽。

---

风险二：权限越界

是什么：系统检索到了这个用户本不该看到的内容。

最常见的错误做法：先全量检索，再过滤结果。

为什么这是错的：即使最终没把内容显示出来，回答的措辞本身会泄露信息的存在。系统说"关于这个问题我无法回答"，和说"没有找到相关内容"，传递的信息完全不同——前者暗示了"有，但你不能看"。

正确做法：检索必须在权限范围内进行。用户的权限在检索发起时就参与过滤，而不是检索完再筛。

这条要求会影响架构选型，所以必须在开工前定。上线后再改，通常意味着检索层要重做。

验证方法：建一组"越权测试用例"——建议覆盖至少 3 个权限层级、每级 10–20 条，用低权限账号问高权限内容，检查两件事：

1. 内容没返回（这是基本要求）

2. 拒答措辞与"内容不存在"时完全一致（这是容易漏的那条）

---

风险三：数据外泄

是什么：企业数据通过 AI 系统流到了不该去的地方。

三条主要路径：

一、发给外部服务。

用公有云 API 时，输入内容会离开企业。这不是漏洞，是设计决定——问题在于很多团队没意识到"输入内容"包括了检索到的内部文档全文。

二、进了训练数据。

免费层的服务通常会使用用户内容改进模型。企业数据、客户资料、会谈记录绝不能走免费通道——这一条要写进制度，不能靠个人自觉。

三、通过输出泄露。

系统回答里带出了不该出现的内部标识、路径、字段名。

防护判据：

有没有一张明确的"数据分级表"，说清哪类数据可以走哪条路径
走外部服务的通道，有没有做脱敏或字段过滤
输出侧有没有内部标识的检查

第三条最容易漏。系统可能在解释来源时说出"根据 /internal/pricing_2024_final.xlsx"这样的内容——文件名本身就是信息。

一个低成本的检查：把内部路径前缀、系统代号、内部项目名整理成一张关键词表（通常 20–50 条就能覆盖大部分），在输出侧做一次匹配，命中就拦下。这道检查实现成本很低，却能挡掉这一类里的绝大多数。

---

风险四：输出不可控

是什么：系统给出了不该给的内容——编造的事实、越界的建议、不当的表述。

这一类的处理方式和前三类不同：前三类靠架构和权限解决，这一类必须靠输出侧的检查。

三道必要的输出检查：

1. 溯源检查：事实性陈述能不能对应到检索到的原文。对不上就不输出。

2. 数值校验：金额、比例、期限、日期这类数字，与原文做程序化比对。这一道最容易被跳过，而"不超过 30%"被复述成"35%"这种错误语义完全通顺，人眼很难发现。在一批真实输出上抽查时，数值类错误往往占全部事实性错误的 3 成以上，而它们恰恰是人工复核最容易放过的一类。

3. 边界检查：属于系统不该回答的类别（医疗诊断、法律结论、投资建议等），必须能识别并拒答。

拒答不是失败，是功能。任何问题都给答案的系统，一定在编。

---

一张表：四类风险的对照

风险	传统清单能不能查出	主要防护位置	最容易漏的一点
提示注入	不能	输入通道分离 + 输出检查	检索结果里带进来的间接注入
权限越界	部分能	检索层（不是过滤层）	拒答措辞泄露信息存在
数据外泄	部分能	数据分级 + 通道管控	输出里的内部文件名/路径
输出不可控	不能	输出侧三道检查	数值的程序化比对

---

合规这一项

在境内提供生成式人工智能服务，适用《生成式人工智能服务管理暂行办法》。面向公众提供服务与仅供企业内部使用，要求不同，这会影响到备案、内容标识等一系列要求。

各行业还可能有本行业的专门规范。这些必须由企业自身的合规部门确认适用情况——本文只提示其存在，不构成合规意见。

---

一份上线前的安全自检表

[ ] 系统指令与用户输入是分离通道
[ ] 检索结果中的内容被当作不可信输入处理
[ ] 检索在权限范围内进行，不是检索后过滤
[ ] 越权测试用例通过，且拒答措辞不泄露信息存在
[ ] 有数据分级表，明确哪类数据走哪条通道
[ ] 企业与客户数据不走免费或不受控的外部服务
[ ] 输出侧有溯源检查、数值校验、边界检查三道
[ ] 完整的输入输出留痕，可追溯到人和版本
[ ] 明确了拒答的场景和固定措辞，并有测试覆盖

九条里，第三条和第七条最常被跳过，也最贵。第三条上线后改要重做检索层——这通常意味着 4–8 周的返工；第七条缺失会持续产生难以发现的错误。

一个务实的排期建议：把这九条拆成"架构决定"（第 1、3、5 条）和"上线前补齐"（其余 6 条）。前三条必须在选型阶段定，改起来最贵；后六条可以在开发过程中逐步补上。

---

最后一条：安全评审要提前介入

最常见的项目延误原因不是技术做不出来，而是做完了才发现过不了安全评审。

正确的做法是在选型阶段就把安全和合规拉进来——他们提的要求（比如"检索必须在权限内进行""数据不能出网"）会直接决定架构，而这些要求在上线前才知道，就意味着返工。

把安全评审当成前置条件，不是最后一道关卡。

---