Jimi-Ige/ai-governance-framework

# Agentic AI 治理：从业者框架 **Jimi Ige | AI 治理与转型从业者** Georgetown AI 治理与合规行政证书 CISSP | CISM | CRISC | ISO 27001 | jimiige.com ## 生产落地差距 5 家企业中有 4 家正在试验 AI agent。9 家中有 1 家将其投入生产运行。 这一差距不在于技术，而在于治理。 大多数企业治理框架是为人类做决策、AI 辅助人类的世界而构建的。这些控制措施预设了一个可识别、可问责、且能在事后被要求解释某项选择的人类主体。Agentic 部署打破了这一模型：agent 成为决策者，它以机器速度运作，跨系统和 API 链接行动，并且在每个步骤中仅在有限的人类监督下运行。为静态软件和人类决策者构建的治理基础设施已不再适用，而这一差距首先在以下七个领域中显现出来。 本框架识别了 Agentic 部署中最常见的七个治理失效领域，并为每个领域提供了从业者级别的控制措施。 ## 框架结构 本框架围绕七个治理领域组织而成，这些领域源自 NIST AI RMF（治理、映射、测量、管理）、ISO 42001（AI 管理体系）以及在企业规模下治理 Agentic 部署的运营经验。 ## 领域 1：Agent 身份与访问治理 **问题** 大多数组织将 AI agent 视为人类用户或静态的 service account。这两种模型都不够充分。Agent 是动态的，可以通过使用工具获取权限，并且可能会在单个会话中跨多个系统运作。传统的 IAM 框架预设了一个具有固定权限集的有界主体。 **关键风险** - 权限偏移：agent 通过链式 tool call 积累了超出其初始范围的权限 - 影子 agent：在治理可见性之外的未授权 agent 部署 - 断裂的委派链：agent 与 agent 之间的交接未能保留问责制 **控制措施** 1. 为每个 agent 分配一个唯一的、非人类的身份，并具有限定于其特定任务领域的最小权限集 2. 对任何涉及敏感数据或外部 API 的 tool invocation 实施即时访问 3. 维护一个 agent 注册表，即所有已部署 agent 的清单，包括其身份、权限范围、工具访问权限和业务所有者 4. 将 agent 身份事件与人类身份事件分开审计；agent 的行为模式与人类的访问模式存在实质性的差异 ## 领域 2：Human-in-the-Loop 架构 **问题** 大多数 Agentic 部署的默认设置是“除非出现问题，否则人类置身事外”。这是本末倒置的。人类监督点应该在部署前就设计到工作流架构中，而不是在发生事件后再去改造加装。 **关键风险** - 在没有人类审查的情况下执行重大决策 - 仅在失败节点引入人类，而不是在决策关卡 - 监督疲劳：检查点过多，导致人类未经审查便直接盖章同意 **控制措施** 1. 在部署前映射 agent 工作流。识别出每一个错误后果严重的决策点 2. 为每个决策点指定监督层级：自主（无审查）、咨询（人类可覆盖）、必需（继续执行前必须经人类批准） 3. 设计监督界面，呈现人类做出有意义决策所需的信息，而不仅仅是 agent 行为的日志 4. 跟踪覆盖率：如果人类频繁覆盖 agent 的决策，说明 agent 的决策边界是错误的。如果人类从未覆盖，则该监督点可能是不必要的，或者人类可能没有进行实质性的审查 ## 领域 3：MCP 协议与工具使用治理 **问题** Model Context Protocol (MCP) 使 AI agent 能够动态访问外部工具、API 和数据源。这是 Agentic 部署中 prompt injection、工具滥用和未授权数据访问的主要攻击面。 **关键风险** - 通过工具输出进行 prompt injection：工具响应中的恶意内容重定向了 agent 的行为 - 未授权的 tool invocation：agent 调用了超出其预期范围的工具 - 通过工具参数泄露数据：敏感数据未经审查便传递给外部 API **控制措施** 1. 为每个 agent 维护已批准的 MCP server 和工具的白名单。默认拒绝。 2. 记录所有带有完整参数值的 tool invocation。将 tool call 日志视为安全审计日志，而不仅仅是操作日志 3. 在工具结果传回给 agent 上下文之前实施输出验证：进行清理、验证 schema 合规性、标记异常 4. 作为部署前评估的一部分，测试工具响应中的 prompt injection。对工具接口进行红队测试，而不仅仅是对模型进行测试 ## 领域 4：审计跟踪与可解释性 **问题** 监管机构和审计师越来越多地要求组织解释 AI 辅助决策。对于 Agentic 系统，这在结构上比单次推理 AI 更难：该决策可能是数十个链式步骤、tool call 和模型推理的产物，而所有这些都没有以人类审计师可以跟进的方式单独记录下来。 **关键风险** - 无法重构 agent 决策背后的推理链 - 审计日志只记录了 agent 做了什么，却没有记录为什么这么做 - 当受监管的决策（信贷、保险、就业、医疗保健）涉及 agent 但缺乏充分文档记录时所带来的合规风险 **控制措施** 1. 记录完整的 agent 推理轨迹，而不仅仅是输入和输出。捕获中间步骤、tool call 和决策分支点 2. 以具有防篡改功能的不可变格式存储审计日志 3. 在工作流层面进行可解释性设计：对于每一个重大决策，审计跟踪应当能被非技术背景的合规官浏览导航 4. 在部署前通过运行模拟审计演练来测试可解释性。如果你的团队无法从日志中重构某项决策，你的审计师也同样无法做到 ## 领域 5：针对自主故障的事件响应 **问题** 标准的事件响应 playbook 预设是人类做出了导致问题的决策。Agentic 故障则不同：agent 可能在几秒钟内做出了数百个微观决策，故障可能分布在多个系统中，而根本原因可能是一种在设计期间未被预料到的涌现行为。 **关键风险** - 没有定义 kill switch 或优雅降级路径 - 事件响应团队不熟悉 agent 架构，无法控制故障 - 事后分析只发现了症状，却没有找到导致该问题的治理失效 **控制措施** 1. 在投入运行前为每个 agent 部署定义一个 kill switch。文档化：谁可以激活它，在什么条件下激活，以及激活时对处理中的任务会产生什么影响 2. 针对 agent 架构对事件响应人员进行培训。他们需要了解 tool call 链和 MCP 连接，才能有效遏制 Agentic 故障 3. 进行事后审查，重点检查失效的治理控制措施，而不仅仅是技术故障模式 4. 在部署前运行模拟 Agentic 故障场景的桌面演练 ## 领域 6：偏见、公平性与危害监控 **问题** 做出或影响关于人的决策的 Agentic 系统，带有与其他 AI 系统相同的偏见和公平性风险，但这些风险更难被检测到，因为该决策是诸多步骤链的产物，而不是单次推理。 **关键风险** - 由 agent 辅助的决策对受保护群体产生的差别性影响 - agent 调用的工具（搜索结果、评分系统、外部 API）中嵌入的偏见，agent 放大了这些偏见而不是进行了纠正 - 对已部署的 agent 缺乏公平性监控，因为评估的重点是准确性，而不是公平性 **控制措施** 1. 在部署前为 agent 的决策领域定义公平性指标。公平的结果是什么样的？你将如何衡量它？ 2. 定期监控 agent 输出在相关人口统计维度上的差别性影响 3. 将工具输出纳入偏见分析。如果 agent 正在调用一个已知会产生差别性影响的评分 API，则 agent 会继承该偏见 4. 建立公平性审查阈值：什么样的结果分布会触发人类审查和潜在干预？ ## 领域 7：监管一致性与跨司法管辖区合规 **问题** Agentic 部署通常会跨越司法管辖区边界：模型托管在一个地区，数据在另一个地区，用户在第三个地区。每个司法管辖区可能对 AI 透明度、可解释性、人类监督和数据处理有不同的要求。 **关键风险** - 对于包含 Agentic 组件的高风险 AI 系统，存在 EU AI Act 合规缺口 - 当 agent 处理或路由受保护的健康信息时，存在 HIPAA 风险暴露 - 当 agent 在受控非密信息环境内或相邻运行时，存在 CMMC 合规缺口 - 联邦采购对 AI 透明度的要求未在治理设计中得到体现 **控制措施** 1. 根据每个 agent 部署的运作地点、处理的数据及其影响的对象，将其映射到适用的监管框架 2. 对于 EU AI Act：确定每个 agent 部署的风险等级。高风险应用需要人类监督、透明度文档和合规性评估 3. 对于 CMMC 环境：访问或处理 CUI 的 agent 必须满足与访问 CUI 的人类用户相同的访问控制、审计和事件响应要求 4. 将监管一致性作为 agent 部署记录的一部分进行归档。合规性是部署的先决条件，而不是上线后的审查 ## 实施顺序 对于开始对 Agentic AI 部署进行治理的组织，此顺序能以每单位努力产生最快的风险降低效果： 1. 构建 agent 注册表（领域 1）。你无法治理你看不见的东西。 2. 实施 kill switch 协议（领域 5）。在扩大部署之前，先确立阻止它的能力。 3. 为所有重大决策设计 Human-in-the-Loop 架构（领域 2）。要在部署前做这件事，而不是在发生事件后。 4. 将 MCP 工具访问权限锁定在白名单内，并开始记录 tool call（领域 3）。 5. 确立审计跟踪要求并测试可解释性（领域 4）。 6. 定义公平性指标和监控频率（领域 6）。 7. 完成监管映射（领域 7）。 ## 关于本框架 本框架是根据在金融服务、联邦政府和医疗保健技术环境中大规模治理 Agentic AI 部署的运营经验制定的。它以 NIST AI RMF (2023)、ISO 42001 (2023)、IAPP AIGP Body of Knowledge v2.1 (2026) 以及新兴的 Agentic AI 治理实践指南为基础。 欢迎反馈与协作。本框架是一份动态更新的文档。 **Jimi Ige** jimiige.com | linkedin.com/in/jimi-ige

标签：AI治理, DLL 劫持, 合规框架, 大语言模型, 身份与访问管理