12 篇博文 含有标签「governance」

打开你团队用来发布提示词（prompt）变更的配置仓库。看看最近的 30 个 commit。其中有多少个经过了代码审查（code review）？有多少个在 CI 中设置了评估门禁（eval gate）？有多少个你能——肯定地——归因为对看到它们的用户的生产环境行为产生了可衡量的变化？如果你的答案是“绝大多数”，那你是个例外。对于其他人来说，这些 commit 此刻正在生产环境中运行，而读取它们的系统所做的事情与特性标志（feature-flag）服务完全一致：热加载一个值，分发给用户，改变产品行为。区别在于，你的特性标志服务拥有审计日志、曝光追踪、熔断开关（kill switches）以及针对特定分群的定向投放。而你的提示词发布流水线只有 git push。

这并非隐喻。这是对你团队正在运行的生产系统的准确描述。提示词配置仓库、你的 worker 轮询的 S3 存储桶、数据库中的 “prompts” 集合、你的应用在启动时获取的 LangSmith/PromptLayer/Braintrust 资产——这些全都是特性标志服务。它们具有相同的运行时形态：一个存在于二进制文件之外的值，二进制文件在热路径（hot path）上读取它，更改该值即可在无需部署的情况下改变真实用户的行为。唯一缺少的，是你的 SRE 团队在批准“真正的”特性标志服务之前所要求的所有控制措施。

演示进行得很顺利。试点运行了六周，展示了清晰的成果，与会的利益相关者印象深刻。然后，什么都没有发生。三个月后，项目悄悄被搁置，构建它的工程师转向了其他事情，公司的AI战略变成了一张写着"探索机会"的幻灯片。

这就是扼杀AI项目的模式。不是技术失败，不是模型能力不足，甚至不是预算问题。技术本身确实有效——研究一再表明，约80%进入生产的AI项目达到或超过了预期目标。问题在于那70-90%从未走到那一步的项目。

一家大型保险公司的 AI 系统正在拒绝理赔申请。人工审核这些决定后，发现其中 90% 是错误的。这家保险公司的工程团队构建了性能出色的模型，MLOps 团队有完善的部署流水线，数据科学家有严格的评估指标。但这一切都无济于事，因为在董事会层面，从来没有人回答过这个问题：对于影响病人能否获得治疗的 AI 决策，我们可接受的失败率是多少？

这个缺口——功能正常的技术系统与缺失的高管决策之间的鸿沟——正是 AI 治理在实践中最常出现问题的地方。结果是：组织同时在生产环境中运行 AI，却暴露在从未正式承认的责任风险之下。

大多数工程团队是通过在截止日期前三周收到的一封法律邮件才了解到 GDPR 的。欧盟 AI 法案（EU AI Act）正在重演这一模式，而 2026 年 8 月 2 日针对高风险 AI 系统的强制执行日期已经非常临近，“以后再处理合规问题”已不再是一个可选项。GDPR 与 AI 法案的区别在于，GDPR 的合规大多是关于数据处理政策的。而 AI 法案的合规要求构建新的系统组件——这些组件在大多数生产环境中的 AI 系统中尚不存在。

法规中所谓的“人类监督义务”和“审计追踪要求”，转化为工程语言，就是一个仪表盘、一个事件日志和一个数据血缘系统。本文将欧盟 AI 法案视为一份工程规范而非法律文件，并逐步介绍你实际需要构建的内容。

一项针对 106 个企业 AI 系统的 appliedAI 研究发现，40% 的系统风险分类不明确。这一数字并不反映监管的复杂性——它反映的是有多少工程团队在交付 AI 功能时，从未追问该功能是否改变了合规层级。欧盟 AI 法案对高风险系统的强制执法日期定为 2026 年 8 月 2 日。届时，处于那 40% 之列不再是管理问题，而是一个架构问题——你将在监管机构注视之下，以四倍于原始成本的代价、在截止日期的压力下修复它。

本文不是法律概述，而是面向工程师的深度解读：哪些产品决策会悄然触发高风险分类，这些分类对应哪些具体交付物，以及为什么事后改造的成本远高于一开始就内置合规的成本。

一位初级产品经理在产品冲刺期间编辑了一个面向客户的提示词，让它"听起来更友好"。两周后，一位后端工程师调整了同一个提示词以修复格式问题。一位机器学习工程师，对这两次更改毫不知情，在一条单独的系统消息中添加了思维链指令，这与产品经理的编辑产生了冲突。这些变更都没有工单，都没有审查人，也都没有回滚计划。

这就是大多数团队管理提示词的方式。在五个提示词时，这令人烦恼。在五十个时，这是一个隐患。

