核心要点
- Shadow AI管控措施应随企业规模和数据敏感度调整——而不是统一部署。
- 最被低估的风险敞口是企业已经付费使用的SaaS工具中已经开启的AI功能，而不仅仅是员工的个人ChatGPT账号。
- 全面封锁失败有三个结构性原因：个人设备处于安全边界之外，激进封锁会助长隐蔽行为，而嵌入已批准SaaS中的AI功能若被封锁往往会破坏该SaaS工具本身。
- 没有经批准替代方案的检测工具无法减少Shadow AI的使用——只会将其进一步推向地下。
- 一旦组织在相当规模上处理受监管数据，仅有书面AUP是必要但不充分的。
- 本地或自托管部署是针对"员工使用未经批准的消费级AI"这一问题的持久管控措施，但它无法解决已嵌入第三方SaaS中的AI功能问题，也无法单独满足对员工或监管机构的告知或披露义务。
大多数政策忽略的Shadow AI全景
一份写于2023年的Shadow AI政策，假设的风险场景是员工在浏览器中打开ChatGPT，粘贴一份客户名单。这种情况依然存在，但它早已不是最大或增长最快的风险敞口，而只覆盖这一点的政策会让另外三个敞口毫无防护。
企业已经付费使用的SaaS工具中悄悄开启的AI功能，是大多数政策完全忽略的敞口。 笔记类插件、CRM中的"智能"字段、工单摘要功能，以及生产力套件中的AI助手，往往在默认情况下或供应商更新后自动开启，将数据发送给一个安全团队从未评估过的模型——过程中没有安装任何新工具，也不会出现在基于网络流量或新应用注册构建的影子IT清单中。正因为没有"新装"任何东西，大多数清单会完全遗漏这一敞口。
另外三个敞口同样重要，大致按现有管控措施覆盖程度由高到低排列：
📍 简单一句话
Shadow AI是指组织内未经授权的AI使用，涵盖四种敞口——个人账号、浏览器扩展、已嵌入已批准SaaS中的AI功能，以及AI会议记录工具——其中SaaS内嵌敞口是现有清单最常遗漏的一种。
💬 简单来说
这不仅仅是员工偷偷使用ChatGPT的问题。你已经批准使用的某些软件供应商，可能已经悄悄开启了一项AI功能，把你的数据发送给一个你的安全团队从未批准过的模型——而且由于没有安装任何新应用，它永远不会出现在影子IT清单上。
- 在受管设备上使用的个人AI账号——员工用个人邮箱登录自己的ChatGPT、Gemini或Claude账号，在公司笔记本电脑上处理工作任务。
- 将网页内容或剪贴板数据通过第三方AI后端传输的浏览器扩展程序，往往是出于正当的生产力需求而安装，从未经过安全基线审查。
- 以可见或静默方式加入会议、默认将内容录制、转写并摘要发送至第三方服务器的AI会议记录工具。
- 已嵌入已批准SaaS工具中的AI功能（如上所述）——通用清单最不可能发现的敞口。
为什么全面封锁会失败
在网络防火墙上封锁AI域名，是大多数公司首先采取的管控措施，但无论企业规模如何，它都会因三个结构性原因而失败。
- 1个人设备处于安全边界之外。
网络封锁只能覆盖经过受管网络的流量。员工在个人手机、家庭网络，或使用分离隧道的BYOD笔记本电脑上，永远不受其约束。 - 2激进封锁助长隐蔽行为，而非合规行为。
当员工发现一款真正有用的工具被封锁时，往往会绕开封锁——使用个人热点、浏览器代理，或用手机代替笔记本电脑——这只会让该行为更难被察觉，而不会减少其发生频率。 - 3嵌入已批准SaaS中的AI功能，若被封锁往往会破坏该SaaS工具本身。
封锁某个CRM或工单平台内部调用的AI后端，通常会破坏该应用的核心功能，而不仅仅是AI功能——这使得网络封锁对最难被发现的这一敞口反而最不可行。
Shadow AI 风险敞口自评
回答下方问题，获取初始风险等级及匹配的管控措施清单。评分完全在你的浏览器中完成——不会提交任何数据。
Shadow AI Exposure Self-Assessment
Answer 12 questions about your organization to get a risk tier and a matched starting control set. Nothing is sent anywhere — scoring runs entirely in your browser.
1. How many employees does your organization have?
2. Which regulated data types does your organization handle? (select all that apply)
3. What share of employee devices are enrolled in mobile device management (MDM)?
4. How common is bring-your-own-device (BYOD) access to company systems?
5. Roughly how many SaaS applications does the organization use?
6. Does the organization already provide a sanctioned AI tool?
7. Are employees free to install browser extensions on managed devices?
8. Does a written AI Acceptable Use Policy (AUP) exist today?
9. Has the organization had a known incident involving unauthorized AI tool use?
10. How often does the organization run AI-usage awareness training?
11. Does the organization have any AI-aware detection tooling (CASB/SSE, DNS/egress telemetry, or DLP tuned for AI endpoints)?
12. Does the organization operate in a heavily regulated jurisdiction (EU, healthcare, financial services)?
检测层
检测工具大致分为四大类，大多数中型组织最终会组合使用至少两类，而不是依赖单一工具。
CASB / SSE
- 可发现的内容:
- 受管设备到已知AI域名的流量
- 典型局限:
- 对未受管/BYOD设备以及通过分离隧道VPN的个人账号加密流量视而不见
DNS/出站流量遥测
- 可发现的内容:
- 网络中的设备解析或连接了哪些AI域名
- 典型局限:
- 只能识别发生了连接，无法识别流出了什么数据——而且无法发现从已批准SaaS应用内部调用的AI功能
浏览器级代理
- 可发现的内容:
- 浏览器本身内的页面内容及复制/粘贴活动
- 典型局限:
- 仅覆盖已安装代理的受管浏览器；增加端点管理负担
针对AI端点调优的DLP
- 可发现的内容:
- 流向已知AI服务的敏感数据模式（PII、源代码、财务数据）
- 典型局限:
- 随着新AI端点和消费级应用不断出现，需要持续调优；若范围界定不严谨，会对合法的已批准工具流量产生误报
以上四类检测工具都无法解决组织已批准的SaaS工具中已嵌入的AI功能问题——请参阅下方"替代层"及"本地部署无法解决的问题"部分，了解检测在这一点上的结构性上限。
检测与监控供应商
该领域的供应商通常按其主打的上述检测类别分组，尽管大多数供应商随着时间推移已扩展到多个类别。这只是一般性方向说明，而非经过评测的比较——在购买前，请根据自身环境及当前定价评估任何供应商，因为这个市场的打包方式和覆盖范围经常变化。
- Netskope和Zscaler常被列为CASB/SSE类别的供应商，在其更广泛的安全访问平台之上叠加了AI应用可见性与控制功能。
- Kiteworks常被定位为安全内容/数据治理领域，提供针对AI的数据暴露管控功能。
- Harmonic Security和Nightfall AI常被列为专门围绕AI使用可见性及针对AI端点调优的DLP构建的供应商，而不是作为更大平台上的附加功能。
替代层：为什么仅靠检测算不上一种管控
检测工具回答的是"这种情况正在发生吗？"，而不是"员工应该改用什么？"——而正是后一个问题，才真正改变行为。
如果一名员工在某个AI工具中获得了真实的效率提升，却发现它被封锁或被标记，同时没有提供任何经批准的替代方案，那么他现实中只有三个选择：放弃这个好处，想办法绕开封锁，或者继续使用该工具并寄望于不被发现。实践中，相当一部分员工会选择第二或第三种做法——这正是为什么纯检测型项目常常显示"被检测到"的事件数量在下降，而潜在的未经授权使用并未相应减少。
经批准的内部部署——最持久的形式是由安全团队端到端掌控的自托管或本地运行模型——之所以能弥合这一缺口，是因为它从新政策实施的第一天起，就为员工提供了"那我该用什么？"这一问题的正当答案，而不是让他们绕开一条没有替代方案的规定。这也是Shadow AI政策与更广泛的本地LLM部署内容之间的自然衔接：关于其背后的取舍，参见本地LLM与云端API对比；关于经批准的内部部署具体涉及什么，参见本地/离线本地LLM部署。
📍 简单一句话
没有经批准替代方案的检测，并不能减少Shadow AI的使用——它通常只减少了可见、被检测到的那部分，而经批准的内部部署则能直接满足潜在的需求。
一份可行的AUP究竟应该包含什么
一份只写着"不要使用未经批准的AI工具"的可接受使用政策，在实践中缺乏可执行性，因为它没有给员工任何正面指引。一份可行的AUP通常涵盖以下条款：
- 哪些工具已获批准，以及员工在哪里能找到最新清单（静态PDF容易过时，是常见的失败模式——应链接到一个持续更新的页面）。
- 哪些数据分类永远不得输入任何AI工具，无论该工具是否获批（例如客户PII、受NDA约束的源代码、尚未公布的财务业绩）。
- 当员工发现一款真正有用但未获批准的工具时该怎么办——应有明确处理时限的申请流程，而不是一条死胡同。
- AI生成的输出在对外使用前，是否以及如何需要披露或审核（客户交付物、代码、公开传播内容）。
- 该政策如何适用于已嵌入已批准SaaS工具中的AI功能，而不仅仅是独立的AI产品——这是大多数现有AUP完全遗漏的条款。
- 违规后果应按比例分级（首次因规则不清晰而无意违规，不应与反复、蓄意的数据外泄承担相同后果）。
- 一位指定负责人及定期审查节奏——从未被重新审视的AUP，会随着AI工具格局的变化在几个月内变得不准确。
- 员工确认机制——员工如何以及何时确认已阅读当前版本，尤其是在重大更新之后。
本地部署无法解决的问题
经批准的本地或自托管部署，对一个具体问题而言是真正持久有效的管控措施：为员工提供未经批准消费级AI工具的正当替代方案。但它并不是Shadow AI的完整解决方案，将其视为完整方案会造成一种虚假的安全感。
本地部署无法解决已嵌入组织无法控制的SaaS工具中的AI功能问题。 如果某CRM供应商在服务端启用了AI摘要功能，并行运行自己的模型并不会改变该供应商的AI功能对其系统内已有数据所做的处理——这需要在供应商合同及DPA层面加以管控，而非部署层面的决定。
本地部署本身并不能满足对员工或监管机构的告知或披露义务。 在本地运行模型改变的是推理发生的位置；它不会自动创造某些司法辖区无论模型运行在何处都要求的内部AI素养培训、员工代表机构（如职工委员会）的协商，或监管备案——请参阅下方"司法辖区说明"部分，了解这一区别在实践中真正重要的具体例子。
💬 简单来说
在企业内部运行自己的AI模型，解决的是"员工使用某个随意的消费级应用"这个问题。它解决不了"我们的CRM悄悄开启了一项AI功能"这个问题，也不能单独满足告知员工或监管机构AI使用情况的法律义务——这需要单独且有意为之的步骤。
司法辖区说明
在中国，Shadow AI问题的形态与其他地区相反：由于境外主流消费级AI服务大多无法使用，数据泄露的主要渠道是国内消费级AI应用，而非ChatGPT一类的海外产品；主要法律风险在于《个人信息保护法》（PIPL）和《数据安全法》下的跨境数据传输问题，而不是隐私告知失败问题。面向公众的生成式AI服务需要向国家网信办（CAC）进行备案。
实际结果是：中国企业较早采取了经批准的私有化部署路径——2025至2026年间，众多国有企业陆续完成的DeepSeek本地化部署浪潮，实质上就是在国家层面大规模实施的Shadow AI替代方案。
本节仅为一般性方向说明，不构成法律意见——在最终确定政策前，请就贵企业具体的司法辖区、行业及数据类型咨询法律顾问以确认适用性。
常见问题
什么是Shadow AI？
Shadow AI是指组织内未经IT或安全团队审查或批准的AI工具使用行为——涵盖受管设备上的个人AI账号、将数据传输至AI后端的浏览器扩展、已在已批准SaaS工具中开启的AI功能，以及AI驱动的会议记录工具。
如何检测公司中未经授权的AI使用？
结合使用CASB/SSE来监控受管设备到已知AI域名的流量，使用DNS或出站流量遥测来查看公司设备连接了哪些AI域名，并使用专门针对AI端点调优的DLP。没有单一类别能覆盖所有情况——CASB/SSE会遗漏未受管设备，而这些方法都无法发现已嵌入你已批准SaaS工具中的AI功能，这需要转而进行供应商合同审查。
我们应该直接在防火墙上封锁AI工具吗？
单靠全面封锁是一种薄弱的管控措施。它无法覆盖受管网络之外的个人设备，往往会把使用行为进一步推向地下而非消除它，并且在不破坏母应用的情况下，无法处理已嵌入SaaS工具中的AI功能。
多大规模的公司需要专门的Shadow AI检测工具？
应使用上方的风险自评，而不是仅凭员工人数判断——一家处理受监管数据（健康、支付或商业秘密信息）的小公司，可能比一家数据敏感度低但设备管理良好的大得多的公司承担更高风险。作为一般规律，一旦组织同时具备相当程度的受监管数据敞口与薄弱的设备管理或庞大的SaaS资产，检测工具就变得具有相称性。
我们应该多快部署一个经批准的AI替代方案？
时间表应随风险等级调整：处于"严重"等级的组织（受监管数据、设备管理薄弱、无现有经批准工具）应以30天为目标；处于"低"等级的组织通常可以采用更长、不那么紧迫的时间表。没有经批准替代方案的检测无法降低潜在使用——只能降低可见的部分。
运行本地LLM能解决我们的Shadow AI问题吗？
经批准的本地或自托管部署，能持久地解决"员工使用未经批准的消费级AI工具"这一问题，但无法解决已嵌入你无法控制的第三方SaaS中的AI功能问题，也无法单独满足对员工或监管机构的告知或披露义务——这需要单独的步骤。
Shadow AI的可接受使用政策（AUP）究竟应该包含什么？
至少应包括：一份最新的已批准工具清单、永远不得输入任何AI工具的数据分类、供员工申请使用有用但未获批准工具的流程、对外使用AI生成内容的披露规则、对已批准SaaS中嵌入的AI功能（而不仅是独立AI产品）的明确覆盖、按比例分级的后果、一位指定负责人，以及定期审查节奏。
我们现有SaaS工具中的AI功能真的构成Shadow AI风险吗？
是的，而且这往往是标准影子IT清单最容易遗漏的敞口，因为没有安装任何新应用，身份或费用日志中也不会出现新的注册记录——该AI功能是在组织已经批准且已经付费使用的软件内部被开启的。
我们应该多久重新进行一次Shadow AI风险评估？
应在任何重大变化后重新评估——例如员工人数变动、新增SaaS平台、公司开始处理的新受监管数据类别——并且鉴于AI功能正被以多快的速度加入现有SaaS产品，至少每六个月进行一次。