「绕过权限过滤的检索数」应恒为 0，并做成定期检查。
"谁看过什么"必须能查
AI 检索会跨越很多文档 ✔。一旦涉及权限与合规，"谁在什么时候检索到了哪些文档" ✔
就必须可审计 ✔ —— 否则出了泄露事件，你连影响范围都说不清 ✗。
证据链要能回答四个问题 ✔：谁、何时、用什么查询、取到了哪些文档 ✔。
一、审计日志该记什么（六项）
1. 主体（用户/服务账号 id ✔ —— 不记明文姓名，用可追溯的 id ✔）；
2. 时间（含时区，统一 UTC 存储 ✔）；
3. 查询（原文或其哈希 ✔；敏感场景只存哈希 ✔）；
4. 候选集摘要（取了多少条、过滤条件是什么 ✔）；
5. 最终使用的片段（块 id + 文档 id + 版本 ✔）；
6. 判定结果（权限通过/拒绝、是否需要二次确认 ✔）。
第 5 项最关键 ✗：只记"查了什么"不够 ✔，要记"实际用了什么" ✔ ——
因为泄露往往发生在"结果里带了不该带的" ✔。
二、日志本身要保护
· 访问受控 ✔（谁能看审计日志要有清单 ✔）；
· 不可篡改（追加写 + 校验和，或写入只读存储 ✔）；
· 保留期限明确 ✔（与合规要求一致 ✔）；
· 脱敏（查询原文可能含个人信息 ✔ —— 存哈希或脱敏版本 ✔）。
三、三件应该能"一键回答"的事
```
① 某文档被哪些人检索到过？（影响面评估 ✔）
② 某用户一周内检索了哪些文档？（行为审计 ✔）
③ 哪些检索绕过了权限过滤？（异常检测 ✔ —— 正常应恒为 0 ✔）
```
第 ③ 项应做成定期检查 ✔：正常系统里"绕过权限过滤"的检索数应恒为 0 ✔（见可筛选检索那篇 ✔）。
四、三个常见坑
· 只记 UI 层 ✗（直接调 API 的检索无记录 ✔）；
· 只记成功 ✗（被拒绝的检索也要记 ✔ —— 那是安全信号 ✔）;
· 日志里塞原文 ✗（审计日志变成新的泄露面 ✔）。
五、落地顺序
1. 先记"主体 + 时间 + 查询哈希 + 最终片段 id"（四项 ✔）；
2. 再把日志写进只读存储并设访问控制 ✔；
3. 然后做"权限绕过 = 0"的定期检查 ✔；
4. 最后把影响面查询做成一条命令（出事时能用 ✔）。
一条判据
> 假设某份敏感文档被误放进索引 3 天 ✔，你能否在半小时内列出"这 3 天里哪些人检索到了它" ✔？
> 不能，说明证据链还不完整 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：容量演练：主动断一次上游，验证降级链
下一篇：AI 功能的成本可视化：看得见、分得清、能追责 →
第 81 / 171 篇