你的 AI 聊天记录即证据：法律保存指令下的 LLM 产品保留设计

2025 年 5 月 13 日，纽约南区的一位联邦地方法官签署了一项保护令，用一个词取代了一家消费级 AI 公司的保留政策：永远。OpenAI 被指示保留并隔离其 Free、Plus、Pro 和 Team 等所有层级的每一份输出日志——包括用户已明确删除的对话，以及隐私法原本要求删除的对话。到 11 月，同一法院下令将其中 2000 万份去标识化的转录文本作为抽样取证（sampled discovery）提供给《纽约时报》及其共同原告。这一无限期保留义务一直持续到当年的 9 月 26 日。在这五个月里，“删除”的实际含义是“保存在隔离的保险库中，供对方当事人日后查阅”。

该命令是对每一个基于 LLM 构建产品的团队发出的警告信号。如果你的产品存储了聊天记录，你的保留政策距离被法院认为合理的任何规定所取代，仅隔着一场潜在的诉讼。工程上的问题不在于这是否会发生在你身上，而在于你的存储架构是否能够承受这种变化，而不至于让你的产品变成法务部门的责任引擎。

电子邮件的保留手册无法直接套用。AI 对话包含的内容远多于用户输入的内容，而这“多出的部分”正是取证争端的开始。

什么是“对话”？这是第一个棘手的问题

在电子邮件中，电子存储信息（ESI）的界限很清晰：发件人、收件人、主题、正文、附件、页眉。法律保留（legal hold）只需指示邮件服务器保留这些元组即可，任务完成。

AI 对话则是一个分层的产物。用户提示词（prompt）只是最小的一部分。环绕在其周围的包括：系统提示词（哪个版本？由谁编写？是否在会话中途更改？）、对话历史（智能体是否将之前的回合总结成了压缩的序言？）、从 RAG 中检索到的片段（谁的文档？哪个修订版本？依据什么许可？）、工具调用参数和返回值（模型读取了什么？采取了什么行动？产生了什么副作用？）、模型元数据（模型 ID、参数版本、Temperature、种子值）以及短暂上下文（缓存的推理痕迹、模型在提交最终响应前探索的投机分支）。

法院已经开始要求提供你可能根本没有记录的这些片段。《联邦民事诉讼规则》第 34 条要求提供的 ESI 必须“按照日常业务过程中的保存方式或以合理可用的形式”提供，并保持元数据的完整性。当请求方想要重建你的智能体为何推荐该响应时，他们会要求提供系统提示词版本、检索集、工具输出以及模型所见到的确切形式的对话历史。如果你的生产流水线是即时生成这些内容并在推理后将其丢弃，那么在保留函寄达之前，你就已经面临保留问题了。

可辩护架构的操作定义是：模型在某一回合中所看到的、对输出产生实质性影响的任何内容都属于记录的一部分。这包括你视为基础设施的输入。系统提示词是文档，检索到的片段是证物，工具输出是来自第三方的证词。如果你假装它们不是，法官会纠正你的看法。

经得起传票考验的保留政策设计

无法幸存的架构是大多数团队交付的默认架构：一个名为 messages 的单个 MongoDB 或 Postgres 集合，每回合一行，带有 created_at 且完全没有保留政策，并备份到有人设置后就忘掉的、具有七年生命周期规则的对象存储中。当法律保留函寄达时，法务会问“我们可以保留什么，可以让什么过期？”，答案将是“全部保留或全部不留”，因为这种模式（schema）没有可以切割的接缝。

具备保留意识的架构根据保留层级和可变性将四种记录分开：

用户可见的对话：用户可以通过产品 UI 阅读、编辑和删除的内容，存储在保留期最短的层级中，并带有针对每条对话的 TTL（生存时间）。TTL 是一个产品决策（30 天？90 天？1 年？），直接写入行数据中，而不是全局默认值。删除对话的用户会触发队列中的删除任务，且该队列是可审计的。

系统生成的上下文：系统提示词、检索结果、工具输出、模型元数据——存储在由相同对话 ID 关联的并行层级中，但拥有自己的保留时钟和排除规则。这就是“短暂上下文”排除项存在的地方。如果 RAG 检索取回了 12 个片段而模型引用了 3 个，那么其余 9 个片段可以根据政策文档拥有更短的保留期。关键点在于，这些排除规则是在法律保留到来之前就已写明、版本化并经过评估的，而不是在取证过程中临时发明的。

不可变审计日志：记录某个操作发生的实事，而非操作的具体内容。用户 A 在时间戳 T 删除了对话 X。工具 Y 被调用，带有哈希处理后的参数 Z，并返回了 200 响应。这里的保留期很长（SOC 2 预期至少一年；许多团队为了与财务记录保持一致而选择七年），且日志是只增（append-only）且防篡改的——经过签名、链接或写入 WORM 存储桶。这是证明你的保留政策得到执行的日志，也是如果日后有人指控你毁损证据（spoliation）时，你所需要的证据。

衍生工件：摘要、嵌入（embeddings）、分析汇总——通常需要独立的保留规则，因为它们在源数据删除后可能依然存在，并泄露本应被擦除的事实。在对话删除后依然存在的对话嵌入，就像一个不断回答有关逝者问题的幽灵。

这种分离使得法律保留可以要求“冻结这 400 名用户的用户可见对话，但允许短暂的检索上下文按正常计划过期”——如果所有内容都存在一张表里，这句话将无法执行。

加载中…