Thales 发现：企业对 AI 风险的担忧超过了熟悉的网络威胁

Thales 发现了一个显著的逆转：69% 的受访组织将快速变化的 AI 生态系统列为其最主要的生成式 AI 安全担忧。恶意软件、网络钓鱼和勒索软件等熟悉威胁仍然活跃，但企业如今面对的是一个由自身部署的系统。

这一发现并不意味着 AI 已经造成了比勒索软件或恶意软件更多的数据泄露。它表明，企业对 AI 采用过程中不确定性的担忧，超过了对任何单一既有攻击类型的担忧。安全团队了解网络钓鱼的防护措施，但对于能够访问数据、生成代码并触发业务操作的系统，他们信心较低。

这一区别很重要，因为 AI 风险跨越了多项既有边界。它结合了网络安全、隐私、法律风险、模型可靠性和运营控制。核心冲突不再是采用 AI 与抵制 AI 之间的对立，而是业务部署速度与组织治理已安装系统能力之间的较量。

调查揭示企业担忧的转变

企业并非用 AI 取代对旧有网络威胁的担忧，而是认识到 AI 可以同时放大多种风险。

这份数据威胁报告调查了来自 20 个国家和 15 个行业的逾 3,100 名技术与安全专业人士。S&P Global Market Intelligence 451 Research 为 Thales 开展了这项研究。

在受访者中，69% 将快速变化的 AI 生态系统列为与生成式 AI 相关的首要安全担忧。模型完整性以 64% 紧随其后，而可信度以 57% 排名第三。

“快速变化的生态系统”这一说法涵盖的不只是模型发布，还包括模型提供商、插件、数据服务、开发框架、智能体，以及连接这些组件的基础设施。每个组件都可能独立变化，形成一条安全团队无法完全控制的依赖链。

这不同于熟悉的恶意软件事件。安全团队可以识别恶意文件、隔离终端并调查其传播路径。AI 系统则可能在不携带恶意软件、也不显示传统入侵指标的情况下出现错误行为。

模型可能因用户将机密信息输入未经批准的服务而泄露信息。智能体可能检索超出请求者预期范围的数据。AI 生成的代码可能引入存在漏洞的依赖项，却不会立即触发警报。

这些结果可能看似普通的网络安全故障。然而，其原因往往位于传统安全运营中心之外。采购、法务、工程、数据科学、合规和业务团队都会影响该系统。

调查还发现，73% 的受访者正在投资 AI 专用安全工具。一些人获得了新增预算，另一些人则重新分配了现有安全支出。这一数据证实，担忧已进入采购和规划决策。

但额外的软件并不能自动解决职责不清的问题。监控产品无法决定某个智能体应当访问哪些业务数据，也无法为每位客户、员工或受监管流程定义可接受的模型行为。

在同一项研究中，传统攻击类别依然突出。恶意软件在已观察到的攻击类型中居首，网络钓鱼升至第二位，勒索软件排名第三。

这一背景限制了标题的含义。AI 是围绕生成式 AI 采用的最大新兴担忧，并非既有威胁已经消失的证据。企业必须保护两个相互重叠的环境，而不是在两者之间二选一。

这种转变仍然重要。安全领导者如今将 AI 视为企业风险领域，而不只是另一个需要终端保护的应用程序。其故障可能源自获批工作流内部，并通过受信任的访问权限扩散。

为什么 AI 安全风险会逃脱熟悉的控制措施

AI 将风险单位从可预测的应用程序转变为能够理解指令并选择行动的系统。

传统企业应用通常提供定义明确的功能。用户输入结构化数据、选择被允许的操作，并获得边界明确的结果。安全团队可以将这些功能映射到身份、权限、数据库和审计记录。

生成式 AI 接受开放式指令。其输出取决于提示词、检索到的信息、模型行为、系统配置和连接的工具。这条链中的任何细微变化都可能产生不同的结果。

AI 智能体又增加了一层复杂性。智能体是利用模型规划任务、并在有限人工干预下调用工具的软件。这些工具可以包括电子邮件、代码仓库、客户数据库、日历和财务系统。

