影子 AI 风险集中于企业重度用户

Google News 援引 Akamai 发出了一项明确警示：5% 的企业用户产生的 AI 对话量，是员工中使用最少的半数人群的 12 倍。这些员工并非只是偶尔提问。他们正将 AI 嵌入重复性工作流程、分享工作上下文、上传文件，有时还会部署可访问企业系统的智能体。

这一发现挑战了企业对影子 AI 的常规应对方式。所谓影子 AI，是指在雇主批准的控制措施之外进行的工作场所 AI 使用。许多公司仍为所有员工发布同一套政策，屏蔽几个容易识别的网站，并统计获批平台的许可证数量。这种做法默认风险暴露分布均匀，而 Akamai 的遥测数据表明，风险其实高度集中。

这并不意味着应忽视随意使用 AI 的情形。观察到的企业 AI 对话中，近半数使用的是个人身份，而非企业统一管理的账户。然而，个人访问、高频提示，以及连接型智能体相结合，带来的风险远比一次孤立请求更为重大。

因此，核心矛盾并不在于员工与安全团队之间，而在于广泛的应用级治理与基于身份、聚焦实际行为的控制措施之间。前一种方法问的是某项 AI 服务是否被允许使用；后一种方法问的是谁在使用、以何种身份使用、使用了哪些数据，以及能访问哪些系统。

这一差异至关重要，因为创造最多 AI 价值的员工，也可能带来最大的未受管理风险。无差别地放慢他们的工作节奏，会浪费专业能力并催生更多规避行为；让他们的活动处于不可见状态，则会使敏感工作流程逐渐超出常规安全边界。

Google News 揭示了更聚焦的影子 AI 问题

Akamai 的数据将影子 AI 的讨论重点，从整体采用规模转向活动与访问权限的集中程度。

相关发现来自 Akamai 于 8 月 5 日发布的《Enterprise AI Usage Risk Report 2026》。Akamai 基于其收购的企业浏览器安全公司 LayerX 提供的使用数据编制了该报告。研究涵盖个人账户、AI 应用、浏览器扩展、敏感提示词和自主智能体。

根据这份企业 AI 报告，企业用户平均进行了超过 36 次 AI 对话。但这一平均值掩盖了陡峭的分布差异：半数用户的对话次数不超过 12 次，而排名前 5% 的用户至少进行了 144 次对话。

差距不仅体现在对话数量上。Akamai 表示，一次典型的 AI 对话约包含五条提示词；而最密集使用者的对话至少达到 18 条提示词，显示出持续协作，而非单次类似搜索的交互。

更长的对话会为业务信息进入外部系统创造更多机会。用户可能先提出一个无害的提纲请求，随后在后续提示中加入客户细节、内部限制、文档摘录、源代码、财务假设，或从私人通信中复制的指令。

相比任何单独的一句话，这些累积的上下文更值得关注。现代 AI 工作往往通过碎片化信息逐步展开：员工在多轮提示中补充事实、上传支持文件，并反复要求模型修订输出。每一次披露看似都很有限，但完整对话可能重构出一项敏感的业务流程。

Akamai 还报告称，47.11% 的企业 AI 对话通过个人身份进行。这些会话不受企业身份控制、保留设置、审计系统和协商数据保护条款的约束。安全团队或许能看到浏览器访问了某项 AI 服务，却无法得知员工是否使用了受管理账户。

不同平台的身份使用比例差异显著。Akamai 的遥测数据发现，Gemini Enterprise 有 98.15% 的交互处于企业身份系统之内；Microsoft Copilot for Microsoft 365 的这一比例为 90.55%。

面向消费者的访问则呈现相反模式。报告将 61.36% 的 ChatGPT 交互、61.09% 的 Claude 交互，以及 63.92% 的 Microsoft Copilot Standard 交互与个人身份相关联。DeepSeek 的比例达到 99.8%。

