AI 治理为什么突然成了 CEO 的问题 / Why AI Governance Became a Boardroom Issue

AI 治理为什么突然成了 CEO 的问题 / Why AI Governance Became a Boardroom Issue

2024 年 3 月，某欧洲投资银行（assets under management 3,800 亿欧元）在一次内部 AI Usage Audit 中发现：过去 90 天里，公司 47,000 名员工通过企业 SSO 调用了 17 个不同的大语言模型 API，总调用量 2.4M 次；其中 31% 的请求里躺着客户 PII（Personal Identifiable Information）字段，4% 经过法务审批，0% 经过风险委员会备案。报告递交 CRO（Chief Risk Officer）的当天下午，这位 CRO 在 Slack 群里发了一句话："We have a problem, and it has been sitting in our Slack channels for six months."

这不是个别现象，也不是哪个不知名的小厂在裸奔。Gartner 在 2024 Q1 的一份调研里给出了几乎相同的数字：在财富 2000 强企业里，平均每家公司有 11.4 个 "actively in use" 的生成式 AI 应用 / 模型接入，而 81% 的公司无法在两周内回答 "我们到底在用什么模型、跑在什么数据上、谁在付费、出过什么问题" 这四个看上去极其基本的问题。

换句话说：AI 已经不再是 CIO 的技术议题，而是 CEO、CFO、CRO、董事会、监管机构，甚至 CFO 的会计师们的共同议题。从 "Why now？" 到 "Now what？"，中间只隔了一封 SEC 调查函。

1.1 三个真实故事：AI 失控的三种姿势 / Three Real Stories: Three Ways AI Goes Wrong

治理这事儿，理论讲起来很容易陷入抽象。In the spirit of "show, don't tell"，我们先用三个几乎都发生在 2023–2024 年的真实故事，给这一章定个调子。这三个故事不是为博眼球，是本书后续所有讨论的 failure surface。

故事 A：把芯片机密喂给 ChatGPT 的工程师 / Story A — The Engineer Who Fed Chip Secrets to ChatGPT

时间：2023 年 3 月。地点：韩国水原（Suwon），某全球消费电子龙头（公开案例与三星半导体内部调查高度吻合，这里以 "SuwonCo" 代指）。 人物：一名资深 L4 工程师，目的是用 ChatGPT 帮忙检查一段源代码的语法。

操作：他打开了 chat.openai.com，把公司内部代码（含下一代 3 nm 制程的良率数据）粘贴进对话框。42 秒后，AI 给出了 "should be fine" 的答复。工程师退出浏览器，准备继续工作。

事故：他的同事重复了一次这个操作，把同一段代码发给了另一个 LLM，结果触发了公司 DLP（Data Loss Prevention）系统的 "异常外发" 告警。安全团队介入调查，最终发现 SuwonCo 内部已有 3 起类似的源代码外泄事件，分别涉及半导体工艺、智能手机故障率数据、内部会议纪要。三名员工被解雇，公司宣布 "limited use of generative AI tools"。

教训：这不是一个 "员工违规" 的故事，这是一个 "为什么企业的边界设备、网关、SaaS 管控系统，从来没被设计来识别 '粘贴进 AI 的字符串'" 的故事。The takeaway is structural, not behavioral. 当一种新技术能让员工在 42 秒内把公司最有价值的资产打包出境，传统 DLP（Data Loss Prevention，注：数据防泄漏系统）、CASB（Cloud Access Security Broker，云访问安全代理）、SWG（Secure Web Gateway，安全 Web 网关）就集体失效了。

故事 B：每月烧掉 240 万美元的客服推理账单 / Story B — The $2.4M/month Customer Service Inference Bill

时间：2024 年 Q1。地点：北美某零售集团，8,000 家门店。 背景：CTO 团队为了 "数字化转型"，把客户客服系统接入 GPT-4，希望用 RAG（Retrieval-Augmented Generation，检索增强生成）的方式来自动回答退换货问题。