这种架构带来了边界防御原本并非为之设计的风险。合法员工可以通过获批界面发出存在风险的指令，模型随后可能以非预期方式使用已获授权的连接。

提示词注入说明了这一问题。恶意指令可以出现在 AI 系统处理的文档、网页或消息中。这类指令试图让模型偏离其预定任务。

当智能体已经拥有访问权限时，无需窃取密码。攻击者转而瞄准模型的理解层，这使普通业务内容成为潜在的控制通道。

数据检索带来了类似挑战。检索增强生成使模型能够在生成回答时使用选定的组织信息，模型无需在原始训练数据中包含这些信息。

不过，检索质量取决于权限和元数据。如果搜索索引忽略文档级访问规则，就可能暴露用户本不能直接打开的材料。回答可能会用自然语言掩盖这一访问失败。

这对基于合同、会议记录、支持工单或工程文档构建内部助手的企业很重要。一个有用的助手需要广泛的上下文，而每增加一个来源，薄弱权限造成的后果也会增加。

员工还会通过影子 AI 造成另一种风险暴露，也就是在未经组织批准或监督的情况下使用 AI 服务。员工可能为了节省时间，将源代码、客户记录或业务计划粘贴到公共工具中。

仅靠政策很难控制这种行为。员工往往将 AI 聊天框视作临时工作空间，而非外部数据处理方。与向未知网站上传文件相比，这种界面给人的风险感更低。

这项AI 监督发现引用的一项调查显示，78% 的员工表示曾在工作中使用 AI 工具。在这一群体中，58% 承认曾向大语言模型提供敏感的公司信息。

自报数据并不能衡量已确认的数据损失，但它们仍表明，AI 风险始于获得授权的用户，而不仅是外部攻击者。由于工具很容易获得，采用速度可能超过正式审查。

这一挑战还延伸到软件开发领域。AI 助手提出代码的速度可能快于团队审查的速度。生成的函数可能在测试中正常运行，却包含不安全的默认设置、薄弱的验证机制或过时的依赖项。

安全扫描器可以捕捉已知模式，但不能保证生成的逻辑符合业务要求。人工审查仍然必不可少，尤其是在代码处理身份验证、支付或受监管信息时。

模型输出还会带来完整性风险。系统可能以极高信心生成错误内容，这种行为通常被称为幻觉。当另一个应用程序将其视为已验证输入时，结果便会变得危险。

错误的摘要只是造成不便。错误的访问决策或财务指令则会带来运营后果。相同的模型行为会因其周围工具和权限不同而承载不同风险。

这正是为什么 AI 安全不能被简化为模型准确性。真正相关的问题是：当模型出错、被操纵或被授予过多访问权限时，会发生什么。

真正的冲突是部署速度与控制能力之间的较量

高管希望立即获得可衡量的 AI 收益，而安全团队则接手了权限和故障路径仍不清晰的系统。

压力首先来自安全组织之上。董事会和高管团队期待 CIO 找到高效的 AI 用例、减少运营摩擦，并避免落后于竞争对手。

业务团队可以在数天内启动 AI 试点项目。建立完整的资产清单、权限模型、评估流程和事件计划则需要更长时间。这一时间差造就了本文的核心冲突。

一项 2026 年 Logicalis 调查发现，超过四分之一的 CIO 将 AI 视为重大风险。根据这份CIO 安全发现，受访者将其与恶意软件、勒索软件和网络钓鱼并列。

同一研究发现，三分之二的受访者认为员工在 AI 风险管理方面的培训不足。报告还称，94% 的 CIO 面临网络安全技能短缺。

这些发现揭示的是能力问题，而不仅是技术问题。组织正在增加一类陌生的系统，而现有安全团队已经缺乏足够的专业人才。

责任也可能变得碎片化。CIO 可能负责技术战略，CISO 则负责安全；法务团队负责知识产权和监管风险；数据主管负责治理，业务部门负责选择用例。

