在你分享之前：AI 隐私需要的不只是承诺

引言：对话正逐渐变成你的生活

你打开一个 AI 助手，想写一封难以启齿的回复。你粘贴了消息内容，解释了这段关系，还补充了一些你从未在别处透露的细节。另一天，你上传了一份合同，讨论一个尚未完成的想法，或连接了你的收件箱，让助手理解哪些事情需要你优先处理。

这些行为都不像是在“公开发布”什么。你只是在寻求帮助。

然而，这些信息可能会经过基础设施、存储系统、审核流程，以及法律义务，而这些在对话窗口里大多是看不见的。一个助手带来的感受可以很私密，但它处理你数据的方式，未必已经达到这种期待。

我的观点很简单：AI 隐私不应只取决于公司在收到你的信息之后承诺会怎么做。它还应取决于其系统在一开始就能阻止哪些信息到达模型。 政策很重要，但它们背后还需要技术保护。

这篇文章是在 Dvina 团队支持下完成的。文中考察了 ChatGPT、Claude、Cursor、Perplexity、Manus、Meta 的 Muse 以及 Dvina 已有记录的事件和当前做法。目的在于说明：随着 AI 越来越深地介入我们的生活，隐私必须成为核心工程优先事项——以及 Dvina 正如何承担这一责任。

这些事件告诉了我们什么

这种担忧并非假设性的。但不同类型的证据揭示的是不同的问题。已确认的数据暴露、经授权的人工审核，以及关于研究滥用的指控，不应被表述得仿佛是同一件事。

ChatGPT 在 2023 年的数据暴露：系统本身的失效。

2023 年 3 月 20 日，一个软件漏洞使部分 ChatGPT 用户能够看到另一位活跃用户对话历史中的标题。OpenAI 表示，在某些情况下，新创建对话的第一条消息也可能被看到。其调查发现，在某个特定的九小时窗口内处于活跃状态的 Plus 订阅用户中，有 1.2% 的用户可能暴露了与支付相关的信息。完整卡号并未泄露。OpenAI 修复了该漏洞，并通知了受影响用户。1

这里的教训并不是同样的漏洞至今仍未关闭，而是：仅靠隐私承诺本身，无法阻止系统把信息返回给错误的人。隔离机制、访问检查，以及可被暴露的可识别信息数量，都很重要。

《纽约时报》诉讼：删除行为遇上了法律义务。

2025 年，OpenAI 面临法院命令，要求其保存原本会被删除的数据。其 2025 年 10 月的更新称，对新数据进行无限期保存的广泛义务已于 2025 年 9 月 26 日结束，而一组范围有限的历史数据仍处于法律保全之下。最初的保存要求排除了某些产品以及零数据保留安排。2

后续进展需要分开来看：2025 年 12 月，Reuters 报道称，法官在版权案中要求 OpenAI 提供 2000 万条匿名化聊天日志，驳回了其反对意见，并以去标识化和保护性保障措施为依据。这是一项证据开示命令，并不是把所有人的私人聊天公开到互联网上。3

综合来看，这些事件说明了为什么“删除”设置并不能解决关于信息保留的所有问题。一旦副本已经存在，用户无法控制的外部义务就可能影响它的后续处理方式。在争议开始之前减少不必要的保留，能够先一步降低这种暴露风险。

人工审查：即使没有发生泄露，也可能被允许访问。

OpenAI 面向消费者的文档明确允许经授权的人员和服务提供商出于特定目的进行有限访问，包括安全调查、支持、法律事务以及符合条件的模型改进。Anthropic 面向消费者的指引则允许指定员工为执行使用政策而审查对话；与用户同意反馈相关的访问则另行处理。4, 8

这些都是有文档依据的访问路径，不是传言。它们并不能证明员工会阅读每一段对话。但它们确实表明，看似私密的聊天界面并不一定构成阻止提供方访问的技术屏障。

