45 篇博文 含有标签「governance」

Agent 事故发生后的第一个小时总是相似的。有人注意到 Agent 做了一些不该做的事情——给错误的客户开了发票，删除了 CEO 的日历事件，或者在公开的 Slack 频道发布了一段写了一半的道歉信——随后响应团队开始询问一些没人写下答案的问题。哪个下游系统持有审计日志？哪个值班轮换组负责该系统？该调用是否可逆，窗口期是多久？Agent 使用的凭证归谁所有，该凭证是否还允许它触及我们尚未检查的其他系统？编写 Agent 的团队很少掌握这些答案，因为答案存在于 Agent 调用的系统中，而且在发布时没人把它们统一记录在一个地方。

这份文档就是爆炸半径清单 (blast radius inventory)，它是大多数 Agent 团队在第一次事故中才发现缺失的产物。它不是安全检查表，不是工具 schema，也不是操作手册 (runbook)。它是 Agent 可以触及的每个外部系统的详尽列表，以及在该系统遭遇最糟糕状况时你所需的每一项事实。那些在没有这份清单的情况下发布 Agent 的团队，是在赌事故响应的上下文重构速度能超过爆炸蔓延的速度。随着 Agent 拥有的工具越来越多且功能越来越强大，这场赌局的胜算正变得越来越低。

90% 的公司员工都在使用个人 AI 账号——ChatGPT、Claude、Gemini——来完成工作，而其中 73.8% 的账号是非企业性质的。与此同时，57% 使用未经批准的 AI 工具的员工正在与其共享敏感信息：客户数据、内部文档、代码、法律草案。大多数高管认为他们的政策可以防止这种情况发生。但数据表明，实际上只有 14.4% 的团队部署的 AI 获得了全面的安全批准。

领导层认为正在发生的事情与实际发生的事情之间的差距，就是影子 AI 治理问题。

大多数公司的本能反应是下达禁令。在网络层面封禁个人聊天机器人账号、发布政策备忘录、进行年度培训，并称之为治理。这是最糟糕的应对方式——不是因为担忧是错误的，而是因为这种干预措施在没有缩小问题的同时，反而让问题变得不可见。

我上个季度合作的一个团队发布了一个 AI 助手，并附带了一整套完备的支撑文档：一个提醒 AI 可能会生成不准确结果的产品内工具提示（Tooltip）、一篇题为“助手如何工作”的帮助中心文章、一份处理升级问题的内部支持操作指南（Runbook），以及一份列出了底层模型、助手可调用的工具及其覆盖的数据领域的公开模型卡（Model Card）。发布过程非常顺利。六个月后，提示词（Prompt）被修改了 14 次，模型在不同层级间进行了切换，拒绝行为（Refusal Behavior）发生了微妙的变化，增加了两个新工具，一个工具被废弃但未从提示词中移除，语言设置也从仅限英语扩展到了 9 个语种。

每一份文档都出错了。并非灾难性的错误——而是那种一句话半真半假、描述的功能与模型实际表现不再匹配、记录的拒绝模式在新模型中从未触发、或者帮助文章里出现的工具名称助手根本不会调用的那种错误。这类错误会产生持续不断的令人困惑的支持工单，当 AI 做了文档说它不会做的事情时会导致客户信任倒退，并且——因为公司在受监管的垂直领域销售——还会产生一个微小但真实的合规漏洞，而 AI 团队中没有人想到要跟踪这一点。

在发生第一起涉及六位数损失的智能体（agent）事故后的第二天早晨，董事们不会询问模型是否处于世界领先水平。他们会要求查看风险登记簿（risk register）中列出该场景的那一行、签字的负责人，以及董事会上次审阅该记录的日期。如果你的企业风险登记簿中包含了网络、供应商、监管和运营风险，但唯独没有“自主智能体在我们的凭证下采取了导致客户可见损失的操作”这一行，那么你即将在董事会上花时间解释，为什么其他每一类风险都有的应对方案，在刚刚让你赔钱的这一类风险上却偏偏缺失。

这不再是假设。Gartner 预测，到 2026 年底，企业将面临超过 1000 起因 AI 智能体造成损害而引发的法律诉讼。在短短一年内，AI 相关风险在安联风险指数（Allianz Risk Barometer）中的排名已从第十位跃升至第二位。保险公司现在在董监高责任险（D&O）续保调查问卷中询问：董事会如何将 AI 纳入公司风险登记簿，以及如何跟踪第三方智能体风险敞口。下文列出的项目代表了一个可靠的答案应具备的内容，以及 AI 功能负责人必须据此进行辩护的节奏。

