生成后遮盖
先让模型读全部文档，再在输出里打码。看似省事，实际模型已接触无权信息，遇到诱导式提问就可能复述。正确做法是在检索阶段按权限过滤，让无权文档根本不进入上下文，风险会长期潜伏下去。
共享账号
多人共用一个高权限账号，操作无法归因到人。一旦出现异常查询，既无法定位责任人，也无法证明未越权，调查基本停摆，最后只能全员重置权限，共享账号同理，事后想要追责也几乎无从谈起，责任也说不清。
只记问答
日志只有问题与答案，没有检索命中的文档与版本。回答出错时无法判断是知识过期、检索错配还是模型幻觉，改进只能靠反复试错，效率很低，也就无法改进，事后复盘就只能靠当事人凭记忆回忆。
权限一次性配置
上线时配好就不再维护，组织调整、项目并组后权限长期漂移。应把权限变更纳入人事与项目流程，并定期核对，否则等于把越权风险交给了时间，风险被长期低估，审计结论自然也就不可信了，取证也很困难。
日志可被删改
应用侧拥有日志写权限且可删除，出事后无法作为证据。应把日志写入独立存储，设只追加与访问控制，同时限制运维账号权限并记录其操作，证据链断裂，一旦出了问题，追查也就无从下手，追责也很困难。
适用与不适用
适合谁
- 已上线但未做过权限复查的系统，风险不明
- 出现过越权或数据外泄疑虑的企业
- 准备迎接安全评审与合规检查的团队
不适合谁
- 尚未上线、仍在设计阶段的项目，不涉及存量数据
- 单用户本地工具、无多角色隔离需求
典型场景
某企业在一次内部检查中发现，问答系统把薪酬制度文档返回给了非人力资源用户。排查发现权限过滤写在输出层，且检索未做范围限制。整改后改为检索前过滤，并补了跨部门查询的审计告警，审计告警也补上了，团队也补了规则。
可执行步骤
- 抽查检索链路，确认过滤发生在召回之前，并留样本，标注证据，并留存样本
- 清理共享账号，改为实名账号加最小权限，逐一登记，回收旧账，并登记台账
- 补记检索命中、文档版本与人工接管记录，字段要可查，版本要对齐，并标注版本
- 把权限变更接入人事与项目流程，设生效时限并联动组织架构，确保调岗即时生效
- 日志转独立存储，设只追加与访问控制，并限制删除权，定期校验，并定期校验
常见坑
- 以为输出打码就安全，忽略模型已读全文，风险藏在上下文里，事后难以补救，客户也会质疑，补做成本更高。
- 共享账号方便调试，长期保留成隐患，出事无人认账，调查无从下手，责任也无法落地，责任无人承担。
- 日志字段不全，事故调查只能靠当事人回忆，结论也无法复核，责任难以界定，责任也无法界定，事故也查不清。
- 权限表无人维护，调岗后仍可访问原部门数据，越权成了默认，审计也形同虚设，责任说不清，问题也查不出来。
自检与验收清单
- 过滤是否发生在检索层，而非生成后遮盖，且可复核
- 是否仍有共享账号在用，有无台账，且有台账可查
- 日志是否含命中文档与版本，可逐条复核，且可追溯
- 权限是否随人事变动更新，并定期核对，且有核对
- 日志存储是否防删改，且有访问控制，且有权限控制
常见问题
内部系统也需要这么严吗？
看数据敏感度。涉及人事、财务、客户信息的内部系统，同样需要权限隔离与留痕，内部人员越权的后果往往更直接，也更难对外解释清楚，补救成本很高，事后也难向管理层交代。
日志被删改的风险怎么防？
把日志写到独立存储或只追加的日志服务，应用只写不删；同时限制运维账号权限并记录其操作，形成互相制约，避免单点可以抹掉证据，也便于事后举证与责任认定，也更严谨。
小团队要不要做审计？
至少保留提问人、时间、命中文档与输出四项。成本不高，但出问题时能快速定位，避免扩大排查范围，也能在客户问询时给出可核查的依据，也便于向客户说明清楚情况，也更省心。