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