影子 AI 治理难题：为什么禁止个人 AI 账号会让安全性变差

90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。

领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。

大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。

禁令策略在 AI 领域行不通

十年前，公司试图通过全面禁止个人云存储、USB 驱动器和个人电子邮件办公来遏制影子 IT。那个时代的教训是一致的：禁令减少的是可见性，而不是使用量。员工会找到绕过的方法——他们使用手机、家庭网络、个人账号——而 IT 团队则失去了让问题变得清晰可辨的遥测数据。

AI 是同一个问题的更高难度版本。与 USB 驱动器不同，AI 不是一种人们拿起又放下的离散工具。它已深度融入知识工作者的产出方式中：起草电子邮件、总结文档、调试代码、生成报告初稿。告诉销售人员不能使用 ChatGPT，就像是在告诉他们停止使用已经融入日常工作流的生产力工具。有些人会遵从，但大多数人会绕道而行。

数据证明了这一点。MIT 的一项研究发现，90% 公司的员工在工作中使用个人聊天机器人账号。其中，57% 的人表示他们的直属主管知情并支持这种行为。你认为行之有效的禁令，实际上正被你的中层管理人员和最高产的员工积极规避。

真正的成本体现在违规经济学中。IBM 的《2025 年数据泄露成本报告》发现，涉及影子 AI 的事件平均成本比其他事件高出 67 万美元。这种溢价的存在正是因为影子 AI 的使用对于安全工具是不可见的——你无法监测你看不到的东西。

在禁止之前先进行调查

当你发现影子 AI 的使用时，正确的第一个举措不是禁止，而是调查。你需要了解范围、涉及的数据类型，以及哪些团队在推动使用，然后才能设计出真正降低风险的应对方案。

调查工作分为三个层面：

发现暴露面。 查看 AI 服务域名的 DNS 查询日志和代理流量。审查托管设备上安装的浏览器扩展。检查费用报告中的 AI 订阅费用。大多数公司会发现，使用模式比预期的要广泛得多——不仅是初级工程师在实验，还有销售团队起草外联邮件、法务团队总结合同、财务团队构建模型。

对发送的数据进行分类。 真正的风险不在于抽象的 AI 使用，而在于特定类别的数据通过不受管的渠道离开公司边界。在你拥有可见性的 AI 端点出口流量上运行日志分析，并针对你无法看到的部分进行定向员工调查。典型的细分情况：技术团队分享代码和内部文档；销售和支持团队分享客户记录；高管分享战略计划和财务数据。每个类别都有不同的风险状况和监管含义。

识别推动使用的用例。 使用影子 AI 的员工并非为了好玩。他们这样做是因为它能显著提高他们重复性任务的速度。如果你批准的替代方案不能解决这些特定的工作流，禁令就不会奏效。在制定政策之前，请先梳理用例。

数据分类是承重墙

治理问题本质上并不在于员工使用哪种工具。它在于什么样的数据通过缺乏数据处理协议 (DPA)、审计日志和保留控制的渠道离开了公司边界。

每个行之有效的企业级 AI 治理项目都建立在数据分类方案之上。典型的层级包括：

• 公开 (Public)：公司外部已有的信息。对 AI 交互没有限制。
• 内部 (Internal)：非公开但泄露风险较低的运营数据。允许在经过批准的工具中使用 AI。
• 机密 (Confidential)：客户数据、财务数据、人事记录、源代码。AI 交互仅限于具有 DPA 覆盖且不对你的数据进行模型训练的核准工具。
• 受限 (Restricted)：受监管的数据——如 GDPR/CCPA 框架下的 PHI、PII、商业秘密、并购材料。AI 交互需要明确批准，且可能被完全禁止。

加载中…