统一治理正在让企业 AI 智能体走向失败

Google News 向企业发出了一个尖锐警告：统一治理可能让 AI 智能体变得更不安全、更无用，或两者兼而有之。该分析由 JFrog 发布，并获 Techzine Global 报道，基于 Gartner 一项将带来严重运营影响的预测。

Gartner 预测，到 2027 年，40% 的企业将降级使用或淘汰自主 AI 智能体。该机构认为，治理漏洞往往要等到生产环境发生事故后才会暴露。这一预测使治理不再只是合规工作，而成为部署风险。

矛盾并不在于治理与创新之间，而在于统一控制与按比例控制之间。研究助手与自主支付智能体带来的风险敞口并不相同。然而，许多组织仍将二者置于完全相同的审查流程、权限和监控规则之下。

这种做法会造成两种相反的失败。过度控制会让低风险工具的部署过于缓慢。宽泛而薄弱的控制则会让高影响力智能体拥有超出组织安全监督能力的权限。

正在浮现的替代方案，是根据自主性、访问权限和潜在后果来配置控制措施。它还将每个模型、工具、插件、技能和连接都视为受治理的软件组件。

Google News 的报道究竟改变了什么

最重要的变化，是 Gartner 明确将统一治理与 AI 智能体部署失败联系起来。

Gartner 于 2026 年 5 月 26 日发布了这一警告。其指出，对每个智能体套用相同的治理模式会导致失败，因为不同智能体拥有不同的权限和作用范围。

这种区别听起来显而易见，但企业政策往往忽视了它。许多项目从一份可接受使用政策、一个审查委员会和一张安全检查清单开始。这些控制措施通常将生成式 AI 作为一个宽泛类别来处理。

智能体让这一结构变得更复杂。AI 智能体是能够规划步骤、选择工具并为实现目标采取行动的系统。因此，它的行为不只取决于底层模型。

一个基础的摘要智能体可能会读取文档并生成文本。它无法修改源文件、发送消息或执行代码。其最可能的严重失误，是给出不准确或具有误导性的答案。

客户服务智能体可能读取账户数据、更新记录、发放补偿并联系用户。它的错误会影响资金、隐私、合同义务以及客户信任。

基础设施智能体带来的风险敞口则更大。它可能修改云资源、更改访问策略、部署代码或响应安全警报。一次错误操作就可能扩散至相连系统。

“AI 智能体”这一个标签掩盖了这些差异。单一控制包又再次掩盖了它们。

Gartner 的治理警告将智能体自主性与其访问范围区分开来。这两个维度都很重要。

自主性描述智能体能够在多大程度上独立选择并执行步骤。范围描述它能够接触到的系统、数据和业务流程。智能体可以在一个维度上很高，而在另一个维度上很低。

例如，在可随时弃用的测试环境中高度自主运行的智能体，可能只会带来有限的业务风险。一个自主性较低、但拥有生产支付访问权限的智能体，仍可能需要严格控制。

Google News 的结果之所以重要，是因为它指向了一种基于实际风险敞口的治理模式。相关问题不再是组织是否“允许使用智能体”。

领导者必须问清每个智能体能够观察、决定和改变什么。他们还必须确定这些行动是否可逆。

这些问题使治理更接近工程实践。政策团队仍定义可接受风险，但技术系统必须在开发和生产过程中执行这些限制。

因此，这一变化具有结构性。企业 AI 治理不能继续只是审批时套用的一份文件。它必须成为与身份、权限、依赖项、行动和结果相连的持续控制系统。

为什么一项政策会造成两种不同的失败

统一治理之所以失败，是因为同样的限制对一个智能体可能过度，对另一个却可能危险地不足。

第一种失败是运营瘫痪。一个低风险内部助手可能要面对与获准修改财务记录的智能体完全相同的审批流程。

这一审查可能涉及法务、隐私、网络安全、模型风险、采购和架构团队。每个团队都可能要求提供专为组织最敏感系统设计的证据。

对于影响重大的部署而言，这一流程是合理的。但当智能体只汇总公开文档，或为人工审阅起草文本时，它就显得不成比例。

漫长的审批周期并不总能阻止采用。它们可能会将采用行为推向获批渠道之外。员工依然面临截止日期、重复性工作，以及使用可用工具的压力。

结果便是影子 AI，也就是在缺乏集中可见性的情况下使用未经批准的系统。因此，严格的统一政策可能会减少正式部署，却增加未知部署。

第二种失败是系统性风险敞口。一张通用检查清单可能会批准一个高影响力智能体，却没有测试其具体工具、凭证、故障路径或升级处置行为。