这些数据并不能证明每一次个人会话都泄露了机密数据。它们揭示的是可见性缺口：当工作跨越企业未管理的身份时，雇主无法持续执行企业的保留、访问和数据处理规则。

Google News 展示的文章还强调了一项关键关联：进行更深度对话的重度用户，也更可能上传文件、分享业务信息，并将 AI 与运营任务相连接。风险会随着活动增加而上升，因为每一次额外交互都增加了一次不当暴露的可能。

这种框架比将每位员工视为同等风险来源更有价值。提出一个通用写作问题的员工，与将智能体连接到代码仓库的工程师，所带来的风险并不相同。两者都在使用 AI，但其访问权限、数据和潜在影响截然不同。

“5%”这一标题数字不应被视为永久阈值。每个组织都会呈现不同的分布。真正重要的变化在于方法论：安全团队需要先衡量风险集中度，再决定应将更严格的控制措施部署在哪里。

风险最高的用户往往也是生产力最高的用户

最可能绕过广泛 AI 政策的员工，往往正是那些已将 AI 变成工作基础设施的人。

重度用户通常出现于他们在正式采购流程跟进之前，就已发现了可重复的价值。他们可能用 AI 总结客户研究、调试代码、起草合同、比较技术文档、分析销售通话，或准备财务情景分析。反复成功会推动更深层的整合。

这一过程往往起初无害。员工先用非机密材料测试公共聊天机器人，随后创建可复用的提示词、添加参考文件、安装浏览器扩展，或将模型连接到其他应用。个人实验会逐步演变为未经记录的生产工作流程。

早在 Akamai 报告发布前数年，Microsoft 就观察到了这种采用压力。其 2024 年工作场所 AI 研究发现，75% 的受访知识型员工在工作中使用 AI；在这些用户中，78% 自行引入 AI 工具，而非等待雇主提供选项。

这项较早的调查衡量的是自我报告行为，而 Akamai 提供的是观测到的使用遥测数据。两项来源采用的方法和覆盖时期不同，因此不应将其数字合并为单一统计结论。但它们描述了同一种组织张力：员工采用便捷工具的速度，快于企业评估和治理这些工具的速度。

广泛禁令往往忽视了这种动机。政策可以告诉员工，不要将敏感信息输入未经批准的模型；但它无法让获批替代方案变得真正好用，无法缩短冗长的访问申请流程，也无法说明在特定工作流中哪些信息是安全的。

当获批工具缺乏所需能力时，重度用户会立即面对阻力。他们可以暂停高效工作、提交采购申请，或继续通过个人账户使用。如果审批需要数周时间，个人账户就成了阻力最小的路径。

这并不能为未经授权的数据处理开脱，但它解释了为何通用培训的效果并不均衡。一年一度的合规宣讲，需要与日常截止日期、熟悉的消费者界面，以及有效提示词链带来的即时价值竞争。

Akamai 关于影子 AI 的发现表明，培训应围绕观察到的行为展开。普通用户需要清晰边界和获批选项；重度用户则需要更细致的指导，覆盖数据分类、身份、扩展、连接器、智能体权限和事件报告。

他们还需要一条更安全的实验路径。企业可以建立受控环境，让高级用户测试新模型而不暴露生产数据。安全团队则能在决定批准哪些服务、集成和工作流程之前，先观察实际需求。

这种做法将影子 AI 重度用户视为合作伙伴，但并不假定专业能力等同于安全意识。有人可能理解模型行为，却仍低估保留、授权或第三方处理风险。技术自信有时会让非官方工作流程显得比实际更安全。

高效用户也可能成为隐形系统所有者。如果团队依赖存储在个人账户中的提示词，企业就没有这些指令的可靠记录。若员工离职、更换工具或失去访问权限，工作流程也可能随之消失。

同样的问题也存在于知识管理中。员工常常向 AI 提供分散在个人空间中的笔记、文档、会议上下文和决策。受治理的个人知识系统能够减少这种碎片化，但前提是其访问和数据实践符合组织要求。