一次 AI 故障可能涉及所有这些群体，却无法清晰地归入某一个部门。当职责仍然模糊时，审批会变得不一致，事件响应也会放缓。

成熟的网络安全计划提供了有益对照。组织多年来一直在为漏洞管理、终端保护、身份、备份和恢复定义流程。

这些控制措施仍然必不可少。AI 系统依然运行在普通云服务、应用程序和用户账户之上。被攻破的身份可以暴露 AI 工作流，就像它会暴露其他软件一样。

然而，AI 增加了传统控制措施无法独自作出的判断。防火墙无法判断生成的建议是否包含不可接受的偏见。终端软件无法评估模型是否引用了正确的内部政策。

这并不意味着应建立一个孤立的 AI 治理官僚体系。将 AI 完全与网络安全分离，会重复控制措施并制造新的缺口。

更有力的方法是从既有的身份、数据分类、软件审查和事件管理入手。随后，团队可以在常规流程不足之处增加模型评估和智能体专用控制措施。

身份尤其值得关注，因为智能体通过凭据执行操作。每个智能体都应拥有自己的身份、受限权限和明确记录的负责人。共享账户会使问责变得困难。

权限应与分配任务所需的最小操作集合相匹配。用于总结支持案例的助手不需要删除记录的权限。编程智能体也不需要不受限制的生产环境访问权限。

组织同样需要一份最新的清单。团队无法治理那些他们甚至不知道存在的模型、插件和数据连接。仅靠采购记录会遗漏浏览器工具和员工自行创建的集成。

清单应记录模型提供商、业务负责人、数据来源、已连接工具、目标用户和决策权限。还应注明输出是否经过人工审核。

对于知识密集型工作，公司可通过将源材料保留在获批系统内来降低风险敞口。受控的AI 知识库可在帮助团队检索相关上下文的同时，保留访问边界。

这一选择并不能消除 AI 风险。但与在彼此无关的消费者服务之间复制敏感材料相比，它能提供更清晰的数据路径。明确的所有权和权限执行仍然决定最终结果。

目标并非阻止每一项实验。过于宽泛的限制可能会驱使员工转向未经批准的工具。当获批选项保持实用且易于获取时，治理会更有效。

标题未能证明什么

受访者的担忧衡量的是感知到的风险敞口，而不是 AI 事件的实际发生频率或财务影响。

这个标题很容易让人得出一个简单结论：AI 已变得比勒索软件、恶意软件或网络钓鱼更危险。现有证据并不支持这一说法。

Thales 向受访者询问了与生成式 AI 相关的担忧，并另外报告了观测到的攻击类别。这些衡量指标回答的是不同问题，不能据此直接排出风险高低。

担忧调查反映的是不确定性、关注度和预期后果。事件数据衡量的是组织发现并分类的事件。两者都不能自动代表总体损失。

受访者可能将 AI 排在较高位置，是因为其边界仍不清晰。熟悉的威胁即使造成了更大的可量化损失，也可能让人感觉更易于应对。

新颖性同样会影响回答。安全负责人经常收到董事会、客户、监管机构和员工关于 AI 的提问。这种可见度可能会抬高感知风险，却并不表明事件量更高。

由供应商赞助的研究需要额外谨慎对待。Thales 销售网络安全和数据保护产品，因此该公司在 AI 安全支出方面具有商业利益。S&P Global Market Intelligence 451 Research 进行了这项调查，但读者仍应审视其叙事框架。

这并不意味着研究结果无效。它意味着这些百分比只能支持一个有限的结论：企业报告了较高的担忧，并正将资源投向 AI 专项安全。

数据还来自多个国家和行业。使用智能体处理客户交易的银行，与测试内部写作助手的制造商，面临的后果并不相同。

汇总百分比可能掩盖这些差异。风险取决于数据敏感度、自动化程度、用户群体、监管义务以及模型采取行动的权限。

因此，公司不应照搬一份通用的 AI 安全清单。低影响的起草工具并不需要与能修改客户账户的智能体相同的控制措施。

