大部分团队把注意力都放在「检索准不准」，很少有人认真设计「谁能检索到什么」。后果往往比答错严重得多。
本文对应公开讨论中后果最严重、但最少被提起的一条风险。不涉及恐吓判断，只讲机制。
普通员工问了一个看似平常的问题，AI 从语义相近的文档里，把只有主管能看的薪酬结构捞出来，还组织得清清楚楚。在财税和律所这类机构，这个问题的量级完全不一样——不是内部薪酬，是另一个客户的底稿或卷宗。
这不是假设性的风险，而是现有架构下的默认行为：检索系统不知道谁是「该看的」，它只知道什么「语义相近」。
先把一次问答的完整链路拆开看，问题就一目了然。RAG（检索增强生成）的标准流程是五步：
| 步骤 | 环节 | 发生了什么 |
|---|---|---|
| 1 | 确定用户身份 | 系统拿到「谁在问」——所属部门、职级、可访问的客户/项目范围 |
| 2 | 候选集过滤 | 用元数据把无权访问的文档从待检索集合里剔除 |
| 3 | 相似度匹配 | 在剩下的文档里做关键词 + 语义检索 |
| 4 | 重排 | 对候选片段重新排序，取最相关的若干条 |
| 5 | 拼接上下文 → 生成 | 把片段拼成提示词送进模型，生成自然语言答案 |
分界线在第 4 步和第 5 步之间。
一旦文本被拼进提示词送进模型，它就离开了你可控的边界。此后无论你在界面上做什么——不显示、打码、弹二次确认——都已经晚了。
很多系统的做法正是「第 5 步之后按角色过滤展示」，这在传统搜索里够用，在 RAG 里等于把文件发了出去再让用户别看。
核心只有一句话：让「看不看得到」这件事发生在「找不找得到」之前。具体靠三层机制。
每个文档切片入库时必须带四类字段，缺一类整套机制就塌一角：
元数据不是装饰性标签，它是第 2 步唯一的过滤依据。没有元数据，系统在第 2 步就没有任何东西可依据，只能放行全部文档进第 3 步。
用户身份确定后，先执行一次权限集合运算，把无权文档从待检索集合中物理移除，再做相似度匹配。这一步的工程要求是可审计、可回放——出事时要能回答「这次请求到底动用了哪些文档」。
每一条回答必须能定位到「来自哪份文档的哪一段」。溯源不是给答案加装饰，它是权限体系的验收手段：没有溯源，你就无法证明过滤真的生效了。
| 做法 | 是否有效 | 说明 |
|---|---|---|
| 第 2 步：候选集前置过滤 | 有效 | 无权文档根本不参与检索，是唯一正确的位置 |
| 第 3 步后：结果再过滤一遍 | 部分有效 | 多一道保险可以要，但不能替代第 2 步 |
| 第 5 步后：按角色遮挡显示 | 无效 | 文本已进模型上下文，遮挡显示只是自我安慰 |
| 只靠提示词约束模型别说 | 无效 | 提示词是可绕过的技术手段，不能作为安全边界 |
律师与客户之间的关系建立在保密之上。落到知识系统上，有三条通常被认为是硬要求（具体到你所在机构的适用规范，请以本所合规负责人或当地律师协会的意见为准，本文不替代法律意见）：
甲客户的卷宗、尽调材料、交易方案，对乙客户项目组的人员必须完全不可见。这不是「最好有」。技术上对应的就是元数据层的客户归属字段 + 第 2 步前置过滤。
同一所内代理利益冲突双方时，需要设置信息屏障。反映到系统上就是：权限不是静态的，同一个人在不同案件角色下可见范围不同，且案件结项、人员调岗后权限必须能立即变更。因此系统集成时通常需要与所内的案件管理系统（PMS）对接取权限，而不是在系统里维护一份会过期的名单。
客户材料是否被送进了第三方云端模型进行推理，很多委托合同里是明确禁止的。这也是我们坚持私有化部署的原因——模型跑在你自己的环境里，数据不出内网。此外通常会要求签署数据处理协议，明确数据用途、留存期限与销毁方式。
顺带一句：如果某个项目的保密要求高到不允许任何形式的结构化处理，我们的建议是直接不做，而不是先接单再想办法。这个边界在需求沟通阶段就该谈清楚。
财税机构的敏感数据类型和律所不同，但敏感程度不低：
财税系统的特殊性在于「按项目授权」是常态：同一个会计师同时跟五个客户的年审，权限要跟着项目走而不是跟着人走。因此元数据里的「归属」字段粒度必须是项目级，不是部门级。
把客户材料发给第三方闭源大模型做推理，在律所和财税机构的合规审查里基本都会被否掉。可行路径只有两条：私有化部署，或与模型服务方签署严格的企业级数据处理协议并确认不用于训练。选哪条要让客户的合规负责人拍板，不该由技术供应商替客户决定。
人员离职、调岗、案件结项后，权限必须立即失效。依赖「每月同步一次花名册」的方案存在一个月空窗。做法是权限尽量从客户的权威系统实时或准实时拉取，而不是在系统内部留副本。
AI 不会说「我不知道」。如果某个知识从来没被写下来，它不会报告缺失，它会用找到的东西编一个很像答案的东西。所以交付时要同时拿到知识缺口清单，明确知道哪些东西系统是覆盖不了的。
这事真正难的不是技术，是你得先承认自己的文档是乱的。
AI 是一面镜子。很多组织不喜欢镜子里的样子，然后得出结论说镜子是坏的。
上面这些落成可勾选的检查项，验收时逐条对照：
| 检查项 | 通过标准 |
|---|---|
| 元数据完整性 | 归属（项目级）/ 密级 / 时效 / 适用范围，四类缺一不可 |
| 过滤位置 | 在第 2 步候选集阶段完成，不是生成后遮挡 |
| 可审计性 | 每次请求动用了哪些文档可回放、可导出 |
| 答案溯源 | 每条回答可定位到文档 + 段落，作为权限生效的证据 |
| 权限时效 | 离职 / 调岗 / 结项后权限立即失效，不依赖月度同步 |
| 数据处理协议 | 明确用途、留存期限、是否用于训练、销毁方式 |
| 部署形态 | 私有化部署或经客户合规确认的云端方案 |
| 知识缺口清单 | 明确列出系统覆盖不了的部分，不声称「什么都能答」 |
说明：本文讲机制与工程做法，不构成法律或合规意见。落到具体机构，请由你们的法务 / 合规负责人结合适用的行业规范做最终判断。
留下联系方式，我们把这套元数据字段与检索阶段过滤的设计项整理给你，可自行对照现有系统检查。