因此，安全团队面临一项微妙任务：既要保留让 AI 发挥价值的专业能力，又要将周边工作流程迁移至受管理身份、获批数据路径和可审查系统中。

惩罚最活跃的用户，可能会将他们进一步推向地下；忽视他们，则可能使私人实验演变为未经追踪的基础设施。更好的应对方式始于找到他们、理解他们构建了什么，并将有价值的实践与不安全的实施选择区分开来。

广泛政策看到的是应用，而非暴露

应用清单无法显示，用户是在提出一个通用问题，还是让自主智能体访问关键代码仓库。

传统的影子 IT 项目通常会盘点服务、对供应商分类，并屏蔽被禁止的域名。这一模式假定每个应用都代表相对稳定的风险单元。生成式 AI 使这一假设复杂化，因为同一个界面可以支持截然不同的行为。

一名员工可能使用 ChatGPT 改写公开的职位描述；另一名员工可能将尚未发布的产品规格粘贴到同一服务中；第三名员工则可能安装可访问本地文件和开发凭据的编程扩展。

域名相同，但风险暴露会随身份、内容、权限和使用时长而变化。简单的“允许或屏蔽”决定无法表达这些差异。

Akamai 的安全分析指出了五个相互关联的领域：不断扩大的 AI 使用、个人账户、数据暴露、浏览器或开发扩展，以及自主智能体。它们的组合比任何单一类别都更重要。

浏览器扩展尤其值得严格审查，因为它们贴近用户活动运行。根据获得的权限，扩展可以读取页面内容、观察输入、与云应用交互，或将信息发送至外部服务。员工可以安装这些扩展，却未必将这一行为视为软件部署。

集成开发环境扩展也给工程师带来了类似问题。AI 编程助手可能会看到源代码文件、配置资料、错误日志或附近的机密信息。即使核心服务已获批准，某个特定扩展、账户类型或配置仍可能游离于企业管控之外。

Agent 再次抬高了风险。AI Agent 是一种软件：它利用模型通过工具追求某个目标，并只需要有限的人类干预。根据所获权限，它可以搜索文件、调用 API、修改记录或触发其他应用程序。

聊天机器人通常返回文本，由人来评估。Agent 则可以采取行动。这一转变使不准确的输出、被操纵的指令或过度授权转化为实际运营后果。

尝试使用 Agent 的员工可能会连接个人令牌、授予广泛的代码库访问权限，或在未受管理的设备上运行系统。安全团队可能根本不知道该 Agent 的存在，因为它看起来像普通的浏览器、API 或本地开发活动。

风险也会在最初的对话结束后持续存在。浏览器标签页关闭后，提示词可能很快淡出视野；但 Agent 可能仍按计划运行、保留凭据，或通过集成持续执行操作。

Netskope 在其 2025 年影子 AI 研究中指出了这一不断扩大的风险面。研究发现，2025 年 5 月，60% 的受观察企业用户仍在访问个人生成式 AI 应用。该公司还将自定义 Agent、云端 AI 平台和本地部署工具视为新兴的影子 AI 形态。

Netskope 报告称，其数据集中的普通组织使用了七款软件即服务生成式 AI 应用，高于三个月前的 5.6 款。该公司还在追踪超过 1,550 款不同的生成式 AI 应用。这些数字说明，维护一份完整的封锁清单为何变得困难。

不过，用对每一条提示词的监控来取代封锁清单，也会带来自身问题。员工隐私、劳动法规、数据最小化和信任仍然重要。如果收集缺乏明确目的或适当保障措施，更多可见性并不必然意味着更好的治理。

目标应当是相称的控制。组织可以从身份类型、应用类别、上传事件、扩展权限、工具连接和异常活动水平等元数据入手。只有在法律、政策和风险能够证明其合理性时，才进行更深入的检查。

