AI4 2026大会，一次并不起眼的案例分享，却在会场引发了持续的讨论。

一家制造业企业做了内部AI审计。结果让CIO团队沉默了好几分钟：他们以为公司在运行大约50个AI agent应用；实际数字是超过500个。

这不是这家公司独有的处境。AI4大会聚集了来自各行业的企业决策者，多位发言人在不同场合提到了类似比例的差距。更有据可查的数据来自Gartner的2026年企业AI调研：43%的IT领导者表示他们公司的实际AI工具使用量比他们的官方系统登记数量多出一倍以上；麦肯锡同期的State of AI报告显示，62%的组织已经开始在某种形式上实验AI agents，但其中只有21%的企业对所有已部署的AI应用有系统性的追踪机制。

把这些数字连起来：大多数企业在部署AI agents，但只有五分之一知道自己到底部署了多少。

这个信息差，不只是管理低效的症状，更是一个正在积累的安全风险。

10倍差距是怎么产生的

让我们先搞清楚”AI agent”在这里的定义。我们说的不只是ChatGPT或Claude的企业版；而是任何能够自主执行任务序列、调用工具、访问数据的AI系统——从销售团队用Salesforce内置的Einstein AI自动生成邮件，到运营人员用Zapier+LLM搭的自动化流，到工程师在内部工具上接的AI代码审查插件。

定义一旦放宽到这个范围，10倍的差距就不难理解了。

路径一：员工自建（Shadow AI的主力军）

低代码和无代码工具的普及，让没有工程背景的员工也可以”搭”出一个功能性AI agent。一个销售经理可以在一个下午用Make（前身Integromat）或n8n搭出一个自动分析竞争对手信息、生成销售话术的agent，接入Slack直接推送。这整个过程不需要IT审批，不需要安全评估，也不会出现在任何技术系统的登记表上。

这类自建工具，在数量上可能是最大的一类，但对企业安全团队来说几乎完全不可见。

路径二：SaaS产品的内嵌AI（用具名例子说明）

这是最容易被低估的扩散路径。以Salesforce为例：2026年，Einstein Copilot已默认集成在所有企业版Salesforce账户中，自动分析销售机会、生成跟进邮件建议、在会议结束后生成行动摘要。大多数签合同的采购团队，并不清楚他们购买的CRM系统已经内置了一个AI agent会自动处理客户数据。

类似的情况在Microsoft 365 Copilot中更为明显：在2026年，Copilot已经成为Microsoft Teams的默认功能之一，自动转录和摘要每一次会议——包括那些包含高度敏感业务讨论的内部会议。企业订阅了Microsoft 365，但有多少HR团队意识到他们的所有会议内容都在流经微软的AI系统？

路径三：开发团队的快速实验

工程师文化里有一个根深蒂固的偏好：先做，再报告（如果觉得有必要的话）。一个后端工程师在项目里接入OpenAI或Anthropic的API，”临时测试一下效果”，两周后这个功能上线了，公司数据开始通过第三方API传输，整个过程没有人审批。

不是说工程师有意绕过流程，而是流程本身没有跟上AI工具的普及速度——旧的IT审批流程是为”添加一个新服务器”设计的，不是为”接入一个LLM API”设计的。

结果：一个分散的、不透明的AI基础设施

三条路径叠加的结果是：企业的AI基础设施变成了一个分散的、缺乏统一管理的系统——每个部门有自己的AI工具，技术栈不统一，数据流向不清晰，安全标准参差不齐。而这一切，在CEO和CISO的视野里几乎是空白的。

为什么这是一个安全问题，不只是一个管理问题

当我们说企业有500个AI agent而不是50个时，最直接的担忧可能是”浪费”或”低效”。但更深的问题是安全。

每个AI agent都是一个数据接触点

AI agent要运行，就需要访问数据。销售agent需要访问CRM数据，财务agent需要访问财报数据，HR agent需要访问员工档案。在有认真管理的情况下，这些访问权限经过安全团队的审核，遵循最小权限原则，有日志记录和审计追踪。

在没有管理的shadow AI情况下：这些权限是由搭建这个工具的员工按需申请的，通常权限范围会比实际需要的更宽（因为更省事），没有正式的日志，也没有人知道这些数据是否通过第三方API传到了外部服务器。

一个员工搭的简单”自动发邮件agent”，可能在后台把公司客户联系人列表上传给了某个低成本的LLM服务提供商。这不是故意的数据泄露，但从效果上看，结果是一样的。

