7 个会悄悄泄露公司数据的 AI 智能体数据隐私错误（以及如何避免）

大多数 AI 智能体的数据泄露并不是模型偷偷记住了你的公司，而是来自你可以指出名字并加以修复的配置和架构错误。最主要的几个是：在一个默认会用你的输入做训练的消费级账户上运行、让智能体继承某个人的过宽权限、把对外智能体接入内部系统，以及让「致命三要素」原封不动地存在（私有数据、不可信内容和对外发送通道），从而一次提示注入就能读取你的数据并把它发出去。最后这个模式正是 EchoLeak（CVE-2025-32711）通过一封精心构造的邮件，在用户没有点击任何东西的情况下，经由 Microsoft 365 Copilot 泄露敏感数据的方式。这些修复方法并不深奥，而且几乎都是在智能体上线之前做出的决策，而不是在某次泄露发生之后交给你的一份清单。

这是我们在把自己构建的智能体放进另一家公司的技术栈之前会逐项过一遍的清单，写得让一个非技术背景的老板也能在自己的配置或供应商的配置里发现同样的错误。如果你更希望我们替你把这条线划在该划的地方，请看我们如何运行负责任的 AI 治理与风险管理。无论如何，下面的内容都归你使用。

首先要做一个几乎每篇相关文章都模糊带过的区分，因为搞错它就是第零号错误。数据通过智能体离开的方式有两种完全不同的途径，而且它们的修复方法也完全不同：

• 提供商的数据处理。 模型提供商是否存储或在你的输入上训练？这是你签署的一份合同和你选择的一个账户层级。它通过条款和配置来解决。
• 运行时外泄。 智能体能否在它运行的那一刻被诱骗，把你的数据发送到它不该去的地方？这要靠架构来解决，而不是合同。

调查数据显示，即便买家说不清这一点，他们也能感受到它。在 Cloudera 对 14 个国家近 1,500 名高级 IT 领导者的研究中，96% 的人计划在未来一年扩大 AI 智能体的使用，但有 53%（超过半数）把数据隐私列为他们采用的首要障碍。下面这七个错误正是那份担忧变成真实泄露的地方，也是修复方法所在之处。

错误一：在消费级账户上运行生产环境的智能体

这是最廉价的错误，也是最容易修复的。有人把一个工作流接到了个人的 ChatGPT 或消费版 Gemini 账户上，因为它就在手边，于是你的业务数据现在就受制于一套从来不是为它准备的消费级条款。

消费级层级和企业级层级之间的差距非常明显。在企业一侧，各家提供商的模式是一致的：默认不在你的数据上训练、为滥用监控设置一个短暂的保留窗口，以及按需提供更强的选项。OpenAI API 会为滥用监控保留数据 30 天然后删除，并且默认不在其上训练。自 2025 年 9 月 14 日起，Anthropic 把 API 日志保留期从 30 天缩短到 7 天，而且 API 的输入和输出从不用于训练。Google 的 Vertex AI（企业层级）可配置为不做训练使用。在消费一侧，默认设置则正好相反：消费版 ChatGPT 会无限期存储对话，除非你删除它们；消费版 Gemini 的保留期最长可达 36 个月，并且可能被用来改进产品。

修复方法： 把每一个生产环境的智能体都放在企业级 API 或商业账户上，绝不要用个人登录。技术是完全相同的，但条款不同，而条款正是「保持受治理的数据」和「悄悄变成训练材料的数据」之间的全部差别。

错误二：智能体继承的过宽权限

最常见的运行时泄露并不高明。有人把某个员工的访问权限，或者更糟的是一把管理员密钥，交给了智能体，于是它在技术上能看到那个人能看到的一切。然后它被问了一个问题，或者被诱骗去问一个问题，而这个问题远远超出了它的职责范围。

微软的云采用框架把这条规则讲得很直白：「只授予智能体执行其功能所需的特定数据源的访问权限。不要提供对所有组织数据的宽泛访问。」一个客服智能体不需要你的薪资系统。一个排期智能体不需要客户数据库。当一个智能体代表某个人行动时，它应当通过安全地传递那个人的身份来继承那个人的权限，这样一个服务台智能体只会向某个员工展示他自己的人力资源记录，而不是所有人的。

