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

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

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

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

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

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

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

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

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

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

这是企业领导者必须关注的时刻。代理正在强制一个更高的标准，要求跨环境保持一致性和在运行时保持可计性。

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

从政策到平台

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

• 统一控制平面

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

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

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

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

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

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

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

• 实时可观察性和血统

代理只有在可见的情况下才是可治理的。

这里的可观察性不仅仅是一个“很好”的东西，而是运行时控制和事件响应的基础。

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

将代理视为“数字同事”

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

这里有一个可以分解的比较：就像员工有访问某些建筑和房间的权限，但不是其他的，治理允许代理具有访问限制。一个关键的补充是，代理必须对其允许透露的内容有情况意识。

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

2026 年将发生的变化：代理从实验转向生产

2026 年是实验结束、代理占据生产席位的一年。

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

没有一套架构治理，这两种速度将发生冲突。

如果团队在代理受到治理之前部署它们，将会出现一套零碎的控制和运营故障。如果发生相反的情况，则会出现一种故障模式，即安全阻止一切，创新转移到影子IT，破坏治理。

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

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

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

如果您无法回答这些问题，请将代理部署视为一场等待发生的生产事故。

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

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

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

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

这就是您如何获得代理而不会破坏企业。