所需的架构转变以管理AI代理

AI不再只是一个生成文本的聊天机器人。在企业环境中，AI代理正在执行诸如检索敏感数据、触发工作流、调用工具和跨系统记录活动等操作。自主性完全改变了治理讨论；最初为人类用户和传统应用程序设计的控制和程序并不适用于可以在运行时执行多步操作的软件。

风险并非理论上的。可见性、访问控制和审计能力方面的小缺口可以迅速累积，导致难以检测和更难逆转的运行时故障。

为了跟上这一新时代，管理AI代理不能通过添加更多的政策文档来完成。它需要通过设计来实现治理：一种架构方法，控制措施嵌入控制平面并在运行时持续执行。如果代理要像数字同事一样行事，它们必须继承与人类相同的企业防护措施，以及更强大的运行时监督。

为什么治理在融合时代破裂

企业架构已经进入了融合时代。数据和工作负载现在跨越多个云、私有数据中心和边缘环境。

有一些组织因为需要同时管理多个流程而运行平行系统。这些流程包括单独的身份系统、日志管道、目录和批准流程。结果就是所谓的“弗兰肯斯坦平台”，每添加一个新工具或云环境，集成开销就会增加。事实上，这种碎片化正出现在日常现实中。

根据最近的一项调查，47%的受访者认为复杂的访问要求和流程以及44%的受访者认为对数据位置的可见性有限是使用数据有效的障碍。

这正是代理暴露系统之间的缝隙的地方。

为了回答一个商业问题，代理可能需要从本地ERP系统、云CRM、另一个云中的运营遥测和协作套件中的文档中提取数据。如果组织在每个地方以不同的方式执行策略，代理将会失败，或者更糟糕的是，以无法解释或控制的方式成功。

这是企业领导者必须关注的时刻。代理正在迫使更高的标准，要求在环境之间保持一致性和在运行时保持问责制。

因此，治理正在被监管机构和安全机构推到聚光灯下。一个例子是NIST AI风险管理框架，它强调了在整个AI生命周期中管理风险，而不仅仅是在构建时。这是一个提醒，合规性和信任是运营责任，而不是一次性清单。

从政策到平台

通过设计实现治理意味着治理随着工作负载移动，而不是在每个隔离区重新实现。实际上，这依赖于三个构建块：

• 统一控制平面

一个地方来定义和执行身份、访问、策略、目录和授权跨云和数据中心。

目标是只写一次策略并在数据和模型运行的任何地方执行，而不是在每个系统中重新构建控制系统。这防止了代理行为漂移，即同一个代理在一个环境中表现安全，在另一个环境中表现危险。

一个实用的测试很简单：如果用户无法访问一列，验证代理代表用户也无法访问它。这应该表明是否正在执行跨平面的书面策略。

• 基于开放标准的数据织物

代理需要上下文来操作。当上下文分散在不同结构中，由不同团队拥有时，数据织物有助于标准化语义和访问模式，因此代理不需要为每个数据集学习一套新规则。

像Apache Iceberg这样的开放表格格式支持这一点，允许多个引擎在不将数据复制到新隔离区的情况下共享相同的管理数据。这很重要，因为数据复制通常是治理失败的地方。一旦团队开始复制“代理需要的内容”，您就创建了一个新的、管理较少的环境。

如果代理可以在不引入新权限差距的情况下跨数据集操作，治理就按预期工作。

• 实时可观察性和血统

代理只有在运行时可见时才是可治理的。

这里的可观察性不仅仅是一种“nice-to-have”，而是运行时控制和事件响应的基础。

特别地，需要有代理操作的端到端证明。代理应该能够证明操作，例如访问了哪些数据和调用了哪些工具，并且从那里，血统可以将输出连接回输入。这使得团队能够审计这些决策，并在需要时排除故障，从而证明整体合规性。

将代理视为“数字同事”

一种最有用的思维模型是将代理视为数字同事。

这里有一个比较：就像员工有访问某些建筑和房间但不允许进入其他房间的访问徽章一样，治理允许代理具有访问限制。一个关键的补充是代理必须对其允许透露的内容有情况感知。

考虑一个支持代理。它可能需要访问以前的支持案例来解决一个问题，但在这样做的同时，它不能泄露其他客户的私人细节。换句话说，代理可以使用受限的知识来推理，但仍需要执行披露边界。这不是一个“提示编写”问题，我们过去知道如何处理；相反，这是一个身份和运行时执行问题。

2026年会发生什么变化：代理从实验转向生产

2026年是实验结束、代理进入生产的年份。

这种转变迫使企业以两种速度运营。一个是创新速度，团队在此测试新模型、工具和代理工作流以获得竞争优势。另一个是安全速度，系统必须满足合规性和运营要求，这可能包括严格的访问控制和盲点。

如果没有一套架构治理，这两种速度将会冲突。

如果团队在代理得到治理之前部署它们，将会出现一系列一次性的控制和运营故障。如果相反发生，安全将阻止一切，创新将转移到影子IT，破坏治理。

目标不是选择一种速度。它是建立一个同时支持两种速度的架构。

代理运行时治理的实用清单

• 如果您正在构建或扩展代理，问自己以下问题以确定治理是否真正具有架构性：您能否从头到尾解释代理访问了哪些数据来产生答案或采取行动？
• 访问决策在混合环境中是否一致，还是因平台而异？
• 您是否具有代理操作的遥测数据，包括工具调用、策略检查和人工升级？
• 如果代理行为异常，您能否在运行时限制、暂停或隔离代理？
• 您是否具有与监管义务和风险承受能力相符的部署后监控计划？

如果您无法回答这些问题，请将代理部署视为即将发生的生产事件。

治理转变需要是架构性的，否则它不存在

代理将成为企业运营的标准组成部分。问题是它们是否会成为企业运营的可靠组成部分。

如果代理不能像人类和关键任务软件一样自信地被治理，其后果将是真实的。我们将在数据泄露、合规性失败、运营中断和对AI程序的信任丧失中看到这些后果。

领导者需要停止将代理治理视为文档练习。随着平台能力的扩展，代理治理应该是承担其他角色监督的组成部分之一。这意味着在控制平面中嵌入控制，实现操作的可观察性和决策的可审计性。然后扩展。

这就是您如何获得快速移动而不会破坏企业的代理。