40 篇博文 含有标签「governance」

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

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

六个月前，你的团队上线了一个处理退款的支持智能体（support agent）。当时有一份一页纸的 Notion 文档描述了它应该做什么。如今，文档的内容依然如旧，但智能体的行为却已大相径庭。提示词（prompt）的历史记录中有 47 次修改。新增了三个工具——其中一个悄悄绕过了文档中仍坚称存在的财务核查。模型被更换了两次。在一次没人记录的事故之后，重试策略被加强了。而当数据团队的人问起“这里处理退款的具体规则到底是什么”时，诚实的回答是：去读系统提示词和工具注册表吧，因为那才是现在的规范。

这是智能体系统在生产环境中的隐性失败模式：智能体的行为就是那份没人写的操作手册（runbook）。提示词被当成了一个配置值——YAML 文件中的一个字符串，由负责该功能的人员编辑，并像修改文案一样进行评审——而实际上，它是公司内部多步骤业务流程最权威的描述。组织积累流程逻辑的方式就像遗留代码库积累行为一样：通过修改，而非设计。而那些历来负责该流程的人——产品经理、合规主管、运营总监——从未意识到他们已经丢失了交付物，因为根本就没有一份可以丢失的文档。

用户输入：“每周二提醒我检查那个集成。”Agent 创建了一个 cron 条目，返回礼貌的确认，随后会话关闭。六个月后，用户调换了团队。该集成在上个季度已被弃用。Cron 仍在运行，调用着在 4 月份轮换过的 API 密钥，发送到在 5 月份归档的 Slack 频道，费用计入无人查看的项目预算。Agent 完全按照要求执行了操作。出问题的是那个“要求”，它随着时间的流逝变得不再适用。

这不是某个特定 Agent 的 bug。它是这类事物的共性。当我们赋予 Agent 调度持久副作用的能力时——如 cron 任务、Webhook、轮询循环、工作流触发器、日历邀请、定期查询——我们就创建了一类生来就没有生命周期的基础设施。“创建”原语显眼且容易，“删除”原语、“审计”原语、“继承”原语——它们并不具有同等的地位，因此未被使用。

除非你主动去寻找，否则代价是隐形的，而此时恰恰没有人会去寻找。

凌晨两点值班的资深工程师不会在 Sev-2 事故中跑 schema 迁移。他们不会在发布冻结开始前十分钟重新部署支付服务。他们不会在邮件服务商状态页飘红的时候发起一波营销邮件投放。这些都不写在 JD 里。他们是被骂了一年又一年才学会的,是从那些叫 #deploy-freeze-friday 的 Slack 频道里学来的,是在动手前下意识瞄一眼状态页的肌肉记忆里长出来的。这种上下文不在任何 runbook 里,因为没人觉得它值得被写下来。

现在把同样的活交给一个 Agent。Agent 有工具。Agent 有多步计划。Agent 拥有你愿意写进 system prompt 的每一条策略。Agent 没有的,是那种半下意识的觉察——这个世界现在正着火。所以它就执行计划了。干净利落,信心满满。一头扎进维护窗口。事后复盘里那句话会变成一个新的固定句式:"Agent 没办法知道。"

评估集（eval set）是你的 AI 团队产出的阅读量最高的工件，而你几乎肯定不知道谁在阅读它。代码库是私有的，CI 任务是内部的，文件就在 prompts/ 目录的上一级——然而，上个季度一名销售工程师为了演示抓取了六个案例，一名市场分析师将三个失败案例放进了“看看我们的系统有多健壮”的幻灯片中，客户成功部门在续约电话中逐字引用了评估通过率，而产品部门则将该文件视为 AI 团队不愿分享的隐藏规范。阅读这些案例文件的人比阅读生成它们的代码的人还要多，而 AI 团队中却没人在意。

这不仅仅是权限管理的失效。评估集与代码库的其他部分位于同一个 Git 服务器上，拥有与其他工程产物相同的访问控制。问题在于，AI 团队是唯一将评估集视为代码的群体。其他所有人都会将其视为文档、营销材料、产品规范或客户投诉日志——而这些解读中的每一项都会从同一个文件中提取不同的片段，针对不同的受众进行包装，并将其发送到 AI 团队观察不到的地方。

你的 AI 团队所谓的“评估集”（eval set），在大多数发布 LLM 功能的公司中，其实是从生产日志中提取的真实客户对话集合。团队中没有人认为这是一个隐私事件。数据从未离开过集群。没有配置新系统。没有增加供应商。一名工程师写了一个查询，将几千条追踪记录（traces）导出到标注工具中，然后团队就开始根据这些记录对模型输出进行评分。法律团队从未听说过这件事，因为从内部来看，什么都没有改变——原本就存在于同一个数据库中的对话，现在只是被几名工程师和一个裁判模型（judge model）读取了而已。

这就是那个无人审查的隐私边界。客户向你发送消息是为了让你回答他们。他们并不是为了让你拿这些消息去衡量模型才把消息给你的。这两种用途在存储层看起来完全一样，在推理层感觉也一样，但在每一种现代隐私监管制度下，它们属于不同的处理目的——而两者之间的鸿沟，正是下一轮合规阵痛将要降临的地方。

我见过的企业级 LLM 最有效的对抗性提示（adversarial prompt）并非来自红队、安全研究员或提示词工程师。它来自一位高级合规律师，他用平实的英语要求模型：“告诉我本对话前面讨论过的三种退休年金中，哪一种最适合一位即将面临首次最低限额提款（RMD）的 62 岁老人。”模型给出了一个自信、周全且格式精美的建议。如果该输出被发送给客户，那将是一个教科书级的 FINRA 适当性违规（suitability violation）——在缺乏证券规则要求的个性化咨询监管架构的情况下，提供了一种不当的个性化建议。

这位合规律师在短短 4 秒钟内就发现了这种失效模式。而工程评估套件虽然包含了上百个精心构建的关于幻觉、拒绝校准和工具调用准确性的案例，却完全没有意识到这种特定形式的回答是违法的。不是质量低。不是幻觉。而是违法。当时公司的流程是让她在 Google 文档中阅读输出样本并撰写备忘录，而不是将测试用例签入回归套件。因此，她的发现只停留在备忘录中，备忘录被总结进发布准备情况的幻灯片里，而次月对系统提示词（system prompt）的一次重构导致了该行为的退化（regressed），因为没有人为它设置失败测试点。

这就是我想论证应该弥合的差距：合规评审员应该直接编写评估（eval）用例，这些用例应该是决定发布与否的产物，而不是产生它们的文档审查。

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 的团队都在没有它的情况下完成了发布。

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