AI 智能体的审计追踪：该记录什么，记录又能证明什么

traceseal.io 2026-09-01T00:09:29.575922

摘要：AI 智能体执行真实操作时，如何留下可信的审计记录？本文梳理了应记录的六类关键数据、欧盟《人工智能法案》的合规底线，以及让日志具备可验证性的四步机械操作——确保事后既能回答“发生了什么”，也能让外部信服。

为什么审计追踪成了必修课

AI 智能体不只是回答问题，它还会调用外部工具、修改文件、发起 pull request、转账、发消息。只要它做过这些事，总有一天某个操作会被质疑——客户、审计员、监管机构，或者你自己的事故复盘。到那时你能拿出什么答案，完全取决于你今天记下了什么。

为智能体建立可用的审计追踪，需要同时解决两个问题，而多数团队只注意到第一个：

对开发者而言，这意味着在构建智能体时，审计机制不是事后补救的功能，而是需要提前设计的基础设施。

该记录什么：六类关键数据

聊天记录不算审计追踪。聊天记录记的是模型说了什么，事后真正要查的是系统做了什么。一份值得留存的追踪记录，应为每次运行记下以下内容：

监管底线：欧盟 AI 法案怎么说

如果智能体被划入该法案的高风险类别，记录就不再是“最佳实践”，而是有明确数字要求的法定义务，具体由《欧盟条例 (EU) 2024/1689》的三条规定承担：

时间节点方面，根据第 113 条，该法案自 2026 年 8 月 2 日起全面适用，附件三所列高风险系统的各项义务随之生效；因属于受监管产品安全组件而被认定为高风险的系统（第 6(1) 条），则从 2027 年 8 月 2 日起适用。

多数编码和运维智能体并不属于该法案界定的高风险系统。不过，第 50 条的透明度义务已经适用于与人交互或生成内容的系统。再者，既然无论如何都要保留记录，直接照搬法案规定的六个月最低保留期，总比自己另设一个数字更稳妥。

日志再完整，也可能证明不了什么

假设你老老实实把上面这些内容全记下来了。你确实得到了一条对调试和应急响应很有用的记录链——但一旦需要说服组织之外的某个人，这套记录可能依然一文不值。

问题出在作者身份上。应用日志是由其所描述的系统自己写入的，存储在操作者控制的基础设施上，任何拥有存储写权限的人都能编辑。当记录的作者正是其行为受到质疑的一方时，记录无法为他们洗脱嫌疑。安全实践一直把日志缺失或未受保护列为顶级弱点（OWASP Top 10 中的 A09），但完整性与存在性是两回事：一条日志存在且完整，但可能昨天刚被改写，那么它只能为已经信任你的人提供「发生了什么」的答案；对本来就持怀疑态度的一方而言，这和没有记录几乎没什么区别。

问题的根源不在内容是否齐全，而在“作者身份”：日志是系统自己写的，存在自己的基础设施上，读写权限也在自己手里。无论记录多么完整，只要写和存都在同一方手中，它在外部审计里就没有独立分量。WORM 存储（一次写入、多次读取）、集中式日志收集器、哈希链，这些业界的常规解法其实都只是在移动信任边界：你不再需要信任应用服务器了，但还得信任那个集中器或那条哈希链背后的维护者。信任转移了位置，并没有消失。

让审计追踪可验证：四步机械操作

解决办法恰恰是机械性的，不需要高深的密码学：

（后续段落将展开四步操作的具体内容）

关键要点

面对越来越自主的 AI 智能体，审计追踪是追溯其行为的关键机制。本文介绍了一套切实可行的技术方案——哈希、规范 JSON、签名与透明日志的组合，同时厘清了审计记录的边界：它证明“发生过什么”，却无法证明“该不该发生”。

一套可落地的审计方案

具体怎么落地？只需完成四步：

  1. 对运行中触碰过的每一个工件做哈希——把记录锚定到具体的字节内容上，而不是某个事后可以重新定义的版本描述。这样任何细微改动都会留下痕迹。
  2. 将记录序列化为规范 JSON——确保签名覆盖的是一段确定的字节序列。序列化方式不同，签出来的就不是同一个对象，这一步保证了签名对象的唯一性。
  3. 在执行时使用智能体无法触及的 ed25519 签名密钥进行签名——ed25519 是一种安全的非对称签名算法，智能体拿不到密钥，后来的入侵者同样改不了封印。
  4. 将签名结果锚定在透明日志中——让记录在争议发生之前，就已经被证明存在。

这四步走完，审计轨迹就成了一张任何人都能离线查验的“收据”：验签、比对哈希、核对时间，全部可以独立完成，既不需要访问你的系统，也不必事先信任你。

但这里有一个前提：如果太多人连决策内容都没看就随手在审批栏里打了勾，收据就变成了一场仪式，而不是一道保险。要避免这种情况，关键环节必须保留真人审批——要求人在操作执行之前，审阅并批准那些会产生后果的动作，并且把“批准”这个动作本身也写进收据里。

收据之外

需要明确的是，收据证明的是“在某个时间点确实生成了一条记录，而且这条记录没有被篡改”。它证明不了这个行为本身是否正确、安全、符合政策。那些是另一些问题，需要另外的证据：评估结果、红队报告、监控指标、事件复盘。

审计轨迹和安全论证之间的关系经常被混淆。有些团队把一份详尽的日志当成安全论证本身，或者指望增加更多埋点就能替代真正的评估——做不到。日志只告诉你系统做了什么，不告诉你它该不该做。

不过，审计轨迹确实以一种重要方式支撑了安全论证：它让声明变得可核查。如果你声称“我们检查了 100% 的高风险动作”，收据链就是让审计员验证这项声明的东西；如果你声称“部署时模型是版本 X”，收据里的容器镜像哈希和模型哈希就是为这句话撑腰的证据。

什么情况下不该记录

有些场景，记录日志并不合适，甚至有害。法律建议、病史或其他敏感内容可能受保密义务保护。如果你的智能体处理这类数据，正确的做法恰恰不是完整记录，而是最小化保留、限制访问，并且在不再需要时尽快清除。

同样的情况也适用于受“被遗忘权”保护的数据，或者那些保留原始内容只会带来更多责任、而不是更多价值的输入。在这种情况下，只存一个哈希来锚定记录，原始数据放在数据所有者手里，然后设计一套流程：需要验证时，所有者能提供原始数据。这和默认的“全部记下来”模式不同，但它依然是一种有效的审计模式——可以叫它“外部保管的哈希指针”。

结语

AI 智能体的审计追踪今天就能实现。技术构件——哈希、规范 JSON、签名、追加式日志——都是普通且成熟的东西。缺的不是技术，而是纪律：决定记录什么、坚持每条记录都当场签名、让保留政策说到做到、以及在时间压力下实际测试一遍检索流程。

随着智能体拥有越来越多的自主权和访问权限，没有这种纪律的代价会越来越高。为一次动作生成收据的基础设施，可以扩展成整个部署上环环相扣的链条。养成这个习惯很便宜；没有它的代价很贵。

关键要点

查看原文