Anthropic 当前的文档还补充了一个重要的企业侧例子。其指定的 Covered Models 在某些此前采用零数据保留的部署中，要求保留 30 天，并允许受控的人工审查和例外情况。该规则受模型、平台和资格条件限制；它并不是对所有 Claude 产品的一刀切变更。文档称，消费者方案不受影响，因为这些界面本来就会保留输入和输出。9

安全监控有其正当目的。工程上的挑战在于，如何在实现这一目的的同时，尽量减少监控系统和审查人员能够接触到的敏感信息。以安全为理由，并不能让隐私问题自动消失。

数学争议：一项尚无定论的指控，一个真实存在的信任问题

围绕 OpenAI 的 Navier–Stokes 公告在 2026 年 9 月引发的争议，提出了另一层担忧：当协助私人研究的助手属于一家也在自行开展研究的公司时，会发生什么？

这场争议涉及未发表的数学工作和署名归属。相关报道描述称，数学家 Tristan Buckmaster 和 Levent Alpöge 在工作中使用了 AI 工具，而 Buckmaster 质疑他们的私人材料是否对 OpenAI 的成果有所贡献。10

OpenAI 对这一说法提出异议。其公开回应称，无论是其研究人员还是其代理人，在发表前都没有见过这两人的工作。在 9 月 10 日的一则更新中，OpenAI 进一步表示，调查已排除在此前两个月内 Buckmaster 的 Codex prompts 对其成果产生任何影响，包括通过训练产生的影响。与部分报道中较早的说法相比，这一有时间范围限定的表述更为具体。11

公开说法仍然存在争议。这里审阅的资料并不能独立证明 OpenAI 使用了这些私人对话来产出其成果。

尽管如此，这场争议仍暴露出一个值得明确回答的问题：当人们把尚未完成的工作交给 AI 时，什么在保护这些工作的资讯价值？ 从证明中移除作者姓名，并不会移除证明本身。对商业策略做去标识化处理，也不会让该策略变成公共财产。

这就是为什么强有力的隐私保护既需要保护身份，也需要保护内容。用户应当能够了解，他们的材料是否可能进入训练、研究、评估或审查流程——以及有哪些技术控制措施在执行这些边界。

四个绝不应被混为一谈的问题

很多混淆都源于把“私密”当作单一属性来理解。实际上，决定一段对话会发生什么的，是四个彼此独立的问题。

训练： 内容能否用于开发或改进模型？选择退出会改变一种被允许的信息使用方式，但不一定会改变这些信息是否已被传输或存储。

访问： 哪些系统和人员可以查看它？传输中和存储中的加密都很重要，但这并不自动阻止获得授权的服务为处理或审查而解密内容。

保留： 会留下什么、留在哪里、留多久？从界面中移除聊天、删除生产记录、让备份过期，以及将数据排除在未来训练之外，是不同的操作。

操作： 一个已连接的助手可以读取、修改或发送什么？一旦它能够通过你的各类账户执行操作，隐私还取决于权限设置以及对外发数据的控制。

一份有用的隐私比较应当把这些问题分开来看。付费订阅、训练开关或私有任务标签，都无法同时回答这四个问题。

各服务如何比较

下表聚焦个人使用场景，除非另有说明。它总结的是已审阅的文档内容，而不是独立安全审计的结果。

服务	训练立场	需要单独理解的边界
ChatGPT	个人内容可用于改进；相关控制会排除新的对话和 Codex 任务。Temporary Chat 不包含在内。4, 5	已授权访问和保留仍是独立问题。Codex 还具有单独的全环境训练设置。
Claude	面向消费者的模型改进取决于用户选择；反馈和与安全相关的用途适用单独规则。Incognito 不纳入一般改进。6	审查和保留例外仍然适用。某些商业 Covered Models 还有额外的保留要求。7–9
Cursor	Privacy Mode 将客户数据排除在 Cursor 训练之外，并说明了提供方不保留数据的安排，但受已声明例外约束。12	请求仍会经过 Cursor 的后端。滥用调查、缓存和特定模型通知都很重要。
Perplexity	面向消费者的 AI 训练数据收集默认开启，包括 Pro 和 Max；用户可以对未来收集选择退出。13	选择退出并不会停止为服务运营或法律合规而进行的处理。Enterprise 条款不同。
Manus	Team 文档列出了训练退出选项；本次审查无法核实个人计划的最终训练规则。15	个人任务默认私有描述的是共享可见性，而不是对提供方使用的完整限制。14
Meta’s Muse	发布文档说明默认会基于经净化的交互数据进行训练，并提供退出选项。16	训练前净化并不等同于推理前屏蔽。发布时的操作方限制与计划中的 Confidential VM 不同。
Dvina	对话、文件、提示词和工作区数据不会用于训练 AI 模型。17, 18	自动屏蔽处理的是更早一道边界：检测到的个人标识符会在模型处理前被替换。

