治理的回归：从模型即产品到模型即受控服务 / The Return of Governance

第 1 章 治理的回归：从模型即产品到模型即受控服务

The Return of Governance: From Model-as-Product to Model-as-Controlled-Service

2023 年 3 月初，三星电子（Samsung Electronics）半导体部门的工程师为了排查一段代码缺陷，将整段含有晶圆良率参数、良率提升专有逻辑的源码贴入 ChatGPT 对话框。同月，第二次、第三次，类似事件接连发生。OpenAI 的服务端不仅看到了这些字符串，而且按照 ChatGPT 的产品协议，把它们永久存入了模型对话记忆与人类反馈训练池。仅仅 30 天后，三星发现无法通过任何技术手段回收已经外泄的机密——它们已经被合并进 OpenAI 的语料改进流程。三星随即将 ChatGPT 列入全公司禁用名单，并紧急启动内部 LLM 项目"三星 Gauss"。

这个事件像一道分水岭。它不是一次孤立的泄密事故，而是一个信号：在 Generative AI 让任何员工都能在 5 分钟内构建一个"AI 应用"的当下，企业传统 IT 治理体系——RBAC、SOC2、ISO 27001、ITIL——正在以肉眼可见的速度失效。本章要回答的核心问题是：当 GenAI 把"开发者"和"使用者"的身份压缩到同一台笔记本电脑上时，治理为什么必须从"可选项"变为"生死线"？

我们将沿着三条主线展开：第一，回顾 GenAI 之前三年企业 AI 治理的真实创伤；第二，归纳 LLM 带来的三大结构性冲击波；第三，提出"五大支柱"框架（Identity / Auditability / Cost / Compliance / Lifecycle），给出可立即落地的成熟度自评表，并勾勒本书 15 章的技术地图。

1.1 LLM 时代的三大治理冲击波 / Three Governance Shockwaves of the LLM Era

在 2020 年之前，企业 AI 部署遵循一条相当稳定的链路：数据团队清洗数据 → 算法团队训练模型 → 平台团队部署为内部 API 或批处理任务 → 业务团队通过 Web 控制台消费。整个链路被严格嵌入企业 IAM、CMDB、变更管理流程之中。一个模型从立项到上线，平均周期 6–9 个月，需要经过架构评审、安全评审、合规评审三道关卡。

LLM 改变了这一切。ChatGPT 在 2022 年 11 月上线后的 60 天内，全球企业用户突破了 1 亿。到 2023 年中，几乎每一家 Fortune 500 公司的员工都已经在用消费级 LLM 工具处理工作内容。Gartner 2024 年发布的调查指出：超过 70% 的企业员工承认在工作中使用未经 IT 批准的生成式 AI 工具。这不是技术变化，而是治理范式的颠覆。

我们将这种颠覆归纳为三大冲击波。

1.1.1 非人身份（Non-Human Identity）的爆炸式增长

传统 IAM 体系是为"人"设计的：员工入职、权限授予、离职回收。即使有 Service Account，也是 IT 团队显式创建、明确审计的。

LLM 时代，"使用者"和"被使用者"被分离开来。一个 LLM Agent 会代为调用工具、访问数据库、调用 API、发起网络请求——所有这些动作都需要身份。在 Anthropic 2024 年发布的 Model Context Protocol（MCP）规范草案中，我们看到一个 Agent 在执行一次"帮我订机票"的任务时，会自动派生至少四类身份：MCP 客户端身份、Tool 身份、API 调用身份、数据库连接身份。

更复杂的是：LLM Agent 的身份不是静态的。同一个 Agent 会因为任务上下文不同而调用不同的 API；同一个 API 会被不同的 Agent 调用；一个 Agent 在每次会话中可能产生数十次身份切换。这与传统 IAM 的"账号 → 权限 → 资源"三元组模型严重不兼容。

AWS 在 2024 年 re:Invent 大会上披露了一个细节：在他们一个客户的 AI 推理集群里，非人身份的访问令牌数量是人身份的 17 倍。Google Cloud 的 IAM 团队则在内部白皮书里把这种现象称为 *"identity inflation"*。身份通胀的代价是：审计日志的信噪比急剧下降，安全团队无法从数十亿条 API 调用中识别出真正的异常行为。