另一项不确定性涉及事件分类。攻击者可能使用 AI 撰写网络钓鱼信息，但组织或许会将事件记录为网络钓鱼。AI 协助了攻击，却未成为报告中的类别。

反过来也可能发生。AI 应用中的传统权限错误，可能因为新的界面让故障变得可见，而被贴上 AI 标签。

在比较变得可靠之前，研究人员需要一致的定义。他们必须区分利用 AI 的攻击、针对 AI 系统的攻击，以及由获批 AI 使用导致的故障。

NIST 的智能体安全分析发现，各方普遍认同基础网络安全实践仍然适用。受访者也表示，这些实践需要针对智能体安全进行调整。

这比宣称传统网络安全已经过时更有价值。AI 继承了熟悉的基础设施风险，同时增加了指令、访问和自主行动的新路径。

预算过快转移也存在风险。公司仍需要补丁管理、多因素认证、备份、电子邮件安全和经过测试的恢复计划。AI 控制措施无法弥补被忽视的基础能力。

攻击者经常利用已知弱点，因为这些方法依然有效。在薄弱的身份控制之上增加一层 AI 监控，可能制造出进展的表象，却无法降低基础风险敞口。

高管应询问每项投资如何改变可衡量的结果。有用的指标包括未经授权的数据访问、高风险智能体操作、违反政策的情况，以及遏制 AI 相关事件所需的时间。

安全团队应在现实条件下测试供应商的主张。能够检测明显提示注入的产品，可能无法应对隐藏在业务文档中的指令，或跨多个步骤编码的指令。

红队演练可以暴露这些弱点。AI 红队会测试系统如何应对操纵、不安全请求、过度权限和意外数据。

测试必须覆盖完整应用，而非仅测试模型本身。安全的模型在连接到权限广泛的工具后可能变得危险。较弱的模型在严格受限的工作流中则仍可保持低风险。

人工审核也不是万能答案。当系统生成的决策过多，或截止日期鼓励速度时，审核者可能沦为橡皮图章。

正确的控制措施取决于后果。低风险内容可采用抽样。高影响操作应要求明确审批、独立验证，或设置防止自主执行的技术限制。

AI 治理正在进入董事会

AI 风险已成为治理议题，因为技术控制无法解决责任不清或相互冲突的商业激励。

公开披露显示，这一议题扩张得有多快。The Conference Board 发现，提及 AI 风险的 S&P 500 公司比例从 2023 年的 12% 上升至 2025 年的 83%。

其治理研究还发现，58% 的公司将网络安全和数据泄露列为最重大的 AI 相关风险。接受调查的高管中，不到 10% 表示其公司已为 AI 监管做好充分准备。

风险披露并不证明事件已经发生。公司通过申报文件描述可能构成重大影响的威胁，法律上的谨慎可能会促使其采用宽泛措辞。

但这一变化表明，AI 已超出创新团队的范围。董事会如今必须考虑监督、升级机制和管理层问责。

董事会的职责不是批准每一个模型。董事需要确认管理层了解 AI 在何处影响产品、运营、员工和客户。

他们还应知道哪些部署能够作出具有重大影响的决策。起草内部文本的助手，与更新价格、转移资金或更改访问权限的智能体并不相同。

管理层报告应将技术信号与业务影响关联起来。如果没有说明系统支持哪些决策，模型测试分数意义不大。

一份有用的报告可以展示有多少 AI 系统能够访问机密数据。它还可以识别拥有写入权限的智能体、尚未解决的高风险发现，以及等待审查的例外情况。

董事会还应审视集中度风险。多个内部应用可能依赖同一家模型提供商、身份服务或检索平台。届时，一次故障就可能影响多个业务职能。

第三方依赖使保障工作更加复杂。企业可能保护了自己的应用，却依赖于会改变模型行为、保留条款或集成功能的供应商。

合同可以确立通知、审计和数据处理义务，但无法阻止每一次技术变更。团队仍需要监控和应急预案。

监管增加了另一层压力。不同司法辖区会按照用途、行业和潜在危害对 AI 系统进行分类。一家跨国公司可能面临相互重叠的隐私、网络安全、消费者保护和 AI 专项要求。

