OCC新规：银行AI监管转向主动控制，第三方依赖成难题

美国货币监理署（OCC）针对银行部署AI发布了新的监管预期，显著提高了合规门槛。该指引明确了银行必须展示“主动控制”的六大领域：AI模型风险管理、数据治理、可解释性、第三方AI依赖、运营韧性和消费者保护。

措辞的变化至关重要——OCC使用了“主动控制”，而非“监控”或“日志记录”。被动的审计追踪不再满足标准。

从“事后 detective”到“事前 preventive”的范式转变

这一监管转向给已经在生产环境中运行AI的银行带来了具体的运营难题。这些银行此前围绕事后审查构建了合规体系，如今其架构与审查人员期望之间出现了明显鸿沟。

从 detective controls（检测性控制）到 preventive controls（预防性控制）的转变，本质上不是文档问题。它要求控制措施在AI采取行动的瞬间就存在，而不是数小时后在日志审查中才被发现。这意味着银行需要重新设计AI工作流的控制点，将合规检查前置到决策环节。

据Reddit社区讨论，从业者普遍认为这种实时控制要求对现有架构构成了实质性挑战，尤其是那些依赖批处理审计和定期抽查的遗留系统。

检测性控制（Detective Controls） 与 预防性控制（Preventive Controls） 是内部控制与审计领域的两大基础分类。检测性控制旨在事后发现已发生的错误或违规，典型手段包括日志审查、定期对账、异常告警和抽样审计；其价值在于提供可追溯的证据链，但无法阻止损害发生。预防性控制则前置到业务发生之前或发生瞬间，通过权限校验、规则引擎、实时拦截、输入验证等机制阻止不合规行为，其核心特征是“行动前或行动时生效”。在传统IT治理中，两者通常互补搭配；而OCC此次明确要求“主动控制”，实质是要求银行将AI合规的重心从检测性控制迁移到预防性控制，这对依赖批处理日志的既有架构构成了根本性挑战。

第三方AI依赖：最棘手的合规盲区

在六大领域中，第三方AI依赖被普遍视为最难改造的一环。银行可能能够治理自己的模型，但对同一工作流中运行的供应商或合作伙伴AI组件的行为可见性有限。

这种“黑箱中的黑箱”问题在组合式AI应用中尤为突出——当银行将外部API、预训练模型或SaaS服务嵌入自己的流程时，控制边界变得模糊。审查人员要求银行对这些外部组件的行为负责，但银行往往缺乏足够的技术手段来实时干预或解释这些组件的行为。

社区讨论中，有从业者指出，将第三方依赖纳入主动控制框架需要重新谈判供应商合同、建立实时监控接口，甚至要求供应商提供可嵌入的控制钩子——这些都不是短期内能完成的工作。

第三方AI依赖在监管语境下通常指金融机构使用外部供应商提供的模型、API、SaaS服务或预训练组件来完成自身业务流程的情形。这类依赖的风险在于控制边界外移：银行对供应商模型的训练数据、版本迭代、内部逻辑和失效模式缺乏完整可见性，却仍需对最终输出承担责任。监管机构一般要求银行对第三方风险实施尽职调查、合同约束、持续监控和退出预案，但当AI组件以黑箱形式嵌入实时工作流时，传统的年度评审和静态合同条款难以满足“主动控制”标准。行业实践中，可嵌入的控制钩子（control hooks）、实时遥测接口和模型行为契约正成为缓解该问题的技术方向，但目前尚无统一标准。

对从业者的实际影响

对于受监管机构的AI从业者而言，OCC的指引意味着合规工作重心需要从“证明我们记录了发生的事”转向“证明我们在事情发生时就实施了控制”。这涉及模型风险管理流程的重构、数据治理粒度的细化、可解释性工具的前置部署，以及跨部门协作机制的建立。

目前尚不清楚有多少银行已经具备满足新标准的架构基础，但社区反馈显示，大多数机构仍处于评估差距和规划改造的早期阶段。第三方依赖问题尤其需要行业层面的协作和标准制定，单一银行难以独立解决。

模型风险管理（Model Risk Management, MRM） 是银行监管中的成熟框架，源自美联储OCC于2011年发布的SR 11-7指引，要求机构对模型的开发、验证、部署和持续监控实施全生命周期治理。传统MRM强调独立验证、文档化和定期复审，节奏以季度或年度为主。OCC此次将AI纳入主动控制要求，意味着MRM的节奏需要从周期性评审转向实时或近实时干预，验证对象也从静态模型扩展到持续学习或在组合式工作流中运行的AI组件。对从业者而言，这不仅是工具升级，更涉及治理流程、职责划分和证据留存方式的系统性调整。

结语

OCC的新指引标志着银行AI监管从“事后追责”向“事中控制”的实质性转变。对于AI从业者而言，主动控制的要求不仅考验技术架构的敏捷性，更考验组织在供应商管理、跨部门治理和实时风险干预方面的成熟度。第三方AI依赖作为最薄弱的环节，很可能成为下一阶段监管审查和行业讨论的焦点。