先分级再分权
把数据按敏感程度分级，再对照岗位确定可访问范围。分级不清时，权限只能按部门粗放设置，实际使用中不是过宽就是不够用，最后靠人工逐个审批补洞，效率很低，业务方也会抱怨审批太慢，审批也更顺。
过滤要在检索前
在召回阶段就按用户权限过滤文档，而不是生成后再遮盖。后遮盖意味着模型已经看到无权内容，一旦遇到诱导式提问就可能复述出来，责任无法推给用户，越权也难以察觉，事后也难界定责任归属。
身份要能同步
组织架构与人员变动应自动同步，离职与调岗即时回收权限。手工维护的权限表在三个月内必然与实际不符，而错配往往在越权发生之后才会被发现，错配无从纠正，错配也很难被及时发现，审计也更难。
审计记全链路
记录提问人、时间、检索命中的文档与版本、模型输出、人工接管与导出行为。只记问答对，无法解释为什么返回了这条内容，事故调查只能靠当事人回忆，审计价值大打折扣，记录也要能导出，取证也更完整。
审计要有人看
设异常规则，例如高频导出、跨部门查询、敏感词触发，并定期抽查。没人看的审计日志只是存储成本，也无法在评审时证明制度真的在运行，抽查要有结论与整改人，评审时根本拿不出任何有效证据。
适用与不适用
适合谁
- 面向多部门开放的知识问答类应用
- 涉及敏感数据、需要留痕的企业，且有内部审计要求
- 要通过安全评审或等保测评的系统
不适合谁
- 单人或单团队内部使用、数据不敏感的工具
- 尚无身份体系、也无建设计划的组织
典型场景
某集团的知识助手接入统一身份，按部门与职级配置文档可见范围，检索阶段完成过滤。上线后审计发现一名员工频繁查询其他事业部文档，经核实为权限配置错误，当天修正并回收，避免了一次实质性越权，权限也一并修正了。
可执行步骤
- 按敏感程度给数据分级，标注每类数据的责任人，并写成表，并写成清单，并留档
- 设计角色与数据范围的对应关系，覆盖跨部门场景，留出例外通道，并留例外通道
- 接入统一身份，实现入职、调岗与离职的自动同步，并做验证，并做一次验证
- 在检索层做权限过滤，并记录每次命中的文档与版本，便于回溯，保留检索日志
- 配置异常规则，定期抽查审计日志并跟进整改，形成闭环记录，并跟踪整改
常见坑
- 生成后再遮盖，模型已接触无权内容，诱导提问即可复述，责任说不清，事后难以追责，责任也说不清。
- 权限按部门一刀切，跨部门协作频繁申请例外，最后管理员直接开口子，权限迅速失控，审计也看不出边界。
- 离职人员权限未回收，账号长期可用，审计也看不出异常，风险持续累积，离职后依然能查到数据，风险一直存在。
- 审计日志只有时间与问题，没有检索命中，无法还原上下文与判断依据，也无法向评审交代，处置也无法证明。
自检与验收清单
- 数据是否完成分级并标注责任人，形成分级清单
- 过滤是否发生在检索阶段而非输出阶段，且有记录
- 身份变动是否自动同步到权限，并有验证记录，且可验证
- 审计字段是否覆盖检索、输出与导出，并可导出复核
- 异常规则是否有人跟进并闭环，整改可追溯，且有整改
常见问题
权限做多细才够？
到文档或字段级即可满足多数场景，过细会增加维护成本。关键是分级清楚、责任人明确、变动能同步，而不是追求把每个字段都单独配置一遍，否则规则没人维护，维护才可持续。
审计日志要存多久？
按行业与合规要求确定，通常不少于六个月。涉及个人信息或重要数据的，应参照相关法规与客户方制度延长，并在制度里写清保留期限与销毁方式，也便于合规审计，也便于复盘。
员工问敏感问题要不要拦？
应在检索阶段按权限过滤，并在交互层提示可见范围。是否记录与告警由客户方制度决定，系统提供能力与证据，不替客户方做合规判断，也不替代其制度，也便于解释，也更省心。