能够读取发票的智能体，与能够批准付款的智能体不同。能够起草云端变更的智能体，与能够自动部署变更的智能体不同。

宽泛的政策措辞很少能捕捉到这些边界。“人工监督”之类的术语，如果没有说明审批发生在哪里，以及审查者会收到什么证据，也同样意义不大。

批准每项行动的人可能沦为橡皮图章。只审查例外行动的人，则需要可靠的标准来识别例外情况。

时机同样重要。不可逆行动之后的批准，不构成有意义的监督。事后事故审计可以解释损失，却无法防止损失发生。

JFrog 的智能体治理分析将这一问题概括为：在一刀切的限制与按比例控制之间作出选择。其论点反映了软件供应链视角。

这一视角很有价值，因为智能体由多个不断变化的组件构成。团队今天可能批准一个智能体，明天便更新其模型、提示词、插件或工具。

每一项变更都可能改变行为。新工具可能扩大访问权限。修改后的提示词可能改变决策优先级。依赖项更新可能引入易受攻击的代码。

统一治理将已批准的智能体视为稳定对象。实际上，部署后的系统更像一个不断变化的软件栈。

因此，审批模式必须考虑变化。一次无害更新不应触发与新增支付能力相同的流程。然而，具有实质意义的变更也不能在无人察觉的情况下通过。

这需要明确阈值。团队需要知道，哪些变更需要自动化测试、安全审查、业务批准或新的风险评估。

核心问题不是文书工作不足，而是控制粒度太粗。

当治理将每个智能体视为等同对象时，其分辨率就很低。当它区分权限、数据敏感性、可逆性和运营触达范围时，才具备有用的分辨率。

真正的分界线是读取权限与行动权限

当智能体能够改变其对话窗口之外的现实世界时，它的治理难度会显著上升。

传统聊天机器人主要生成内容。用户决定是否信任这些内容，以及是否据此采取行动。这种分离形成了天然的审批边界。

智能体可以消除这一边界。它们可以选择工具、调用 API、更新应用程序，并在无需人工批准每一步的情况下持续工作。

这种能力之所以能创造价值，是因为它减少了人工交接。它也将故障点从屏幕上的回答，转移至业务流程中的实际行动。

请考虑三种企业场景。

研究智能体读取获批准的文档，并起草市场摘要。它没有外部通信工具。内容在分发前由人工检查。

销售智能体读取客户记录、创建跟进任务并起草消息。它可以写入客户关系管理平台，但无法发送外部通信。

营收智能体会变更订阅状态、发放补偿并发送客户通知。它可能直接带来财务和声誉后果。

这些系统可能使用相同的基础模型，但它们的治理要求仍应有显著差异。

第一个智能体需要针对来源访问、数据泄露和事实准确性的控制。第二个还需要写入限制、记录级权限和变更日志。

第三个则需要交易限额、审批关卡、回滚程序、职责分离和快速暂停机制。它还可能需要与特定司法管辖区相关的合规审查。

这就是按比例治理。随着智能体跨越更多影响重大的信任边界，控制措施随之加强。

这一原则已体现在既有框架中。NIST AI RMF通过治理、映射、测量和管理功能来组织风险工作。

NIST 并未将这些功能描述为一张通用检查清单。其指南要求组织将风险管理与具体情境、目标、法律要求和风险容忍度相协调。

该框架的映射功能尤其相关。团队只有理解智能体的预期任务、受影响方、运行条件和可能的故障模式，才能选择合适的控制措施。

欧盟也遵循类似逻辑。其 AI Act 根据风险类别和使用场景设立不同义务。

AI Act 指南区分了不可接受风险、高风险、透明度风险和最低风险系统。它并未对每一项 AI 应用采取相同监管方式。

企业治理也需要在更细致的层面实现类似区分。监管分类提供了一道边界，但内部运营风险还需要额外层级。

两个智能体可能都不属于高风险法律类别，却会带来截然不同的网络安全风险敞口。一个可能访问公开信息，另一个则持有内部系统凭证。

身份成为核心控制。每个智能体都应拥有独立的非人类身份，而非借用开发人员账户或共用权限宽泛的服务凭证。

权限应遵循最小权限原则。这意味着只授予完成既定任务所需的访问权限，并在不再需要时将其移除。

组织还需要行动级政策。获得某个应用程序的访问权限，不应自动授权在其中执行每一项操作。

智能体可能需要读取工单、添加内部备注并建议状态变更的权限。它未必需要关闭工单或删除其历史记录的权限。