合规不应成为安全的唯一界定。一个系统可以满足文档要求，同时仍保留过多权限或产出不可靠的决策。

相反，技术团队可以降低即时安全风险，却未处理透明度、歧视或知识产权方面的法律义务。

这一区别解释了为何在一些调查中，对 AI 的恐惧超过了任何单一的熟悉威胁。风险并非某一种攻击方法，而是贯穿技术完整生命周期的治理问题。

组织需要在部署前设置明确关卡，也需要持续审查。模型、数据、用户和集成会在初次批准后发生变化。

监控应发现异常工具调用、未经授权的检索、异常数据流动和输出质量变化。日志必须显示是哪个身份发起了每项操作，以及哪些来源对其产生了影响。

事件预案应纳入 AI 专项场景。团队需要制定停用智能体、撤销凭证、保留提示内容和识别受影响数据的程序。

他们还必须确定何时不可靠的输出会成为需要报告的事件。这一决定可能涉及安全、隐私、法务和运营负责人。

培训应反映员工角色。关于机密数据的一般性警告很容易被忽视。开发人员、销售团队、分析师和高管遇到的故障模式各不相同。

开发人员需要获得关于生成代码和依赖项的指导。销售人员需要了解客户数据规则。高管需要识别深度伪造冒充和被操纵的决策材料。

因此，有效治理应让安全行为变得更容易。获批工具应提供足够价值，使员工无需为日常工作寻找非官方替代方案。

三个信号将显示企业防御是否正在跟上

下一阶段将通过智能体权限、经验证的事件数据，以及治理是否改变部署决策的证据来衡量。

第一个信号是更严格的智能体访问权限。企业应开始报告有多少 AI 智能体拥有唯一身份、受限权限，以及针对重大操作的人类审批。

这一指标超越了对获批应用数量的统计。它检验公司是否理解自己正在授予软件的权限。

当组织淘汰共享凭证和不受限制的连接器时，进展将变得可见。失败则会表现为智能体继承了广泛的员工或管理员权限。

第二个信号是更完善的事件分类。安全报告需要区分 AI 辅助攻击、针对 AI 系统的攻击，以及由内部 AI 使用导致的故障。

可靠的类别将使公司能够比较频率、严重程度和控制措施的有效性。它们还将检验当前的恐惧是否与观测到的危害相符。

报告事件数量上升并不自动意味着防御失败。更好的检测通常会先带来更高的数字，之后才会带来更低的损失。

第三个信号是治理是否改变了实际部署。只有当政策限制数据、削减权限、推迟不安全发布或要求额外测试时，它们才有意义。

最有力的证据将来自有记录的范围变更。公司可能会移除智能体发送消息的能力、限制检索来源，或对财务操作保留人工审批。

另一个较弱的信号，是又成立了一个没有实际运营权限的监督委员会。无法改变上线决策的治理机制，将很难抵御业务压力。

企业还应关注网络保险公司和监管机构如何处理与 AI 相关的事件。更具体的要求将迫使组织记录控制措施，并区分宣称的能力与经过验证的能力。

核心教训并不是 AI 已经击败了网络安全。真正的问题是，企业将概率型系统连接到高价值数据和受信任的业务工具上的速度，快于控制措施成熟的速度。

这种失衡解释了人们的担忧。恶意软件、钓鱼攻击和勒索软件固然危险，但其运作模式人们已经熟悉。AI 则在企业积极希望扩展的工作流程内部引入了不确定性。

如今，安全负责人需要在保持基本网络安全卫生的同时，增加模型评估、智能体身份管理、数据控制和跨职能问责机制。忽视任何一方，都会造成原本可以避免的漏洞。

对技术采购者、开发者和知识工作者而言，实际问题很直接：一款 AI 工具是否只获得完成其任务所需的信息和权限？

在下一次集成上线前提出这个问题。记录答案，测试边界，并确定当系统出现意外行为时，谁有权将其停止。与又一次泛泛承诺“组织会负责任地使用 AI”相比，这些证据将更为重要。