单位
1. 及时注入、分层防御 2. 数据泄露预防和 PII 屏蔽 3. 输出验证和人工检查 4. 访问控制、身份和秘密管理 5. 日志记录、审计跟踪和可证明性 6. 模型风险管理和红队 7. 供应商评估和第三方风险 8. 本地、VPC 和开放式托管 9. 连续监测、可观察性和漂移 10. 事件响应和业务连续性 11. 企业人工智能安全清单和治理
单位 5 / 11

日志记录、审计跟踪和可证明性

收益：

  • 能够设计足以重建事件的最小审计跟踪方案
  • 能够通过屏蔽提示/响应来防止日志成为泄漏源
  • 能够建立具有相关身份、不变性和保留期限的可验证日志

在人工智能系统中，有一天肯定会问这样的问题：“为什么会做出这样的决定，那天到底发生了什么？”客户、审计员、监管机构或法院可能会提出这个问题。您的答案要么是可验证的审计跟踪，要么是“我们不知道”。后者在企业环境中是不可接受的。在本单元中，我们将学习针对人工智能应该记录什么、不应该记录什么、如何建立审计跟踪，以及如何保持日志与安全和隐私的平衡。

为什么人工智能中的日志记录有所不同？

在经典软件中，会记录“谁做了什么”。在人工智能中，添加了三个新维度：使用什么型号/版本、发送什么提示以及产生什么响应。当发生错误或投诉时，如果没有这三者，您就无法重建事件。但正如我们在第 2 单元中看到的那样，这个提示/响应可能包含 PII，这意味着日志本身可能成为泄漏源。这就是平衡的艺术。

注意：日志记录并不是“记录所有内容”。太多的日志记录会带来隐私风险，而太少的日志记录则会导致缺乏证据。目标是保留足够的 PII，以便通过屏蔽事件来重建事件。

应该记录什么？审计追踪模式

可靠的人工智能审计跟踪至少包括：

  • 谁：用户 ID 和角色（或服务 ID）。
  • 时间：时间戳（如果可能，仅附加）。
  • 内容：所需的行动和召唤的工具。
  • 哪个型号：型号名称和版本（例如 claude-opus-4-8）、温度等关键参数。
  • 输入/输出摘要：请求和响应的屏蔽版本或摘要/散列。
  • 决策：它是自动处理的，还是交给人工处理的，是批准还是拒绝？
  • 结果：操作是成功还是错误，哪些资源受到影响？

一步一步：建立审计跟踪

  1. 设定一个目标。谁会阅读这些日志以及为什么？ （事件响应、合规性审核、调试。）目的决定了您保留什么。
  2. 执行 PII 政策。在记录之前屏蔽提示/响应（单元 2）。
  3. 提供不变性。让关键日志仅附加；没有人能够默默地抹去过去。
  4. 定义保留期限。根据法律要求和保密性的平衡确定期限；时间到了自动删除。
  5. 限制访问。对日志的访问也应该受到 RBAC 的保护；日志读取也应该被记录。
  6. 添加关联 ID（跟踪 ID）。使用单一身份连接请求的所有步骤（输入、工具调用、验证、输出）。

四个可复制模板

审核日志架构 (JSON)：

{ "trace_id": "...", "时间": "YYYY-MM-DDThh:mm:ssZ", "用户": "...", "角色": "...", "型号": "claude-opus-4-8", "参数": { "温度": 0 }, "request_summary": "<masked>", "response_summary": "<masked>", “工具”：[“tool_a”，“tool_b”]，“决定”：“自动|人类批准”，“批准”：“批准|拒绝|无”，“结果”：“成功|错误”，“受影响的资源”：“...”}

记录PII控制提示：

查看下面的日志示例。审计跟踪所需的字段（人员、时间、模型、决策、结果）是否完整？原始 PII 是否也已泄露？对于每一行，报告为：“空间不足/缺少：... /PII 泄漏：...” <logs>{{ Examples }}</logs>

