没人回答的责任问题
您的 AI 销售 agent 刚刚向潜在客户发送了一份定价提案。价格比您的标准费率低 15%。agent 推断该潜在客户的购买历史和竞争信号证明了这个折扣是合理的。它选择了一个 CRM 工具来提取历史数据、一个邮件工具来发送提案、以及一个定价 API 来计算折扣。
谁批准了折扣?谁验证了定价逻辑?如果折扣违反了您的定价政策,谁负责?
如果您在没有治理基础设施的情况下运行自主 AI agent,答案是:没人知道。
三个责任差距
传统合规模型是为确定性软件设计的——每次都做同样事情的系统。AI agent 以三种方式打破了这个模型:
差距 1:Agent 自主推理
当 LLM 决定如何处理任务时,推理是涌现的。agent 考虑上下文、评估选项并选择方法——所有这些都在一次推理调用中完成。与可以追踪决策树的基于规则的系统不同,LLM 的推理是概率性的且不可重复的。
如果不记录推理过程——使用的模型、提供的上下文、生成的令牌——决策在生成结束的那一刻就消失了。思维过程没有审计追踪。
差距 2:Agent 动态选择工具
自主 agent 不仅仅推理——它们还采取行动。它们在运行时选择使用哪些工具:发送邮件、查询数据库、调用 API、更新记录。工具选择本身就是一个需要治理的决策。
谁批准了 agent 访问邮件 API?谁验证了定价数据库查询是适当的?没有工具审批门,每个工具调用都是一个未经审计的、具有潜在业务影响的操作。
差距 3:Agent 调整行为
最先进的 agent 从上下文中学习并在任务中途调整方法。处理客户支持的 agent 可能根据情感分析改变语气,根据账户价值升级,或根据过去的交互提供不同的解决方案。
这种适应性很强大——但它使每次交互都是唯一的。如何审计一个永远不会以完全相同方式重复的决策?没有捕获每个决策完整上下文的持久追踪,自适应行为对合规团队来说是不可见的。
为什么静态合规不起作用
传统合规假设您可以预先记录系统行为并定期验证。对于确定性软件,这有效。对于 AI agent,不行:
- 部署前文档无法捕获运行时决策
- 定期审计遗漏实时 agent 行为
- 基于规则的控制无法治理涌现推理
- 静态权限无法考虑动态工具选择
EU AI Act 认识到了这个差距。第 12 条要求自动记录事件。第 14 条要求人工监督机制。第 50 条要求对 AI 生成内容的透明度。这些不是可选的——它们是高风险 AI 系统的法律要求。
责任链
解决方案是一个治理架构,为每个 agent 决策创建完整、可审计的责任链。五个阶段,每个都完全可追踪:
阶段 1:用户意图 —— 用户要求 agent 做什么?记录时间戳、用户 ID、部门和完整请求上下文。
阶段 2:Agent 推理 —— agent 如何决定做什么?LLM 调用追踪模型、供应商、令牌使用和推理输出。如果 agent 使用多步推理(思维链),每一步都被捕获。
阶段 3:工具审批 —— 请求了哪些工具,谁批准的?工具审批门要求在 agent 使用敏感工具前进行显式审批。审批决策、审批人身份和时间戳都被记录。
阶段 4:执行 —— agent 实际做了什么?每个工具调用、API 请求和数据访问都带有输入、输出、持续时间和成本的日志。错误处理和重试逻辑都被追踪。
阶段 5:审计追踪 —— 完整记录,为合规而结构化。标准化格式的证据导出(OTel 兼容 JSON 带治理增强属性)、合规时间线可视化,以及跨 8 个类别的 17 个 Trust Service Criteria 控制。
如何映射到法规
| 法规 | 要求 | 责任链阶段 |
|---|---|---|
| EU AI Act 第 12 条 | 记录保存 | 阶段 1-5:完整事件日志 |
| EU AI Act 第 14 条 | 人工监督 | 阶段 3:工具审批门 |
| EU AI Act 第 50 条 | 透明度 | 阶段 1:交互披露 |
| NIST Agent Standards | 监控与事件响应 | 阶段 4-5:执行追踪 + 审计导出 |
| SOC 2 TSC | 安全与可用性 | 阶段 5:跨 17 个控制的证据导出 |
实际影响
有了责任链:
- 当 CISO 问”我们的 agent 本季度做了什么?“时,您有完整的答案
- 当审计师问”谁批准了这个工具访问?“时,您有审批记录
- 当监管机构问”您能证明人工监督吗?“时,您有升级历史
- 当客户问”这是 AI 生成的吗?“时,您有披露日志
每个 agent 决策。每个工具调用。每次升级。完全可追踪。
查看责任链实际运作:
- 责任链页面 —— 可视化追溯图
- EU AI Act 合规 —— 逐条能力映射
- 开始企业试用 —— 部署具有完整可追溯性的治理基础设施