13 篇博文 含有标签「ai-governance」

我在生产环境中见过的代价最高昂的偏差缺陷（bias bug），是通过一个 Twitter 讨论串发现的，而不是仪表盘。一个小团队发布了一个信用评分助手。他们运行了标准的发布前审计：平衡的训练集、对抗性去偏差（adversarial debiasing），以及留出集（holdout set）上低于 5% 的等同赔率差距（equalized-odds gap）。发布一个月后，一名用户发布了截图，显示其家庭中的女性在财务状况完全相同的情况下，获得的额度始终低于男性。当团队的监控系统反应过来时，监管机构已经开始介入调查。

教训并不是说这个团队懒惰。他们严格执行了文献推荐的审计流程。教训在于，发布前审计衡量的是模型的快照，而当真实用户接触到它时，那个模型早已不复存在。分布发生了偏移。新的人群出现了。提示词模板（prompt-template）的更改引入了措辞伪影（phrasing artifact），并与姓名产生了交互作用。模型升级悄悄地牺牲了校准度（calibration）来换取流畅度。你在 11 月进行的审计，无法保护 5 月在生产环境中运行的模型。

你的数据治理审计可能已经发现了它们：用个人信用卡支付的 OpenAI 和 Anthropic API 密钥，通过个人账户接入 Claude 的 Slack 机器人，通过企业 VPN 代理请求的本地 Ollama 实例。没有人通知平台工程团队，没有人请示 IT 部门。工程师们只是……自己动手做了。

这就是影子 AI 问题。无论你是否已经发现，它早已潜伏在你的组织内部。在知识工作环境中，大约一半的员工表示自己在使用雇主未授权的 AI 工具。在软件工程师群体中——他们既有能力搭建非官方集成，又面临提升生产力的压力——这一比例几乎肯定更高。

当法务团队问"AI 为什么拒绝了这笔贷款申请？"时，你的思维链追踪并不是正确答案。就算你有 1200 个 token 的逐步推理过程也没用。他们需要的是一句能在庭审中站得住脚的话——而现在，大多数工程团队根本不知道如何生成这样的解释。

这就是利益相关者解释鸿沟：工程师对模型行为的理解，与监管机构、高管和法律团队完成工作所需的信息之间的距离。弥合这一鸿沟需要一个独立的架构层——而大多数生产 AI 系统从未构建过这一层。

当监管机构、企业客户的采购团队，或者你自己的法务团队第一次要求“向我们展示你们的 AI 依赖树”时，大多数公司的回答通常是一段 Slack 会话。平台频道的某人呼叫模型团队。模型团队呼叫 Prompt 负责人。Prompt 负责人抄送给数据负责人。两天后，一份填了一半的电子表格出现在审计员的收件箱里，里面充满了“待定”单元格和一条脚注：“我们认为这是截至上周的最新数据。”

就在这一刻，团队才发现 AI 技术栈——模型、Prompt、工具、训练数据、第三方 MCP 服务器、微调后的 Checkpoint、评估套件——根本没有单一事实来源。软件供应链合规产生了 SBOM 作为监管机构和客户期望的产物。AI 产品具有类似的暴露面，但 SBOM 的概念仅止于代码依赖。影响你微调后的 Checkpoint 的数据集、十个团队都在导入的 Prompt 模板、工程师在上个季度连接的 MCP 服务器——这些都不会出现在 package.json 中。

在 “开放权重”（open-weight）这个词中，“开放” 二字承担了极大的重任。当一名工程师从模型中心下载 safetensors 文件时，他们往往倾向于将这种行为归类为与 npm install lodash 相同的心理范畴 —— 拉取依赖、上线功能、继续下一步。但伴随这些权重而来的许可证很少是 Apache 2.0 或 MIT。它通常是带有可接受使用例外项、署名要求、衍生品命名规则以及用户数量阈值的自定义社区许可证，一旦你的产品变得流行，这些阈值就会改变合同条款。而且，加载器几乎不会强制执行其中任何一项。无论你是否遵守，模型都会运行。