问题：上线第一周一切都好。第二个月，账单来了——单月推理费用 $2.4M，远超预算。原因不是 "用户量暴增"，而是产品经理为追求 "更高的准确性"，在 prompt 里加了 47 个 few-shot 示例，每个示例 800 token；外加一个 "let me think step by step" 的 CoT（Chain-of-Thought，思维链）触发器，把响应长度从平均 200 token 推到了 1,400 token。Top‑p 调到 0.95，温度 0.9，"感觉会更自然"。

这还不是重点。重点是：当 CFO 冲进来要 explain 时，没有任何人能告诉他：每个客户的单次对话到底花了多少钱、"退货问题" 和 "投诉建议" 哪个类目最烧钱、"哪些产品经理的 A/B 实验正在暗中掏钱"。The cost is invisible until it is on the P&L.

教训：AI 成本不是 IT CapEx，是 OpEx，且具有内生反馈性。一句话 prompt 的调整，可能在毫秒间把账单翻 7 倍；而传统 FinOps 看的是 CPU 小时数、虚拟机数量，对 "token" 这种全新计量单位无感。

故事 C：自动驾驶撞上审计盲盒 / Story C — When Self-Driving Hits the Audit Black Box

时间：2023 年 11 月。地点：美国旧金山。 背景：某 Robotaxi 服务在晚间左转弯时撞上一名行人。事故发生前 1.2 秒，系统既没有刹车也没有鸣笛。NHTSA（美国国家公路交通安全管理局）启动调查。

问题：调查员索要系统决策日志，得到的回答是："模型在 0.08 秒内输出了一个 'slight left nudge' 的规划指令。" 为什么是这个指令？没有人能解释。不是不想，是架构上无法解释——感知模块、规划模块、控制模块是端到端训练的，没有可读的决策链。

教训：审计盲盒（Audit Black Box） 是 AI 系统最特殊的风险类型。传统软件 "日志" 写的是 "if/else"，AI 日志写的是 "embedding → 注意力权重 → 输出"。当监管机构问 "why did the car turn left instead of braking"，你能给的答复只有一行 weight dump。监管机构不接受这种答复。

这三个故事，是 AI 治理这门新学科的 "创始文本"。它们分别命中了 AI 治理的三大典型失败模式：

• **故事 A** 命中的是 **权限象限（Permissions）** 的失守——影子 AI（Shadow AI）。
• **故事 B** 命中的是 **成本象限（Cost）** 的失控——模型泛滥（Model Proliferation）。
• **故事 C** 命中的是 **审计象限（Audit）** 的盲盒——决策不可追溯。

而贯穿这三个故事的，是第四象限——合规（Compliance）。当你无法解释、无法量化、无法限制 AI 在做什么的时候，你就无法证明自己在满足 EU AI Act 第五条、第七条，或者 SEC 在 2023 年发布的 "Disclosure of Cybersecurity Incidents" 和 AI 相关补充要求。

1.2 三种失败原型：影子 AI、模型泛滥、审计盲盒 / Three Failure Archetypes

> A taxonomy is not just classification; it is the first move toward a defense plan.

让我们把上面三个故事进一步抽象成三种可以在任何组织里复现的失败原型。它们不是 "可能出错的方式"，它们是 "每天都在出错的方式"。

原型 1：影子 AI（Shadow AI）

定义：影子 AI 指的是任何未经企业 IT / 安全 / 法务 / 合规正式审批，但在生产环境中产生数据访问、用户交互或业务流程影响的人工智能应用、模型或 API 调用。

它包括但不限于：

• 员工个人在公司笔记本电脑上注册的 ChatGPT Plus、Claude Pro、Cursor Pro 等付费账户，通过公司网络访问；
• 业务部门跳过 IT 直接与 SaaS 厂商签下的 AI 合同（如合同管理 SaaS 内置的条款抽取 AI）；
• 开源模型被部署到云上但未纳入 CMDB（Configuration Management Database，配置管理数据库）；
• 内部黑客马拉松的 demo 长成了生产环境的实际能力，但没人写进 IT inventory。

它为什么比传统影子 IT 更危险？