你所在的平台团队计划在第三季度调查的影子 IT 事件，其实早在 1 月份就已经发生了。情况大致是这样的：某个产品团队的一名高级工程师本月要发布产品。而平台团队的“官方” LLM 网关还在“下季度”的路线图中。于是，这位工程师用公司信用卡开通了 OpenAI 账号，将 API 密钥丢进 .env 文件，发布了功能，并赶上了公开的截止日期。发布非常成功。六个月后，FinOps 团队发现了三个无人认领的供应商账号，安全团队发现包含客户数据的 Prompt 被路由到了不受数据处理协议（DPA）保护的地区，而平台团队发现他们花了两个季度构建的网关只有 14% 的采用率，因为每个需要 AI 的团队都在没有它的情况下完成了发布。

这不是安全方面的失败，也不是纪律方面的失败。这是平台与产品交付速度之间的不匹配，如果将其视为其他任何问题，那么你发布的下一个网关注定会遇到同样的采用率问题。

隐私审计员在 SOC 2 续期前两天提出了一个问题：“为什么你入门引导提示词示例中的电子邮件字段是一个真实客户的地址？”产品团队在脑海中回溯了整个流程。一年前，当他们发布 AI 摘要功能时，有人需要为 few-shot 模板找一个“看看它是如何工作的”示例。他们从预发布环境（staging）中选取了一条具有代表性的客户记录，清理了明显的字段——姓名、账户 ID、电话——并提交了文件。该客户在六个月后流失了。根据数据保留政策，他们的记录已从数据库中删除。但该记录并没有从提示词模板中删除，而该模板已发布到了生产环境中的每一个租户。

团队曾像大多数团队一样，认为隐私边界就是数据库。提示词模板是代码。代码要经过评审。评审并不会标记 PII（个人身份信息），因为评审人员不会在标记为 example_input: 的 YAML 字符串中寻找它。能在 Slack 消息和邮件附件中捕捉 PII 的 DLP（数据泄露防护）扫描器不会扫描提交的代码，即使扫描，它也不会将部分清理过的客户记录识别为个人数据，因为它知道要查找的字段已被移除。剩下的所有内容——公司规模、行业、稀有的职位名称、特定的城市——都是扫描器没有规则去处理的数据。

周二早上收到了一张支持工单：一名客户收到了关于退款期限的、言之凿凿的错误回答。工程团队调取了追踪记录，发现模型识别错了意图。产品 PM 查看仪表板，发现上个迭代发布的“极速退款”入口触发了一个 Prompt 从未针对其进行过调优的意图。平台 PM 指着评估套件（eval suite）说，测试全是绿色的。两人在技术层面都是正确的。但客户得到的回答依然是错的。

这就是“两个 PM 问题”，大多数 AI 团队都存在这个问题，只是没有给它命名。产品 PM 负责面向用户的界面——意图、成功指标、支持升级路径。平台或 ML PM 负责 Prompt、模型选择、评估套件和成本上限。两者的路线图在季度规划层面是协调的，但在每周发布层面却在背道而驰，因为两个 PM 在不同的仪表板上针对不同的指标进行优化，且有着不同的变更控制流程。

这种有趣的失效模式并不是因为两个 PM 意见不合，而是因为他们都在各自的职责范围内正确地完成了发布，却共同导致了一个无人负责的退化（regression）。

一个编程智能体在凌晨 2 点合并了一项变更，导致客户的生产数据库下线了 90 分钟。一个客户服务智能体在循环被终止前，向外发送了 1.4 万封措辞错误的退款拒绝邮件。一个自主对账工作流对 2800 张卡进行了重复扣款。损失是真实的，审计追踪指向了你的公司，你的财务团队针对六周前续签的网络保险保单提出了理赔。保险公司的回复是一封礼貌的信函，解释说该保单涵盖的是“恶意第三方的未经授权访问”和“对员工的社交工程攻击”——而该智能体是经过身份验证的，其行为是经过授权的，且没有员工被欺骗。理赔被拒。损失只能由你的资产负债表承担。

这并非假设性的极端案例。它是未来 18 个月内最典型的理赔画像，保险业深知这一点。网络保险（Cyber）、职业责任险（E&O）和董事高管责任险（D&O）的保单条款是根据一种威胁模型校准的，在该模型中，泄露的严重程度取决于记录外泄的数量，而事故响应则取决于计费的取证小时数。智能体 AI（Agentic AI）产生的事故并非这种形态。它产生的是一种精算师没有任何基准数据可参考的形态，而保险公司在缺乏精算基准时的第一反应，就是将这种风险敞口完全排除在保单之外。