下面的细节说明了这些区分在日常使用中会在何处变得重要。

ChatGPT 和 Claude：你采取的操作会改变适用规则。

OpenAI 允许用户在不删除普通聊天记录的情况下关闭训练。Temporary Chat 会进一步改变对话的处理方式，但其文档仍允许进行滥用审查，并说明了 30 天的删除周期。Codex 用户还应区分账户范围的内容设置与其单独的全环境设置。4, 5

对于 Claude，反馈尤其值得注意。Anthropic 表示，点赞、点踩或错误报告可能涉及将相关对话存储长达五年，并将其用于包括模型训练在内的目的。启用一般模型改进也允许符合条件的去标识化材料在训练管线中保留长达五年。这些规则与普通聊天删除并不相同。6, 7

因此，一个人可能会在同一款产品内做出多个隐私决定，却没有意识到这些其实是彼此独立的决定。产品设计应在使用当下把这些差异清楚地呈现出来。

Cursor 和 Perplexity：产品标签并不是处理边界。

Cursor 的 Privacy Mode 对训练和提供方保留施加了有意义的限制。但这并不意味着编辑器只在本地运行：Cursor 表示，请求仍会经过其后端，即使使用的是用户自行提供的 API key。其文档还说明了临时加密文件缓存，以及与滥用调查或指定模型相关的例外情况。12

Perplexity 则体现了另一种区分。其 Free、Pro 和 Max 账户都适用面向消费者的训练控制，且数据收集默认开启。已发布的退出机制适用于之后收集的数据，而不是追溯删除更早的训练数据。购买个人订阅并不会使其变成 Enterprise 账户。13

在这两种情况下，关键问题都是所选模式和账户究竟改变了什么——而不是产品名称看起来暗示了什么。

Manus 和 Muse：私有工作区仍然需要明确边界。

Manus 表示，个人任务除非被共享，否则是私有的。其 Team 文档还说明，所有者可以访问团队会话内容。这些都是有用的可见性规则，但它们并未确立个人训练政策。本次审查无法获取完整的 Manus 隐私页面，因此这个问题仍处于未核实状态，而不是用其他计划的信息来补齐。14, 15

Muse 的发布文档对操作限制与技术性防止之间的区别说明得格外明确。Meta 表示，发布时的 Secure VM 通过策略限制员工访问，但并不阻止在运营、支持或保护服务所需时进行访问。其所述旨在通过密码学方式阻止操作方访问的 Confidential VM 仍在规划中，并处于有限测试阶段。计划中的保护措施不应被算作已经向所有人提供。16

Muse 还会让真实的连接器凭证远离其主代理，并将操作批准置于单独的权限机构之下。这说明了一个有价值的原则：不能仅仅因为可能更方便，就把某个秘密或某项权限交给代理。16

把保护前移到暴露之前的环节

训练排除约束的是数据的一种用途。屏蔽改变的是可供处理的数据。限制保留会减少留下来的副本。权限控制限制的是代理能够执行的操作。这些保护彼此互补，而它们各自生效的阶段很重要。

不妨看一个示例请求：给某个电子邮件地址的客户写一封跟进邮件。模型可能需要知道邮件目的、语气以及相关承诺。它未必需要客户的真实姓名或地址，也能起草这封邮件。在推理前先将检测到的这些标识符替换为占位符，可以在保留任务有用结构的同时，减少模型接收到的信息。

