FSB 提出金融机构 AI 治理的 12 项做法

By: foresightnews.pro|2026/10/21 10:02:39

2026 年 10 月 15 日，金融稳定理事会（FSB）发布《金融机构负责任采用人工智能的健全做法》最终报告，提出 12 项供金融机构参考的治理做法。报告覆盖 AI 战略、风险评估、数据管理、人工监督、网络安全以及第三方服务等环节，回应了金融机构近几年加快引入生成式 AI 和智能体 AI 后出现的一系列管理问题。

金融机构的 AI 治理连接业务负责人、风险团队与外部供应商。

这份报告经过公开征求意见后定稿，提供一套国际层面的实践框架，供机构结合自身业务和风险情况参考。金融机构落实时仍需结合所在地区的具体法律和监管要求。

一套做法为何要覆盖董事会、数据、模型和供应商这么多环节？可以从一个常见项目理解：银行准备让 AI 辅助处理小企业贷款。业务团队希望缩短审查时间，模型团队关心识别准确率，合规团队关注客户资料和决定解释，运营团队则需要保证供应商停服后贷款业务还能继续。只检查模型表现，无法回答另外几方的问题。FSB 这份报告试图让这些决策进入同一套管理流程。

一、12 项做法从机构治理延伸到 AI 全周期

FSB 把 12 项做法分成两组。前四项关注机构层面的治理，后八项覆盖 AI 从引入、开发、部署到持续使用的各个环节。

四项机构治理做法先把责任、记录和持续调整放进管理框架。

机构治理部分首先要求董事会和高级管理层把 AI 使用与业务模式、风险偏好和整体战略放在一起考虑。当 AI 参与信贷审核、客户服务、交易监测或内部决策，管理层需要了解它被用在什么地方、承担什么功能，以及出错会产生怎样的影响。

第二项做法强调责任划分。机构需要明确业务、技术、风险、合规和审计团队各自承担什么职责，并把 AI 风险纳入既有风险管理框架。第三项延续这一思路，要求记录 AI 的使用方式、风险评估及相关控制。

记录的价值在于出现问题时，机构能够还原系统作出了什么判断、使用了哪些数据、谁作了决定，以及哪些控制在当时已经运行。第四项则提醒机构，技术和业务环境会变化，治理架构也需要随之调整。

这四项做法决定了一项 AI 项目由谁批准、谁维护以及谁有权叫停。董事会无需逐个审查模型参数，但应知道机构把 AI 放进了哪些重要业务、预计取得什么收益、准备承担多大风险。管理层随后把总体要求落到产品审批和岗位职责上。例如，贷款业务负责人决定 AI 建议能进入哪一步审批；模型风险团队设计测试；合规人员检查客户权利；内部审计则评估前述控制是否真的运行。岗位之间若存在空白，就要在上线前指定最后的决策人。

FSB 所说的文档也不等于保存一份产品说明书。一个用例至少需要能够追踪业务目的、数据来源、模型版本、测试结果、人工干预位置、第三方依赖和重大变更记录。之后若客户质疑审批结果，机构才可以沿着这些材料还原流程。对已经采购的办公软件也一样：原本不含 AI 的产品加入自动摘要或客户分类功能后，机构应重新确认输入数据流向和使用范围。

后八项从具体使用场景出发，覆盖 AI 用例的重要性与风险评估、模型和系统选择、数据治理、可解释性与透明度。后续做法还涉及系统绩效、人类监督、网络与信息通信技术（ICT）风险，以及第三方 AI 依赖。

12 项做法按治理主题编排，许多要求贯穿 AI 使用的多个阶段。机构可以结合自身规模、业务复杂程度、在金融体系中的角色，以及 AI 进入关键业务的程度，决定控制措施的深度。

这里的"重要性评估"（materiality assessment），简单来说，是判断某个 AI 应用是否会影响机构的关键业务、客户权益或风险决策。用于整理会议纪要的工具，与参与贷款审批或客户资产管理的系统，需要配置不同的审查强度。FSB 提出按应用场景和风险配置治理力度，让机构把更多控制资源放到影响更大的用途上。

这套生命周期管理要求机构把数据、模型和业务场景放在一起审视。训练和运行数据的质量会影响模型输出，模型更新可能改变原有表现，客户与员工的使用方式也会带来新的风险。风险评估因此需要贯穿选型、测试、上线和持续运行。

