搞个AI,居然把公司的＂裤衩＂都暴露了,问你怎么办?

上周和一个朋友聊天，他在某家集团公司负责AI落地项目。

聊到一半，他发来一张截图，沉默了几秒，说："你看，我们的智能问答系统……出事了。"

截图上，一个销售部门的员工在内部知识库里问了一句："最新的客户合同模板在哪里？"

AI回答得非常热情，不仅给了合同模板，还顺带把三份尚未签署的客户报价单、一份竞品分析文件，以及一个季度的销售毛利数据，一并"贴心地"附上了。

那几份数据，本来只有销售总监和财务VP才能看到。

他问我，这是Bug吗？

不是。

这是绝大多数企业在搭建RAG知识库时，会踩的一个系统性的坑——权限控制，根本没做，或者做错了地方。

先说清楚，问题出在哪

RAG（检索增强生成）系统的逻辑，用大白话解释就是：

员工问问题 → 系统去知识库里检索相关文档 → 把检索到的内容喂给大模型 → 大模型总结回答

听起来很顺滑。但有一个隐患藏在第二步：

系统去检索的时候，它根本不知道你有没有权限看这些文档。

它只管"相关不相关"，不管"该不该给你看"。

于是，那个销售员工的问题触发了语义相似性检索，系统找到了和"客户合同"高度相关的一堆文档，其中就包括那几份敏感数据，然后毫无障碍地交给了大模型去整理总结。

大模型不知道这些数据是机密，它只负责把检索到的内容讲清楚。

最终呈现给用户的，就是那份"贴心"的回答。

这不是大模型的问题，是架构的问题。

真正安全的企业知识库，需要三层防线

我把这套架构拆成三层，逐一说清楚。

第一层：接入层——"你是谁"

员工登录系统的那一刻，系统就要知道一件事：这个人，是谁。

不只是知道姓名，而是要知道：

他在哪个子公司（tenant_id）
他在哪个部门（department）
他的职级和角色（role）
他的安全密级（security_clearance）

这些信息，会被写入一个叫 JWT Token 的访问令牌里，随着每一次查询请求，一起带到系统后端。

安全密级怎么定？企业场景里，我建议分四级：

级别	内容举例	可见范围
L1 公开	员工手册、行政通知	全员
L2 内部	部门流程、通用技术文档	正式员工
L3 敏感	财务报表、客户名单、薪酬数据	财务、HR、管理层
L4 绝密	并购计划、战略规划、核心专利	高管 + 核心项目组，需二次审批

这是整个权限体系的基础。没有这一层，后面的防线都是空中楼阁。

第二层：检索层——"你能看什么"（这是最关键的一层）

很多团队的做法是：先检索，再过滤——"反正先把相关内容都找出来，最后再判断哪些能给用户看。"

这是最常见的错误。

原因有两个：

第一，性能浪费。大量无权限的文档被召回，占用计算资源，拉低检索质量，最终影响回答的准确性。

第二，存在泄露风险。过滤逻辑一旦出现哪怕一行代码的Bug，数据就直接裸奔。

正确的做法是：在检索之前就把权限条件锁死。

具体实现上，有两个方案可以选择：

方案A：元数据过滤（逻辑隔离）

每一份文档入库时，强制附上权限标签：

json

{"tenant_id": "subsidiary_A","department": "finance","security_level": 3}

员工查询时，系统根据他的 Token，自动构建过滤条件：

只检索：属于该员工所在子公司 AND 部门匹配 AND 安全级别不超过该员工密级的文档

这样，检索引擎在执行向量搜索之前，就已经把无关的文档排除在外了。

方案B：分区物理隔离

对于多子公司、多事业部这种"数据绝对不能互通"的场景，元数据过滤还不够稳，需要更硬的手段。

利用向量数据库（比如Milvus）的分区机制，直接把子公司A的数据和子公司B的数据放进不同的物理分区。子公司A的员工查询，就只在A的分区里搜，物理上根本碰不到B的数据。

实际工程建议：大型集团用"按子公司分区 + 分区内元数据过滤"的混合方案——公司间用物理隔离，公司内用逻辑过滤控制部门和角色权限。两层叠加，才是真正稳的。

第三层：返回层——"最后一道闸"

再稳的系统，也要假设它可能出错。

在把检索到的内容喂给大模型之前，应用层会做最后一次校验：这批文档片段，当前用户真的有权限看吗？

如果发现有漏网之鱼，直接丢弃，不进入大模型的上下文。

除此之外，还有一个动作：脱敏处理。身份证号、手机号、薪资数字，即使通过了权限校验，也要在返回前做自动打码，防止因为大模型的"热情发挥"而被完整复述出来。

光靠这三层还不够，还需要配套能力

元数据安全：用数据库的RLS兜底

文档的元数据（标题、上传人、版本号等）通常存在 PostgreSQL 这样的关系数据库里。

一个稳健的做法是开启 Row Level Security（行级安全策略）。

它的作用是：即使应用层代码有漏洞，数据库本身也会根据当前用户的身份，自动过滤掉无权访问的数据行。

应用层是第一道墙，数据库是最后的堡垒，两道墙都倒了才出事。

审计日志：出了事才知道是谁干的

每一次智能问答，系统都应该记录：

谁问的（员工ID）
问了什么
检索到了哪些文档（文档ID + 安全级别）
最终返回了什么

这不只是为了合规（GDPR等要求），也是追溯泄露源头的唯一手段。

如果哪天真出了数据泄露事故，没有日志，就是无头案。

异常检测：发现不对劲的行为

有些攻击不是技术层面的破解，而是利用合法账号"慢慢蚕食"数据。

几个值得关注的异常规则：

高频查询：同一账号1分钟内发起50次以上查询，可能是在跑脚本批量爬取数据
越权尝试：普通员工账号频繁触碰L3/L4文档的查询条件
异常时段：凌晨2点的密集查询请求

触发规则后，可以自动冻结账号并通知安全团队，不用等到第二天早上开会才发现。

权限缓存：别让安全拖垮性能

每次查询都去企业的LDAP或权限数据库里实时拉取权限信息，会带来50-100ms的额外延迟。一天几千次查询，体验会很差。

解决思路是把权限信息缓存在JWT Token里，Token有效期设5-10分钟。

但随之而来的问题是：员工离职或岗位调整时，旧Token还在有效期内怎么办？

答案是维护一个Token黑名单，员工权限变更时，把其旧Token强制加入黑名单，立即失效。这样既保住了性能，也不会留下权限"空窗期"。

写在最后

回到开头那个朋友的故事。

他们花了两周时间，把整套权限体系从头补上，重新灰度上线。

他后来跟我说了一句话，让我印象很深：

"以前以为权限是锦上添花，现在觉得它是系统的地基。地基没打好，楼建得越高，摔得越惨。"

企业AI落地的坑，很多不是模型不够聪明，而是工程上没想清楚。

数据泄露，从来不等你想清楚了再发生。

你们公司的知识库，目前是怎么做权限控制的？欢迎留言聊聊，或者转给正在做企业AI项目的朋友看看。