我合作过的一个团队在周三下午发布了一个“微小的提示词调整”。同一个 PR 还向智能体注册中心添加了一个新工具——一个对内部管理 API 的便利封装，提示词现在偶尔会调用它。评估套件通过了。金丝雀发布看起来也很正常。到周四早上，由于智能体处理了一个包含提示词注入攻击的支持工单，一名客户的计费记录被修改了。审计追踪显示，管理工具完全按照设计运行。值班工程师的第一反应——回滚提示词——毫无用处，因为凭证已经使用，数据行已经写入。

复盘报告将其定性为安全审查失败。其实不是。这是发布流水线的失败。团队通过相同的审查、相同的关卡和相同的回滚逻辑，发布了两个完全不同的资产类别——对模型的行为引导和授予智能体的新权限，就好像它们是同一种变更一样。它们并不是。一旦你将它们视为两个流水线，大多数关于“智能体治理”的争论就会变得清晰得多。

绿色 CI 并不意味着“这个提示词有效”。绿色 CI 的本质是“编写评测的工程师想不出这个提示词会如何出错”。这是两个截然不同的断言，而它们之间的差距正是生产事故的温床。一个评测套件并不是对模型的测量——它是对编写者的冰冷写照。他们的方言、领域知识、资历、偏好的失败模式，以及他们在编写测试用例时恰好使用的模型。根据构造，工程师没想到的测试内容统统未经测试。更糟糕的是：他们会从同一个视角不断扩展套件，因此随着套件的增长，盲点并不会缩小，反而会变得根深蒂固。

这就是评测作者单一化（eval-author monoculture）问题，也是当今 AI 工程中讨论最少、风险最高的可靠性问题。团队痴迷于裁判偏差、位置偏差、冗长偏差、泄漏和污染——但上游偏差其实是最初决定测试用例的人的偏见。其他任何评测误差来源都会被它放大。如果你的套件是由一个人编写的，那么你就拥有了一个带有性格的基准测试，而这种性格正是你的 CI 能够捕获风险的无形天花板。

一位产品经理写下了一段话：“助手应当乐于助人、准确且简洁，绝不能让客户感到匆忙。”一位工程师读了这段话，打开一个 YAML 文件，编写了 47 个加权标准，以便 LLM-as-judge 能够为每一个追踪（trace）生成一个分数。六个月后，那个 YAML 文件成了产品的实际规范。每一次发布都受其把关。每一次回归警报都基于它触发。每一个“达到发布质量”的决策都通过它来路由。而产品经理从未读过它。

这是当今 AI 工程中最为常见的、无意间发生的产品所有权转移。评估准则（rubric）不是对规范的衡量 —— 它就是规范，就像编译器不是对语言的描述，而是它的运行真相。就像编译器一样，评估准则也有决定语义的实现细节。哪种失败模式得 0 分而不是 0.5 分？哪个标准的权重是 0.3 而不是 0.05？哪些行为在评估准则中缺失，从而完全未被计算？每一个都是产品决策。而它们都没有出现在最初的任务书中。

一个客户给客服发邮件，询问为什么你的 CRM 智能助手停止起草他们的 NDA 了。你根本不知道你的 CRM 智能助手竟然在起草 NDA。一位资深用户抱怨说，你的客服机器人的他加禄语（Tagalog）翻译质量自上周以来有所下降。你根本不知道你的客服机器人还会他加禄语。一个论坛帖子传播了一个提示词，能将你的代码审查助手变成一个还算凑合的安全扫描器，不到一个季度，你就收到了针对该助手生成结果提交的 CVE 报告。其中的每一项都是一个拥有用户群、业务影响力，但完全没有组织归属的功能——没有评估（eval）、没有 SLA、没有在 UX 中体现、没有列入路线图，而且还有一个隐蔽的、仅为 1 的公交因子（bus factor）：那个摸索出这种用法的客户。

当你的产品封装了一个能力范围（capability surface）远超你设定范围的模型时，就会发生这种情况。用户会探索更广阔的能力范围，寻找能解决他们问题的行为，并在这些行为之上构建工作流。然后，当你进行下一次模型升级时，即便你的路线图上没有任何变动，他们也会将其视为一种退化（regression）。你与用户之间的契约不再是你书面写下的那份。它包含了模型碰巧为他们做到的、且你碰巧没有破坏掉的所有事情。

将此视为工程上的意外——“我们会强化提示词，增加护栏，下次我们会捕获到它”——这是一种范畴错误（category error）。“发现的能力”（Found capabilities）是一个产品管理问题。这门学科的核心不在于防止它们发生，而在于检测它们、决定如何处理它们，并记住你曾做出的决定。