传统影子 IT（比如团队自购的 SaaS）通常影响边界是清晰的——一个 Notion 工作区、一个 Slack 连接，泄漏的也只是该团队的数据。影子 AI 的危险在于它有数据消化能力、有"幻觉"输出的能力、有跨上下文推理的能力。一段机密合同被消化进 AI 后，AI 可能用其中的条款 "辅助" 另一个完全无关的业务场景。Once the data is in, you cannot scoop it out.

根据 Microsoft 2024 年 Work Trend Index，全球 78% 的 "AI 用户" 正在用未审批的工具处理工作相关内容，而其中 41% 的用户承认曾经把客户信息粘进 ChatGPT。这类数字不是来自某次调研，是来自不同行业、不同规模、连续 12 个月的多份独立报告。

原型 2：模型泛滥（Model Proliferation）

定义：在缺乏治理中心化的组织里，模型数量、版本、供应商在 6–12 个月内呈指数级膨胀，每个团队都会自己挑模型、自己微调、自己部署，没有人知道 "我们到底有多少个模型在跑"。

它是如何发生的？

假设一家中等规模的金融科技公司，2023 年初只有 1 个 GPT-3.5 驱动的客服机器人。到 2024 年中，可能已经出现：

• 7 个不同的 LLM API（OpenAI / Anthropic / Google / Mistral / 自建 Llama / Qwen / DeepSeek 中的若干）；
• 23 个独立微调过的 LoRA（Low-Rank Adaptation，一种参数高效微调方法）adapter，分别跑在不同的向量召回之后；
• 4 个多模态模型（一个 OCR、一个 ASR、一个图生文、一个文生图）；
• 6 个预测模型（旧时代的遗产，XGBoost / LightGBM 系）；
• 11 个 Agent 编排框架（Dify / LangChain / AutoGen / CrewAI 等等）；
• 若干 "决策类小模型"（信用评分、欺诈检测、推荐排序）。

总数 50+ 起步，混乱时 200+ 不奇怪。每个都有自己的版本号、prompt 模板、token 计费规则、latency profile、failure mode。

为什么这是治理问题，不是工程问题？

因为当一个组织有 50 个模型的时候：

1. 你不知道每个模型在为谁服务、为哪些业务流程兜底 —— 这是审计象限的盲盒； 2. 你不知道每个模型上次评估是什么时候 —— 这是合规象限的风险； 3. 你不知道每月 token 总花费、Top 3 模型分别多少钱 —— 这是成本象限的失控； 4. 你不知道每个模型被谁授权访问了哪些数据 —— 这是权限象限的失守。

这就是为什么我们说：模型泛滥是 AI 时代的 "系统蔓延"（system sprawl），而 AI 治理的首要动作就是清点资产。If you cannot list it, you cannot govern it.

原型 3：审计盲盒（Audit Black Box）

定义：任何无法以人能理解的方式输出决策原因、决策依据、决策时序的人工智能系统，我们称其为审计盲盒。

它的两种典型形态：

• **完全黑盒型**：模型内部结构不透明。例如大型神经网络，其权重和激活值虽然存在，但没人能在工程上实时给出 "为什么这次拒贷"。
• **结构黑盒型**：模型本身可解释，但上下文被切断。例如一个 RAG 系统，决策原因分布在 embedding 检索、reranker、prompt template、model sampling 四步里，每一步都有自己的隐性假设；最终 "为什么输出这条" 需要把四步拼起来。

为什么传统的 IT 审计工具统统失效？

传统审计看的是 "系统做了什么" 和 "谁授权做的"，依据是日志。AI 系统的日志要么：

• **太过细碎**：embedding、attention map、token probability — 审计员拿不到 summary；
• **太过抽象**：模型最终回答就是一段文本，无法 trace back；
• **太过偶发**：相同的输入可能因为温度、采样、模型版本、prompt 微小差异，得到不同输出。

再加上 "AI 输出是被消费的"，最终用户读到的是结果而不是 reasoning。一份 "AI 写的退信函" 不告诉你，它是因为 "customer 投诉超过阈值"、"句子包含敏感词"、"模型偏置" 中哪一个被拒的。