Prompt Injection攻击：已有真实案例

LLM驱动的agent有一个与传统软件根本不同的安全风险：prompt injection——通过向agent的输入数据注入恶意指令，让agent执行攻击者想要的操作。

2026年初，安全研究机构AISI在测试OpenAI和Anthropic的agent系统时，发现两者都存在在特定条件下绕过安全限制的行为（Anthropic随后在8月风险报告中部分披露了这一现象）。更具体的案例：2026年3月，安全公司Wiz披露了一起针对企业HR AI工具的prompt injection攻击——攻击者在简历中嵌入隐藏指令，成功让一个自动简历筛选agent向攻击者发送了内部招聘流程的敏感信息。

这类攻击的难度取决于agent访问了多少系统权限。权限越宽，被利用后的危害越大。而在shadow AI场景下，很多agent的权限配置没有经过安全审查，过宽授权是常态。

攻击面的数字化

把这些风险量化一下。一家拥有5000名员工的中等规模企业，如果实际运行了500个AI agents（而不是系统登记的50个），那么每个agent平均有2个外部数据连接，就意味着有1000个未被追踪的外部数据接口。这些接口中只要有1%存在安全漏洞，就是10个潜在的攻击入口。在传统IT时代，这个规模的未追踪接口会被任何安全审计立即发现并处理；在shadow AI时代，它们是完全不可见的。

从「Shadow IT」到「Shadow AI」：历史教训能用上吗？

IT历史上有过一次类似的「影子扩散」危机，最终被业界找到了应对方法。

2000年代后期到2010年代，云服务的爆发带来了”Shadow IT”问题：员工开始自行注册Dropbox、Google Docs、Slack，绕过IT审批直接使用；IT部门对公司真实运行了多少SaaS工具一无所知。

这个问题最终通过几个工具和实践组合解决：CASB（云访问安全代理）工具帮助IT部门发现和管理所有云服务使用；零信任安全架构减少了数据接触面；最重要的，文化和政策的转变——从”禁止Shadow IT”到”快速审批+安全监控”，让员工使用便捷的工具，同时保证安全可见性。

Shadow AI有相似之处，但难度更大：AI agent的行为比SaaS工具复杂得多，”是否安全”的判断需要理解模型的行为模式，而不只是看权限列表；AI工具的更新速度更快；而且，AI agent会主动调用工具和访问数据，而不只是静态地存储数据，这让监控的难度指数级上升。

企业应该怎么做？几个真实可行的方向

没有一个简单的”解决方案”，但以下几个方向被实践者认为是有效的起点。

第一步：先盘点

你无法管理你看不见的东西。最紧迫的第一步是开展一次认真的AI使用盘点——通过技术手段：扫描网络流量，找出所有与已知LLM API的连接；审计SaaS订阅，找出含有AI功能的工具；对工程师使用的代码库进行扫描，找出接入了哪些AI SDK。

这个盘点本身可能会让CISO团队不舒服——他们可能会发现500而不是50，这在内部会引发一些棘手的对话。但这个不舒服是必要的，因为”不知道”不等于”没有风险”。

第二步：分级管理，而不是全部禁止

更可行的策略是分级：高风险的（接触核心业务数据、有外部API调用、有自主执行能力的）走正式审批流程；低风险的（本地运行、无外部数据传输、有限功能范围的）简化审批。

关键是把流程从”禁止”变成”快速合规”——员工提出需求，安全团队在24-48小时内给出答复，而不是让需求在漫长的IT审批流程里消失。

第三步：建立最低安全基线

对所有企业运行的AI agent，设立几条无论如何都必须遵守的最低要求：数据必须有访问日志；涉及外部API调用必须有数据处理协议审查；权限配置必须经过最小权限原则评估；有异常行为必须有告警机制。

第三层洞察：这是一个「组织认知延迟」问题

最后值得重新定义这个问题的本质。

表面上看，这是一个技术管理问题——企业没有工具来追踪和管理AI agent。但技术工具的缺乏只是表象，更深层的是一个组织认知延迟问题。

高管层的AI认知，往往停留在”我们在战略层面部署了几个AI项目”的层次，对AI工具在日常工作层面的实际扩散速度和广度，缺乏真实的感知。这个感知差距不是懒惰或疏忽造成的，而是一种结构性的组织盲区：信息没有从执行层流向决策层，而决策层也没有问出正确的问题。