这种区分形成了可控的行动面。它也让审计更有价值，因为日志会显示是哪个身份请求了每一项操作。

每个智能体也是一条软件供应链

治理不能止步于模型批准，因为模型只是智能体执行路径中的一个组件。

现代智能体将模型与提示词、记忆、检索系统、工具、插件、API 和编排代码结合起来。每个组件都可能改变智能体所知的信息或采取的行为。

模型或许能生成合理的计划，但遭到入侵的工具仍可能执行有害操作。即使是安全的工具，在被配置了过度权限后也可能变得危险。

模型上下文协议（通常称为 MCP）正说明了这一挑战。MCP 为 AI 应用连接数据源和可执行工具提供了一种标准方式。

这种标准化可以减少定制集成工作，也能让新功能更易添加，有时可通过从外部来源获取的软件包或服务器实现。

易于连接改变了治理问题。安全团队可能批准了智能体所使用的模型，却忽略了一个新加入、可访问源代码或凭据的 MCP 服务器。

插件和技能也会带来类似问题。它们可能包含模式、指令、脚本、认证范围和依赖链。每一项都会扩展系统的行为边界。

传统软件程序遵循明确的代码路径，尽管复杂系统仍可能出现意外行为。智能体则加入了由模型驱动的决策，在运行时从这些路径中进行选择。

这并不意味着智能体无法得到保护，而是说明组件清单和运行时观测至关重要。

组织需要为每个已部署的智能体建立物料清单。该记录应标明模型、提示词、工具、插件、软件包、容器、数据源和外部服务。

每个组件都应有负责人和版本信息。团队应清楚谁批准了它、它通过了哪些测试，以及它能够访问哪些系统。

依赖项控制十分重要，因为一次更新可能在不改变智能体公开名称的情况下改变其行为。某个插件版本可能请求新的权限，或引入存在漏洞的库。

构件应通过受信任的仓库流转。这样，安全检查就能在部署前扫描软件包、容器和配置文件。

同样的纪律也应适用于提示词和策略。它们并非传统意义上的可执行代码，但其变更可能实质性地改变智能体行为。

一次提示词更新可能指示智能体将速度置于审查之前。一次策略更新则可能允许在低于某个交易阈值时自动执行。

这两类变更都应具备版本历史和测试。所需的审查应与其影响相匹配，而非取决于文件格式。

OWASP 智能体指南描述了由目标、工具、记忆、身份和多智能体交互所引发的风险。这些风险不止于模型输出不准确。

目标操纵可将智能体引向攻击者的目标。工具滥用则可能将合法功能变成攻击路径。

记忆投毒可通过存储的上下文影响后续决策。过度自主性则可能让智能体采取超出用户意图的行动。

这些威胁需要不同的控制措施。仅靠输入过滤无法阻止遭入侵的依赖项。仅靠模型评估也无法发现权限过大的服务账户。

这正是为什么相称治理也必须以构件为中心。风险分类决定所需的控制措施，而构件管理让这些控制措施能够被落实。

模型决定智能体能够推理什么。其工具和凭据决定这些推理能够影响什么。

相称治理需要证据，而非标签

如果团队无法证明某一风险等级的控制措施能在真实执行过程中发挥作用，那么这个风险等级几乎没有价值。

组织经常设置低、中、高等风险类别。如果这些标签缺乏可衡量的标准，这一工作可能沦为另一份统一的检查清单。

一个有用的分级应从自主性开始。团队应记录智能体是仅提出行动建议、需要批准，还是独立执行。

下一个维度是访问权限。这包括数据敏感度、允许访问的系统、操作类型、地理边界和受影响的用户。

第三个维度是后果。团队应评估错误、恶意或不可用行为可能造成的损害。

可逆性是另一个重要维度。草稿可以丢弃，内部记录通常可以恢复，而公开披露或资金转移则可能难以撤销。

速度同样会改变风险。一个每天执行一次经审查操作的智能体，与一个每小时进行数千次变更的智能体，面临的是不同的遏制问题。

这些维度应产出具体的控制措施。

低风险的只读智能体可能需要经批准的信息源、防数据泄露保护、输出审查和基础日志记录。其发布流程可以保持轻量。

具备写入能力的中风险智能体可能需要范围受限的凭据、操作日志、自动化测试、使用限制，以及针对敏感操作的批准。

高风险自主智能体需要更强的隔离。控制措施可包括交易限额、独立授权、持续监控、紧急暂停和经过测试的回滚流程。

随后，组织必须验证这些控制措施。书面声明某智能体采用最小权限原则，并不能说明其凭据实际能够执行什么操作。

