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

两年前，一个团队将他们的检索索引指向了 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 讨论串中，你拥有的不是审计追踪，而是隐患。

对系统提示词（system prompt）的一个单词修改在生产环境中运行了 21 天，期间没有人发现它误分类了数千份抵押贷款文件。估算的损失：340,000 美元的操作效率低下和 SLA 违约成本。没有人能说出是谁做的改动，什么时候改的，或者为什么要改。提示词存放在一个环境变量中，有三个团队拥有写入权限，而且没有人认为自己有责任对其进行审核。

这就是提示词所有权（prompt ownership）问题。随着 LLM 驱动的功能在企业中激增，提示词已成为技术栈中影响最深远、但治理最薄弱的资产。它们控制模型行为、塑造用户体验、执行安全约束并定义业务逻辑——然而，大多数团队管理提示词的严谨程度甚至不如修改一次 CSS。