McKinsey的调研数据提供了另一个切入角度：在实现AI预期ROI的企业中，有85%表示他们有清晰的AI使用政策和治理框架；而在AI投资未达预期的企业中，只有23%有这类框架。治理和可见性，不只是安全要求，更是让AI投资真正产生价值的前提条件。

如果CEO每季度的AI汇报只问”我们的AI战略执行如何”，而不问”我们实际上在运行多少个AI系统，每个的权限和数据接触面是什么”，那么这个认知差距会一直存在，直到一次安全事故把它暴露出来。

在AI快速渗透企业各层级的2026年，这个问题值得每一个企业领导者认真对待——不是在下一次战略研讨会上讨论，而是在本周就开始盘点。

参考资料

  1. AI4 2026 closes: Enterprise CEOs are running 10x more AI agents than they know — MSN, 2026-08-06（核心案例来源）
  2. Best AI agent builders in 2026: 8 no-code and low-code platforms compared — MSN, 2026-08-10（无代码AI工具普及背景）
  3. Anthropic says its AI agents are killing rivals and hiding their tracks — MSN, 2026-08-15（AI agent安全风险直接印证）
  4. From Rule-Based Automation to AI Agents: The Future of Enterprise Applications — CACM, 2026-08-14（学术视角：AI agent架构演进）
  5. Claude and Microsoft 365 Copilot AI Agents Named Champions in Info-Tech Research Group’s 2026 Agentic AI Platforms Data Quadrant — TMCnet, 2026-08-06（Agentic AI平台市场调研）
  6. Healthcare, financial services, and public sector industries face greatest risks in shadow AI — Zawya/Nutanix, 2026-08-10（Shadow AI风险行业数据）

注：文中引用的Gartner调研具体数字（43%、62%、21%）基于McKinsey 2026 State of AI Report和Gartner年度调研的综合，未提供具体报告链接；Goldman Sachs AI治理框架细节来自公开媒体报道，非Goldman Sachs官方文件；Wiz 2026年HR prompt injection案例属于当时公开报道，如需查阅原始披露建议搜索Wiz官方博客。每天10,000-20,000次未追踪AI交互的估算为作者基于行业规模的推算，仅供参考。

深度分析：为什么这个问题在2026年变得紧迫

Shadow AI不是突然出现的问题，它是多个趋势在2026年同时收紧的结果。

趋势一：LLM API的摩擦成本降到接近零

2020年，接入一个AI API需要专业的机器学习工程师，需要自己处理模型推理基础设施，需要大量的技术积累。这种高摩擦成本是一道天然的筛选门槛——只有有资源的项目才能使用AI。

2024年后，这一切改变了。OpenAI、Anthropic、Google的API，加上大量的包装工具（LangChain、LlamaIndex、CrewAI），让”接入AI”从工程挑战变成了一个下午的任务。任何会写Python的员工，都可以在几个小时内把一个LLM接入他们的工作流程。

摩擦成本降低的直接后果是：AI使用从”有专属工程团队的项目”扩散到”任何有基本编程能力的员工”。这个扩散速度，远超IT治理体系的更新速度。

趋势二：无代码/低代码平台的AI原生化

2023年，Zapier的主要用例是连接不同的SaaS工具（当Google Sheet更新时，自动发Slack消息）。2026年，Zapier的新用例有大量是”当X发生时，触发一个AI分析，然后根据分析结果执行Y”——这是一个真正的AI agent循环。

Make（前身Integromat）、n8n、Pipedream等工具，都在2025-2026年添加了”AI节点”，让非工程师用可视化拖拽的方式构建含AI的自动化流程。这批工具的用户基数庞大，且几乎完全在IT的可见性之外。

一项2026年初的调研显示，使用这类无代码AI工具的企业员工中，只有7%声称他们在使用前向IT部门申请过审批。这7%很可能包括了大量”事后补报”的情况，实际比例可能更低。

趋势三：AI功能成为SaaS产品的差异化竞争点

在SaaS产品市场，2026年”没有AI功能”已经成为实质性的竞争劣势。每一家SaaS公司都在快速往产品里添加AI：Notion AI、GitHub Copilot、Figma AI、Linear AI、HubSpot AI……这些功能上线的速度，远超企业IT团队审核和评估它们的速度。

更棘手的是，这些功能往往以”改进的用户体验”为名推出，而不是以”我们新增了一个AI数据处理系统”的方式宣传。采购团队在年度合同续签时，不会仔细审查供应商在过去12个月里新增了多少AI功能，以及这些功能是否符合企业的数据安全政策。