修复方法： 给每个智能体一个范围限定为最小权限的独立身份，并让它继承当前行动用户的权限，而不是携带一份长期存在的超集权限。检验方法很简单。如果明天这个智能体被诱骗了，损害范围会被限制在它被授予的那个狭窄集合内，而不是被一个权限过大的账户所能触及的一切。

错误三：对外智能体接入了内部数据

你网站上的一个聊天机器人和一个起草内部报告的智能体是两个不同的安全世界，而泄露就发生在有人让它们共享一个后端的那一刻。一个对外智能体接受来自互联网上任何人的输入。如果同一个智能体还能查询内部业务数据，那你就建了一扇从公共网络直通你私有系统的门。

微软的框架在这里划出了最严格的界线：「对外智能体绝不能访问内部业务数据。」用一道物理或逻辑边界把机密和公开分隔开（他们的例子使用了分开的「corp」和「online」管理组）。重点在于这道边界是结构性的，而不是寄希望于提示词能扛得住。

修复方法： 在接受不可信公共输入的智能体和接触机密数据的智能体之间设立一道真正的边界。如果某个单一智能体确实必须两者都做，那是你能选择的风险最高的设计，它需要后续错误中那些打断三要素的控制措施，而不仅仅是一段谨慎的系统提示词。

错误四：忽视致命三要素

这是把前三个错误变成真正外泄的那个错误。提出「提示注入」一词的独立专家 Simon Willison 为 AI 智能体命名了「致命三要素」：三个条件，当它们结合在一起时，一条被注入的指令就能窃取你的数据。

当这三者全部具备时，攻击者就会把一条指令藏进不可信内容里。用 Willison 的话来说，模型「会乐于遵循任何送到它面前的指令，无论这些指令是来自其操作者还是来自其他来源」。它会读取你的私有数据并把它发出去，而提示词里没有任何东西告诉它不要信任那封邮件。

直白的部分，也是为什么这是架构问题而不是提示工程问题的原因：「我们仍然不知道如何 100% 可靠地防止这种情况发生。」已记录的漏洞利用攻击命中了 Microsoft 365 Copilot、GitHub 的 MCP 服务器和 GitLab Duo。在 2026 年 1 月的一周里，四款 AI 生产力工具被披露存在间接提示注入漏洞，全部都是同样的三要素模式。

修复方法： 打断其中一环。封堵对外发送通道，让被窃取的数据无处可去；或者绝不让一个读取不可信内容的智能体在同一上下文中同时持有私有数据访问权限。你不需要去赢「抓住每一次注入」这场赢不了的仗。你需要确保即便一次注入成功了，它也没有任何出路。

错误五：把 EchoLeak 当成别人的问题

值得点名一个真实事件，因为「致命三要素」听起来很抽象，直到你看到它被实际执行出来。EchoLeak（CVE-2025-32711）是针对 Microsoft 365 Copilot 的一次零点击攻击。攻击者发送了一封精心构造的邮件。Copilot 在做它的日常工作时处理了那封邮件（不可信内容），它能访问用户的内部数据（私有数据），并且有一条把信息发送出去的途径（对外通信）。那条隐藏指令在完全没有用户交互的情况下完成了敏感数据外泄。没有人点击任何东西。

这里的错误是假设一次泄露需要一个粗心的员工。EchoLeak 一个都不需要。真正起作用的防御不是「培训员工识别钓鱼」，因为根本没有什么可供人去发现的东西。起作用的防御是架构层面的：一个既不能读取攻击者控制的内容、又不能外泄的智能体，无法以这种方式被反过来对付你。

修复方法： 把零点击当成威胁模型，而不是例外。如果你的智能体读取任何外部人员能够影响的东西（邮件、网页内容、上传的文件、工单），并且它还能把数据向外发送，那么在你关闭这两项能力之一或硬性围栏住发送通道之前，你就有一个 EchoLeak 形状的漏洞。

错误六：没有数据驻留或保留边界

