AI 智能体日志该保留多久?

「日志要保留多久?」通常得到的答案,是某人从上一份工作里记下的一个数字。九十天。一年。七年,因为听起来稳妥。
有更好的决定方式,而它始于一个观察:你保留的不是一样东西,而是两样,而这两样的成本天差地别。
一句话要点
- 把记录拆成两层:一个很小的骨架,和体量庞大的内容。
- 骨架保留数年。它很便宜,而且事后补不回来。
- 内容保留数月。它占了几乎全部存储,也占了几乎全部风险。
- 多数 AI 智能体根本不在欧盟《人工智能法案》的日志义务范围内。
- 什么都永久保留不是稳妥选项,而是另一个问题。
两个时钟,而不是一个
只要不再把记录当成一整块东西,关于保留期的争论几乎会自动化解。
| 层 | 包含什么 | 保留多久 | 为什么 |
|---|---|---|---|
| 骨架 | 标识、时间戳、状态、模型、成本、走过的分支、内容指纹、谁批准的 | 数年 | 体量极小,且大多数问题它自己就能回答 |
| 内容 | 提示词、回复、工具参数与结果、错误消息 | 数月 | 几乎全部存储,也几乎是全部个人数据风险 |
两者之间的铰链是指纹。把每份内容的哈希留在骨架里,你就能在数年后仍然证明当时发送和返回了什么,而一个字的原文都不必保留。
正是这一点,让长期保留变得可辩护,而不是变成隐患。
算一算,答案自己就出来了
假设一个繁忙的系统:每天一万次智能体运行。一年下来字节大致是这样分布的。把它当作模型而不是测量值,再为现实留一点余量。
| 内容 | 每年 | 该怎么处理 |
|---|---|---|
| 骨架,所有运行与所有步骤 | 约 31 GB | 保留数年,这是便宜的保险 |
| 重复存储的工具结果 | 约 84 GB | 只存一次,其余引用 |
| 重复存储的系统提示词 | 约 21 GB | 每个版本只存一次,用指纹引用 |
骨架一年只要几美元的块存储。几乎所有关于保留期的争论,其实都是在争内容层,而内容层恰恰是你有充分理由缩短的那一层。
这张表里藏着两个容易到手的胜利。每次运行都存一遍、有时一次运行还存好几遍的系统提示词,是纯粹的重复;被复制到多处的工具结果同理。把这两处修掉,存储问题基本就自己消失了。
法律到底要求什么
以下不是法律意见,其中任何一个制度都不该被压缩成一个「适用于你」的数字。但了解大致形状是值得的,因为多数文章都在同样的两个地方出错。
欧盟《人工智能法案》六个月的下限只适用于高风险系统。 对这些系统而言,提供者与部署者各自承担自己的六个月最低期限,且各自只限于自己控制范围内的日志。它被两个不同主体各欠一次,而不是共用一份。
六个月是日志的下限,十年是文档的下限。 这是两个不同制度,却常被混为一谈。把设计文档保存十年,并不说明运行记录该保存多久。
以及多数读者真正需要的部分: 高风险指的是受监管产品的安全部件,或法案列出的特定领域,例如生物识别、关键基础设施、就业决策、基本服务获取或执法。编程助手、内部调研智能体、起草文档的智能体、做客服分流的智能体,都不在这份清单上。
另外还有一项独立的权利值得知道,因为真正强制要求解释某个决定的是它:受高风险系统输出所作决定重大影响的人,可以要求解释该系统在其中的作用。这是一项不同于日志的义务,而且同样只对高风险系统生效。
如果你此前引用过日期,还有一点要更新:时间表变了。高风险义务已推迟至 2027 年 12 月 2 日(独立系统)和 2028 年 8 月(嵌入受监管产品中的 AI)。任何仍然引用 2026 年 8 月来谈高风险的文章都已过时。
所以如果你不在适用范围内,就按你真正会被问到的问题来建记录:客户纠纷、事故复盘、账单争议、安全调查。让六个月成为你顺带越过的一条底线,而不是一个专项工程。
明天就可能收到的删除请求
冲突来了。你想要一份能留数年的记录,而某个人有权要求你删除他的数据。
有四件事能让这件事变得可行。
假名化的引用不等于匿名。 如果某个标识能借助你在别处持有的信息重新关联到个人,它仍然是个人数据。把对应关系单独存放,别对自己说这份记录是匿名的。
什么都永久保留不是合规答案。 设定最低期限的那句话,同时也让位于数据保护法。过度保留本身就是问题,而不是一个安全的默认值。
删掉运营层,保留台账。 把删除请求可以带走的部分(内容与运营行)与必须存续的部分(计费与安全记录)分开,并确保存续的那层不含任何内容与直接标识符。
当心在删除后仍然存活的数据。 典型故障是:大块内容存在文件存储里,数据库行只保留一个指针。删掉行之后文件仍在,无人引用,对之后任何「你到底持有什么」的审计都不可见。把文件本身作为删除目标,并定期核对残留。
如果条件允许,有一种模式值得实现:内容被删除时留下一块墓碑,保留指纹和体量。后来的读者就能知道那里曾经有东西、它有多大,以及它是依权利请求被移除的,而不是丢失的。
唯一无法撤销的错误
保留策略上的其他错误都能补救,这一个不能:保留期无法追溯延长。
当你发现所需窗口比清理任务更长的那一天,数据已经没了。反方向也一样痛:某个团队把生命周期日志从 30 天提高到一年后,第一次清理就撞上了十二倍的积压。
所以第一天就把骨架层设成你能合理设想的最长窗口。按每年约 31GB 算,它是整个系统里最便宜的保险。然后再去调内容窗口,那部分既昂贵又可逆。
同一类里还有两个小错误。检查你写在文档里的保留期是否与实际配置一致:一句写着「30 天」的注释配上一个默认一年的设置,正是两者悄悄背离的方式。另外,把日常查询挡在明细行之外,用按天的汇总来回答常见问题,否则你的记录会在技术上完整、在实践中不可用。
常见问题
如果我不受监管,合理的默认值是什么?
骨架保留几年,内容保留三到六个月。这足以覆盖纠纷、事故复盘和账单争议,同时不必囤着一仓库个人数据。
我必须保留提示词和回复吗?
在你还可能需要解释某个具体决定的期间内,是的。之后由指纹承载证据,原文就只剩风险了。
六个月的规定适用于我的聊天机器人吗?
几乎可以肯定不适用。它适用于法案定义的高风险系统,而普通的内部或效率类智能体不在那份清单上。请去查那份清单,而不是往任一方向臆断。
存储究竟消耗在哪里?
在内容上。工具结果和提示词占大头,尤其是当它们被复制到多个地方时。结构化的骨架与之相比可以忽略不计。
我能先全部留着,以后再决定吗?
这正是那个看起来安全、实际并不安全的选项。长期保留的内容是一项持续的负债,而且会是删除请求最先找到的东西。
下一步
写下两个数字,一个给骨架,一个给内容,并让骨架那个宽裕一些。然后确认你的记录里确实装着这两个窗口应当保护的东西:每次 AI 智能体运行该记录什么。