随着企业将AI规模化部署到核心业务中，治理必须从政策层面升级为可执行的风险与合规机制，否则这一缺口将在审计、风险审查和监管审查中暴露无遗。
对每一位CDO而言，问题已不再是要不要治理AI，而是AI治理能否跟上部署的速度。
这一挑战的核心在于AI治理合规——即在监管机构、审计人员或风险事件发现缺口之前，将可执行的管控措施嵌入整个AI生命周期的学科。
采取行动的必要性不仅关乎声誉或营收风险，《欧盟AI法案》明确了可接受风险的等级，并将于2026年8月全面强制执行。
高风险违规的罚款高达3500万欧元(约合3800万美元)，然而仅有20%的企业拥有成熟的自主式AI智能体治理模型，尽管2025年单年员工AI使用率就已增长了50%。
根据我在金融服务、信用合作社以及受美联储(Federal Reserve)、OCC、NCUA和FCA审查的机构等复杂受监管环境中治理AI的经验，能够通过监管审查的企业都有一个共同特征：
他们让治理成为系统强制执行的内容，而非文档中描述的内容。
CDO和数据负责人应参照那些成功将AI治理合规落地的企业的最佳实践，来构建本组织的AI治理体系。
1. 从完整的AI资产清单开始
• 利用三个大多数治理项目未能充分利用的证据来源，对所有在产AI系统进行盘点：IT资产登记册、供应商合同组合以及业务单元工作流日志。
• 按决策重要性、数据敏感性和监管暴露度对每个系统进行风险分类，领先企业已实现这一流程的持续运营。
大多数企业认为自己清楚生产环境中运行着哪些AI，大多数都错了。
根据我在一家正在准备美联储安全与稳健性审查的美国顶级金融机构的经历，官方AI系统清单仅列出了12个在产模型。
一次完整的发现演练——审查云工作负载、SaaS集成、业务单元采购以及供应商平台发布——共发现了47个。
审查员会找到它们，我们先找到了。
其中35个系统正在治理框架之外做出关键决策：信贷审批、欺诈标记、客户通信，部分系统涉及受公平借贷要求约束的数据，没有一个出现在任何模型清单上。
12和47之间的差距不是文档的失败，而是控制的失败。正在弥合这一差距的机构，是那些将发现视为持续控制而非年度审计的机构。
模型风险始于资产清单，美联储SR 11-7要求对所有AI系统建立完整的模型清单、独立验证和持续监控。
在复杂的受监管环境中，三类入口点构成了大多数未受治理AI的来源：
供应商嵌入式AI：核心银行、临床和运营平台在标准发布中激活评分模型，通常不通知模型风险职能部门。机构采购了平台，AI随之而至，处于无治理状态。
业务单元自行部署的模型：业务团队因业务需求紧迫且审批周期过长而自行构建模型。模型能用，便上线生产，从未经过验证。
企业平台功能：Microsoft 365和Salesforce等平台在升级过程中默认激活嵌入的AI能力。每一项都在影响决策，但几乎没有一项出现在正式的模型清单上。
每一个未受治理的系统同时也是一条未受治理的数据管道，消耗着未经分类、未追踪血缘、未经过审计的数据。
问题不在于AI是否在你的治理控制之外运行，而在于你是否比审查员先发现它。
2. 治理供应商、第三方和SaaS AI，包括数据保护和供应链
• 在采购阶段而非部署后，就将供应商监督纳入合同条款。
• 在每一份AI相关供应商协议中，要求包含模型文档、验证证据、漂移监控报告、数据治理条款以及明确的升级协议。
• 将同样的要求延伸至SaaS AI功能和基础模型提供商。
• 作为第三方风险管理计划的一部分，每年开展供应商和供应链AI治理审查。
如果供应商提供的模型被用于决策，机构仍需对验证、监控和数据治理负责。
复杂受监管环境中的监管机构要求机构证明其对外部AI服务拥有监督能力。
供应商AI治理仍然是我遇到的最常见缺口，采购团队谈判价格和SLA，却很少就模型风险问责或数据治理条款进行谈判。
当供应商的评分逻辑影响面向客户的决策，而机构无法提供验证证据时——因为采购部门将其视为软件而非受治理的模型——风险便会浮出水面。
SaaS平台使这一挑战更加复杂，嵌入企业SaaS中的生成式AI能力(通常在升级时默认激活)会处理敏感数据并生成带有监管和数据保护风险的输出，其中大多数并未纳入正式的模型清单。
AI供应链引入了更多脆弱性，使用开源模型和第三方微调服务构建AI管道的企业，在每个节点都继承了风险：从受损的训练数据到传统治理、风险与合规(GRC)框架无法检测的未披露模型行为。
数据保护缺口会放大所有这些风险，IBM的研究发现，影子AI事件目前占所有数据泄露的20%，每次事件的成本溢价为463万美元，而标准泄露事件为396万美元。
当美联储、OCC或NCUA审查员开展安全与稳健性审查时，他们要求提供完整的AI系统清单，他们还想知道这些系统是什么、按风险如何分类，以及每个系统背后的控制文档。
"活页夹式治理"会在数小时内崩塌，因为审查员不读政策手册，他们测试的是控制措施。
3. 为每个AI系统指定单一问责人
• 为每个在产AI系统指定一名具名的问责负责人：是个人，而非某个职能部门。
• 该负责人对模型的治理状态、升级决策和审查就绪度负责。
• 每季度确认归属权。
人人有责等于无人负责，领先咨询机构的研究指出，2026年的AI治理正从高层原则转向可执行规则，以明确的关键风险指标(KRI)和关键绩效指标(KPI)衡量，而非纸面上的政策。
审查员要看的是问责是否具名、有日期、可审计，还是分散在一个无人主导的委员会中。
在复杂受监管环境中，最常见的治理失败不是缺少政策，而是出了问题时没有一名具名个人承担责任。
4. 持续生成证据，而非审查就绪型文档
• 持续生成治理证据，而非仅在审查前准备。
• 为每个AI系统定义具体的性能阈值。
• 当输出偏离这些参数时，自动触发器将异常路由至具名问责负责人。
• 将带时间戳的证据存储在可检索的审计轨迹中：风险评估、监控结果、控制实施和事件响应。
年度模型验证是为一个更慢的世界设计的，AI不会等你做年度审查。
美国证券交易委员会(SEC)检查部已将AI治理列为2025年受监管环境中的审查重点。
审查员要看的是治理证据是持续生成的，还是在审查前临时拼凑的。
持续生成证据的机构能够提供早于审查数月的记录。
那些在审查前才拼凑证据的机构做不到，审计轨迹就是证明。
5. 将GRC演进为AI生命周期治理框架
• 在部署前将治理嵌入AI生命周期，而非在发现问题之后。
• 每个上线的AI系统在做出第一个决策之前，都应拥有具名负责人、经过验证的清单记录、活跃的监控阈值和数据保护控制措施。
GRC框架必须从定期合规审查演进为持续的AI生命周期治理，在企业层面支撑可审计性、问责制和监管就绪度。
AI通过供应商更新、平台功能、API、SaaS激活和业务单元部署进入企业。GRC现在必须验证系统实际做了什么，而不是政策说它应该做什么。
有效落地AI治理合规的企业已做出三项结构性变革：
• 从定期审查转向持续监控
• 用单一问责制取代委员会负责制
• 将升级触发器嵌入运营流程，使异常自动路由
每位CDO都应该问自己的问题
你的组织当前有多少AI系统在生产环境中运行，包括供应商嵌入式AI、业务单元自行部署的模型、SaaS AI功能，以及企业平台内部激活的AI能力?
现在，加上这个限定条件再回答一次。
治理只有在审查中可被证明时才算数，审查员不接受一张政策截图。
他们要求的证据轨迹包括：已记录的控制操作、带时间戳的审批、已触发并已解决的监控告警。如果你的清单答案仅假设了你能文档化的AI系统，请重新计算，包括那些你知道但尚无法提供证据的系统。
如果你的答案在加上限定条件后发生了变化，那么这个缺口是有监管成本的——可审查、可衡量，并且在2026年，在每一个复杂受监管环境中都将被越来越严格地执行。
AI治理合规不是AI采用的刹车，而是在审查下实现规模化的架构。
唯一的问题是：你来弥合这个缺口，还是让监管机构来。
