3 篇博文 含有标签「audit」

审计员的问题听起来很简单。她翻开你的申诉日志，指着八个月前的一行，询问是哪个模型决定了那个案例。你的工程师调出了 Schema：有一个 model 列，审计窗口内的每一条决策都显示为 v1。接着，平台团队的一位成员随口提到，在审计期间，v1 背后的别名（alias）轮换了四次——一次基础模型升级、一次微调刷新、一次供应商侧的容量迁移，以及一次在事故期间持续了六个小时的回滚。诚实的回答是，你无法确定是哪一个 Checkpoint 产出了那个决策。审计员记录下了一些内容。那个回答不是监管机构能接受的答案，而你刚刚意识到，你交付的系统未能满足一项它从未被设计去满足的审计要求。

这里的差距不在于缺失了一行日志，而在于对“模型”含义的两种不同理解。对于交付系统的工程师来说，v1 是一个 Endpoint——一个稳定的契约，调用者可以指向它，而其背后的东西则可以免费升级。对于审计员来说，“产生此决策的模型”是一个特定的 Artifact：一个权重 Checkpoint、一个哈希值，一个原则上你可以在相同的输入上重新运行并获得具有辩护一致性输出的东西。Endpoint 别名是为了向调用者隐藏 Checkpoint 的轮换而发明的。而审计级的溯源要求恰恰相反——每一项决策都必须能追溯到产出它的确切 Checkpoint。这两个想法从一开始就处于碰撞轨道上；审计只是它们相遇的地方。

调出你今天早上的 SSO 日志。每一条 Slack 消息、每一个 GitHub PR、每一项日历邀请、每一次 CI 运行、每一条 Jira 评论——它们都显示着与人类手动输入完全相同的信息：一个人的名字、一个会话令牌（session token）、一行绿色的“身份验证成功”。从审计的角度来看，你根本无法分辨哪些行为来自人类，哪些来自人类启动后便置之不理的智能体。这就是“幽灵员工”问题，而且过去 12 个月里上线了智能体的团队几乎都面临这个问题。

导致这一问题的捷径是结构性的，而非疏忽大意。当你将智能体接入工具时，最简单的凭证就是工程师环境中现有的那个——他们的个人访问令牌（personal access token）、OAuth 会话或绑定设备的 SSO Cookie。替代方案则是一项平台级工程：配置一级身份（first-class identity）、在每个下游服务中进行联邦认证、将其接入审计流水线、构建针对每个实例的撤销机制。这些工作无法在一个 Sprint 内完成，也不会出现在功能路线图中。因此，智能体选择了“借用”。

一个用户打开聊天窗口，请求退款，得到“抱歉，此次购买不符合退款条件”的回复后，关闭了标签页，再也没有回来。在内部，智能体生成了一条完美的追踪记录：工具调用、中间推理过程、参考的政策包，以及运行的模型版本。每一个 span（追踪跨度）都进入了可观测性平台。但没有任何内容是用户可以触及的。这里没有标为“请求人工再次审核”的按钮，即使有，后面也没有相应的服务。这个决定在默认情况下就是终局，而非设计使然。

这就是“可争议性差距”（contestability gap），它是监管机构、律师和愤怒的用户接下来要撕开的口子。这也是一个最典型的例子：一个从外部看像是政策问题，而从内部看实际上是工程链路（plumbing）的问题。