1.1.2 推理路径的不可观测性（Unobservable Inference Path）

传统应用系统的执行路径是确定性的：用户点 A 按钮，系统按代码规定的顺序执行 B、C、D 函数，调用 E 数据库，写入 F 日志。审计员可以一行一行地回溯。

LLM 应用打破了这种确定性。RAG（Retrieval-Augmented Generation）系统的执行路径如下：

1. 用户提问 → 2. 向量数据库召回 Top-K 文档 → 3. 文档重排 → 4. Prompt 拼装 → 5. LLM 推理 → 6. 结果格式化 → 7. 返回用户。

这条链路中的每一步都引入了不确定性：Top-K 召回的文档是哪些？Prompt 拼接的顺序如何影响输出？LLM 在不同温度（temperature）下会给出不同回答？这种"概率性执行路径"使得传统的"控制流审计"（control flow audit）几乎失效。

更糟糕的是，多 Agent 系统（Multi-Agent System）进一步放大了这种不可观测性。当一个主 Agent 把任务分解给子 Agent，子 Agent 又递归调用工具时，整个调用栈可能跨越数十个节点，而其中每一个节点都可能独立决策。OpenAI 在 2024 年发布的"Agents"白皮书里直接承认："We do not have first-class observability for multi-agent systems today."

这种不可观测性带来的直接后果是：SOC（Security Operations Center）分析师无法定位异常行为，DPIA（Data Protection Impact Assessment）审计员无法验证数据流向，模型风险（Model Risk）管理团队无法对模型的每一次决策归因。

1.1.3 合规边界的模糊化（Blurred Compliance Boundary）

传统合规框架的基石是"角色—资源—动作"的三元映射：医生可以读 P0 病历、护士可以读 P1 病历、行政人员只能读脱敏后的统计信息。PII、PHI、PCI-DSS、GDPR、HIPAA，这些框架都假设数据有明确的"边界"——一个文件系统目录、一个数据库表、一个 S3 桶。

LLM 把所有这些边界都模糊化了。

第一个层面：数据被 LLM 重新组合。当一个客服 Agent 同时调用订单数据库、产品手册、退货政策、用户画像四类数据源时，它生成的输出是这四类数据的"组合产品"。这个产品在源数据层面可能都没有违规，但在组合后可能泄露了不该被同一个人同时看到的信息。

第二个层面：Prompt Injection 导致边界穿透。攻击者可以在用户输入里嵌入恶意指令，诱导 LLM 越过本来的权限边界。例如，让一个客服 Agent 把内部价格表"翻译"成公开网页。2024 年 OWASP 发布的 Top 10 for LLM Applications 列表里，*Prompt Injection* 和 *Insecure Output Handling* 并列第一位。

第三个层面：跨境数据流动的合规盲区。当一家欧洲企业使用美国云厂商的 LLM 服务时，用户输入的数据流向了美国服务器。根据 Schrems II 判决，这种流动需要 SCC（Standard Contractual Clauses）或者充分性认定作为法律基础。但当 LLM 厂商进一步把数据用于模型训练时，合规链条断裂——用户根本无法知道自己的输入是否会被用于训练下一代模型。

1.2 真实事件剖析：从三星到加拿大航空 / Real Case Anatomy

抽象的冲击波需要落到真实事件上才有血肉。本节剖析四个具有标志意义的案例，它们分别对应三类治理失效：机密泄露、幻觉责任、权限越界。

1.2.1 三星半导体机密泄露事件（Samsung Semiconductor Leakage, 2023）

事件回顾：2023 年 3 月，三星电子 DS（Device Solutions）部门连续发生三起员工违规使用 ChatGPT 事件。第一次是某工程师为排查代码缺陷，将包含晶圆良率参数的源码粘贴进 ChatGPT；第二次是某研究员让 ChatGPT 总结会议纪要；第三次是某开发者直接请 ChatGPT 优化一段专有算法。这三起事件涉及的内容包含三星核心工艺参数、产品路线图、内部会议记录。