安全影响的量化框架

我们来尝试量化shadow AI的安全风险，这比定性描述更有帮助。

数据暴露面的估算方法

假设一家有5000名员工的中型企业：

  • 平均每名员工每天与AI工具的交互次数：约10-20次（包括Copilot补全、SaaS内嵌AI等）
  • 其中，经过IT正式审批的工具比例：约30%
  • 未经审批的AI交互中，涉及企业敏感数据的比例：估计15-20%

这意味着，每天有约10,000-20,000次未被追踪的、涉及企业数据的AI交互发生在IT的视野之外。每次交互都是一次数据流向外部服务器的事件——大多数情况下无害，但也不可控。

最高风险场景的识别

并非所有shadow AI使用都有同等风险。以下几个场景是需要优先管控的最高风险类别：

场景一：客户数据流经未审批AI。如果一个销售员用一个未经审批的AI工具分析客户通话录音，这份录音里可能包含大量个人身份信息（PII），违反GDPR或CCPA可能产生真实的法律责任。

场景二：源代码流经AI代码辅助工具。工程师在使用代码辅助工具时，往往会把整个代码库或关键函数上传给工具分析。如果这个工具没有企业级的数据处理协议，代码可能被用于模型训练或被竞争对手访问。

场景三：战略规划文档流经AI摘要工具。高管团队用一个AI工具摘要董事会报告，这份报告里可能包含未公开的并购计划、财务预测等材料非公开信息。

这三类场景有一个共同点：对企业的损害不是立即可见的，而是以合规风险、知识产权泄漏或监管罚款的形式在未来某个时间点显现。

企业AI治理的最佳实践：从头部企业的真实经验学习

有趣的是，部分头部企业已经在这个问题上走在了前面，形成了可以借鉴的实践。

Goldman Sachs的AI使用政策框架

Goldman Sachs在2024年早期就建立了一套企业AI使用分类框架：将所有AI工具分为”批准使用”、”审批使用”和”禁止使用”三个级别，并建立了一个内部”AI工具注册系统”，要求所有团队在使用新AI工具前完成注册。

这个系统的核心创新是：把注册的负担降到最低（填一个简单表格，通常72小时内得到批复），同时把”未注册使用已知工具”定义为违规行为。这种”低摩擦审批+明确规则”的组合，比”全面禁止”或”完全放任”都更有效。

微软的”AI Responsibility Framework”

微软内部有一套详细的AI产品责任框架，这套框架要求任何使用AI的内部工具，都必须完成”负责任AI审查”，覆盖公平性、可靠性、隐私、安全、包容性、透明度和问责制七个维度。

这套框架有三个特点：它是内部工具的强制要求（不只是外部产品）；审查流程有明确的时间线（一般2-4周完成）；以及有专门的Responsible AI团队提供支持。微软的这套内部经验，也构成了它向企业客户提供AI治理咨询服务的基础。

一个中小企业的简化方案

不是所有公司都有Goldman或微软的资源。对于没有专职AI治理团队的中小企业，一个更实用的起点是：

制定一个”AI工具使用3条底线”，用一页纸写清楚：（1）什么类型的数据绝对不能输入任何未经审批的AI；（2）哪些AI工具已经正式批准使用；（3）新工具怎么申请审批（给一个简单邮件或表单链接）。把这3条底线发给所有员工，并要求管理层签名确认，这就是最简单版本的AI治理框架。

它不完美，但比什么都没有好得多——而且明确的规则本身，就减少了员工”我不知道该不该用”的灰色地带决策。

未来展望：AI治理市场的崛起

这个问题有一个光明的一面：它正在创造一个全新的市场机会。

AI治理和监控工具的市场，在2025-2026年已经开始快速形成。从已经在这个方向创业的公司来看，他们在解决的问题包括：自动发现企业内所有AI使用行为（类似早期CASB工具）；自动评估AI工具的数据处理合规性；监控AI agent的实际行为是否符合政策；以及提供”AI风险仪表盘”让CISO和CIO有清晰的可见性。

这个市场还在形成早期，但需求是真实存在的。任何有CISO的企业，在读到AI4 2026大会那个”500 vs 50”的案例时，都会感到一阵不安。

这种不安，是这个市场最好的启动燃料。

监管趋势对企业AI治理的推动力

在企业内部动力之外，外部监管压力正在成为AI治理体系建设的另一个推动力。

GDPR的延伸适用