有些泄露并不是戏剧性的外泄，而是缓慢的漂移。数据最终被存储在一个你从未同意过的区域，或者在日志里停留得比你的策略允许的时间更久，仅仅因为没有人设定边界。微软的框架把这一点列为核心治理：识别每个数据源、智能体运行时和输出存储的位置，把数据保留在符合你驻留策略的区域或本地，并保持其在静态时加密。

令人安心的消息，也是几乎没有哪篇文章会明说的，是你能锁定的东西有多少。各家提供商的企业模式是默认不训练，加上一个短暂的保留窗口，再加上按需提供的更强保证。Anthropic 为符合条件的企业提供零数据保留（ZDR）协议，在该协议下，输入和输出不会被存储超过筛查滥用所需的范围。OpenAI 通过协商达成的协议提供 ZDR 和数据驻留。两者都允许你选择数据存放的位置。自托管一个开放模型（例如使用 Ollama）能让数据完全保留在本地，第三方零保留。

修复方法： 在上线之前决定并记录边界。哪个区域存放数据、日志存活多久、你是否需要 ZDR，以及敏感检索是否应该运行在你自己的 VPC 或本地。ZDR 通常仅限 API 且需要协商，并且它不会自动覆盖每个产品，除非你专门加上，所以细节很重要。

错误七：把隐私当成一份交给别人的清单

最后一个错误是结构性的。大多数指南，包括出色的微软框架，都假设你会自己构建并治理智能体，于是它递给你一份 3,000 字的、由 Entra 身份、Purview 标签和管理组堆叠而成的东西。对一个大型 IT 团队来说，这是正确答案。但对大多数企业来说，这是一份没有人有时间或专业技能去完整实施的清单，于是它只落地了一半，而那些缺口恰恰就是数据泄露的地方。

错误在于把这些控制措施当成文档，而不是当成由某个人端到端拥有的一套架构。一份列出「隔离机密数据」和「将外部集成限制在可信的 MCP 服务器上」的清单，其有效程度只取决于那个把它接入、验证每一次对外通信、并建立起能在出问题时快速停用智能体的事件响应预案的人。

修复方法： 确保有一方真正拥有这道边界，而不仅仅是拥有那份文档。要么你建立起内部能力去实施和维护整套技术栈，要么你让一个运营方从架构层面把这些失效模式排除掉并负责运行它们，并提供一道你可以指着说的公开边界。错误的中间地带是一份控制措施清单，却没有人为它的扛住与否负责。

七个错误与修复方法如何对应

这里把全部七个放在一处，按照修复方法是「你签署的合同」还是「你构建的架构」来排序。这种划分是判断每一个由哪个团队负责的最快方式。

请注意，七个之中只有两个是靠合同解决的。另外五个是架构和归属，这正是一份最佳实践 PDF 无法替你做到的部分。这也是权威来源留下缺口的诚实原因：它们告诉你要构建什么，却没告诉你谁会在你的特定系统里正确地把它构建出来。

当边界构建得当时，到底什么永远不会离开

读完七个错误，很容易得出 AI 智能体是个隐私雷区的结论。但当这条线被刻意划好时，它们并不是。在企业条款下，你的输入不是训练数据，而且保留期是以天计的，不是永久（Anthropic API 是 7 天，OpenAI 是 30 天，之后删除）。有了 ZDR，它们不会被存储超过滥用筛查的范围。固定了数据驻留区域后，它们就留在你的区域里。有了 VPC 或本地检索，敏感数据根本不会离开你的边界。有了边界处的脱敏，那些绝不应当外传的字段在任何东西被发送出去之前就已被剥离。有了继承用户权限的最小权限范围，智能体永远只能触及当前行动的人本就能触及的东西。

那是一道具体、站得住脚的边界，而能够把它平白说清楚正是整件事的重点所在。危险从来不是模型悄悄吸收你的公司，而是上面那七个配置和架构错误，其中每一个都能在第一个智能体上线之前被预防。

这就是我们在其他公司技术栈内部所做的工作：选择条款、限定身份范围、把公开与机密隔离、打断三要素，并拥有这道边界以确保它扛得住。如果你想在这些智能体接触任何真实数据之前就把这些错误从架构上排除掉，请在下方预约一次免费咨询，我们会一起为你绘制出这道边界。