zh作者：Zeeshan Mallick
你的 AI 政策不是 AI 治理，而是一张许可单。
一页纸政策无法控制模型、数据、访问、供应商和事件。McKinsey、NIST和IBM说明了创始人为什么需要运营型AI治理。
人工智能治理创始人ceo网络安全风险领导力公司建设
# 你的 AI 政策不是 AI 治理，而是一张许可单。
**直接答案：** AI 政策告诉人们应该做什么。AI 治理则证明谁负责风险、有哪些系统、系统接触什么数据、如何检查输出，以及发生故障时要做什么。
一页纸的政策不是治理。它只是带着良好意图的许可单。
数据已经显示出这个差距。McKinsey 报告称，**超过四分之三的组织**至少在一个业务职能中使用 AI。但在使用生成式 AI 的组织中，只有 **27%的受访者**表示，员工会在使用前检查所有 AI 生成内容。另有相近比例表示，只检查 **20%或更少**。**47%的受访者**表示，他们的组织已经经历过至少一种生成式 AI 的负面后果。
IBM 报告称，在 Ponemon Institute 研究的 **600家组织**中，**63%没有 AI 治理政策**来管理 AI 或防止影子 AI。IBM 还报告说，在发生 AI 相关安全事件的组织中，**97%缺少适当的 AI 访问控制**。在 IBM 的研究中，高水平影子 AI 使用使平均数据泄露成本增加了 **67万美元**。
来源：[McKinsey，《The State of AI》](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value)、[NIST，《AI Risk Management Framework》](https://www.nist.gov/itl/ai-risk-management-framework)以及[IBM，《2025 Cost of a Data Breach Report》](https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai)。
## 政策幻觉
多数创始人会先写一份文件：
“不要把机密数据放进公共 AI 工具。”
“把 AI 输出发送给客户前先检查。”
“只使用获得批准的工具。”
这些话听起来很负责，但它们没有回答运营问题：
- 员工已经在使用哪些 AI 工具？
- 谁批准了它们？
- 哪些模型可以访问客户或公司数据？
- 哪些员工或代理有权限使用？
- 在高流量工作流程中，“检查输出”具体意味着什么？
- 提示词、输出、批准和事件记录在哪里？
- 谁可以关闭系统？
- 哪些供应商可以保留数据或用数据训练模型？
如果没人能回答这些问题，政策就没有控制 AI，而是在记录希望。
## 采用速度超过了监督速度
McKinsey 2025年全球调查显示，AI采用很广，但治理并不均衡。在使用 AI 的组织中，只有 **28%的受访者**表示由 CEO 监督 AI 治理，**17%**表示由董事会监督。
McKinsey 还发现，**21%的受访者**表示，他们的组织已经围绕生成式 AI 对至少部分工作流程进行了根本性重设计。不到五分之一的人表示组织正在跟踪生成式 AI 解决方案的 KPI。不到三分之一表示组织遵循了 McKinsey 测试的12项采用和扩展实践中的大多数。
这很重要，因为 AI 风险不只存在于模型里，也存在于工作流程里。
一个帮助起草内部笔记的 AI 助手是一种风险。一个可以退款、改价格、批准供应商、发送客户消息或访问敏感记录的 AI 代理是另一种风险。把两者都归类为“使用 AI”的政策，不是控制系统。
## 只有政策与运营治理
| 问题 | 只有政策的方法 | 运营治理 |
|---|---|---|
| 责任 | 有人写了文件 | 指定高管负责风险 |
| 清单 | 员工自行报告工具 | 公司维护实时 AI 清单 |
| 访问 | 对敏感数据的一般警告 | 按角色访问、最小权限和撤销 |
| 风险 | 所有用例一条规则 | 按影响和自主性分级 |
| 输出 | “发送前检查” | 明确检查阈值、抽样和签字 |
| 供应商 | 合同文字 | 尽职调查、数据使用限制和退出计划 |
| 数据 | “不要上传机密数据” | 分类、血缘、保留和删除规则 |
| 监控 | 每年提醒一次 | 日志、KPI、漂移检查、告警和审计 |
| 失败 | 责怪用户 | 暂停、隔离、调查、纠正和学习 |
| CEO问题 | 我们发布政策了吗？ | 我们能否说明谁用什么数据做了什么，以及为什么？ |
## NIST认为治理是生命周期
美国国家标准与技术研究院建立 AI Risk Management Framework，帮助组织在 AI 系统的设计、开发、使用和评估中加入可信度。NIST 将框架分为四项功能：**Govern、Map、Measure 和 Manage**。
**Govern**意味着在整个生命周期中建立责任、文化和政策。
**Map**意味着理解环境、预期用途、受影响人员、数据、依赖关系和潜在伤害。
**Measure**意味着测试性能、安全、隐私、偏见、可靠性和其他风险。
**Manage**意味着随着时间推移，对风险进行排序、响应、记录和控制。
NIST 的重点很实际：系统会变，数据会变，用户会变，供应商会变，风险也会变。系统变化时，一份 PDF 不会变化。
## 访问控制问题
IBM 的2025年数据泄露研究，是给那些认为 AI 治理只是伦理或合规问题的创始人的警告。
它同样是身份和安全问题。
IBM 表示，发生 AI 相关安全事件的组织中，**97%缺少适当的 AI 访问控制**。问题不仅是员工是否可以使用 AI，而是工具可以读取、写入、执行、导出、记忆或触发什么。
员工使用聊天机器人总结公开文章，与自动代理访问 CRM、财务系统、代码仓库、客户支持邮箱或人力资源数据库完全不同。
把两者放进同一个政策类别，就是让访问权限的增长速度超过责任的增长速度。
## 成长型公司的最小治理系统
**1. 指定负责人。** CEO不需要执行每项控制，但必须有人负责风险清单、决策、例外和报告。
**2. 建立 AI 清单。** 列出模型、工具、供应商、内部代理、部门、数据源、用户、权限、位置和受影响的业务决策。
**3. 建立风险等级。** 把低风险起草与高影响决策、外部沟通、敏感数据、自主行动和受监管用例分开。
**4. 控制访问。** 使用最小权限。只给 AI 系统所需的数据和动作权限，并在角色或供应商变化时复查和撤销。
**5. 分类数据。** 定义哪些数据是公开、内部、机密、个人、受监管或禁止使用的，并为每类数据设定工具规则。
**6. 定义人工检查。** “有人参与”还不够。要说明何时必须检查、谁有资格检查、检查什么以及记录什么证据。
**7. 记录重要活动。** 在适当且合法的情况下，保留工具、用户、模型、数据类别、批准、动作和事件记录。
**8. 检查供应商。** 询问数据去哪里、保留多久、是否用于训练模型、使用哪些分包商、如何报告事件，以及如何退出。
**9. 衡量结果和失败。** 跟踪采用率、准确性、返工、人工覆盖、客户投诉、安全事件、节省时间、收入影响和成本。节省时间但增加返工，不是生产力提升。
**10. 练习关闭系统。** 决定谁可以暂停系统、隔离数据、撤销权限、通知客户和调查。如果答案是“到时再说”，控制就是缺失的。
## 创始人审计
在下一次领导会议上提问：
1. 今天正在使用多少 AI 工具，包括员工自行购买的工具？
2. 哪些 AI 系统可以访问客户、财务、代码、人事或法律数据？
3. 哪些系统可以执行动作，而不只是生成文字？
4. 每个高风险用例的负责人是谁？
5. 多少比例的外部 AI 输出接受了合格检查？
6. 上一次检查每个供应商的数据保留和训练政策是什么时候？
7. 撤销某个 AI 系统访问权限的最快方式是什么？
8. 哪个 AI KPI 能证明业务价值，而不只是活动？
9. 哪种事件会让我们今天停止系统？
10. 我们能否向董事会展示当前 AI 清单和风险地图？
如果多数答案是“我们有一份政策”，那就没有治理。只是让一份文件代替了一个系统。
数据图表。来源：McKinsey、NIST AI RMF和IBM 2025 Cost of a Data Breach。
Master Collective 简报
获取关于创始人、资本与战略增长的简明观点。