只有 29% 的安全团队能够定期报告员工发送给 AI 工具的敏感数据

本文依据 Cloud Security Alliance (CSA) 委托 Jazz 开展的 2026 年调查报告《人工智能时代的 DLP》中的调查结果撰写。

6 月和 7 月，CSA 询问了 433 名 IT 和安全专业人士，他们的团队能否生成一份报告，显示过去 30 天内有多少次敏感数据被发送到生成式 AI 工具。29% 的受访者表示，他们能够定期生成这类报告。

如果受访者认为生成式 AI 只是一个次要渠道，这一数字就没那么重要了。但他们将其列为数据外泄风险的首要渠道，48% 的受访者把它列入风险最高的三种渠道。

我在一家开发数据防泄漏产品的公司负责工程工作，我的大部分工作都围绕着数据在系统中的流动证据出现在哪里，以及风险为何产生。从这个角度来看，团队自认为能够看到的内容与实际能够证明的内容之间存在差距，这直接源于生成式 AI 控制措施的设计方式。

团队对生成式 AI 可见性的信心远高于实际能够证明的程度

略多于半数的受访者给自己的生成式 AI 可见性打了 4 分或 5 分（满分 5 分）。然而，只有 29% 的受访者能够定期用一份报告为这一评分提供依据；这份报告只需统计敏感数据被发送到 AI 工具的次数。

来源：Cloud Security Alliance，《人工智能时代的 DLP》（2026 年），n=433。根据该报告第 22 页和第 23 页的图表重新绘制。

执行情况也呈现出同样的模式。只有 22% 的受访者会严格拦截通过生成式 AI 渠道传输的敏感数据。受访者认为可移动介质是数据外泄风险最低的渠道，但该渠道的严格拦截率最高，达到 31%。严格拦截主要集中在工具最陈旧的渠道上。

来源：Cloud Security Alliance，《人工智能时代的 DLP》（2026 年），n=433。根据该报告第 23 页和第 26 页的图表重新绘制；对于因四舍五入而合计为 99% 或 101% 的行，条形均按 100% 缩放。

Jazz 还在调查结果之外，公布了来自其客户环境的遥测数据。该数据中的组织平均使用 169.5 种不同的 AI 工具，其中 9.8 种获得批准，这意味着 94.2% 的工具不在获批名单之内。

差距为何存在：工具名单不会记录任何事件

应对生成式 AI 风险的常见做法，是通过企业协议批准少数 AI 服务，并劝阻员工使用或屏蔽其余服务。94.2% 这一数字显示，实际情况远远超出了这份名单的管控范围。赶着完成任务的工程师会使用当下能解决问题的任何工具，因为采购获批工具需要数周时间。

即使有一份完整的名单，也无法生成 CSA 所询问的那类报告。事件响应团队或审计人员会询问某个数据外流事件的具体情况，而工具名单并不包含任何事件记录。

要说明这起事件中发生了什么，你需要掌握四项事实：涉及了哪些敏感数据、哪个工具接收了这些数据、使用的是哪个账户，以及发送者为何要发送这些数据。

工具层面的治理最先在账户环节失效。同一个网站既供你公司的企业账户使用——该账户有自己的数据保留设置和合同条款——也供员工的免费个人账户使用，而后者两者皆无。通过个人账户登录使用获批工具，所能提供的证据与使用未经批准的工具差不多。

发送数据的目的更难判断，而这决定了事情是否出了问题。财务分析师把营收模型粘贴到聊天机器人中，以修复出错的公式，这是在履行工作职责。若在周五递交辞呈的人做了同样的事，所引发的讨论就应截然不同。两者的区别在于与当事人有关的背景信息，而这些信息绝不会出现在数据载荷中。

现有控制措施各自只能看到一个环节

调查发现，对于控制发送到 AI 工具的敏感数据，并没有一种占据主导地位的方法。针对 AI 域名进行网络层拦截、基于浏览器的内容检查，以及仅依靠可接受使用政策，这几种做法的占比各为 21% 至 23%；内置 DLP 的企业 AI 平台占 10%。

这些控制措施都是围绕单一检查点设计的。域名拦截可以允许或阻止连接，并记录连接访问了哪个网站。浏览器扩展只能看到在该浏览器中输入的内容，却无法看到通过桌面应用、代码编辑器中的编码助手或命令行工具发送的内容。企业 AI 平台内置的 DLP 只能看到进入该平台的内容。每种措施都只选择一个环节进行检查，并寄望数据恰好经由该环节传输。

单一检查点也解释了这些拦截数据。如果控制措施无法区分企业账户与个人账户，或无法区分常规粘贴与高风险粘贴，就只能两者都拦截，或两者都不拦截。严格拦截因此会连同有风险的操作一起阻止正当工作。当被问及尚未采取更积极的主动拦截措施的主要原因时，46% 的受访者表示担心影响业务工作流程，39% 则表示对 DLP 的准确性缺乏信心。

值得注意的限制因素

调查数据为受访者自行报告，调查并未将可见性评分与实际覆盖情况进行对照验证。受访者主要来自美洲（80%），且多就职于员工人数少于 5,000 人的机构（67%），因此调查结果未必同样适用于大型全球企业。遥测数据来自选择部署此类可见性工具的机构，因此样本可能偏向于那些已经对 AI 泛滥感到担忧的机构。

获批工具和智能体会让这份清单更加不完整

随着获批的 SaaS 产品开始加入 AI 助手，数据究竟交给了哪个工具，往往有两个答案：员工打开的应用，以及背后的 AI 模型提供商。AI 智能体让情况更加复杂。当智能体为员工提取文件并将其发送到某处时，谁执行了操作、为何执行，部分归因就落在了软件身上。正如 Unite.AI 最近一篇关于生产环境智能体中的提示注入的文章所指出的那样，智能体可能会受到其读取内容的操控，因此，智能体自己对所做操作的说明，不能代替对其目的的证据。

本月即可开展的测试

回顾过去 30 天，选出你认为曾传入 AI 工具的最敏感数据。然后检查你的团队能否在不手动整理的情况下，提供以下信息：

• 数据内容及其来源
• 接收数据的工具，包括未列入获批名单的工具
• 数据是通过企业账户还是个人账户发送的
• 发送数据时，相关人员正在处理什么工作

如果前两项很快就能查明，而后两项却需要采访员工才能弄清，那么你们的治理只能覆盖工具清单，对数据本身几乎没有覆盖。