Microsoft 重写责任 AI 标准：Agent 治理开始按模型、平台、应用分层

Microsoft 重写责任 AI 标准：Agent 治理开始按模型、平台、应用分层

Microsoft 9 月 1 日发布第三份年度责任 AI 透明度报告，并披露已重构内部 Responsible AI Standard。新标准按照模型、平台服务和应用等技术栈组件，以及 Microsoft 在开发或部署环节的角色分配要求。基础规则始终适用，特定场景再叠加可随风险调整的要求。

这套变化反映了 Agent 产品带来的治理难题。一个 Agent 会保留记忆、调用工具、读取数据并代表用户采取动作，风险来自模型、应用、MCP 服务、身份系统和人工审批的共同作用。只做一次发布前模型评测，很难覆盖运行中权限变化、Prompt 注入和工具返回造成的偏移。

同一个模型放在不同层，责任并不相同

模型提供方负责能力评测、安全限制和版本说明；统一模型网关负责鉴权、路由、日志、成本与供应商切换；应用团队则决定提示、数据、工具权限和最终业务动作。企业采购 AI 中转站或模型聚合平台时，不能把上游模型的安全声明直接当作整套应用已合规，也不能要求网关替代所有业务审批。

按技术栈分层的好处是能找到控制点。模型输出不稳定，可以做评测和回退；平台路由错误，可以设置模型 allowlist、预算和审计；Agent 越权，则要约束身份、工具和目标资源。每项风险都应有明确负责人和证据，避免在事故后才发现供应商、平台和业务团队都以为对方会处理。

Microsoft 表示，对具有显著网络安全能力的系统会采用更严格措施，同时把 Agent 身份、工具权限与动作监控作为新的治理重点。对普通企业，这比一句“人工在环”更可执行：谁能启动 Agent、它代表哪个主体、允许调用哪些工具、什么动作必须停下来审批，都可以写进系统配置和测试。

责任 AI 正在从评审表变成持续运行的工具链

报告提到多项实践工具。AI Red Teaming Agent 用于加快风险发现，Agent evaluators 测量质量、安全与性能，RAMPART 把红队发现转成可重复测试；ASSERT 与 Agent Control Specification 则用于按策略评测、在运行关键点放置控制并观察行为。它们代表的方向是把治理嵌入开发和运行，而非只保留会议纪要。

采用任何治理工具前，都要确认它测量的对象和覆盖范围。安全评分可能遗漏业务违规，自动红队也可能受测试提示限制，运行策略若缺少身份绑定仍会被绕过。团队应把模型评测、工具调用轨迹、审批日志和事故回放放在一起，检查控制是否在真实任务里生效。

Microsoft 还称其包括 Microsoft 365 Copilot、Foundry 与 GitHub Copilot 在内的广泛产品组合通过 ISO 42001 认证，并与 18 所分布于六大洲的大学建立外部红队联盟。这些属于厂商披露，企业采购仍要查看认证范围、适用服务和自身责任，不能把供应商认证自动继承到自建应用。

企业可以先补一张跨层控制表

最实用的起点是把模型、平台和应用列成三层。每层记录版本负责人、数据输入、可用权限、监控指标、失败回退和证据保存期限。使用多个模型时，还要说明切换后哪些安全假设会变化；同一个 Prompt 在 Claude、GPT、GLM 或开源模型上可能触发不同工具行为。

运行中的 Agent 应拥有可追溯身份，不与普通用户或服务账号混用。工具权限按任务和时间窗口授予，敏感动作使用确定性规则拦截；模型复核可以发现遗漏，但不作为唯一授权依据。模型网关的 token 与费用日志也要关联到具体 Agent、用户和业务任务，才能支持调查和成本归属。

如果团队通过 [AnyAIS](/) 统一调用多种模型，可以在网关层集中管理 Key、模型目录和用量；应用侧仍需自己完成身份、工具权限、审批和业务结果验证。分层治理的意义正是保留这些责任边界。

资料来源：[Microsoft：Responsible AI in 2026](https://blogs.microsoft.com/on-the-issues/2026/09/01/responsible-ai-in-2026-how-we-are-adapting-for-whats-ahead/)。