美国货币监理署让检查员先问银行 AI 能做什么

美国大银行的 AI 检查，从此先看一个代理被允许做什么，再看它用的模型有多先进。我的判断是：这条标尺选对了，但美国货币监理署（OCC）把它写成「不设期望」的参考材料交给检查员，规则的分量有了，规则的程序和责任却没有到位，出事时兜底的只剩银行。

11 月 4 日，OCC 发布第 2026-54 号公告，附上一份 22 页的检查框架。据 Reuters 报道，OCC 称这是它第一份指导检查员如何审查银行 AI 使用的文件。

一个能付款的简单代理排在最高级

读者最想问的是：检查员到底凭什么给一项 AI 定级？框架的答案写在「总原则」一节：按失败或被滥用的后果、决策权转移了多少、人工监督到什么程度来分级，而不是按技术多复杂。

框架举的例子很直白：一个按规则运行、但被授权发起交易的简单代理，可能比一个只帮内部起草文件的复杂模型风险更高。第 3 节的举例分级表把这条原则落到了用途上：

级别	举例用途
第 1 级（关键）	自主付款代理、实时信贷决策、解除欺诈冻结
第 2 级（高）	AI 辅助核保、代理发起的客户沟通、反洗钱警报处置
第 3 级（中）	为信贷备忘录做内部文件摘要
第 4 级（低）	内部效率工具、写代码辅助、员工问答

框架还写明，一个面向客户、完全自主的付款代理属于第 1 级，「无论它在测试中表现多好」。这句话堵上了一种常见的辩护：测试分数高，不能换来更低的定级。

16 个检查要点里，权限写在第一条

框架列了 16 个组成部分，归进目的、风险、控制、监督、韧性、保证六根支柱。排在第一的是「目的与许可用途」：上线前和重大变更后，银行可以写清这个代理能做什么、不能做什么、谁能调用、能碰哪些数据和系统、什么情况要人工复核或暂停。

越出许可范围本身就算控制失效，哪怕结果看起来合理。这一条对智能体最要紧，因为代理的问题常常不是答错，而是做了没被授权的事。

其他几条同样落在权限上：

• 人工复核要有能力、有权限叫停，不能只是「点一下批准」，批量审批会拉低复核质量；
• 代理的身份、凭证和日志按特权用户管理，权限范围本身算作攻击面；
• 供应商的代理进入银行系统，银行要划定它的权限与升级上限，开发和托管分给外包商，管理风险的责任通常仍在银行。

CDO Magazine 的解读是，代理从给建议走到执行交易、修改业务记录时，机构要先划清它能碰的数据和系统，访问权限、审计记录和人工批准都成了风险管理的一部分。

「不设期望」的写法把规则留给了检查现场

问题出在文件给自己定的身份。公告写明，这份框架不为银行设定监管期望，银行不必用它自评，文中任何内容都不构成可执行标准或强制要求。全文几乎每条要求都用「可以」「可能」来写。

同一份公告又要求检查员按用途的重要性调整检查，并用这份框架里的概念来做。Reuters 的报道点得更直接：这类指引不像规则那样有法律约束力，但银行通常会照着执行。

这意味着（分析推断，依据是上面两句原文），银行会照着第 1 级的标准去配付款代理的控制，因为检查员会照着问；可公告里没有提到公开征求意见，OCC 也不必像发布规则那样逐条回应业界。

框架还在脚注里写明，按 10 月 2 日第 14434 号行政令，全文把「人工智能」改称「超级智能」，并且在超级智能协助下起草，经人审阅批准。监管者用 AI 写出给 AI 定级的文件本身无可厚非，这反倒说明它更该公开接受推敲。

写成「可以」并不减轻任何一方的义务

最有力的反驳是：指引本来就不是规则，写成「可以」给快速变化的技术留了余地，OCC 也承诺会定期更新，谈不上把规则藏起来。

这个反驳对了一半。内容保持弹性没有错，代理技术变化快，硬性条款很快会过时。错在把弹性写成了免责：文件说银行「不被期望」使用它，检查员却被指示使用它，两句话放在同一页上，银行只能按最严的读法准备。

我的分析推断是，「不设期望」保护的是 OCC 自己不受规则程序约束，银行和它的客户没有因此少担一分风险。

至于责任落在谁身上，框架自己已经写清：开发和托管可以外包，管理风险的责任仍在银行；合同里该写明模型出错、客户受损由谁赔、赔多少。

给一个代理付款权限的那家银行，就是第 1 级风险的责任人，测试分数和供应商合同都转不走这份责任。OCC 拿出了一份检查员照着问、却声称不设期望的清单，程序上站不住的是 OCC 自己。