arXiv
修订痕迹会把删除的细节发送给接收者
AI 助手可以遵从删除请求，却仍在解释编辑内容时泄露已删除的细节。研究人员分析了 26,753 次修订请求，发现 8.8% 的修订回复中存在被删除内容的痕迹。如果起草工具不把私密的编辑说明带入交接内容，管理者就可以只把可用的时间安排发送给承包商。
从 AI 撰写的消息中删除一句话，并不总能删除其中的信息。管理者可能会在把日程发送给承包商前删掉员工的就医预约，但助手却可能补充一句：“我删除了就医预约。”这样一来，承包商就知道了管理者原本想保密的内容。把助手整段回复转发出去的团队也会遇到同样的问题：最终消息和助手私下的编辑记录可能会作为一个整体到达接收者手中。
隐藏的第二条消息
人们越来越多地使用 AI 助手为他人起草电子邮件、报告、代码注释和工作场所文件。在起草过程中，用户可能加入一项事实，之后又要求助手删除或替换它。要求输出的正文可以很干净，但前言、后记或评论却可能解释消失了什么。
这种解释就是修订痕迹：面向接收者说明编辑内容的记录。对于负责起草的人来说，它听起来可能很有帮助。但对于将要接收结果的人来说，它未必安全。“删除这个”之类的指令，也不是一道牢靠的访问控制边界。同一条回复可能把本来要给接收者的信息，与有关生成这一结果的私密过程的信息混在一起。
这个问题类似于普通文档系统中的修订记录、评论、元数据和失败的涂黑。但语言模型无需显示可见的标记层，也能在普通 prose 中重新制造这个问题。
解释如何泄露编辑内容
研究人员将其描述为一条独立的信息披露渠道：模型在正文中遵从编辑要求，却又在解释编辑内容时把被撤回的项目带了回来。他们分析了来自三个公开对话集合的 26,753 次修订请求，发现 8.8% 的修订回复中存在修订痕迹。
随后，他们构建了 RevLeakBench，这是一个包含 100 项任务的测试集，覆盖私密对话和 AI 智能体。在测试中，读者只能看到被当作交付内容的部分，并尝试找回被撤回的项目。在对话案例中，读者有 13.7% 的概率找回它。相比用户只是决定不发送的信息，个人信息更容易被找回。
这一结果指向一个简单但重要的区别。从要求生成的文档中删掉文字还不够。系统还必须决定：它自己的解释中哪些部分属于接收者。把助手完整回复当作文档的转发界面，无法在这两者之间划出可靠的界线。
研究人员测试了建立这条界线的方法。要求助手只返回交付内容，可以降低痕迹出现率，也能减少信息被找回的情况。一个会删除已识别编辑句子的输出过滤器，则将对话测试中的信息找回率进一步降至 1.3%。但这种过滤器需要两类信息：被撤回项目的别名，以及关于哪些内容必须保留的说明。真正的工具必须从交互中或从其他组件获取这些限制条件。
安全交接应当是什么样
在工作场所聊天中，管理者可以删除就医预约，而承包商只会收到可用的时间段。消息中不会有点名提及该预约的解释性句子。工具必须强制执行仅面向接收者的交接，而不是转发自己的编辑说明。
同样的边界在代码审查中也可能很重要。工程师可能会从示例配置中删除凭据或内部端点。公开评论会包含修正后的示例，而过滤器会删除点名提及该秘密的句子，同时保留协作者仍然需要的技术说明。
这一未来取决于工具能否可靠地区分必要内容和私密的起草历史，也取决于过滤器是否知道哪些内容已被撤回，以及接收者仍然需要什么。该基准测试没有涵盖多语言、长时间运行或可执行代码的场景，因此这一边界还没有在所有环境中接受测试。但它的核心教训已经很明确：“已删除”必须意味着内容不在交接结果中，而不只是它不在文档的主要段落中。