你的 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 名用户的用户可见对话，但允许短暂的检索上下文按正常计划过期”——如果所有内容都存在一张表里，这句话将无法执行。

法律保存与被遗忘权的正面碰撞

法律保存（Legal hold）要求：停止计时。当可以合理预见诉讼时，保存义务即刻生效，继续执行常规删除计划将被视为证据毁损（spoliation）。FRCP 第 37(e) 条授权在当事人未能采取合理措施保存本应保存的 ESI（电子存储信息）时进行制裁，如果法院发现有意剥夺证据，制裁将更为严厉——包括不利推断或驳回起诉。《纽约时报》起诉 OpenAI 的案例是当下的典型，但这一原则早在十年前就已确立。

GDPR 第 17 条则要求：开始计时，而且要快。欧盟用户拥有被遗忘权，数据控制者必须在不无故拖延的情况下予以满足。CCPA、巴西的 LGPD 以及越来越多的各州和各国法律中也存在类似规定。

这两者无法调和。美国法院可以下令保存有关欧盟居民的数据，而该命令可能与控制者在 GDPR 下承担的删除义务直接冲突。纽约南区联邦法院 2025 年 5 月的一项裁决明确承认，保存可能需要忽视“世界各地”的隐私法，并依然下达了保存命令。遵守美国命令可能违反 GDPR 第 5 条和第 17 条；遵守 GDPR 则面临美国证据毁损制裁的风险。欧盟律师和美国律师会给出截然相反的指示，且在各自的法律下他们都是正确的。

处理这一冲突的架构是“法律保存注册表”（legal-hold registry）——这是一个独立的服务，而不是用户行中的一个标记——它记录哪些用户、对话、账户或主题处于保存状态，以及原因、由谁发起以及何时结束。当删除队列尝试处理用户的擦除请求时，它会首先查询该注册表。匹配并不会取消擦除，而是对其进行路由。数据被移至隔离的保存存储（通常使用应用程序无法访问的密钥加密），删除操作被记录为“因法律保存而暂停”，并在法律允许的范围内通知你这一暂停。

注册表存在的意义在于，当 GDPR 执法部门询问“为什么你没有在 30 天内删除该用户的数据？”时，你的回答是：“这是签署的保存令，这是路由决策，这是隔离证明。”这个回答是站得住脚的。而“我们忘了，因为当时有个诉讼”则不是。

跨租户污染让每一份记录都成了共同记录

多租户 AI 产品面临着电子邮件从未遇到的问题：一个用户的记录可能包含另一个用户的受监管数据，因为智能体在对话中抓取了它。客服智能体在回答用户 A 的问题时，检索到了一篇最初为描述用户 B 的投诉而撰写的知识库文章。内部助手拉取了一个包含第三方 PHI（个人健康信息）的 Slack 线程。编码智能体读取了一个包含供应商专有 API 密钥的仓库，而这些令牌最终出现在了对话日志中。

在证据开示（discovery）中，这份记录是一件证物。而在隐私法下，它涉及三个或四个权利指向不同方向的数据主体。用户 A 的删除请求不能在不破坏用户 A 获知内容的证据的情况下，从存储记录中剥夺用户 B 的数据。用户 B 的访问请求是否能触及用户 A 的对话，取决于控制者和处理者的角色是如何界定的。

实际应对措施从摄入开始。在内容进入上下文的瞬间，为其检索到的内容贴上原始出处标签——文档 ID、所属租户、分类——并将这些标签传播到存储的对话记录中。当删除请求到达时，标签会告诉你受影响的代码段是可以就地脱敏（替换为“[根据保留政策已脱敏]”标记加审计条目），还是整个对话轮次都必须保留。保留出处使脱敏变得可行；放弃出处则意味着每次删除请求都是对记录的一次推倒重来。

同样的标签纪律也让你能回答监管机构的同类问题。当欧盟数据保护机构询问“哪些用户的数据在这个类 ChatGPT 产品中？”时，你可以根据出处标签回答，而不是通过 grep 搜索对话全文。

“我们只是把所有东西存进 S3”是一个政策，但不是个好政策

尚未做出保留决定的团队，默认已经做了一个决定。无限期保留也是一种政策；它是那种将各种形式的负面风险最大化的政策。传票风险随保留量线性增长——你多保留一天记录，原告就多一天机会对其发起传票。隐私违规风险复合增长——你保留受监管数据的时间越长，跨司法管辖区的风险积累越多，细粒度删除就越困难。泄露波及范围随每一行未归档的数据而扩大——“数据泄露会有多严重”的答案纯粹是算术题。

扭转这一局面的纪律是将保留视为产品需求，而非合规事后的补救。在设计文档中，每个写入存储的新功能都必须回答三个问题：保留 TTL 是多少，审计保留是多少，删除流程是什么。评审人员应当像反对“没有测试”或“没有指标”一样反对“待定（TBD）”。无法回答这些问题的功能不具备发布条件。

相反的纪律同样重要：不要让保留政策也变成一种无声的“短路”。即使是被政策标记为“24 小时后删除”的瞬态检索上下文，在法律保存生效时仍必须保留，这意味着 24 小时的计时器必须是可暂停的，且暂停必须记录在案。一个无法暂停的保留政策不是保留政策，而是对毁灭证据法律责任的极速冲刺。

这一切都不再仅仅是理论。OpenAI 的保存令、2000 万条记录的提交，以及关于 LLM 交互属于受保护工作成果还是普通 ESI 的日益严重的分歧，都表明每一个规模可观的 AI 产品都将面临至少一次此类需求。能够承受这些需求而不产生毁灭性打击的产品，将是那些在设计存储架构时就考虑到了这些需求的产品——按记录类型分层，按可变性分离，并受法律保存注册表可冻结和解冻的单次对话 TTL 约束。没有做这些工作的产品将不得不在保存令下被动地花一个季度的时间去补课，而那是成本最高的方式。

核心要点

聊天内容不再是转瞬即逝的了。你的产品保存的每一段对话都可能面临取证披露，而 AI 特有的组成部分——系统提示词（system prompts）、检索结果、工具输出、模型元数据——无论你是否将其视为记录，它们都已经成为了记录的一部分。真正关键的架构决策往往是那些枯燥乏味的：按保留类别划分你的存储层级、在需求产生前建立真正的法律保存（legal-hold）登记簿、在数据摄取时标记溯源信息、将 TTL 作为一项产品需求，并在不可变的审计日志中记录保留策略的执行情况。趁现在成本只需一两个冲刺（sprint）的时间，赶快完成这些工作。如果你等到法院命令强制要求进行设计时，同样的工作将耗费一个季度，而且在你构建系统期间，对方律师可能正在阅读你客户的对话。