这种模式类似于既有的零信任原则。访问权限取决于身份、设备、资源和上下文，而非仅取决于位置。AI 治理也应使用类似的信号组合来评估每一次交互。

受管理的 AI 服务并不意味着每项操作都安全。未经批准的服务也不意味着每项操作都同样危险。真正关键的问题是，用户、模型和已连接工具共同能够触及什么。

这正是广泛政策错过核心集中化问题的原因。它管控的是应用名称，而实际暴露则围绕特定身份和工作流程不断累积。

集中化控制也会带来自身风险

定向治理比一刀切限制更精准，但组织不应将使用量视为不当行为的证据。

Akamai 的发现支持对高频用户给予更多关注。但这些发现并不能证明前 5% 的用户造成了大多数已确认事件、泄露了最敏感的记录，或存在不负责任的行为。高活动量是风险指标，而不是事故裁决。

这一局限很重要。遥测数据描述的是对话、身份和使用模式，无法揭示每一次交互背后的完整业务目的。仅以对话量衡量时，测试 AI 控制措施的安全分析师可能看起来与不安全用户无异。

因此，组织应避免将 5% 这一数字变成自动执法类别。高强度活动应触发结合上下文的审查，而不应在缺乏额外证据的情况下，成为立即暂停账户、侵入式监控或纪律处分的理由。

该数据集也反映了 Akamai 和 LayerX 的可见范围，不应被当作涵盖所有行业、地区、设备和 AI 部署的普遍普查。企业在设定阈值或估算暴露程度之前，需要先建立自己的基线。

第二个担忧涉及对企业账户的虚假信心。受管理身份可改善审计、访问控制和合同保护，但无法阻止员工输入受限信息、接受幻觉式回答，或向已连接应用授予过多权限。

企业版 Gemini、Copilot、ChatGPT 或 Claude 可以通过管理控制降低某些风险，但无法替代数据分类、授权设计、工作流程审查或人类判断。

第三个担忧是组织信任。如果员工认为每一次 AI 交互都会被管理层阅读，他们可能隐藏使用行为、转向个人设备，或避免使用已获批准的工具。这种反应会削弱定向项目原本应当带来的可见性。

企业需要透明的监控规则。用户应了解收集哪些信号、这些信号为何重要、谁可以审查它们，以及它们会保留多久。安全团队应尽可能将风险检测与绩效监控分开。

NIST AI 框架为狭义执法提供了有益的制衡。它从治理、映射、测量和管理四个方面组织风险工作。这种生命周期方法将控制视为持续运行的系统，而非单一的员工政策。

治理明确所有权、可接受使用、报告路径和问责机制。映射识别业务背景、受影响人员、数据和依赖关系。测量检验风险与控制是否能够被观察。管理则根据影响和容忍度确定响应优先级。

将这一顺序应用于影子 AI 高频用户，可以防止从检测过早跳转到惩罚。企业首先识别高强度工作流程，映射其业务目的和数据访问范围，衡量具体暴露，随后选择相称的控制措施。

响应措施可能包括将个人账户迁移到受管理账户；移除过度的扩展权限；替换个人 API 密钥；限制 Agent 的工具；或批准更合适的企业服务。

某些工作流程应当完全停止。一个未经审查、能够修改财务记录或处理受监管健康数据的 Agent，其暴露水平显然不同于使用公开资料的文案起草助手。集中度分析有助于发现这种差异，但其含义仍需由人工审查来判断。

定向治理还必须考虑特权用户。工程师、管理员、研究人员、高管、法务团队和财务人员通常比同事接触更具影响的信息。对话量和访问敏感度应结合评估。

一名围绕公开营销文案进行 150 次低风险对话的用户，其暴露程度可能低于上传了一份机密收购文件的人。使用量之所以有价值，是因为它能识别嵌入式行为；而内容和权限上下文则决定潜在影响。

