2026年银行业人工智能模型风险管理
作者：Jonas Mohamed Osman Abdelghafour。
2026年的监管方向十分明确：采用人工智能并不能豁免模型风险管理，反而会带来额外的义务。传统的信用评分卡可以用三十页文档记录，并针对稳定的样本群体进行验证；而一个人工智能系统可能每周重新训练一次，依赖第三方基础模型，摄取非结构化文本，并产出任何审阅者都无法追溯到某个系数的输出结果。但这一切都不会改变银行必须能够回答的根本问题：这个模型的所有者是谁，它驱动着什么决策，我们如何知道它仍然有效，以及一旦它失效会发生什么。
从清单入手，而非从算法入手
银行中大多数人工智能模型风险事故，首先是清单管理的失败。一个在某业务条线内部构建的工具——信贷部门的文档摘要助手、金融犯罪部门的分流分类器、商业贷款部门的定价建议引擎——常被作为“生产力软件”部署，却从未被纳入模型清单。此后它就从未被验证过，也从未被监控过，甚至在供应商更换底层模型版本时也从未被复审过。
补救之道，是制定一个基于重要性的模型定义，用以涵盖影响判断的系统，而不仅仅是量化估计器。只要某项输出会改变放贷、定价、拨备、资本或客户结果方面的决策，无论业务部门是否称其为“模型”，它都应纳入管理范围。随后由分级机制来完成后续工作：最高层级需要完整的独立验证，最低层级则只需登记、指定负责人并定期复审。
责任归属与变更管理
人工智能系统打破了年度验证周期。一个权重、提示词、检索语料库或供应商版本可能在两次委员会会议之间发生变化的模型，需要的是持续性的、而非按日历安排的变更管理。以下三项控制措施承担了大部分权重：
- 版本锁定与发布关卡。 任何生产环境变更——包括供应商悄然进行的模型升级——都不得在未记录对已批准用途影响评估的情况下发生。
- 黄金测试集回归测试。 每次变更时都运行一套固定的、具有代表性的评估集，并由第二道防线预先商定通过阈值。
- 明确记录的使用限制。 审批文件应说明该模型可以以及不可以被用于什么用途，并由控制环境予以执行。
独立验证真正应当检验什么
对人工智能模型的有效质疑并非重新执行一遍模型运算。审阅人员能够创造的最大价值，在于攻击开发者自己无法测试的那些假设：训练所用的样本群体是否仍与当前实际群体相似，数据血缘是否站得住脚，模型在受保护及商业敏感的细分群体中表现是否依然稳健，模型在输入分布边缘是渐进退化还是灾难性失效，以及处于闭环中的人类是否真正能够推翻模型输出，还是只是走过场地盖章通过。
可解释性尤其值得审慎对待。事后归因方法作为诊断工具有其用处，但作为证据则十分薄弱。一份仅依赖特征重要性图表、却未对该图表进行稳定性分析的验证报告，并不能证明该模型已经被真正理解。
第三方风险与集中度风险
极少有银行会自行训练前沿模型。大多数银行是在使用这些模型，这就把模型风险转化为第三方风险和集中度风险。如果多个关键流程都依赖于同一个供应商，银行就制造了一个自身模型治理体系无法察觉的单点故障。获取证据的合同权利、重大模型变更的通知条款、退出与替代方案，以及一份关于服务被撤回或降级后果的书面说明，都应当与绩效指标一并纳入风险评估之中。
董事会能够使用的报告
董事会并不需要模型数量的统计。他们需要知道：目前哪些决策已受到人工智能的重大影响，这些决策背后有多大的风险敞口，哪里出现了绩效漂移，哪些发现事项已超过整改期限仍未结案，以及一旦关键模型或供应商失效，管理层将采取什么行动。一页能够回答这五个问题的报告，比一份五十页的附录更有价值。
实用清单
- 按决策影响而非技术手段来定义模型，并按重要性分级。
- 在部署前为每一个人工智能系统登记一名指定的责任人。
- 对每一次变更——包括供应商升级——设置回归测试关卡。
- 验证假设、数据血缘、细分群体表现和失效模式；将可解释性输出视为诊断工具，而非证据。
- 绘制供应商集中度图谱，并保有一套切实可行的替代方案。
- 以决策语言报告漂移情况、未结案发现事项和管理层的应对行动。
2026年的竞争优势，不在于模型有多复杂精巧，而在于能否迅速而可信地证明，一个复杂的模型正处于受控状态之下——因为受到良好治理的模型，才是监管机构、审计师和资本提供方真正愿意让银行使用的模型。
主要资料来源： 英国审慎监管局（PRA）SS1/23（银行模型风险管理原则）；金融稳定理事会（FSB），《负责任采用人工智能的良好实践》，2026年6月；欧洲银行管理局（EBA）风险评估报告，2026年6月。