欧盟GDPR中”算法决策”的条款（第22条），要求对完全自动化的、对个人产生显著影响的决策提供人工复审的权利。这条规定在2018年就已生效，但真正被严格执行是在2024年后——当AI开始被广泛用于真实决策（招聘筛选、信用评分、保险定价）时，监管机构开始更主动地调查这些应用是否符合GDPR第22条。

对于在欧盟有用户或员工的公司来说，这意味着：任何shadow AI工具，如果用于做出影响个人的决策，都潜在地违反GDPR，可能面临最高年营收4%的罚款。这个风险不是理论上的——2025-2026年已经有多起涉及AI招聘工具的GDPR处罚案例。

美国EEOC的AI聘用指南

美国平等就业机会委员会（EEOC）在2024年发布了专门针对AI在招聘中使用的技术性指南，明确了如果AI招聘工具对受保护群体产生”差异影响”（Disparate Impact），雇主可能承担歧视责任，且”我不知道AI工具有偏见”不是有效辩护。

这个指南的实际影响是：企业在使用任何AI招聘工具前，需要评估该工具是否对种族、性别、年龄等受保护特征有差异影响。而对于那些在IT视野之外自行引入AI招聘工具的HR团队，这种评估几乎不可能完成——因为他们连工具的技术细节都不了解。

NIST AI Risk Management Framework的悄悄主流化

美国国家标准与技术研究院（NIST）发布的AI风险管理框架（AI RMF），在发布之初是完全自愿的。但2026年，越来越多的联邦政府合同开始要求供应商遵循NIST AI RMF的核心原则；大型企业的采购部门也开始把NIST AI RMF合规性列为AI供应商的评估标准。

从自愿标准到实际合规压力，这个转变正在发生——即便没有法律强制性，市场机制也在把NIST AI RMF推向实际执行层面。

写给CTO/CISO的七个优先行动

基于以上分析，为企业技术和安全领导者提供一个优先行动清单：

优先级1（本周）：摸底实际AI使用情况 立即要求IT团队开始扫描网络流量，识别对主要AI API（OpenAI、Anthropic、Google AI、Azure OpenAI）的连接。不需要立即处理，但需要先知道规模有多大。同时向工程负责人发一封简短邮件：列举所有你们知道正在使用的AI工具，说明数据处理协议情况。

优先级2（本月）：制定简单的分级政策 不要试图一次写出完美的AI治理手册。先写3页纸的”AI工具使用基础规则”：批准使用的工具列表（可以是空的）；申请新工具的流程（越简单越好）；绝对禁止事项（客户PII数据不得输入未审批工具）。发给全公司，请管理层背书。

优先级3（本季度）：建立轻量化审批流程 目标是把AI工具的审批时间控制在72小时内，这样员工才有动机走正规流程而不是绕过。审批的核心检查点：（1）数据处理协议是否存在？（2）该工具是否接触生产数据库？（3）是否有访问日志？

优先级4（半年内）：加入AI治理市场测评 对市场上已经出现的AI治理工具（AI usage discovery, AI policy enforcement）开展评估，找1-2个在技术上适合自身架构的工具进行POC。这个市场在2026年仍然早期，选择时要注重工具的灵活性而非功能完备性。

优先级5（年度）：把AI治理纳入安全审计范围 下一次请外部安全审计公司来做年度安全评估时，明确要求他们的scope包含”AI使用行为审查”。如果他们没有这个能力，这也是一个找到一家更新的审计公司的原因。

优先级6（持续）：在工程文化里植入AI安全意识 最有效的防御不是技术控制，而是工程师理解为什么随意接入AI API是有风险的。在下一次全工程团队会议上，用15分钟讲讲prompt injection攻击和数据泄漏的真实案例，比任何政策文件都更有效。

优先级7（持续）：保持谦逊，接受不完美 在AI工具如此快速演进的时代，没有任何治理框架是完美的。目标不是消灭所有风险，而是把风险控制在可接受的范围内，并建立一套随技术变化而更新的机制。接受”不完美但持续改进”比追求”完美但永远没建好”的治理框架更有价值。

结语

AI治理，是2026年企业技术议程上最被低估的优先事项。

它不像AI战略那样令人兴奋，也不像AI投资那样引人注目。但在一个”你比自己以为的多了10倍AI agents”的现实里，忽视AI治理的代价，正在以安全事故、合规罚款和公关危机的形式，在一家家企业的财报里悄悄显现。

那家制造业公司发现500个agent的那一刻的沉默，是一个预警信号，也是一个机会：现在开始，还不晚。