审慎的结论很直接：Akamai 的影子 AI 遥测数据改善了优先级判断，但并未提供完整风险评分。组织仍需要本地证据、透明规则和谨慎审查。

安全团队下一步应关注什么

影子 AI 治理的下一阶段，将通过受管理身份的采用情况、Agent 权限以及敏感暴露的经验证减少来衡量。

第一个信号是，与工作相关的 AI 活动中，从个人身份迁移至企业受管理账户的比例。这比统计已购买许可证数量更有意义。一家企业可能拥有数千个企业席位，而员工仍在继续使用熟悉的个人账户。

安全负责人应按团队和活动水平衡量账户迁移。普通用户的进展固然有用，但最重要的是高强度用户群体的变化。若该群体中个人账户占比下降，将支持 Akamai 的集中度论点，并表明定向干预正在发挥作用。

这一指标需要谨慎解读。受管理登录并不能证明行为安全，但它确实为访问控制、保留设置、可审计性和事件响应提供了更坚实的基础。

第二个信号是，具备业务系统访问权限的 Agent 和扩展的增长情况。组织应盘点这些工具能读取、修改和传输什么，并识别哪些身份提供了相应凭据。

权限比 Agent 数量更重要。十个仅限访问公开信息的 Agent，带来的暴露可能低于一个拥有生产数据写入权限的系统。审查应优先关注敏感资源、持久化凭据、外部数据传输，以及缺少人工确认的操作。

任何对过度权限的削减，都会加强聚焦治理的理由。未被发现的 Agent 若快速增长，则会削弱“现有 AI 政策提供了有意义覆盖”的说法。

第三个信号是，组织能否在不压制有益采用的前提下，证明敏感数据事件有所减少。这是最难衡量的指标，因为它要求安全和生产力团队共同评估结果。

成功的项目应减少受限上传、未受管理凭据和未经批准的集成。同时，它也应让已获批准的使用方式足够易用，避免员工转向不可见渠道。

仅以被拦截请求为基础的指标会诱发错误激励。更多拦截可能意味着执法更严格、不安全需求增长，或已获批准的替代方案不足。团队需要将预防事件与账户迁移、已批准工作流程采用、用户反馈和已确认事件进行对比。

只有当组织在自身环境中验证 Google News 的表述时，这一框架才会继续有用。精确的 5% 阈值可能变化，但如果底层模式成立，内部遥测中应当出现集中化现象。

安全团队可以从几个实际问题开始：哪些员工最频繁使用 AI？其中哪些人依赖个人身份？谁在上传文件、安装扩展，或将 Agent 连接至内部系统？哪些已获批准的工具无法满足他们的需求？

这些问题比“是否应允许或禁止所有 AI”提供了更好的起点。它们将治理与实际工作相连，并揭示便利性正在哪些地方绕过控制。

企业还应建立一条不以纪律处分为起点的升级路径。当安全团队发现高级的非正式工作流程时，首次审查应识别其业务价值、数据输入、权限和替代方案。这为保留有用做法、同时移除不必要暴露创造了机会。

当风险是即时的，例如某个 Agent 拥有广泛的生产环境访问权限时，应首先进行遏制。暴露较低时，迁移和辅导通常比一刀切禁令更能带来长期合规。

领导者在宣布问题已受控前，还应提出最后一个问题：组织能否在不依赖问卷调查的情况下描述其最高强度的 AI 工作流程？如果答案是否定的，说明政策的推进已领先于证据。

Google News 让人们关注到一个重要转变。影子 AI 虽然广泛存在，但其最严重的暴露未必均匀分布。最深入使用 AI 的人群，正是生产力、数据、身份和自主访问权限汇聚之处。

这就明确了下一步行动：找出高频集中的工作流，将其迁移至受管理的身份体系下，审查其权限，并衡量敏感信息暴露是否下降。广泛适用的规则可以划定边界，但只有真实使用中的证据，才能显示保护应部署在哪里。