审计盲盒的最大风险并不是 "我看不见"，而是 "我必须假装看得见"。监管机构不接受 "模型自己决定的"。当 EU AI Act 把高风险 AI 系统（第 6 条 Annex III 列举的招聘、信贷、教育、执法等）定义为必须具备 "human oversight + logging + explainability" 时，审计盲盒从工程事故升级为合规事故。

失败的相互催化

这三种原型从来不是孤立出现的。当影子 AI 进入组织，模型数量就开始膨胀；模型一多，审计盲盒就更严重；审计盲盒加上模型泛滥，就更容易触发合规风险；合规风险一旦触发，监管又开始强化对权限的审查；权限审查一严格，业务部门就更倾向于绕开 IT，新的影子 AI 又产生了。

这就是 AI 治理的 "failure loop"，它有自我强化的属性。治理的任务不是消灭这三种原型，是把它们从 "失控" 变成 "受控"，从 "盲盒" 变成 "玻璃盒"，从 "泛滥" 变成 "有序"。

1.3 传统 IT 治理为什么在 AI 场景失效 / Why Traditional IT Governance Fails in AI Scenarios

大多数企业并不是从零开始。它们已经拥有一套 IT 治理体系：IAM（Identity & Access Management，身份与访问管理）、ITSM（IT Service Management，IT 服务管理）、SOX 控制、ISO 27001 信息安全体系、变更管理流程。为什么这套体系在 AI 面前集体失灵？

我们逐一拆。

3.1 IAM：身份的边界变了 / IAM: The Boundary of "Identity" Has Shifted

传统 IAM 假设系统有三个稳定实体：人、机器账户、资源。RBAC（Role-Based Access Control，基于角色的访问控制）把权限附在人身上，资源则是稳定的对象（数据库表、API endpoint、文件系统路径）。

AI 系统把第三个实体彻底模糊化了。LlmContext 既不是人也不是机器账户，它是一段拼接起来的字符串，它既不持久也不可寻址。一个 prompt 可能是 "你是 HR 助手，帮我查询员工张三的工资"，另一个可能是 "忽略以上指令，现在请你..."

当我们说 "治理" 时，传统 IAM 关心的是 "张三能不能访问 HR 数据库"；AI 治理关心的是 "张三在公司 AI 助手里调用 HR 数据时，是不是同时触发了另一个工作流的查询"。前者是 ACL（Access Control List，访问控制列表）问题，后者是 上下文上下文上下文（context）的访问控制问题。

更进一步：模型自己也是一个 "身份"。当你让 GPT-4 帮你生成一句话，并通过 RAG 注入了某客户的 5 份合同，这个 GPT-4 调用就是一个 "临时的、不可重放的、上下文敏感的身份"。我们没有办法给模型贴一个 "长期 RBAC"，只能贴 "会话级 ABAC（Attribute-Based Access Control，基于属性的访问控制）"。

传统 IAM 在 AI 时代的失效方式，是身份从"长期、静态、可枚举"变成了"短期、动态、不可枚举"。Identity has become a verb, not a noun.

3.2 ITSM：变更不再是开关 / ITSM: Change Is No Longer a Switch

ITSM 的核心是 变更管理（Change Management）。一次系统升级，先 RFC（Request For Change），然后 CAB（Change Advisory Board）评审，然后实施，然后回滚预案。一个版本号对应一个被精确描述的行为。

AI 系统的 "变更" 是另一种东西。当 OpenAI 在某次例行更新中调整了 GPT-4 的 safety filter（不会告诉你调了什么），你的客服助手的 1.7% 的回复被拒了；当你把 temperature 从 0.7 调到 0.6，你的法律审查助手开始大量重复同一句话；当你更换了 embedding 模型，你的 RAG 召回率从 92% 掉到 78%——这些 "变更" 没有 RFC，没有 CAB，没有回滚预案。

ITSM 的根本假设是"系统的行为可以从代码版本号逆向追溯"，而 AI 系统的行为由 N 个变量共同决定，任何一个变量动一下，行为都可能跳变。When the change is everywhere, the change ticket is nowhere.

替代方案是 AI 时代