这就是合规债务如何悄无声息地累积的。如果团队将许可证审查视为一次性的下载检查，那么公司就在为一项审计结果埋单，而该结果将在点击 “我同意” 的开发者离职多年后才会显现。解决方法不是在入口处设置更严格的采购门槛，而是将模型权重视为供应链的一种严谨做法，具备来源追溯、定期重新审查以及一份能够将每条已部署的推理路径追溯回其上游许可证的清单。

两年前，一个团队将他们的检索索引指向了 Wiki、Zendesk 导出文件以及公共文档的快照。上周，同一个索引返回了一个已弃用的运行手册（runbook），告诉 SRE 去重启一个已不存在的服务。该运行手册已经废弃了 18 个月。没人负责它的下线工作，所以没人把它删掉。Agent 自信地引用了它。模型没有错；错的是语料库（corpus）。

这是检索评估（retrieval evals）中不会出现的故障模式：语料库被视为一次性的工程决策，而实际上它是一个持续的治理问题。负责初始摄取（ingestion）的团队早已解散。本应标记出客户机密 PDF 的法律审查从未发生，因为没人告诉法务部门存在这个流水线（pipeline）。“新鲜度策略”（freshness strategy）只是一个在第三季度离职的人留下的 Slack 消息。检索索引变成了任何人抓取过的每一份文档的共享收件箱，而纳入标准已逐渐演变为“任何容易摄取的内容”。

模型的输出曾经只是一个字符串。到 2026 年 8 月，它将变成一个带有监管链清单的签名制品（signed artifact），任何将其视为普通字符串的团队都将在截止日期的压力下进行补救式改造。

这种说法听起来可能有些戏剧化，直到你读到《欧盟人工智能法案》（EU AI Act）第 50 条。该条款将于 2026 年 8 月 2 日全面实施，要求生成式系统产生的任何合成内容都必须能被机器检测为 AI 生成。2026 年 3 月发布的《行为准则》（Code of Practice）明确指出，单一的标记技术是不够的——提供商必须将元数据嵌入（C2PA）与不可见水印结合起来，且输出内容必须在裁剪、压缩和截图等常见转换操作后依然存续。不合规的罚金高达 1,500 万欧元或全球营业额的 3%。这不仅仅是一个标签指南；这是一个签名制品的强制指令，它将落在每一个向欧盟市场发布生成式功能的团队头上。

这是一个周二早晨的对话，你的 AI 团队中没人为此做好了准备。新模型以影子模式（shadow mode）上线。不到一小时，评估仪表盘亮起：它对 4% 退款申请的分类与你上一季度运行的模型不同。大多数这类决策翻转看起来都是新模型是对的。房间里的一位成员——通常是汇报线中律师最多的那位——提出了一个让庆祝戛然而止的问题：那么，对于旧模型已经交付的 90 天决策，我们要怎么处理？

这就是智能体回填（agent backfill）问题。当一个更智能的模型开始产生比之前模型更正确的输出时，之前模型做出的每一个持久化决策都会变成一个有争议的记录。你本无意指责过去，但新模型在第一次对比追踪（traces）时就自动为你这么做了。现在你面临一个工程问题（我们能重演历史吗？）、一个法律问题（我们必须披露修正后的结果吗？）以及一个产品问题（用户会看到追溯性的变化吗？），这些问题发生了碰撞。

当你的第一个微调模型上线生产环境时，你的权重就成了一种你的隐私计划从未编目过的新型记录。进入训练组合的客户服务记录不再仅仅是数据库中你可以 DELETE 的一行 —— 它现在被冗余且不可提取地编码进了你的 API 所提供的参数中。原始记录可以从 S3 中擦除，从你的仓库中抹去，并从你的 RAG 索引中删除，而模型仍会继续使用该客户的姓名、账户 ID 或病史片段来完成提示词。你的销售团队签署的数据保护协议 (DPA) 承诺你会履行删除请求。但没有人问过 ML 团队这在技术上是否可行。