测试应尝试执行被禁止的操作，并确认智能体无法访问未经批准的记录、工具或环境。

团队还应测试间接路径。智能体可能没有直接修改付款的权限，却仍可触发会执行该修改的工作流。

运行时遥测构成下一层证据。日志应记录智能体身份、所选工具、参数、结果和批准状态。

敏感数据需要在日志中得到谨慎处理。监控不能成为机密信息或凭据的新来源。

行为基线有助于发现异常活动，但不应取代明确策略。新颖的智能体行为并不总是恶意的，熟悉的行为也并不总是安全的。

确定性控制措施应阻止明确禁止的操作。行为系统则应识别值得调查的意外模式。

持怀疑态度的人会问：企业是否能在数千个智能体之间维持如此细致的管理？相称模型比一刀切的禁令需要更完善的清单、归属和监控。

糟糕的实施可能导致分级膨胀。团队可能为避免延误而把所有内容归为低风险，也可能为避免个人责任而把所有内容归为高风险。

因此，业务负责人必须参与其中。安全团队了解威胁，但流程负责人了解财务、客户和运营后果。

智能体负责人应在部署后继续承担责任。归属责任包括审查事件、批准重大变更，以及确认智能体仍在服务于有效目的。

治理也应设置失效机制。权限和批准应设定审查日期，而不是无限期有效。

最强的模型并非毫无摩擦的控制，而是将摩擦置于后果足以证明其合理性的地方。

Google News 读者接下来应关注什么

下一项检验在于，企业是否会将基于风险的原则转化为可执行的运营控制措施。

第一个信号是智能体清单的质量。组织无法治理无法识别的系统。

可信的清单应包括获批准的智能体、嵌入式供应商智能体、内部原型，以及通过员工账户连接的外部服务。

发现工作必须超越采购记录。智能体可能通过浏览器扩展、SaaS 功能、开发者软件包、工作流工具和云市场进入组织。

第二个信号是身份隔离。成熟的部署会为每个生产环境智能体分配独立身份，并赋予范围狭窄、可检查的权限。

共享账户仍将是一个警示信号。它们会模糊责任，也让人们难以在不中断其他服务的情况下暂停某一个智能体。

第三个信号是操作级可见性。企业应了解智能体尝试了哪些操作、哪些操作被策略阻止，以及哪些操作获得了人工批准。

仅展示模型使用情况的仪表板并不够。Token 数量无法揭示智能体是否修改了数据库字段，或发起了一笔业务交易。

MITRE 的 ATLAS 知识库为针对 AI 赋能系统的对抗性战术提供了有价值的参考。其不断演进的技术表明，威胁模型必须跟随实际系统行为。

组织还应按智能体风险等级跟踪生产事故。这些证据可以揭示控制措施是否相称，还是仅仅图方便。

如果低风险智能体面临长时间延误，却没有带来实质性的安全收益，治理仍然过于严格。如果高风险事故在部署后才暴露出来，控制措施仍然过于薄弱。

指标应包括批准延迟、被阻止的操作、回滚频率、策略例外、未经授权的工具和未解决的归属问题。

这些指标将治理与运营联系起来，也能帮助领导者判断某项控制措施是在降低风险，还是仅仅增加行政工作。

监管动态将提供另一个信号。欧盟持续发布有关高风险分类、监控、文档、人类监督、网络安全和事件响应的指导意见。

不过，法律合规只是底线，而非完整的智能体安全计划。许多有害行为并不属于受到专门监管的使用场景。

供应商行为同样值得审视。企业平台正日益将智能体嵌入现有产品中，有时会通过常规功能更新激活新能力。

客户应询问这些智能体是否拥有独立身份，也应询问哪些操作可以受限，以及哪些记录仍可供审计。

如果企业开始将智能体从自主执行降级为建议模式，Gartner 的预测将更具可信度。这一变化将表明，组织正根据生产环境中的经验纠正授权范围。

如果公司在没有事故增加或大规模回滚的情况下扩大自主系统规模，该预测将被削弱。这一结果需要能够跨开发和运行时环境发挥作用的控制措施。

Google News 放大了一项有益的警告，但这一标题不应成为禁止企业智能体的理由。这一论点支持的是更精细的治理，而非减少雄心勃勃的自动化。

高管应针对每个已部署的智能体提出一个直接问题：在无人阻止的情况下，该系统能够改变什么？

答案应决定其身份、权限、测试、监控、批准关卡和关闭流程。如果这些控制措施在每个智能体之间仍然完全相同，那么治理模型依然没有抓住风险。