第五项"重要性与风险评估"适合在立项时完成第一轮，此后在用途改变、数据范围扩大或模型更新时重做。客服知识库回答产品营业时间，与自动推荐客户购买高风险投资产品，面对的是不同的消费者后果。机构可以把影响人数、决定可逆性、数据敏感度、财务敞口和人工接管能力放进评估表，再决定需要怎样的测试和审批。这样，资源会优先流向真正可能伤害客户或中断服务的系统。

第六项是选型。市场上既有自建模型，也有外部 API 和嵌入常用软件的 AI 功能。业务团队通常先看到价格和功能，风险团队还要问：模型能否在本机构的语言、客户群和市场条件下稳定工作？供应商更新时是否通知？数据是否会被用于进一步训练？如果只能取得有限技术资料，机构可先限定用途和数据范围，在上线后用自己的样本持续测试，而不是把采购演示当成正式验证。

第七、八项连着数据与解释。若贷款历史样本遗漏某类客户，模型可能在这类申请上持续失准；若前线员工又无法解释推荐结果，客户异议会更难处理。数据治理因此涉及完整性、准确性、来源许可、访问权限与安全。可解释性要求也应按场景安排：为内部检索提供出处，与向客户说明影响其融资机会的决定，需要达到的清晰程度不同。FSB 允许机构在难以解释的模型上设置用途限制、复核和额外测试等补偿控制，重点是让负责决定的人掌握足够信息。

第九、十项进入日常运行。机构应监测模型表现是否随业务环境变化，观察错误率、投诉、异常调用和人工改判情况；监控指标需要与原始用途相连。人工监督也要有实际权力。审核员若只在屏幕上点"同意"，既看不到依据，也无权改变输出，监督就很难起作用。高风险流程可设置强制二次确认、抽样复核和自动停止阈值；记录人工为何采纳或推翻模型建议，反过来可以改进测试。

最后两项把 AI 放回技术和供应链环境。模型接口、数据连接器和 Agent 工具可能成为新的攻击入口，网络安全演练要覆盖提示注入、密钥泄漏、错误工具调用和外部服务中断。供应商风险还包括模型表现、透明度、训练与运行数据质量、分包链条以及集中依赖。多家银行同时使用少数云平台或基础模型，个别供应商故障就可能具有更广的业务影响。机构至少要知道关键依赖在哪里，以及重要业务中断时由谁接管。

二、公开意见让最终稿补上了运营层面的细节

FSB 在 2026 年 6 月发布咨询稿，并于 7 月 22 日结束征求意见。最终收到约 160 份反馈，来自银行、保险公司、其他金融机构、行业协会、技术服务商、学术界和公共部门。总体上，受访方支持以原则为基础、强调比例性的做法；同时也提出了实施中的实际困难。

终稿保留了原则导向和技术中立的框架，也补充了小型机构如何借助现有岗位和外部专业能力落实治理的说明。案例部分增加了保险公司、资产管理机构和支付服务商的实践，让这套做法适用于更多类型的机构。FSB 将案例作为实践路径的展示，具体安排仍要结合机构自身情况。

第三方 AI 是反馈较集中的问题之一。金融机构使用外部模型或嵌入式 AI 产品时，可见的模型、数据和供应链信息往往有限，增加了独立评估风险的难度。少数关键服务商在 AI 基础设施中的份额不断增加，也让机构关注服务中断后如何切换供应商、恢复业务。

第三方依赖与网络安全也进入 AI 全生命周期管理。

最终稿因此进一步扩展了对第三方 AI 的讨论，覆盖嵌入式 AI、分包服务以及供应链依赖，并强调集中度管理、业务连续性和退出安排。对关键服务的退出安排，简单来说，就是在供应商停服、合同终止或风险超出机构承受范围时，机构如何切换服务或维持业务运行。

合同谈判中，金融机构可以围绕四件事取得信息：供应商如何处理输入与输出、重大模型或服务变更怎样通知、事故时能提供哪些日志、终止合作后数据如何返还或删除。大型服务商未必接受每一家客户的定制条款，机构仍能通过限制接入范围、保留内部备份流程和定期测试替代路径降低单点依赖。所谓退出安排最后要落到人员、数据格式和转换所需时间，不能停留在合同中的"可以终止"。

智能体 AI 也成为修改重点。它与一般的文本生成工具有所不同，能够在设定目标后连续执行多个步骤，有些系统还会调用外部工具或访问业务数据。反馈意见提出了执行前授权、最小权限、不可篡改的操作记录和运行时监控等控制思路。最终报告增加了相关考虑，并说明这部分实践仍在发展，未来可能需要更深入的指引。