关于 PII 提取的研究表明，这并非假设。PII-Scope 基准报告显示，在现实的查询预算下，针对预训练模型的对抗性提取率最高可增加五倍；而使用自提示校准的成员推理攻击已将微调模型的 AUC 从 0.7 提升至 0.9。Llama 3.2 1B 是一个被广泛复制的小型基座模型，已被证明会记住其训练集中存在的敏感记录。对于任何在生产追踪数据上发布微调模型的人来说，结论是生硬的：你不能假设你的权重已经忘记了。

这一点很重要，因为大多数微调流水线是由 ML 工程师设计的，他们优化的是损失 (loss)，而不是由优化 GDPR 第 17 条款的数据主管设计的。结果产生了一个法律地位模糊、来源极少被记录、且不存在“删除用户 X”工作流的产物。

每个复杂的 AI 产品最终都会产生一个谁也不敢碰的 prompt。它包含三个条件分支，两个在处理客户报告的事故时临时粘贴进去的内联示例，以及一个以 “IMPORTANT:” 开头的句子，后面跟着一段没人记得是谁写的语气指令。这个 prompt 长达 1,400 个 token。最后一次修改它的 PR 是由一名早已转岗的工程师审核的。当新模型发布时，没人敢保证这个 prompt 依然有效。当评估（evals）结果下降时，没人确定是 prompt、模型、检索流水线还是下游工具导致的。这个字符串被四个服务共享。每个团队都有自己的本地覆盖（override），而且这些覆盖都没有文档记录。

这就是 Prompt 所有权问题，它是多团队 AI 工程中讨论最少却最普遍的失效模式。这不只是一个技术问题，而是康威定律（Conway's Law）在 token 层面的体现。一个组织的 prompt 最终会反映出它的组织架构、RACI 缺口和协作成本——而模型并不关心你的 Jira 层级，它只会为同样不在乎这些的终端用户产生不连贯的行为。

你的生产系统中有一个智能体删除了 10,000 条数据库记录。这次删除符合有效的业务逻辑 —— 这些记录被正确标记了。但三个月后，监管机构提出了一个简单的问题：谁授权了这个操作，智能体是根据什么依据做出决定的？你打开日志，找到了 SQL 语句，找到了时间戳，但什么都找不到了。

这就是决策溯源问题。你可以证明你的智能体采取了行动；但你无法证明它为什么这样做，或者这个行动是否曾经得到了一个真正理解自己在批准什么的人的授权。随着自主智能体开始执行跨越数小时、数十次工具调用、且决策具有真实世界影响的工作流，"我们有日志"与"我们有问责机制"之间的鸿沟已经在运营上变得危险。

走进几乎任何一家拥有在线 LLM 功能的工程团队，问一个简单的问题：谁负责管理提示词（Prompts）？你会听到一阵停顿，然后是一个耸肩，接着是一个经不起推敲的回答。“产品经理写了第一个版本。”“PM 在上个迭代（Sprint）里改了一下。”“我觉得它在某个 Notion 文档里，或者可能是 agent.ts 里的那个 const SYSTEM_PROMPT。”提示词正在生产环境中运行。它决定了用户看到的内容，决定了智能体采取的操作，也决定了下季度收入图表中显示的数字。然而，它的治理覆盖面甚至不如那个没人愿意承认动过的 CSS 文件。

这就是影子提示词库：堆积如山的字符串——系统提示词、few-shot 示例、工具描述、路由规则、评估器准则——它们共同定义了产品行为，却集体缺乏代码审查、部署流水线、负责人、弃用策略和审计追踪。它们是你 AI 技术栈中最关键的承重构件，也是受监管最少的环节。

后果已不再仅仅停留在理论层面。现在有 98% 的组织报告存在未经授权的 AI 使用，近一半的组织预计在 12 个月内会发生影子 AI 事件。监管机构的步伐比治理速度更快：欧盟 AI 法案（EU AI Act）的高风险条款将于 2026 年 8 月生效，其中第 12 条明确规定，将输出结果与提示词及模型版本绑定的日志必须是自动生成的，而非设想中的。如果你的提示词散落在十几个代码库和一个 Slack 讨论串中，你拥有的不是审计追踪，而是隐患。