事件重建提示：

以下审计记录属于单个trace_id。将事件按照时间顺序进行叙述：用户想要什么，模型做了什么，运行了哪些验证，决策是如何做出的，结果是什么？标记缺失或不一致的步骤。<records>{{trace_registers }}</records>

保留策略决策规则：

对于每种日志类型，确定：- 是否有法定保留义务？ （最短期限，如果有）- 是否包含 PII？ （如果包括，缩短持续时间，缩小访问范围）- 安全事件的证据？ （存储无法更改）结果：“存储 N 天 + 仅附加 mi + 访问级别”。

弱提示/强提示

糟糕的方法

强硬的做法

根本不记录（“不需要”）

记录重建事件的最小集合

按原样记录原始提示/响应

屏蔽摘要 + 跟踪 ID 记录

无限存储日志

法律+隐私平衡的保留期限

任何人都可以删除日志

关键日志仅附加，访问受控制

三个迷你箱

案例 1 — Trace ID 将一天的调查时间缩短至 15 分钟。 “我的申请被不公平地拒绝了，”一位客户对银行的信用预评估助理说。借助相关 ID，团队在 15 分钟内重建了该应用程序的输入、员工验证和决策；表明该错误是由规则验证中不正确的阈值引起的，并已修复它。

案例 2 — 审计中发现过多的日志记录。一家电子商务公司正在将所有提示/响应写入原始日志以进行调试。在年度审计中，发现这些日志包含客户地址和电话号码，并保存了两年。通过改用屏蔽 + 90 天保留政策，该发现得以结束；审计追踪功能被保留。

案例 3 — 仅附加日志揭示了内部滥用行为。一家提供商的一名员工试图删除日志以隐藏他制作的错误批次。由于日志是仅追加的并且记录了日志读取/删除尝试，因此该尝试立即可见；该事件导致纪律处分和流程纠正。

提示：为每个请求分配一个关联 ID（跟踪 ID），并在所有步骤中携带它。当问题发生时，能够通过单个查询收集“有关该请求的所有信息”是事件响应的最大加速器。

常见错误

  • 根本不记录，或者记录太少以至于您无法重建事件。
  • 在没有掩码的情况下记录原始请求/响应，并将日志变成泄漏源。
  • 不记录模型名称/版本和决策（自动/人工）。
  • 无限期地存储日志会增加隐私风险。
  • 保留关键日志可能发生的变化；不记录日志访问。
  • 无法将步骤连接在一起，因为它不使用相关 ID（跟踪 ID）。

综上所述

  • 人工智能日志记录为“谁做了什么”添加了三个维度：哪个型号/版本、哪个提示、哪个响应。
  • 目标是使 PII 保持在足够低的水平，以便通过屏蔽事件来重建事件——不多也不少。
  • 审计跟踪应包括谁/何时/什么/哪个模型/决策/结果字段。
  • 关键日志应该是仅附加的，访问应该受到限制，并且日志访问也应该被记录。
  • 关联 ID（跟踪 ID）连接请求的所有步骤并加快事件调查速度。

应用任务

从您自己的 AI 流程中选择一个请求，并使用上面的 JSON 架构为其编写理想的审计跟踪。然后做两个测试：（1）你能仅用这段录音从头到尾讲述故事吗？ (2) 记录中是否有原始 PII？如果有缺失字段，则添加它，如果有 PII，则屏蔽它。最后，设置保留期限和访问级别。

清单

  • [ ] 审计跟踪包括谁/何时/什么/模式/决策/结果字段。
  • [ ] 提示/响应在日志之前被屏蔽（无 PII）。
  • [ ] 为每个请求分配相关 ID（跟踪 ID）。
  • [ ] 关键日志仅可附加且受访问控制。
  • [ ] 存储期限由法定+保密余额定义，并在期限结束时删除。
  • [ ] 通过日志，我可以在 30 分钟内重建一个事件。
上一页 下一页