我合作过的一个采购团队花了 11 周时间，对照一份 312 行的 RFP（征求建议书）电子表格给 4 家 LLM 供应商打分。他们谈妥了 99.9% 的正常运行时间 (uptime)、每 1K 输入 token 0.0008 美元的价格、SOC 2 Type II 认证，以及一份光鲜亮丽的基准测试 PDF——该文件显示他们选中的供应商在 MMLU 上领先 2.3 分。合同在周五签署。随后的周二，供应商悄然发布了一个模型更新，该团队构建的客服代理开始将大约 14% 的退款请求路由到错误的队列。正常运行时间 SLA 得到了遵守。基准测试得分没有变化。采购流程完全按照设计运行，而系统依然坏了。

这就是 AI 采购鸿沟。企业采购用于管理软件风险的工具——功能清单、正常运行时间保证、安全问卷、样本基准测试——都是为输出可重现的系统而构建的。这些工具都无法衡量真正决定 AI 供应商是否能持续为你工作的因素：由供应商控制而你无法控制的随机表面的行为稳定性。

当一位人工贷款官员拒绝一份申请时，这个决定背后有一个具体的名字。这位官员接收了特定信息，经过深思熟虑后做出了行动。推理过程或许并不完美，但它是可归因的——有人可以被联系、被质询、被追责。

当一个 AI 智能体拒绝同一份申请时，留下的只有一条数据库记录。这条记录表明决定已做出，但没有说明原因，没有说明是什么输入驱动了这个决定，没有说明当时运行的是哪个版本的模型，也没有说明系统提示词是否在两周前悄悄更新过。当你的合规团队将这条记录交给监管机构时，监管机构不会满意。

这就是智能体审计追踪问题，而大多数构建 AI 智能体的工程团队至今尚未解决它。

2024年，加拿大航空的聊天机器人凭空发明了一项并不存在的丧亲票价退款政策。法院裁定该公司须对机器人的言论负责。根本原因并非传统意义上的模型幻觉——而是优先级反转。系统提示写着"乐于助人"，实际政策写着"遵循已记录的规则"。当用户询问赔偿问题时，模型悄悄地将"高效解决问题"置于"升级投诉"之上，而没有人在这一判断影响公司之前对其进行审计。

这就是利益相关者提示冲突问题。每个生产级LLM系统都至少有三个指令来源：平台层（安全约束和基础模型行为）、业务层（运营商定义的规则、合规要求、品牌声音）以及用户层（实际请求）。当这些层相互矛盾时——它们终将矛盾——模型会选出一个胜者。问题在于，这个选择是由你的工程团队有意为之，还是模型在无人察觉的情况下自行决定的。

大多数团队认为内部 AI 工具比面向客户的 AI 产品需要更少的安全工作。这个逻辑看起来很明显：员工是受信任的用户，爆炸半径是可控的，你随时可以通过一条 Slack 消息来修复问题。这种直觉是危险的错误。内部 AI 工具往往需要更多的安全工程——只是完全不同的类型。

去年报告了 AI 智能体安全事件的 88% 的组织，大多数并非通过面向客户的产品受到攻击。这些事件来自拥有对业务系统的环境权限、访问专有数据以及隐式信任员工会话的内部工具。

大多数构建 AI Agent 的团队在第一个月都在追求性能：更好的提示词、更智能的路由、更快的检索。接下来的六个月，你则会忙于补救之前忽略的东西——治理（governance）。无法被审计的 Agent 会被法务部门叫停。没有权限边界的 Agent 会在预发布环境中造成混乱。没有人工升级路径的 Agent 则会在规模化运行时悄无声息地犯下严重的后续错误。

一个令人不安的事实是，大多数 Agent 部署之所以失败，并不是因为模型性能不足，而是因为围绕它的脚手架（scaffolding）缺乏结构。近三分之二的企业正在尝试 Agent；但只有不到四分之一的企业成功实现了生产规模化。差距不在于模型质量，而在于治理。

在 AI 的大部分历史中，治理问题从根本上说是关于输出的：模型说了错误、冒犯或机密的内容。这固然糟糕，但它是受控的。影响范围仅限于读取该输出的人。

智能体 AI（Agentic AI）完全打破了这一假设。当一个智能体能够调用 API、写入数据库、发送电子邮件并生成子智能体时，问题就不再仅仅是“它说了什么？”，而是“它做了什么、针对哪些系统、代表谁做的，以及我们能否撤销它？”近 70% 的企业已经在生产环境中运行智能体，但其中大多数智能体在传统的身份与访问管理（IAM）控制之外运行，使其处于不可见、权限过高且未经审计的状态。