事件细节与时间线：根据韩国《经济日报》（Kyunghyang Shinmun）2023 年 4 月的报道：

• **3 月 11 日**：第一次泄密事件发生，工程师使用 ChatGPT 排查源代码 bug。
• **3 月 15 日**：第二次事件，会议纪要被上传。
• **3 月 20 日**：第三次事件，专有算法被输入。
• **4 月初**：三星内部 IT 安全团队在 OpenAI 的 API 网关日志中发现了异常上传行为。
• **4 月 12 日**：三星电子正式宣布将 ChatGPT 列入禁用名单，要求所有员工立即停止使用消费级 AI 工具。
• **5 月起**：三星启动内部 LLM 项目，最终命名为"三星 Gauss"，由 DS 部门和 SAIT（三星先进技术研究院）联合开发。

治理失效的多重维度：

1. 身份治理失效：肇事工程师都有合法权限访问这些源代码，但他们的身份管理系统完全不知道这些内容会被粘贴到外部 LLM 对话框里。DLP（Data Loss Prevention）系统只监控了邮件、U 盘、云盘上传，没有覆盖浏览器到外部 LLM 的内容流动。 2. 可观测性失效：OpenAI 在事后通知中明确指出，用户输入的数据无法从训练数据中单独删除，只能通过关闭整个账号的"聊天历史与训练"功能来阻止进一步使用。这意味着数据已经进入不可回收状态。 3. 合规边界失效：三星与外部 LLM 供应商之间没有专门的数据处理协议（DPA），普通的 SaaS 合同条款没有覆盖"用户输入可能成为训练数据"这一情形。

事后影响：三星 Gauss 项目在 2024 年正式上线后，被强制部署给 20 万名员工，但它在产品能力上明显落后于 GPT-4。这揭示了一个治理与创新的核心矛盾：严格的治理会拖慢业务响应，但放任的治理会带来不可逆的损失。

1.2.2 加拿大航空客服幻觉败诉案（Moffatt v. Air Canada, 2024）

事件回顾：2024 年 2 月，不列颠哥伦比亚省民事仲裁庭（British Columbia Civil Resolution Tribunal, BCCRVT）裁决了 Moffatt v. Air Canada 一案。原告 Jake Moffatt 的祖母去世后，他访问加拿大航空的客服 chatbot 询问丧亲票（bereavement fare）政策。Chatbot 错误地告诉他可以先买全价票、之后再申请丧亲折扣退款。他照此操作后，加拿大航空客服拒绝退款，理由是丧亲折扣必须在购票前申请。

判决要点：仲裁庭长 Christopher Rivers 在裁决书中写了一段被广泛引用的话：*"...the chatbot's responses are not merely 'informative' — they are representations made by Air Canada and form part of the contract negotiation."* 也就是说，chatbot 的回答构成加拿大航空的"意思表示"，公司必须为 AI 的错误回答承担法律责任。

治理失效的多重维度：

1. 生命周期治理失效：这个客服 chatbot 上线前，加拿大航空没有进行结构化的幻觉（hallucination）测试，也没有建立人工兜底（human-in-the-loop）流程。一个生产环境的客服 Agent 没有最低准确率门槛。 2. 可观测性失效：在事后调查中，加拿大航空无法回答"这个 chatbot 的回答依据是哪些政策文档"——这意味着系统的可追溯性（traceability）几乎为零。 3. 责任归属失效：加拿大航空在庭审中辩称，chatbot 是一个"独立工具"，其错误回答不应归责于公司。这一抗辩被法庭明确驳回，确立了"AI 输出 = 公司输出"的法律原则。

判例意义：这是全球范围内第一个明确认定企业对生成式 AI 输出承担法律责任的司法判例。它直接改写了企业的 AI 部署策略：任何面向客户的 LLM 应用都必须经过严格的事实性核查（groundedness check），否则将面临法律责任。

1.2.3 M365 Copilot 越权读取事件（M365 Copilot Over-read, 2024）