咨询反馈还提及，如果多家机构依赖相同模型或少数供应商，市场行为可能趋同，风险也可能相互放大。最终报告聚焦单个金融机构如何负责任地采用 AI；更广泛的系统性风险将通过其他金融稳定评估继续观察。

三、对金融机构而言，关键工作是把原则放进日常流程

这 12 项做法落到机构内部，首先需要一份能持续更新的 AI 使用清单。清单应说明系统服务于什么业务、由谁负责、会影响哪些客户或关键流程、依赖哪些外部模型与云服务，以及发生异常时如何暂停或切换。AI 能力也可能嵌在常用办公、客服或分析产品中，因此清单需要覆盖采购项目之外的日常软件和业务工具。

其次，AI 风险评估要从采购和试用阶段开始。业务团队说明应用目标，技术团队评估模型与数据，风险和合规人员判断它对客户决策、关键业务或法定义务的影响。系统上线后，机构还要持续观察运行表现，并检查数据或模型更新是否带来新的风险。

当模型的决策路径较难说明时，机构可以通过限制用途、增加人工复核或设置额外测试来降低风险。这类"补偿性控制"用于缓释模型透明度不足带来的风险，并与数据保护、消费者权益等法定义务一并落实。

一份可用的内部流程还应区分"试验"与"生产"。试验环境可以使用脱敏或合成数据，限定用户和调用次数；接入真实客户数据及业务系统之前，再由业务、技术、安全、法务共同确认数据和权限。上线批准不应成为终点。机构可以设置版本变更触发器：更换基础模型、接入新的外部工具、扩展到新客户群或调整自动化程度时，自动启动复核。许多 AI 风险出现在用途慢慢扩大之后，而首次立项材料还停留在原来的低风险场景。

第三方管理也要进入采购和合同流程。机构需要了解供应商能提供哪些模型信息、数据如何处理、服务由哪些下游企业支持、发生重大更新时怎样通知客户，以及关键服务中断时有哪些替代方案。

在供应商仅提供部分模型技术信息的情况下，金融机构可以记录已取得的资料、待处理风险和运营安排，作为尽调和后续管理的依据。

对智能体 AI，还需要把授权边界讲清楚：它能访问什么数据、可以调用哪些工具、哪些操作必须由员工确认，以及怎样在出现异常时暂停任务。监督人员需要具备实际介入权限、充足时间和可查阅的执行记录。

例如，机构允许 Agent 整理客户申请材料，可以让它读取指定文件夹、生成待核验清单，却把修改授信额度和对外发送决定留给员工。若同一 Agent 要完成查询、写入和通知三项动作，系统可在不同步骤发放短时凭证，并记录每次调用。这样，风险团队看到的不再是"使用了 Agent"这样一个抽象标签，而是一条可以测试、审计和暂停的执行链。

实务上，可以把 12 项做法压到四类交付物中：董事会批准的 AI 使用原则、持续更新的应用与依赖清单、每个重要用例的评估和测试记录、以及异常时的停用与恢复预案。这四类材料相互连接。清单告诉管理层有哪些项目；评估决定哪些控制更严格；测试证明控制是否有效；事故记录再推动规则修改。小型机构也可以复用既有风险会议和采购流程，关键是让责任和证据可追踪。

四、这是一套管理参考，落地仍要看所在法域

FSB 把这 12 项做法定位为可结合机构情况调整的实践工具。机构在应用这份框架时，仍需把 AI 用例与所在法域关于数据保护、消费者权益、外包管理、模型风险或金融机构治理的具体要求逐项对照。

它的现实作用在于提供一张共同的治理清单：从董事会责任、内部文档，到模型选择、人工监督和供应商管理，机构可以据此核验现有流程对关键环节的覆盖情况。随着 AI 进一步进入金融业务，这张清单背后的责任人、控制措施和应急安排也需要持续更新。

从国际政策的角度看，FSB 的做法还有一个价值：不同法域可以用相近的问题审视金融机构的 AI 应用。监管者未必使用同一张表，但都会关心风险由谁承担、模型在关键业务中怎样运行、外部依赖出现故障时客户是否受影响。机构若能把上述证据准备好，面对不同地区的数据、消费者保护和审慎监管要求时，也更容易说明自己的控制安排。