微软把 AI 治理推进到运行时：从制度文件走向可验证执行

导语

随着生成式 AI 应用和智能体进入生产环境，企业面临的治理问题已经不只是“有没有政策”。更现实的问题是：规则能否在调用发生时被执行，系统行为能否被观察，异常能否被追溯，审计人员能否获得可信证据。微软近期提出的 AI 治理架构，正是试图回答这些问题。

核心要点

• 治理被设计成持续循环。 政策负责定义要求和风险分类，控制措施把要求转化为访问规则与运行时规则；可观测性记录系统行为，评估检验质量与安全，审计则把遥测数据整理成合规和事件调查证据。
• 治理范围覆盖整个 AI 运行链路。 微软列出的九个领域包括政策、数据治理、模型治理、可观测性、评估、安全、身份与访问、审计与合规，以及智能体治理。控制对象不只包括模型，也包括用户、智能体、工具、API、MCP 服务器和企业系统之间的交互。
• 平台服务承担执行边界。 Microsoft Foundry 与 Purview、Entra ID、Defender、Azure API Management 等服务组合使用。Foundry AI 网关可用于身份验证、令牌限制、配额管理和策略执行；在管理 MCP 工具时，还可以集中处理身份验证、速率限制、IP 限制和审计日志，而无需修改 MCP 服务器或智能体代码。
• 评估贯穿上线前后。 团队可以使用内置或自定义评估器，在部署前借助数据集检查应用和智能体的质量、安全性；上线后则持续观察其生产行为。
• 智能体需要额外控制。 针对自主运行的智能体，治理还要覆盖身份、访问、活动和工作流检查点。相关机制可以对输入、模型调用、工具执行和输出进行检查，影响较大的操作还可设置人工审批。

意义与影响

这套架构的关键变化，在于把 AI 治理从一次性的合规工作转成可运营、可验证的基础设施。企业如果只拥有政策文本，却无法证明策略在生产环境中被执行，治理就很难形成闭环。运行时控制和遥测数据因此成为连接制度与实际行为的桥梁。

微软的方案建立在其产品体系之上，但涉及的治理问题并不局限于单一厂商。它也可以与 NIST AI 风险管理框架及生成式 AI 配置文件中的全生命周期风险管理思路对照理解：前者提供供应商中立的风险框架，微软则进一步把部分要求映射到平台控制和运营数据。

对企业技术团队来说，下一步重点可能不再是单独采购“治理工具”，而是把身份、访问、模型评估、网关策略、日志、人工审批和审计流程连接起来。只有当生产系统能够持续回答“谁调用了什么、执行了什么、结果如何、规则是否生效”，AI 治理才真正从纸面进入运行时。

来源：InfoQ 中文