事件覆盖率
把事件清单逐项对照系统实际埋点，缺一项就算未通过。怎么验：用真实操作走一遍提问、检索、导出与授权变更，逐条确认日志中能找到对应记录；只抽查登录环节等于没验，因为问题恰恰出在业务链路上。
字段与链路完整
每条日志要能取到主体、时间、对象、动作、结果与数据范围，且同一次请求的多段记录能用链路标识串起来。怎么做：验收时随机取三条真实请求，要求现场还原完整链路，拼不齐即视为字段或埋点缺失，需补做后重验。
脱敏与访问控制
抽样检查日志中是否出现明文手机号、证件号或合同正文，同时验证查询日志需要审批、审批记录可查。边界：脱敏规则与可查范围由客户方数据负责人确认，实施方按规则配置，不自行放宽或临时开口子。
删除测试与演练
怎么做：用应用账号尝试删除或修改日志，验证是否被拒绝；再做一次还原演练，记录从提出调取到给出完整链路的耗时。证据包含日志样例、字段字典、删除测试记录与演练记录，四项齐备才算完成，缺项不签认。
截图不算证据
验收现场常被要求截几张日志页面图，这在争议时基本没用。做法：由双方共同指定三到五条真实操作，现场按主体与时间段检索原始记录，确认字段完整、链路可串、导出可复现；导出文件记录检索条件与操作人，随验收材料归档。抽不到的说明索引或字段有问题，需先修复再验收。
适用与不适用
适合谁
- 上线前需要安全评审的 AI 应用
- 需要通过等保或内审的组织与部门及其实施团队
- 由外部实施方交付的系统与部门及其实施团队
不适合谁
- 不处理业务数据、仅有演示数据的原型
典型场景
某保险公司的理赔问答助手上线前做日志验收。安全团队随机取三条真实请求，要求现场还原检索到的条款与模型输出；用应用账号尝试删除日志被拒；抽查两条记录确认手机号已掩码。演练耗时与缺口写进验收记录，随项目归档。
可执行步骤
- 按事件清单逐项核对埋点，用真实操作走完提问、检索到导出全流程。
- 随机取三条真实请求，现场还原主体、对象、动作与完整链路并记录。
- 抽样检查日志中的敏感字段是否脱敏，查询是否需审批并留痕，完成后归档。
- 用应用账号做删除与修改测试，并完成一次还原演练，记录耗时与缺口。
常见坑
- 只核对登录日志就签字通过，业务链路上的检索与生成没有验，上线后仍回答不了谁看过什么。
- 字段看着齐全但缺链路标识，三条日志分散在三个系统，现场还原时拼不起来，验收只能延期。
- 脱敏只在前端做，日志里仍是明文，抽查时被一眼看穿，整改要重跑历史数据，代价很高。
自检与验收清单
- 事件清单是否逐项核对过埋点位置与产物，并有记录
- 随机抽取的真实请求能否还原完整链路，可现场抽查
- 日志中的敏感字段是否已按规则脱敏，可逐项核对
- 删除与修改测试是否均被系统正确拒绝，并有书面确认
- 还原演练是否记录了耗时、缺口与责任人，并有验收记录
常见问题
验收要出什么材料？
四类：脱敏后的日志样例、字段字典、删除与修改测试记录、还原演练记录。材料要能对应事件清单逐项打勾，评审时才不需要靠口头说明；缺项直接记为未通过，补做后重新验收。
抽样多少条合适？
看覆盖面而不是数量。至少要覆盖每个角色、每类事件与每条关键链路，新增功能必须补测；三条覆盖三类的请求，比三十条都来自同一账号更有说服力。样本要写进验收记录，便于复跑。
日志级别怎么设？
审计必需的信息用固定级别并保证不被采样丢弃，调试信息走单独通道并设保留上限。关键是不能因为容量压力把审计日志采样掉，那会让证据出现随机缺口，比完全没有更麻烦，也更难解释。