这不同于把原始文本直接发送出去，再承诺在之后的某个使用环节中移除标识符。

同样的原则也适用于个人标识符之外的内容。机密研究需要对研究内容本身进行控制；关联账户需要权限范围严格受限；保留记录需要明确的保存期限和可执行的访问限制。身份掩码只是这套设计中的一个组成部分，不能替代对发明或文档实质内容的保护。

业内已经有相关工作。OpenAI 在 2026 年 4 月发布了可在本地运行的 Privacy Filter，而 Meta 的 Muse 文档则描述了技术隔离，以及一套正在开发中的、更强的机密计算设计。这些努力都支持了将隐私通过工程方式嵌入系统的观点。然而，工具的发布或路线图本身，并不能证明每一段消费者对话都已经获得了相应的保护。16, 19

衡量标准应当是：一个人在今天正在使用的产品中，实际获得了怎样的保护。

Dvina：让隐私成为正常交互的一部分

Dvina 的方法，是把这种更早发生的保护带入助手体验中。其公开说明的设计会在人们输入或上传内容时，于本地检测敏感个人信息，对检测到的个人数据进行加密，并在模型处理前用占位符替换。模型处理的是这些占位符，而不是原始检测到的标识符。17, 18

这种差异体现在实际使用中。用户不应为了每一项任务都停下来手动删除姓名和联系方式，也不应只能依赖“模型收到之后会如何处理”的承诺。保护应当伴随交互本身。

Dvina 还将用户对话、文件、提示词和工作区数据排除在模型训练之外。这种组合很重要：不用于训练的承诺限制了再利用，而预处理保护则从一开始就限制了暴露给模型的个人信息。17, 18

还有其他层级共同支撑这一方法。Dvina 提到对话存储经过加密、存储消息与用户身份相分离，以及数据托管于欧盟并具备 GDPR 级别的保护。它们分别针对处理流程中的不同环节，而不是把全部负担都压在某一项训练偏好设置上。17, 18

这里的技术区别非常明确：在模型输入阶段，检测到的个人标识符会被替换，而周围的任务上下文仍可供处理。这样一来，隐私就成为数据流的一部分，而不再只是用户必须记得自行管理的一项偏好设置。

在我看来，这才是 AI 更有价值的发展方向：让人们能够把有意义的上下文带入工作，同时通过系统设计，尽量少披露超出任务所需的身份信息。

结论：隐私将决定人们愿意让 AI 进入自己生活多深

AI 助手越了解我们的处境，就越有用。这也带来了保护这种理解背后信息的责任。如果一边要求人们开放更多访问权限，一边给出的回答却只是再多一个设置页面，这并不足够。

现有证据指向了几类彼此不同的风险。软件可能会在账户之间暴露数据。存储的对话可能会受到法律要求的约束。即使没有发生安全漏洞，授权审查也可能存在。即便相关指控尚未得到独立证实，围绕私人研究的争议仍可能削弱信任。

这些风险需要工程上的投入，而不只是更好的措辞。敏感数据检测、预处理保护、身份分离、有限保留以及可执行的权限控制，都应作为 AI 安全基础能力获得持续关注。助手的实用性与对用户的保护，必须同步推进。

借助 Dvina，我们正通过将模型处理前的保护做成产品基础的一部分，帮助引领这一转变。 这一目标不是通过更强的说法来要求更多信任，而是要减少必须仅仅建立在承诺之上的那部分信任。

人们应当能够寻求帮助、发展想法，并分享推动事情向前所需的上下文，而不必把每一次对话都视为可能交出自己隐私的行为。建立这种信心，是 AI 未来最重要的任务之一。

来源与范围

资料于 2026 年 9 月 22 日审阅。本文依据服务提供商文档和署名报道撰写；并非独立安全审计。比较范围主要针对个人方案。商业版、API 以及特定模型的例外情况另行标注。数学部分区分了已报道的担忧与 OpenAI 更新后的回应；两者均不应被视为独立结论。由于无法获取 Manus 的完整隐私政策，其个人方案的训练规则仍未得到验证。