事件回顾：2024 年初，多家 Fortune 500 企业的 IT 安全团队发现，Microsoft 365 Copilot 在用户提问时，会通过 Microsoft Graph API 检索用户"有权限访问"的所有文档。这意味着，如果一名销售经理在过去三年里因为各种历史原因被加入了多个 SharePoint 站点的访问组，Copilot 会自动把所有这些站点的内容整合到回答里。

具体场景：某大型金融机构的合规团队发现，一名普通分析师在向 Copilot 提问"我们部门上周的销售会议内容是什么"时，Copilot 不仅返回了本部门的内容，还返回了其他部门的并购讨论、内部薪酬数据等远超业务需要的信息。原因在于该分析师的账户虽然能访问本部门文档，但通过间接群组（nested group）继承了过宽的 SharePoint 权限。

治理失效的多重维度：

1. 身份治理失效：Microsoft 365 的 SharePoint 权限继承模型在十多年里积累了大量"隐性授权"（implicit grants）。这些授权在传统搜索（关键词匹配）下很少被触发，但在语义检索（RAG）下被大规模激活。RAG 把"权限膨胀"从理论问题变成了现实问题。 2. 可观测性失效：Copilot 在回答用户时，不会显示它检索了哪些文档、为什么检索这些文档。用户（以及审计员）无法事后回溯 AI 的"思考过程"。 3. 合规边界失效：在金融行业，这种"看到不该看到的内容"本身就构成 SOX 控制点失效。即使没有恶意行为，"被访问过"这一事实就足以触发审计违规。

微软的应对：2024 年 5 月，微软紧急上线了 SharePoint Advanced Management（SAM）功能，引入了"Copilot 范围限制"（scope limits）、"过度共享检测"（oversharing detection）、"敏感度标签强制"（sensitivity label enforcement）等补丁。但这些都是事后补救，无法解决历史积累的权限膨胀问题。

1.2.4 影子 AI 的系统性风险（Systemic Risk of Shadow AI）

在上述三个具体事件之外，更深层的危机是 Shadow AI——员工使用未经 IT 批准的 AI 工具处理工作内容。Gartner 2024 年的调查显示，企业实际使用的 AI 应用数量是 IT 部门知道的 3–5 倍。

Shadow AI 与 Shadow IT（影子 IT）有相似的根源，但风险更大：

1. 数据外泄路径增多：每一个未受管的 SaaS LLM 都是一个新的潜在泄密通道。 2. 合规盲区扩大：员工可能把受 GDPR、HIPAA 保护的数据输入到合规范围外的 LLM。 3. 决策不可解释：当员工用 AI 辅助做出业务决策时，这些决策无法被审计。

治理 Shadow AI 的核心思路不是"封禁"，而是"疏导"。本书第 4 章将深入讨论 AI Gateway 模式：通过部署企业内部 AI 代理网关，把所有员工对 LLM 的调用集中接入，从而在治理可控的前提下满足业务对 AI 的需求。

1.3 五大支柱框架：AI 治理的逻辑骨架 / The Five Pillars Framework

面对上述三大冲击波，企业需要的不是一个"AI 治理工具"，而是一套完整的工程体系。本书将这套体系提炼为五大支柱：Identity（身份）、Auditability（可审计）、Cost（成本）、Compliance（合规）、Lifecycle（生命周期）。

下图展示了五大支柱之间的依赖关系和数据流向：

```mermaid graph TD subgraph Foundation[Foundation Layer 基础层] Identity[Identity<br/>身份与权限] end subgraph Execution[Execution Layer 执行层] Lifecycle[Lifecycle<br/>全生命周期] Cost[Cost<br/>成本计量] end subgraph Constraint[Constraint Layer 约束层] Audit[Auditability<br/>可审计性] Compliance[Compliance<br/>合规边界] end

Identity --> Lifecycle Lifecycle --> Identity Lifecycle --> Audit Identity --> Audit Identity --> Cost Lifecycle --> Cost Cost --> Audit Audit --> Compliance Compliance --> Lifecycle Compliance --> Identity Cost --> Compliance ```

这张图的阅读方式：

• **身份（Identity）位于底层**：所有其他四个支柱都依赖"谁/什么在做事"这一基础事实。身份不清楚，其他治理无从谈起。
• **生命周期（Lifecycle）是执行入口**：每一