企业讨论 AI 安全，很多时候讨论的是两个问题。
一个是“模型本身安不安全”，比如越狱、幻觉、偏见、数据泄露、提示注入。另一个是“正式上线的 AI 系统安不安全”，比如企业知识库、智能客服、代码助手、Agent 平台、自动化运维系统。
但最近一篇论文提醒我们：在真正的企业现场里，还有一种更普遍、更隐蔽，也更难治理的风险。
它不是企业正式采购的大模型系统，也不是安全团队评估过的 AI 应用，而是员工、管理员、开发者、业务负责人在日常工作中自己使用的 ChatGPT、Claude、Copilot、Gemini 或其他生成式 AI 工具。
论文把这种现象称为 Shadow AI，也就是“影子 AI”。
https://arxiv.org/pdf/2606.00088
它的危险之处不在于员工一定有恶意。恰恰相反，很多时候员工只是想提高效率，想快点写完报告，想总结一份会议纪要，想改一段代码，想让模型帮忙分析一个表格。
问题在于，这些行为发生在组织正式控制边界之外。
企业不知道员工输入了什么，也不知道模型输出了什么，更不知道这些输出后来有没有进入报告、代码、决策、监管材料或关键业务流程。
如果放在普通公司里，这可能只是一次数据合规风险。但如果放在通信、能源、水务这类关键基础设施里，它就不只是“员工乱用 AI 工具”的问题，而是在侵蚀组织对自身安全状态的证明能力。
换句话说，影子 AI 最大的威胁，可能不是马上造成一次事故，而是让企业慢慢失去回答一个基本问题的能力：
我们到底还能不能证明，自己的系统和流程是受控的？
真正危险的是 AI 已经被用进去了
这篇论文题为 《From Frontier to Shadow AI: A Simmering Threat to Assurance and Security in Critical Infrastructure》，可以译为《从前沿 AI 到影子 AI：关键基础设施安全保障中正在酝酿的威胁》。作者来自澳大利亚 CSIRO，研究对象是澳大利亚通信、能源、水务与污水处理等关键基础设施组织。论文基于对 27 家关键基础设施组织、32 位高管和职能负责人的半结构化访谈，分析影子 AI 在关键基础设施中的真实使用方式、治理盲区和安全后果。
这篇文章的切入点很现实。
过去我们习惯把 AI 风险理解为“模型上线之后的风险”。例如，一个企业要建设智能客服，就先做模型测评；要上线代码助手，就先做安全评估；要引入 Agent，就先做权限管理和工具调用控制。
但影子 AI 不一样。
它通常不是一个正式项目，也不一定有系统名称、预算编号、上线流程、审批记录。它发生在日常工作流中：有人把内部报告复制到公共 AI 工具里做摘要，有人让模型帮忙改写监管材料，有人用 AI 生成 SQL 或 Python 脚本，有人把日志、表格、会议纪要、工程文档传给模型，让它“帮我看一下”。
这些行为不一定会触发传统资产管理，因为它们不是一个新系统；也不一定会触发传统采购审批，因为它们可能只是浏览器里的一个网页；更不一定会触发安全评审，因为员工觉得自己只是在“辅助办公”。
但从组织治理角度看，AI 已经进入了工作流程。
论文非常强调这一点：影子 AI 并不是传统影子 IT 的简单翻版。传统影子 IT 往往表现为未经批准的软件、系统或基础设施，安全团队至少还有机会把它盘点出来，纳入资产管理。影子 AI 更麻烦，因为它很多时候运行在“交互层”——提示词、上传文档、模型总结、内容改写、代码补全、嵌入式 AI 功能。它不是一个容易盘点的资产，而是一种散落在每个人工作动作里的能力。
这也是影子 AI 比影子 IT 更难治理的地方。
影子 IT 的问题是：你用了一个企业不知道的软件。
影子 AI 的问题是：你让一个企业无法完全掌握的模型，参与了企业知识、文档、代码、判断和决策的生成过程。
为什么关键基础设施更怕“隐形使用”
如果一个普通互联网公司员工把营销文案扔进大模型，让模型帮忙润色，风险主要集中在商业秘密、用户隐私、合同约束和内部合规。
但如果类似行为发生在关键基础设施组织里，问题会更复杂。
通信、能源、水务这些行业，本身承担社会基本运行功能。它们有几个共同特点：系统复杂、外部依赖多、监管要求强、事故后果重、容错空间小。论文指出，关键基础设施监管通常默认几个前提：系统边界是清楚的，系统行为是可观察的，责任归属是可以识别的，控制措施是可以审计和复盘的。
影子 AI 刚好会破坏这些前提。
一个员工把设备维护报告上传给公共 AI 工具，表面看不是生产系统操作，也没有直接碰控制系统。但这份报告可能包含设备状态、缺陷分布、地理位置、供应链信息、维护计划、故障模式。这些信息在一般数据分类里未必属于个人敏感信息，却可能具有明显的运营安全价值。
一个开发者用 AI 辅助生成代码，短期看只是提高效率。但如果代码后来进入内部工具、运维脚本、数据处理流程，而组织没有记录它由 AI 参与生成，也没有做额外验证，一旦出现错误，很难追溯源头。
一个管理者用 AI 改写监管材料，模型可能让文本看起来更流畅、更专业，但也可能改变措辞边界、弱化不确定性、引入未经验证的判断。最终材料进入正式流程后，组织很难说清楚哪些内容来自人，哪些内容受模型影响。
关键基础设施的安全，不只是“系统没有被攻破”。它还要求组织能够证明自己持续处在受控状态。能证明数据怎么流动，能证明决策怎么形成，能证明控制措施怎样生效，能证明事故发生后可以复盘。
影子 AI 的问题在于，它让大量 AI 介入过程变得不可见。
这不是一次爆炸，而是一种慢性侵蚀。
影子 AI 已经很普遍，但还没有完全进入 Agent 阶段
论文中有一个很重要的发现：在受访的 27 家关键基础设施组织中，只有一家组织报告没有观察到影子 AI 使用，原因是它很早就全面封禁了未批准的 AI 工具。其他组织普遍认为，影子 AI 已经是常见现象，而不是个别员工的例外行为。部分受访者甚至估计，组织中接近 80% 到 90% 的人都在使用某种形式的影子 AI。
更值得注意的是，影子 AI 并不局限在某个部门。
它可能出现在办公室员工那里，用来写邮件、写报告、做摘要；也可能出现在开发者那里，用来写代码、查资料、调试问题；还可能出现在管理者和技术管理员那里，用来准备材料、理解系统、分析问题。论文提到，受访者描述影子 AI 的使用是组织范围内扩散的，包括运营人员、办公室员工、开发者、管理者以及拥有较高权限的技术角色。
不过，论文也做了一个克制判断：当前观察到的影子 AI，主要还是“人在回路中”的交互式使用，并没有发现大规模私下部署自主 Agent 或直接进入安全关键控制流程的证据。
这个判断很关键。
因为它说明今天的风险还不是科幻电影式的“AI 接管电网”或者“Agent 自动操作水厂”。更现实的风险是，AI 正在被悄悄用进关键基础设施组织的知识工作层。
报告、文档、代码、分析、邮件、监管材料、内部总结，这些东西看起来离控制系统很远，但它们会影响组织对系统的理解，影响管理层判断，影响安全策略，影响监管沟通，也可能间接影响未来的工程决策。
所以，影子 AI 的第一阶段，不是 AI 自动控制世界，而是 AI 悄悄改写组织理解世界的方式。
员工为什么会使用影子 AI
如果把影子 AI 简单归结为“员工不守规矩”，就会误判问题。
论文把影子 AI 描述为一种社会—技术条件，也就是组织环境、技术便利性、管理信号和个人效率需求共同塑造出来的结果。受访者普遍认为，影子 AI 风险更多来自善意、日常、低摩擦的使用，而不是恶意行为。论文中有一句关键判断：影子 AI 相关风险更多表现为良性使用模式长期累积带来的暴露，而不是突然发生的灾难性事件。
这符合企业现场的真实逻辑。
员工不是不知道企业有流程，而是正式流程太慢。一个 AI 工具打开网页就能用，一个内部工具申请可能要走审批、采购、权限、部署、培训。员工不是不知道数据有风险，而是很多时候不知道哪些内容不能输入模型，也不知道“让 AI 总结一下”会产生怎样的数据流。管理层一边鼓励拥抱 AI，一边没有给出清楚边界，员工收到的信号自然是：可以试，但别出事。
更复杂的是，很多 AI 能力并不是员工主动安装的，而是供应商通过软件更新“带进来”的。
办公软件里突然有了 AI，总结会议、改写文档、生成邮件；浏览器里有了 AI，搜索时自动总结网页；开发工具里有了 AI，代码补全和解释默认可用；协同平台里有了 AI，文档和聊天内容可以被调用分析。
这类场景尤其难管。
因为从资产角度看，软件是批准过的；从功能角度看，能力已经变了。过去安全评估的是办公软件、协同平台或 IDE，现在实际运行的是一个带大模型能力的数据处理和内容生成系统。
这就是论文说的“批准技术中的未评估能力扩张”。
企业以为自己批准的是一个工具，实际上员工已经获得了一种新的推理、总结、改写、聚合和生成能力。
影子 AI 真正侵蚀的是“可证明安全”
这篇论文最重要的概念，不是 Shadow AI 本身，而是 Assurance Erosion。
这个词可以翻译为“保障能力侵蚀”或“可证明安全能力侵蚀”。
在普通安全语境里，我们经常问：有没有攻击？有没有泄露？有没有违规？有没有事故？
但在关键基础设施场景里，还要问一个更底层的问题：组织能不能证明自己做到了安全？能不能证明哪些系统受控，哪些数据受控，哪些决策受控，哪些行为可审计，哪些责任可追溯？
影子 AI 对组织最大的破坏，就是让这些证明链条变薄、变断、变模糊。
员工用 AI 总结了一份内部材料，组织可能不知道。员工用 AI 改写了一段监管答复，组织可能不知道。开发者用 AI 生成了一段脚本，组织可能不知道。管理员把日志贴给模型分析问题，组织可能不知道。AI 输出经过人工修改后进入正式文档，组织更难知道。
每一次看起来都不严重。
但长期累积之后，企业会越来越难回答几个问题：
哪些内部数据被 AI 处理过？哪些工作产物受 AI 影响？哪些模型输出经过验证？哪些 AI 工具具备外部数据传输能力？哪些 AI 生成内容进入了正式决策？出了问题之后，证据链在哪里？
论文图 2 用一条路径把这个过程讲得非常清楚：组织中的生产力压力、低门槛 AI 访问、高层试验信号、基础设施碎片化、AI 素养不足和治理滞后，会推动员工形成写作总结、信息检索、代码辅助、文档表格分析、本地 RAG 和自下而上实验等影子 AI 实践；这些实践再通过边界绕过、未评估能力扩张、可观测性丧失，带来数据边界、访问控制、决策完整性、可见性和问责方面的影响，最终造成关键基础设施环境中的保障能力侵蚀。
三条失控路径
论文把影子 AI 对关键基础设施的威胁归纳为三条主路径。
第一条是边界绕过。
这也是最容易理解的一类。员工使用公共 AI 工具，把文档、代码、日志、表格、会议纪要或内部问题描述输入到组织批准系统之外。数据流离开了企业可控边界，安全团队无法完整记录，DLP 不一定能识别，审计系统也不一定留下证据。
这类风险不是只有“泄露客户数据”才严重。对于关键基础设施来说，设备状态、系统架构、缺陷描述、巡检记录、供应链依赖、维护计划，都可能是高敏感运营信息。
第二条是未评估能力扩张。
这类风险更隐蔽。员工使用的可能是企业批准的软件，但软件里的 AI 能力没有被重新评估。原来一个普通文档工具，只是存储和编辑文档；加入 AI 后，它可以总结、推理、生成、归纳、改写，甚至跨文档聚合信息。原来一个开发工具，只是本地编辑代码；加入 AI 后，它可能把上下文、错误信息、代码片段送到外部服务。
软件名称没变，供应商没变，采购合同可能也没变，但风险属性已经变了。
这就是很多企业 AI 治理最容易漏掉的地方：安全评估停留在工具层，风险变化发生在能力层。
第三条是可观测性丧失。
当员工使用个人设备、个人账号、本地模型、轻量脚本、浏览器插件、非正式 API 或自己搭建的小工具时，组织不仅看不到数据流，也看不到 AI 参与了哪些产物。
更麻烦的是，高权限角色也可能参与其中。
如果普通员工把一份不敏感文案交给 AI，风险相对有限；但如果拥有系统访问权限的管理员、开发者、架构师把运维信息、配置细节、日志片段、内部代码交给 AI，风险边界就会扩大。论文也提到，部分受访组织观察到拥有提升权限的管理员也在进行非正式 AI 使用。
从安全治理角度看，这会削弱最小权限原则。
因为 AI 工具本身没有经过组织授权，却间接接触了只有高权限人员才能看到的信息。
“全部封掉”不是最佳答案
面对影子 AI，很多人的第一反应是：那就封掉。
从安全视角看，这个反应很自然。未经批准的公共 AI 工具，确实可能带来数据外发、合规风险、供应链依赖和不可审计问题。论文也提到，一些组织采取了禁止式控制，包括阻断未批准工具、选择性封禁特定 AI 服务，或者在批准替代工具上线后继续限制公共工具。
但论文中的组织并没有统一走向“全面封禁”。更常见的做法，是把监测、教育、行为引导和批准替代工具结合起来。部分受访者明确认为，与其单纯阻断，不如监控、理解、教育和响应。论文还提到，一些组织会通过提示页面、行为提醒、禁用高风险功能、引导员工使用企业批准工具等方式，降低影子 AI 风险。
这背后的逻辑很简单。
如果企业只是封锁公共 AI 网站，员工可能换成个人设备、手机、家庭网络、截图、复制粘贴、浏览器插件。使用行为并不会消失，只是从企业“部分可见”变成“完全不可见”。
对于关键基础设施组织来说，完全不可见往往比有限可见更危险。
所以，影子 AI 治理不能只靠封禁。封禁可以是高风险场景下的手段，但不能成为唯一策略。
真正合理的方向，是把员工对 AI 的需求纳入正式治理框架：提供可用的企业级 AI 工具，明确哪些数据可以用、哪些数据不能用，建立 AI 使用台账和审计机制，对高风险功能做权限控制，对模型输出进入正式流程设置验证要求。
也就是说，企业不是要假装员工不会用 AI，而是要承认员工已经在用 AI，然后把它从影子里拉回治理边界内。
对企业 AI 安全的启发：从“管模型”转向“管工作流”
这篇论文对国内企业同样有启发。
现在很多企业已经意识到不能随便把客户数据、源代码、合同、财务信息输入公共大模型。但真正的问题是，企业往往只停留在口头规定上，很少能建立完整的执行链条。
员工到底用了哪些 AI 工具？哪些工具是批准的，哪些是个人使用的？哪些 AI 功能是供应商后来新增的？哪些内部文档被模型处理过？哪些 AI 生成内容进入了正式报告？哪些代码由 AI 辅助生成？哪些模型输出影响了业务判断？这些问题如果回答不上来，企业就谈不上真正的 AI 安全治理。
过去企业安全更关注“系统边界”。比如哪些服务器上线，哪些应用开放，哪些账号有权限，哪些数据出境。
但 AI 时代还要关注“认知边界”和“工作流边界”。
AI 不一定直接访问数据库，但员工可以把数据库导出的表格贴给它。AI 不一定直接连接生产系统，但管理员可以把生产日志复制给它。AI 不一定直接写监管报告，但员工可以让它改写一版。AI 不一定进入代码仓库，但开发者可以把它生成的代码复制进去。
这意味着，企业要治理的不是单个模型，而是 AI 介入组织工作的全过程。
更具体地说，企业至少需要建立几类能力。
第一，要有 AI 资产和 AI 使用发现能力。企业需要知道员工访问了哪些公共 AI 服务，内部有哪些系统嵌入了 AI 功能，哪些 SaaS 工具新增了 AI 能力，哪些开发工具和办公工具可能发生数据外传。
第二，要有数据分级和输入约束能力。不是所有内容都不能输入 AI，也不是所有内容都可以输入 AI。企业需要把客户数据、源代码、运营敏感信息、关键基础设施信息、监管材料、合同文本等纳入分级规则，并把规则落到实际工具里。
第三，要有企业级 AI 入口。员工想用 AI 提效是客观需求。如果企业不提供安全可用的替代方案，影子 AI 就会继续存在。企业级 AI 入口可以是内部模型服务、企业版大模型、AI 网关、受控 RAG 系统或受控代码助手，但核心是可审计、可管控、可追责。
第四，要有 AI 输出进入正式流程的验证机制。模型生成的总结、代码、报告、分析结论，不能因为“看起来很专业”就直接进入正式流程。关键场景下，企业要明确人工复核、来源标记、引用检查、安全扫描和审批要求。
第五，要有面向员工的 AI 使用教育。影子 AI 很多时候不是恶意违规，而是边界不清。企业需要用简单明确的方式告诉员工：哪些内容不能输入公共 AI，哪些场景必须使用企业批准工具，哪些输出不能直接用于正式决策。
这些能力组合起来，才是 AI 时代真正的企业安全治理。
影子 AI 也会改变安全产品的边界
从安全产品角度看，影子 AI 是一个很重要的信号。
过去做大模型安全，很多产品关注模型输入输出内容安全，比如敏感问题拦截、越狱攻击检测、违规内容过滤、幻觉检测、提示注入防护。这些能力依然重要，但它们主要解决的是“模型交互本身是否安全”。
影子 AI 提出的新问题是：企业怎么发现和治理那些不在正式系统里的 AI 使用？
这会把 AI 安全产品的边界向前、向外扩展。
向前，是要在员工使用 AI 之前，就做工具准入、数据分级、策略提示和权限控制。
向外，是要覆盖浏览器、办公软件、开发环境、SaaS、终端、网关、DLP、CASB、企业知识库、代码仓库和内部协同平台。
一个成熟的影子 AI 治理产品，可能不只是“大模型安全护栏”，还需要具备 AI 使用发现、敏感数据识别、外部模型访问控制、企业 AI 网关、行为审计、风险画像、合规报表、员工提醒、审批流集成等能力。
尤其在关键基础设施、金融、政务、能源、运营商、医疗等行业，AI 安全的重点会逐步从“这个模型会不会说错话”，扩展到“这个组织能不能证明 AI 使用是受控的”。
这背后其实是一种治理范式变化。
模型安全关注的是模型。
应用安全关注的是系统。
影子 AI 治理关注的是组织。
写在最后
影子 AI 之所以值得重视，是因为它不是一个边缘问题。
它很可能已经存在于大多数企业里，只是没有被系统性命名。
员工用 AI 写材料，开发者用 AI 写代码，管理员用 AI 分析日志，管理者用 AI 准备汇报，业务人员用 AI 总结表格。这些行为本身未必错误，甚至很多时候是组织效率提升的真实来源。
真正的问题是，AI 已经介入组织运行，而组织还没有建立对应的可见性、控制力和审计能力。
对于关键基础设施来说，这种状态尤其危险。因为关键基础设施的安全，不只是把系统守住，还要能证明系统始终处在可治理、可审计、可追责的状态。
影子 AI 的风险，不是员工使用了一个新工具。
它的风险在于，企业正在把越来越多的知识生产、代码生成、材料撰写和判断过程，交给一个自己看不见、管不住、审不清的外部能力。
AI 安全的下一阶段，不只是防模型作恶，也不是简单禁止员工使用 AI。
更重要的是，把那些已经进入日常工作、却没有进入治理视野的 AI 使用，重新拉回光里。
声明：本文来自模安局，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
