引言
人工智能已从孤立试验进入投资研究、客户服务、合规、运营、风险分析和技术交付。在受监管金融领域,核心管理问题是每一项使用能否按其后果得到相称治理。答案需要一份清单、可辩护的分类、可问责的决策权、独立质疑、可靠评估、可追溯运营和可信退出。仅凭政策声明无法提供这些证据。
监管基线在 2026 年发生了实质性变化。美国联邦银行监管机构于 2026 年 4 月 17 日发布了修订后的模型风险管理指引。该指引取代 SR 11-7,强调基于风险且量身定制的方法,预计与总资产超过 USD 30 billion 的受美联储监管的银行机构最为相关 [1]。OCC 还表示,生成式 AI 和智能体式 AI 不在该修订指引的范围内,因为它们新颖且快速演进 [2]。这一范围边界很重要。这意味着机构不能假设仅靠传统模型风险管理就能回答所有生成式或智能体式 AI 问题。
在英国,2026 年 4 月版的 PRA 监管声明 SS1/23 将模型风险管理原则适用于用于支持业务决策的各类模型,包括供应商模型以及在相关原则适用范围内的人工智能 [4]。英格兰银行、FCA 和英国财政部在 2026 年 5 月分别呼吁董事会理解并积极缓释前沿 AI 网络与运营韧性风险 [9]。2026 年 6 月,金融稳定理事会提出了 12 项稳健实践,涵盖全组织治理、生命周期控制、网络、信息与通信技术以及第三方风险 [10]。在 2026 年 8 月 1 日证据截止时,该 FSB 文件仍为征求意见稿;其最终报告原定于 2026 年 10 月发布 [10]。
UAE 的立场也变得更加具体。UAE 中央银行于 2026 年 2 月发布了消费者保护指引,规范持牌金融机构负责任地使用 AI 和机器学习 [16]。DFSA 于 2026 年 6 月发布了关于 DIFC 内 AI 风险管理的监管预期 [18]。这些材料与 UAE 监管机构 2021 年的赋能技术指南、UAE 个人数据框架以及 DIFC 关于自主和半自主系统处理个人数据的规则并存 [17,22,23]。
本文将这些相互重叠的来源转化为一套运营框架,供家族办公室首席投资官、另类投资负责人和国际机构配置者使用。该框架面向这样的投资机构:它们可能直接受到监管,可能向受监管机构配置资金,可能采购由 AI 赋能的服务,或因受托、合同或声誉风险敞口而需要机构级治理。它区分法律、具有约束力的规则、监管指引、征求意见材料、标准和自愿性实践。适用性必须由该实体、活动和司法辖区的合格法律与合规负责人确认。
本文的贡献具有实践性。它定义了覆盖模型、AI 系统、助手、智能体和嵌入式供应商能力的通用清单;一种将决策后果与技术新颖性区分开的重要性方法;设有证据关口的生命周期;确定性、预测性、生成式和智能体式系统的评估要求;第三方与集中度控制;以及支持董事会实际质疑的信息。文中包含两个已演算的运营案例。这些案例中的每一项数值输入均明确为未经核实且仅作说明。归因的 Matchpoint 或客户收入、现金成本降低和损失减少,在存在经批准的观测证据之前仍为 USD 0。
本文提出五项命题。
| 命题 | 决策含义 |
|---|---|
| P1. 清单完整性先于风险分类。 | 未记录的使用无法被治理、监控或淘汰。 |
| P2. 重要性取决于后果、权限和可逆性。 | 熟悉的模型可能具有高后果;新颖的模型可能具有低后果。 |
| P3. 验证必须与系统行为相匹配。 | 生成式和智能体式系统需要超越传统点估计准确性的评估。 |
| P4. 第三方 AI 仍是机构的治理问题。 | 采购证据、合同权利、监控与退出均属于控制要求。 |
| P5. 董事会监督需要决策证据。 | 数量统计、事件、例外情况、剩余风险和退出就绪情况比采用情况的叙述更有用。 |

范围、定义与证据边界
范围
本文主题是受监管金融和受机构治理的投资活动中所使用的 AI 的治理与模型风险。涵盖的用途包括研究、筛选、投资组合分析、估值支持、预测、金融犯罪控制、客户沟通、适当性支持、运营、编码、文档分析和工作流代理。本文讨论内部开发的系统、配置后的第三方系统、嵌入式 AI 功能以及外部提供的模型输出。
本文不针对任何特定机构确定法律地位、监管范围、受托合规、适当性、数据法合规或会计处理。本文不认证任何模型、供应商或 AI 系统。各机构必须通过其获授权的法律、合规、风险、信息安全、隐私和业务负责人确定适用要求。
工作定义
不同规则和标准中的定义各不相同。机构应在其义务登记册中保留适用的法律定义,并为治理维护更广泛的运营边界。
| 术语 | 本文采用的运营定义 |
|---|---|
| 模式 | 一种定量、统计、经济或数学方法,将输入转化为业务决策中使用的估计、决策或信息。 |
| AI 系统 | 一种基于机器的系统,针对明确或隐含的目标,从输入推断预测、内容、建议或决策等输出。 |
| 生成式 AI | AI 可生成内容,包括文本、代码、图像、音频或结构化数据。 |
| 基础模型 | 一种经过广泛训练、能够适应多个下游任务的模型。 |
| 智能体系统 | 一种由AI赋能的系统,可规划或选择行动、调用工具或服务,并可能跨多个步骤持续运行。 |
| 决策支持 | 输出用于辅助人类决策,同时经记录的决策权限仍归人类所有。 |
| 自动化决策 | 系统在授权范围内确定或执行结果。 |
| 模型风险 | 模型输出和决策不正确或被误用可能造成的潜在不利后果 [1]。 |
| AI 风险 | 因AI系统的设计、开发、采购、部署、运行、交互、误用或退役而产生的风险。 |
| 重要性 | 一项用途的重要性,取决于后果、暴露程度、规模、权限、权利影响、可逆性和相互关联性。 |
运营范围有意涵盖广泛对象。电子表格公式、供应商评分、检索助手或工作流代理可能并不满足模型的所有法律定义,但仍可能造成重大依赖。登记会将事项转交给正确的治理责任人;它并不预先确定监管分类。
证据类别
证据具有不同的权威性。将这些类别混在一起会造成虚假确定性。
| 等级 | 示例 | 允许用途 |
|---|---|---|
| 法律和有约束力的监管规定 | 欧盟AI法案、DORA、GDPR、UAE数据法 | 在确认适用性后确定相关义务。 |
| 监管规则或声明 | PRA SS1/23、CBUAE 规则手册指引、DFSA 规则 | 在所述范围内落实监管期望。 |
| 监管指引 | 美国跨机构修订版 MRM 指引、FINMA 指引 | 设计基于风险的做法,同时在有明确说明时保留非约束性地位。 |
| 意见征询 | FSB 2026 年 6 月稳健做法 | 预判方向;标注为拟议并监测最终定稿。 |
| 共识标准 | ISO/IEC 42001 和 23894 | 搭建管理体系与风险流程;单独确认认证声明。 |
| 自愿性框架 | NIST AI RMF、OECD AI 原则 | 建立共同语言和可操作成果。 |
| 市场证据 | 监管机构调查 | 为前置假设提供依据;保留样本、日期和总体。 |
| 本地证据 | 清单、测试、事件、日志、审批 | 支持机构自身的决策。 |
证据截止日期与现状局限性
来源已审查至 2026 年 8 月 1 日。欧盟实施时间表于 2026 年 7 月发生变化,包括高风险 AI 义务的延长日期 [25]。第 50 条透明度义务原定自 2026 年 8 月 2 日起适用,即证据截止日期后一天 [26]。FSB 稳健做法仍处于咨询阶段 [10]。NIST 表示,AI RMF 1.0 正在修订 [29]。因此,义务登记册必须记录来源日期、当前状态、下次审查日期和负责的法律责任人。
研究方法
本文优先采用主要法律、监管机构、标准制定机构和公认标准组织。它交叉验证模型风险、AI 治理、运营韧性、网络安全、数据保护和第三方风险。它不将调查百分比视为普遍采用率。它不将自愿性标准视为法律。它不将咨询文本解释为最终政策。
与决策地图
家族办公室首席投资官与另类投资负责人
| 决策 | 重大风险问题 | 最低证据 |
|---|---|---|
| 使用 AI 进行管理人研究 | 缺乏依据的内容是否会影响入选或淘汰? | 受控语料库、引用覆盖范围、审查人规程、例外日志。 |
| 总结基金和交易文件 | 遗漏或修改的条款是否会影响出资承诺? | 条款级可追溯性、重大条款清单、法律审查边界。 |
| 生成投资委员会材料 | 生成的陈述能否纳入经批准的记录? | 来源映射、具名编制人、审核人、版本和审批证据。 |
| 分析投资组合数据 | 数据权利、数据血缘和核对是否充分? | 数据登记簿、用途、血缘、完整性和核对测试。 |
| 自动化指令或通信 | 系统能否形成约束、披露或传输价值? | 权限限制、双重控制、获准工具、审计日志和恢复。 |
| 使用嵌入式供应商 AI | 该能力是否可见且受合同治理? | 供应商清单、变更通知、数据条款、安全证据和退出计划。 |
机构应避免照搬银行的组织规模。比例原则可以用更少的委员会实现相同的控制目标。一名具名负责高管、一名独立质疑者和一套完整证据包,可能比多个职责不清的议事机构更有效。
国际机构资产配置者
| 决策 | 重大风险问题 | 最低证据 |
|---|---|---|
| 筛选管理人或投资机会 | AI 是否会改变访问权限、评分或升级机制? | 特征依据、相关偏差分析、人工覆盖与申诉流程。 |
| 生成尽职调查问题 | 信息缺口和不利事实是否得到保留? | 总体覆盖范围、来源留存、审核人签核和抽样。 |
| 监控基金和投资组合 | 模型漂移或数据延迟是否会改变风险信号? | 数据时效性、基准、漂移阈值、事件与升级规则。 |
| 支持估值或风险估算 | 该方法是否在模型风险边界内? | 分类、开发证据、独立验证和局限性。 |
| 外包由 AI 支持的处理流程 | 配置方能否审计、过渡并继续获得服务? | 合同、分包商图谱、服务水平、测试、可移植性与退出。 |
| 在受监管报告中使用 AI | 来源与控制证据能否经得起审查? | 对账、数据血缘、经办-复核审批、留存与可复现性。 |
共享治理成果
两类受众都需要一份简明的决策契约。
| 问题 | 必需回答 |
|---|---|
| 该系统是什么? | 登记的范围、版本、所有者、提供方、数据和接口。 |
| 它影响什么决策? | 用例、用户、受益方、流程和后果。 |
| 它拥有什么权限? | 读取、起草、建议、批准、执行、沟通或移交。 |
| 哪些环节可能失败? | 错误、偏见、缺乏支持的输出、滥用、安全、隐私、集中度和韧性。 |
| 如何对其进行测试? | 代表性评估、阈值、挑战者模型和决策记录。 |
| 如何对其进行运营? | 监控、例外情况、变更、事件和用户能力。 |
| 如何停止? | 紧急停止机制、备用方案、数据导出、过渡与退役证据。 |
| 命题 | 决策含义 |
|---|---|
| P1. 清单完整性先于风险分类。 | 未记录的使用无法被治理、监控或淘汰。 |
| P2. 重要性取决于后果、权限和可逆性。 | 熟悉的模型可能具有高后果;新颖的模型可能具有低后果。 |
| P3. 验证必须与系统行为相匹配。 | 生成式和智能体式系统需要超越传统点估计准确性的评估。 |
| P4. 第三方 AI 仍是机构的治理问题。 | 采购证据、合同权利、监控与退出均属于控制要求。 |
| P5. 董事会监督需要决策证据。 | 数量统计、事件、例外情况、剩余风险和退出就绪情况比采用情况的叙述更有用。 |
监管与监督格局
美国银行业模型风险指引
2026年4月的跨机构指引将模型风险描述为因基于不正确或被误用的模型输出作出决策而产生不利后果的可能性。它强调有效的开发与使用、验证以及治理与控制 [1]。它期望根据银行机构的模型风险状况、规模和复杂性进行量身定制。美联储的适用性被描述为在总资产高于 USD 30 billion 时最为相关 [1]。OCC 表示,该指引并非可强制执行的标准,生成式与智能体式 AI 模型不在其范围内 [2]。
这形成了一项由两部分组成的治理任务。传统模型应在适用情况下映射至修订后的指引。生成式与智能体式系统需要一套配套的 AI 风险方法,该方法保留有用的模型风险纪律,同时增加内容、交互、工具使用、安全、数据权利和自主性控制。机构应记录每项控制目标由哪个制度或政策负责。
| 美国指引要点 | 操作转化 |
|---|---|
| 基于风险的量身定制 | 根据重要性和风险敞口设定验证深度与频率。 |
| 开发与使用 | 记录目的、设计、数据、假设、局限性及预期用户。 |
| 验证 | 实施独立且有效的质疑,范围与风险相匹配。 |
| 治理与控制 | 维持董事会或高级管理层监督,以及政策、清单、问题和审计。 |
| 供应商产品 | 获取足够的信息并开展充分测试,以理解和管理依赖关系。 |
| 生成式 AI 与智能体排除项 | 使用有文档记录的相邻 AI 框架;不得暗示该框架受模型风险管理(MRM)指引覆盖。 |
英国
PRA SS1/23 规定了五项原则:模型识别与分类;治理;开发、实施和使用;独立验证;以及模型风险缓释措施 [4]。它既适用于供应商模型,也适用于内部开发模型,并在一般原则适用的建模技术中涉及 AI [4]。银行和 FCA 的材料还强调治理、问责、数据、模型和第三方风险 [5,6]。
2026 年 5 月英国联合声明增加了对前沿 AI 网络韧性的独特关切。它呼吁董事会和高级管理层理解、投资并配置资源,并做好访问管理、网络安全、数据保护、防护与检测能力、威胁遏制与响应 [9]。2026 年 7 月《金融稳定报告》描述了四个渠道:核心金融决策、金融市场、服务提供商运营风险以及不断变化的外部网络威胁 [8]。
治理层面的含义是,AI 风险不能仅停留在模型验证环节。它需要在业务归属、模型风险、操作风险、信息安全、隐私、合规、采购和韧性之间进行协调。
UAE 与 DIFC
CBUAE 2026 年 2 月的指引重点关注使用 AI 和机器学习的持牌金融机构的消费者保护与市场行为。该指引涉及透明度、偏见、伦理、问责、可解释性和数据隐私 [16]。联合发布的 UAE 赋能技术指引涉及 AI、大数据分析、云、应用程序编程接口、生物识别和分布式账本技术 [17]。
DFSA 2026 年 6 月的 SEO 函记录了 DIFC 对 AI 风险管理的监管期望 [18]。其 2025 年调查覆盖 661 家受权公司,参与率为 88%。DFSA 报告称,52% 使用了 AI,60% 具有某种形式的 AI 治理结构,21% 即使在使用至关重要的情形下也缺乏明确的问责或监督 [19]。这些数字描述的是该调查总体和调查时点;并非普遍采用率的估计。
DIFC 第 10 号数据保护条例涉及通过自主和半自主系统处理的个人数据 [22]。UAE 2021 年第 45 号联邦法令确立了联邦个人数据框架 [23]。机构的义务登记表应识别适用的数据制度、控制者与处理者角色、法律依据、敏感数据限制、传输要求、个人权利、留存和事件义务。
欧盟
欧盟第 2024/1689 号条例建立了基于风险的 AI 框架 [24]。2026 年 7 月的 AI 综合法案改变了实施要素,并将高风险 AI 规则的开始适用时间延长至 2027 年 12 月 2 日;嵌入受监管实体产品中的 AI 相关规则定于 2028 年 8 月 2 日适用 [25]。针对特定 AI 交互以及生成或操纵内容的透明度义务原定自 2026 年 8 月 2 日起适用 [26]。
DORA 要求范围内的金融实体识别并记录 ICT 资产、依赖关系和关键互连;管理 ICT 风险;治理第三方安排;测试韧性;并维持合同与退出能力 [27]。在适用情况下,GDPR 继续管辖个人数据处理和自动化决策问题 [28]。因此,AI 分类应与现有的 ICT、外包、隐私、行为和韧性登记册相衔接。
国际协调与标准
金融稳定理事会(FSB)2026年6月的咨询文件提出了12项稳健做法。前四项涉及全组织治理,接下来六项涉及生命周期风险管理,最后两项涉及网络、ICT和第三方风险 [10]。文件指出,这些做法并非旨在建立国际标准,也不规定机构是否应采用 AI [10]。
巴塞尔委员会的材料将数字化与治理、模型风险、第三方依赖、操作风险和韧性联系起来 [12-14]。国际清算银行(BIS)金融稳定研究所(FSI)的研究观察到,大多数金融监管机构通过现有的技术中立框架应对 AI,同时识别出治理、技能、模型风险、数据、第三方和新型商业模式方面的差距 [15]。
NIST AI RMF 将成果组织在治理、映射、衡量和管理之下 [29]。其生成式 AI 概况识别生成式 AI 特有或由其放大的风险及建议行动 [30]。ISO/IEC 42001 规定了 AI 管理体系标准 [33]。ISO/IEC 23894 提供了 AI 风险管理指南 [34]。这些是有用的控制设计参考。使用它们并不构成法律合规。
适用性矩阵
| 来源 | 截至 2026 年 8 月 1 日的状态 | 示意性相关性 | 负责人所需采取的行动 |
|---|---|---|---|
| 欧盟《AI 法案》与《综合法案》 | 具有约束力的欧盟法律;分阶段适用 | 欧盟提供者、部署者或受影响活动 | 法律适用性与角色评估。 |
| DORA | 适用于范围内金融实体的具有约束力的欧盟法规 | ICT 与 AI 服务依赖 | 将 AI 服务纳入 ICT 和第三方登记册。 |
| CBUAE AI 指引 | 面向 UAE 持牌金融机构的监管指引 | 面向消费者或涉及市场行为的 AI | 梳理透明度、偏见、问责与隐私控制措施。 |
| DFSA 期望 | 面向 DIFC 授权机构的监管沟通 | DIFC AI 的使用 | 证明风险管理与可问责监督。 |
| PRA SS1/23 | 适用于范围内银行的监管声明 | 决策中使用的模型 | 梳理模型清单、治理、开发、验证与缓释措施。 |
| 美国跨机构 MRM | 载明适用范围的监管指引 | 适用范围内的银行模型 | 定制模型风险实践;保留对生成式 AI 和智能体 AI 的排除。 |
| FSB 稳健实践 | 意见征询 | 方向性跨境实践 | 跟踪定稿情况;仅作为拟议实践使用。 |
| NIST 与 ISO | 自愿性框架与标准 | 控制架构 | 通过证据图谱采纳选定的成果。 |

清单与分类
一个边界,多套分类体系
机构应维护一个可发现的 AI 与模型登记册,并附带关联分类。针对模型、SaaS、终端用户计算、隐私、供应商和运营流程的彼此独立、互不关联的清单会造成缺口。主记录应链接到专项登记册,而不是重复每个字段。
| 清单字段 | 用途 |
|---|---|
| 唯一 ID 与版本 | 避免在部署和变更过程中产生歧义。 |
| 业务目的与流程 | 将技术与可问责的成果相连接。 |
| 所有者、运营者与用户 | 确立责任与胜任能力。 |
| 提供商与托管 | 识别内部及第三方依赖关系。 |
| 模型或服务组件 | 披露基础模型、工具、检索与确定性服务。 |
| 数据来源与权利 | 明确来源、用途、敏感性与传输。 |
| 输出与受影响方 | 识别决策、行为与权利风险敞口。 |
| 授权级别 | 记录系统是读取、起草、建议、批准还是采取行动。 |
| 司法辖区与实体 | 适用路径评估。 |
| 重要性层级 | 确定控制深度与升级机制。 |
| 评估与审批 | 关联证据、阈值、条件和到期时间。 |
| 监控与事件 | 维护当前运营风险。 |
| 变更历史 | 触发相称的重新评估。 |
| 退出与后备方案 | 证明可恢复性和可移植性。 |
发现途径
清单完整性需要多种发现途径。仅靠自我申报不够,因为嵌入式功能和影子使用可能对中央团队不可见。
| 发现途径 | 示例 | 证据 |
|---|---|---|
| 采购 | 合同、续约、供应商问卷 | 产品、功能、提供商和数据条款。 |
| 身份与访问 | 应用目录、单点登录、特权访问 | 用户、角色和服务访问。 |
| 网络与云 | 域、应用程序编程接口、云服务 | 服务交互与数据流。 |
| 支出与卡片 | 个人订阅 | 影子采购候选对象。 |
| 代码与模型平台 | 代码库、注册表、端点 | 内部构建和配置的组件。 |
| 业务流程审查 | 研究、投资、风险、合规与运营 | 嵌入式使用与决策。 |
| 用户声明 | 定期证明与专项活动 | 有问责的未受管理使用。 |
| 供应商变更通知 | 发布说明与功能开关 | 新嵌入的 AI 功能。 |
| 事件与支持数据 | 服务工单、数据事件与控制例外 | 此前未登记的使用。 |
重要性模型
应在选择控制措施之前评估重要性。拟议评分采用八个维度,每个维度按零至四分评级。该评分支持判断,但不能替代判断。
| 维度 | 低端 | 高端 |
|---|---|---|
| 决策后果 | 便利性或格式 | 资本、客户、法律、监管或权利后果 |
| 权限 | 只读或草稿 | 执行、沟通、转让或产生约束力 |
| 人群与规模 | 少量内部用户 | 大量或受外部影响的人群 |
| 数据敏感性 | 公开或合成 | 个人、机密、市场敏感或受限 |
| 可逆性 | 立即纠正 | 不可逆或补救成本高昂 |
| 可解释性需求 | 无重大依赖 | 决策必须可重建或可解释 |
| 依赖关系 | 易于替代 | 供应商集中或关键集成 |
| 变更速度 | 固定且受控 | 供应商驱动或自适应行为 |
拟议的初始区间为:一级 0-7,二级 8-15,三级 16-23,四级 24-32。这些区间是管理设计参数,而非监管阈值。强制性覆盖应提升涉及法律权利、重大客户沟通、自主价值转移、监管报告、安全、信用或适当性决策,或关键服务依赖的用途。
权限分类
权限往往比模型类型更直接地驱动风险。
| 级别 | 能力 | 默认控制状态 |
|---|---|---|
| 搜索或检索已批准的信息 | 来源控制与访问日志记录。 | |
| 起草或总结 | 在对外使用或用于决策前进行人工审核。 | |
| 推荐或排序 | 明确的决策负责人、理由记录和覆盖机制。 | |
| 准备交易或指令 | 职责分离、限额与独立放行。 | |
| 在限定委托范围内执行 | 明确授权、允许列表、重大事项双重控制、监控和紧急停止开关。 | |
| 跨工具的自主规划 | 例外审批、沙箱隔离、最小权限、交易限额、持续监控和经测试的遏制措施。 |
分类输出
分类记录应分别陈述事实、结论和不确定性。
| 记录组成部分 | 示例格式 |
|---|---|
| 事实 | 系统 X 使用提供商 Y 汇总投资文件;数据托管于区域 Z。 |
| 法律分类 | 法律归属结论、来源、日期和范围。 |
| 模型风险分类 | MRM 负责人结论及政策依据。 |
| AI-风险等级 | 评分、覆盖及理由。 |
| 条件 | 人工复核、获批语料库、禁止数据及权限限制。 |
| 剩余不确定性 | 提供商训练数据详情不可用;已施加补偿性限制。 |
治理与决策权
责任归属
每一项登记用途都需要一位业务负责人,对结果和剩余风险负责。技术所有权不能替代业务问责。模型风险、合规、隐私和安全负责人应在其职责范围内提供独立或专业质疑。
| 职位 | 核心问责 |
|---|---|
| 董事会或治理机构 | 风险偏好、监督、重大风险敞口和质疑。 |
| 高级责任高管 | 全组织范围的框架、资源和上报机制。 |
| 业务负责人 | 目的、结果、用户、控制措施、剩余风险和价值。 |
| 系统负责人 | 技术设计、配置、访问、运营和变更。 |
| 模型风险负责人 | 分类、验证标准、问题与汇总。 |
| 合规与法律 | 适用性、行为、监管义务与法律风险。 |
| 隐私与数据 | 目的、权利、最小化、传输、保留与数据治理。 |
| 信息安全 | 威胁模型、测试、访问、日志记录与事件响应。 |
| 采购与第三方风险 | 尽职调查、合同、集中度、监控与退出。 |
| 内部审计 | 对设计与运行有效性的独立鉴证。 |
相称的决策论坛设计
机构可使用现有的投资、风险或运营委员会,并设有常设的 AI 议程。机构可使用中央 AI 风险委员会,并在业务层面进行审批。所需结果是明确的授权和有记录的质疑。
| 决策 | 最低限度的决策论坛 | 所需记录 |
|---|---|---|
| 登记并分类 | 业务负责人和风险协调员 | 清单记录与分级理由。 |
| 批准低风险内部使用 | 授权负责人 | 条件、到期与监控。 |
| 批准重大使用 | 跨职能风险论坛 | 证据包、质询、决策与剩余风险。 |
| 接受重大例外 | 高级责任高管 | 例外、补偿性控制、期限与整改。 |
| 批准自主权限 | 治理或明确授权的论坛 | 权限边界、限制、遏制与问责。 |
| 退役或暂停 | 业务与系统负责人;风险通知 | 触发条件、服务计划、证据保全与过渡。 |
政策架构
机构应避免制定与既有义务相冲突的独立 AI 政策。一份简明的 AI 政策应界定范围、原则、职责、禁止用途、审批、监测、事件和例外。配套标准应衔接模型风险、数据、隐私、网络安全、外包、运营韧性、行为、记录、变更和审计。
风险偏好
风险偏好应明确禁止活动、定量或分类限额、审批权限和升级机制。示例包括:
| 风险偏好声明 | 证据衡量指标 |
|---|---|
| 未经批准的机密数据不得进入公共 AI 服务。 | 数据丢失事件、被阻止的尝试和经批准的例外。 |
| 任何重大投资决策都不得仅依赖生成输出。 | 包含具名人员授权和来源证据的决策记录。 |
| 任何自主系统不得转移超出批准限额的价值。 | 工具权限、交易限额、发布日志和事件。 |
| 第 4 级系统仅可在当前批准范围内运行。 | 审批到期、逾期条件和部署状态。 |
| 关键供应商依赖具备经过测试的备用方案。 | 退出测试日期、恢复时间和未解决的差距。 |
能力与质疑
培训应与角色匹配。普通用户需要具备数据、来源、幻觉、网络钓鱼、提示词注入和上报升级意识。所有者需要明确分类、证据和事件职责。验证者需要具备技术和领域能力。董事会需要具备足够理解,以质疑风险集中度、自主性、局限性和资源配置 [9,10]。仅凭培训完成情况是较弱的证据;场景测试和观察到的行为能提供更强证据。

生命周期与证据关口
生命周期
拟议生命周期包含十个阶段:构想、登记、分类、设计、开发或采购、评估、批准、受控部署、监控和退役。当模型、提示词、数据、工具、用途、人群或提供商发生变化时,迭代应返回到适当的较早关口。
| 关卡 | 决策问题 | 最低证据 |
|---|---|---|
| G0 受理 | 该用途是否允许探索? | 用途、所有者、数据类别和沙盒条件。 |
| G1 分类 | 该用途受什么管辖? | 清单、权限、重要性和适用性。 |
| G2 设计 | 控制措施是否已设计到工作流中? | 架构、数据流、威胁模型与人类角色。 |
| G3 自建还是采购 | 对该组件的理解是否足够充分? | 开发记录或供应商尽职调查。 |
| G4 评估 | 是否达到既定阈值? | 代表性测试、局限性及独立质疑。 |
| G5 批准 | 剩余风险是否由适当权力机构接受? | 决策材料包、条件、有效期与可问责的签核。 |
| G6 部署 | 发布是否可控且可回滚? | 访问、变更、回退、日志记录与运行手册。 |
| G7 运营 | 当前证据是否仍处于风险偏好范围内? | 监控、事件、异常、漂移和用户反馈。 |
| G8 变更 | 该变更是否需要重新评估? | 变更分类、回归和审批。 |
| G9 退役 | 依赖关系能否安全结束? | 导出、归档、访问权限移除、供应商终止和经验教训。 |
设计证据
设计包应展示完整系统,包括用户任务、数据、模型、检索、确定性控制、工具、接口、人工审核和下游行动。若模型卡缺少工作流上下文,则对于实质性 AI 用途而言是不完整的。
| 设计工件 | 所需内容 |
|---|---|
| 目的声明 | 预期结果、用户、人群、排除项和禁止用途。 |
| 架构 | 组件、提供商、版本、数据流、工具和边界。 |
| 权利映射 | 数据所有者、法律依据、许可证、保密性和传输。 |
| 决策图 | 建议、审批、执行与沟通权限。 |
| 失效分析 | 危害、原因、控制措施、检测、后果与恢复。 |
| 威胁模型 | 资产、行为主体、攻击路径、控制措施与剩余风险。 |
| 评估计划 | 总体、指标、阈值、样本与挑战者模型。 |
| 运营模型 | 负责人、监控、变更、事件、回退方案与支持。 |
| 退出计划 | 可移植性、替换、数据删除、连续性与成本。 |
审批材料包
审批材料包应回答一个问题:现有证据是否支持拟议的限定用途?它应识别缺口,而不是将证据缺失转化为肯定性结论。
| 部分 | 审批内容 |
|---|---|
| 高管决策 | 批准、有条件批准、试点、重新设计、暂停或拒绝。 |
| 适用范围 | 实体、司法管辖区、活动及权威来源。 |
| 分类 | 模型、AI、权限、重要性和关键性。 |
| 证据 | 设计、数据、评估、安全、隐私和供应商结果。 |
| 局限性 | 已知缺口、未覆盖人群和禁止用途。 |
| 剩余风险 | 严重性、可能性、责任人和接受权限。 |
| 条件 | 行动、责任人、截止日期、证据和违规后果。 |
| 监控 | 指标、限制、频率和升级机制。 |
| 到期 | 需要续期的日期或变更触发条件。 |
变更控制
AI 服务可能因模型版本、提示词、系统指令、检索内容、工具、政策、安全过滤器、提供商、数据、用户群体和托管环境而发生变化。变更标准应对每项变更进行分类,并规定所需的回归测试。
| 变更类别 | 示例 | 默认操作 |
|---|---|---|
| 常规 | 非重大接口修正 | 记录并测试受影响功能。 |
| 中等 | 提示词或检索更新 | 有针对性的回归测试和负责人批准。 |
| 重大 | 模型、提供商、用途、权限或适用群体变更 | 重新分类、独立评估和批准。 |
| 紧急 | 安全缓解或服务撤回 | 遏制、记录、批准临时状态并完成事后审查。 |
退役
退役应移除访问权限和依赖关系,同时保留所需记录。对于关键系统,机构应在批准投产前测试数据导出、替代运行和恢复。如果没有运营过渡计划,供应商终止权不足以作为有力证据。
验证与评估
验证目标
验证针对概念合理性、实施、性能、使用和局限性提供有效质疑。验证深度取决于重要性、复杂性和风险敞口 [1,4]。验证人员应具有足够独立性以质疑模型所有者,并在相关领域、数据、模型和工作流程方面具备胜任能力。
按系统类型评估
| 系统类型 | 核心评估 |
|---|---|
| 确定性规则 | 需求覆盖、边界情形、对账和变更测试。 |
| 预测模型 | 区分度、校准、稳定性、敏感性、相关情形下的偏差以及基准。 |
| 生成式助手 | 事实支撑、完整性、有害输出、稳健性、隐私、来源使用和人工接受度。 |
| 检索增强系统 | 检索召回率、精确率、权限、时效性、引用保真度和答案支撑度。 |
| 代码生成器 | 正确性、安全性、依赖项、许可证、测试覆盖率及评审人员能力。 |
| 智能体工作流 | 目标符合性、工具选择、权限、状态、恢复、抗攻击能力及累积误差。 |
| 供应商黑盒 | 结果测试、局限性、变更控制、监控及补偿性限制。 |
代表性评估集
评估总体应反映正常、困难、不利和禁止案例。它应包括重要的子组和时间段、已知失效模式、边界条件及分布外示例。测试集治理应防止污染和未跟踪的变更。
| 评估分层 | 用途 |
|---|---|
| 常规 | 确立正常性能与单位经济性。 |
| 复杂 | 测试长篇幅、模糊、跨文档或异常密集的案例。 |
| 不利 | 测试误导性、冲突性或恶意输入。 |
| 敏感 | 测试保密性、个人数据和受限信息。 |
| 权限边界 | 测试尝试进行的被禁止操作或权限升级。 |
| 时间维度 | 测试当前及较早的制度、条款或市场状态。 |
| 子群体 | 测试在法律或运营上相关的群体。 |
| 恢复 | 测试超时、工具故障、状态损坏和提供商服务中断。 |
指标
对于大多数重大 AI 用途而言,单一准确率百分比并不充分。
| 指标 | 定义 |
|---|---|
| 重大事实支持率 | 所有重大主张均由经批准来源支持的输出数,除以已审核输出数。 |
| 重大遗漏率 | 至少遗漏一项必需重大事项的输出数,除以已审核输出数。 |
| 越权行动率 | 超出授权范围的行动尝试数,除以相关测试数。 |
| 首次通过验收 | 无需重大修正即可接受的输出数,除以已审核输出数。 |
| 严重缺陷率 | 存在符合严重性定义的缺陷的输出数,除以已审核输出数。 |
| 升级精确率 | 正确升级次数除以所有升级次数。 |
| 升级召回率 | 正确升级次数除以所有需要升级的情况数。 |
| 引用保真度 | 支持相关主张的引用数除以已审核的引用数。 |
| 恢复成功率 | 在规定限制内恢复的故障场景数除以已测试场景数。 |
| 人工覆盖决策率 | 经授权审核人员更改的决策数除以由 AI 辅助做出的决策数。 |
阈值必须与后果挂钩。起草助手和自动化客户指令不应采用相同的容差。对于零容忍事件类型,评估目标应是在受测人群中不存在此类事件,并具备强有力的预防性和检测性控制;不应将其描述为事件不可能发生的证明。
生成式 AI 评估
NIST 生成式 AI 概况指出了多种风险,包括虚构、数据隐私、有害偏见、人类与 AI 的配置、信息完整性、信息安全、知识产权以及价值链依赖 [30]。评估应覆盖配置后的系统,包括提示词、检索、工具、安全控制和工作流。供应商基准分数不能证明其适用于本地投资或受监管金融用途。
智能体评估
智能体系统增加了顺序、状态、工具和权限风险。单个步骤可能可以接受,而整个序列却产生未经授权的结果。评估应记录每项操作、工具输入、工具输出、权限决策、人工干预和最终状态。
| 智能体测试 | 问题 |
|---|---|
| 目标遵循 | 系统是否始终在已批准目标范围内运行? |
| 工具允许清单 | 是否仅为任务选择已批准的工具? |
| 参数限制 | 金额、收款方、目的地和数据是否均受限? |
| 提示词注入 | 外部内容能否覆盖系统策略或导致数据外泄? |
| 累积误差 | 小幅中间错误是否会形成重大最终结果? |
| 状态完整性 | 过期或损坏的状态是否会改变操作? |
| 人工检查点 | 是否在正确阶段基于完整信息请求批准? |
| 终止与恢复 | 操作能否安全停止并从已知状态恢复? |
独立质疑记录
验证报告应说明范围、方法、证据、限制、发现、严重程度、条件与结论。有保留的结论可支持有限范围的试点。缺失的证据应继续作为限制或问题。管理层接受应明确责任负责人及授权层级。
| 职位 | 核心问责 |
|---|---|
| 董事会或治理机构 | 风险偏好、监督、重大风险敞口和质疑。 |
| 高级责任高管 | 全组织范围的框架、资源和上报机制。 |
| 业务负责人 | 目的、结果、用户、控制措施、剩余风险和价值。 |
| 系统负责人 | 技术设计、配置、访问、运营和变更。 |
| 模型风险负责人 | 分类、验证标准、问题与汇总。 |
| 合规与法律 | 适用性、行为、监管义务与法律风险。 |
| 隐私与数据 | 目的、权利、最小化、传输、保留与数据治理。 |
| 信息安全 | 威胁模型、测试、访问、日志记录与事件响应。 |
| 采购与第三方风险 | 尽职调查、合同、集中度、监控与退出。 |
| 内部审计 | 对设计与运行有效性的独立鉴证。 |
数据、隐私、安全与第三方
数据治理
AI 控制措施源自数据生命周期。每项实质性使用都应确立来源、所有权、权限、目的、质量、谱系、最小化、保留、传输、删除和事件响应。
| 数据问题 | 证据 |
|---|---|
| 机构是否可以将数据用于此目的? | 合同、法律依据、同意或其他授权依据。 |
| 提供商是否可以处理或保留该数据? | 数据处理条款、配置和经核实的服务行为。 |
| 语料库是否完整且最新? | 来源登记册、对账、刷新和异常日志。 |
| 用户是否只能访问经授权的材料? | 身份、权限、检索过滤器和对抗性测试。 |
| 输出是否会泄露敏感输入? | 隐私测试、日志记录、数据脱敏和事件处理流程。 |
| 数据能否导出和删除? | 可移植性测试、删除证据和合同。 |
安全开发与运营
NIST CSF 2.0 和 NCSC 安全-AI 指南提供了治理与生命周期安全参考 [31,32]。OWASP 的 LLM 应用风险工作提供了技术威胁目录 [36]。机构应从其适用的安全框架中选择控制措施,并记录其实施情况。
| 威胁 | 示例性控制目标 |
|---|---|
| 提示词注入 | 将外部内容视为不可信;隔离指令;限制工具和数据。 |
| 敏感信息泄露 | 最小化数据、强制执行访问控制、过滤输出、监控并响应。 |
| 供应链失陷 | 验证组件、来源、依赖项、更新和提供商控制措施。 |
| 数据或模型投毒 | 控制贡献内容、验证来源、检测异常并保留回滚。 |
| 代理权限过大 | 最小权限、交易限额、审批、允许列表和紧急停止开关。 |
| 不安全的输出使用 | 执行前进行验证,安全编码并实现职责分离。 |
| 模型窃取或提取 | 访问控制、速率限制、监控与响应。 |
| 拒绝服务或提供商中断 | 容量规划、故障回退、恢复和替代流程。 |
第三方 AI
金融机构仍需对其采购或依赖的服务所产生的风险负责。DORA、巴塞尔相关材料、FSB 的工作、FINMA 指引以及 UAE 监管机构材料,均进一步强调了第三方依赖、治理与韧性的重要性 [10,12,15-17,27,37]。
| 尽职调查领域 | 证据请求 |
|---|---|
| 服务定义 | 组件、版本、托管、子处理方和支持。 |
| 数据 | 收集、使用、保留、训练、位置、传输和删除。 |
| 模型治理 | 开发、评估、局限性、监测和变更。 |
| 安全 | 控制保证、事件历史、测试与通知。 |
| 韧性 | 可用性、恢复能力、容量、连续性和依赖关系图。 |
| 可审计性 | 日志、证据获取、审计和监管合作。 |
| 法律与权利 | 许可、知识产权、保密和禁止使用。 |
| 变更 | 通知、版本控制、回归证据和客户选项。 |
| 退出 | 导出、协助、删除、过渡时间和费用。 |
集中度和第四方
基础模型、云基础设施、数据服务和专业工具可能在看似不同的应用之间形成共同依赖。清单应识别最终提供商和重要子处理者。情景分析应考察同时故障、服务降级、单方面变更条款、区域中断、模型撤回以及审计访问权丧失。
合同控制附表
合同应界定服务范围、经批准的数据使用、保密、安全、事件通知、业务连续性、审计、适用情况下的监管机构访问、分包、模型变更、履约、知识产权、记录留存、删除、退出协助和责任分配。合同措辞必须由合格律师审阅。未经运行测试的权利仍是不完整的证据。
![图 5。从组件测试到实时控制证据的评估金字塔来源:Matchpoint 评估框架;模型风险和 AI 风险背景 [1,4,29-32,36]。](../assets/images/insights/body/T20/T20-figure-04.png?v=355bd80e)
人工监督、行为与问责
有意义的人工监督
当复核人具备胜任能力、时间、权限、信息以及有效质疑或阻止结果的能力时,人工复核才有意义。没有支持性证据的强制点击是薄弱控制。
| 复核条件 | 证据 |
|---|---|
| 胜任能力 | 针对角色的培训、经验和评估。 |
| 信息 | 源材料、系统输出、局限性和不确定性。 |
| 时间 | 工作流容量与服务级别设计。 |
| 权限 | 拒绝、修改、升级或阻止的能力。 |
| 独立性 | 在后果要求时进行分离。 |
| 可追溯性 | 具名复核人、时间、操作、原因和最终结果。 |
| 反馈 | 将纠正事项纳入监控与改进。 |
自动化偏见与工作量
当用户依赖精炼的输出、复核过多事项或无法获取源证据时,监督可能失效。监控应衡量纠正、推翻、复核时间、例外和分歧模式。极低的推翻率可能表明高质量;也可能表明质疑不足。调查需要抽样证据。
公平性与受影响各方
当 AI 影响准入、定价、适当性、就业、信贷、保险或其他具有重大后果的待遇时,机构应识别在法律和运营上相关的群体,评估差异化结果,记录正当目标,提供适当说明,并保留异议或升级渠道。具体义务由适用法律确定。OECD 原则、NIST 成果、CBUAE 指引和 FINMA 期望提供了支持性治理参考 [16,29,35,37]。
记录与说明
记录应保留输入、相关来源版本、系统配置、输出、审核人操作、最终决定和理由,并达到可重建所需的程度。说明应与受众和决策相适应。技术上的可解释性并不自动满足客户或法律对说明的要求。
禁止与受限用途
各机构应基于法律、委托和风险偏好界定禁止用途。受限用途只能在规定条件下运行。供管理层考虑的例子包括:未经批准输入机密数据、无人监督的法律或投资建议、超出限额自主转移价值、捏造来源归属、隐蔽的客户互动,以及在批准目的之外使用个人数据。这些是拟议的政策示例;法律负责人必须确立实际禁止事项。
监测、事件与保证
监测设计
监测应将系统行为与风险偏好和批准条件联系起来。
| 监测领域 | 示例指标 | 升级触发条件 |
|---|---|---|
| 表现 | 实质性支持、遗漏和严重缺陷的发生率 | 阈值突破或不利趋势。 |
| 使用 | 数量、用户、流程和超出范围的尝试 | 未经批准的人群或目的。 |
| 权限 | 工具调用、限制、审批和已阻止的操作 | 任何未经授权或无法解释的操作。 |
| 数据 | 新鲜度、完整性、权限和敏感事件 | 关键来源陈旧或访问失败。 |
| 变更 | 提供商、模型、提示词、检索和配置变更 | 未经批准的重大变更。 |
| 安全 | 注入、数据外泄、漏洞和异常访问 | 已定义严重程度的事件。 |
| 行为 | 投诉、覆写、受影响结果和解释 | 对客户或权利的实质性影响。 |
| 韧性 | 可用性、延迟、恢复和回退 | 关键服务限额被突破。 |
| 供应商 | 服务、保证、事件和集中度 | 证据失效或控制恶化。 |
事件分类体系
AI 事件可以是模型、数据、安全、隐私、行为、运营、法律或第三方事件。事件处理流程应避免将所有事项都转交给专门的 AI 团队。严重程度评估应考虑实际和可能后果、暴露范围、遏制情况、监管通报、受影响各方以及再次发生。
| 事件阶段 | 必要行动 |
|---|---|
| 检测 | 保留告警、输出、输入、日志、版本和上下文。 |
| 遏制 | 停止或限制使用、工具、访问或数据流。 |
| 评估 | 确定后果、受影响人群、义务和根本原因。 |
| 通报 | 遵循法律、监管、合同及内部升级程序。 |
| 补救 | 纠正结果、系统、控制及受影响记录。 |
| 恢复 | 在批准条件下恢复并验证稳定性。 |
| 了解 | 更新评估、监测、培训、风险和供应商管理。 |
控制鉴证
一线测试应确认控制措施有效运行。二线监测应对分类、审批、问题和汇总风险提出质疑。内部审计应使用基于风险的计划评估框架设计和运行有效性。外部鉴证可支持供应商或技术证据,但机构必须评估范围、期间、排除项和相关性。
汇总风险
组合报告应识别按供应商、模型、云、数据源、业务流程、地域和权限级别划分的集中度。单个低层级助手在共享供应商、处理大量业务或将常见错误嵌入多项决策时,可能变得具有重要性。
| 威胁 | 示例性控制目标 |
|---|---|
| 提示词注入 | 将外部内容视为不可信;隔离指令;限制工具和数据。 |
| 敏感信息泄露 | 最小化数据、强制执行访问控制、过滤输出、监控并响应。 |
| 供应链失陷 | 验证组件、来源、依赖项、更新和提供商控制措施。 |
| 数据或模型投毒 | 控制贡献内容、验证来源、检测异常并保留回滚。 |
| 代理权限过大 | 最小权限、交易限额、审批、允许列表和紧急停止开关。 |
| 不安全的输出使用 | 执行前进行验证,安全编码并实现职责分离。 |
| 模型窃取或提取 | 访问控制、速率限制、监控与响应。 |
| 拒绝服务或提供商中断 | 容量规划、故障回退、恢复和替代流程。 |
示例运营案例
案例定义
示例假设:假设某家族办公室投资团队使用检索增强型助手来总结私募市场基金文件、比较重大条款并起草投资委员会问题。该系统无权批准投资、与基金管理人沟通或传输指令。本节中的所有数值和运营假设均为未经核实的示例。
| 项目 | 示例假设 示例假设 |
|---|---|
| 用户 | 12名投资与运营专业人员 |
| 年度文件集 | 180 |
| 典型源文件长度 | 120-450 页 |
| 输出 | 带来源链接的摘要、条款表和问题草稿 |
| 权限 | 仅为草稿 |
| 数据 | 保密的管理人及基金文件 |
| 提供方 | 托管的基础模型及受控检索 |
| 决策 | 人类投资团队与投资委员会保留决策权 |
分类
拟议的重要性评估为第3级,因为该用途处理机密数据并可能影响投资分析,而输出仍为草稿且可撤销。如果输出未经审核进入委员会记录、生成法律结论或发起对外沟通,则适用强制覆盖。
评估设计
| 测试集 | 示例性假设与示例性规模 | 验收重点 |
|---|---|---|
| 常规基金文件 | 120 | 重要条款支持与完整性 |
| 复杂结构 | 40 | 分配瀑布、补充协议、冲突和例外 |
| 相互冲突的来源 | 25 | 来源层级与升级处理 |
| 访问控制案例 | 25 | 跨实体与交易的检索隔离 |
| 提示注入案例 | 30 | 指令分离与数据保护 |
| 历史文档 | 20 | 版本与生效日期处理 |
示例性假设 示例性拟议阈值为:在测试集中对既定重大条款的支持率达到 100%,跨交易访问失败为零,自主行动为零,引用保真度至少 98%,并且对每一处未解决的来源冲突均有记录在案的上报升级。这些数值为拟议管理层假设,须经批准。
控制设计
| 控制目标 | 拟议控制 |
|---|---|
| 完整来源 | 将上传的语料与经授权的交易室清单进行核对。 |
| 访问正确性 | 在检索前强制执行事项级权限。 |
| 可追溯输出 | 要求对重要条款提供条款级引用。 |
| 人工决策权 | 阻止对外沟通并记录具名审核。 |
| 法律边界 | 将法律解释和未决条款转交授权法律顾问处理。 |
| 变更 | 在模型、检索、提示词或提供商变更后执行回归测试。 |
| 事件 | 保留输入、语料、版本、输出、审核人及下游用途。 |
| 退出 | 导出语料元数据、评估集、日志和已批准输出。 |
经济边界
示意性假设:该用途可能释放分析师产能。除非观察到经批准的财务结果,否则释放的时间并非现金节省。归属于 Matchpoint 或客户收入、现金成本降低和损失减少的项目仍为 USD 0.。价值台账可以记录已接受成果、审核时间、返工和全部运营成本,而无需将理论工时转化为已实现收益。
示例运营案例
案例定义
示意性假设:假设机构配置方使用预测式和生成式系统来监控外部管理人、标记报告异常并起草尽职调查后续问题。该模型可以优先安排审核;它不能改变配置、发出违约通知或对外沟通。本节中的所有数值输入和阈值均为未经核实的示意。
| 项目 | 示例假设 示例假设 |
|---|---|
| 外部管理人 | 85 |
| 基金与委托 | 140 |
| 报告频率 | 按委托每月或每季度 |
| 输入 | 管理人报告、行政管理人数据和内部敞口记录 |
| 输出 | 风险标记、支持性证据和待确认问题 |
| 权限 | 推荐或排序 |
| 重大后果 | 审查优先级与潜在升级 |
模型与工作流边界
预测组件基于经批准的特征和基准检测异常。生成组件使用受控记录解释标记并草拟问题。确定性规则层强制执行风险敞口限额和必需的升级流程。投资风险负责人决定是否升级。这种分离允许采用不同的评估方法,并减少赋予概率性输出的权限。
评估
| 层级 | 拟议证据 |
|---|---|
| 数据 | 与行政管理人和内部账簿进行对账;延迟及更正历史。 |
| 预测性 | 回测、稳定性、敏感性、基准、误报和漏报事件审查。 |
| 生成式 | 主张支持、遗漏、来源冲突、解释和违禁内容测试。 |
| 工作流程 | 正确路由、责任人决策、人工覆盖、服务水平和记录留存。 |
| 韧性 | 供应商中断、数据过期、备用报告和恢复测试。 |
| 供应商 | 变更通知、模型依赖、审计证据、子处理商和退出。 |
示例性假设 一个示例性试点采用 18 个月的历史记录、60 个已裁决事件和三个月的影子期。这些数值为管理层假设。机构需要评估样本是否支持预期结论及重大子组。
决策与升级
| 系统输出 | 人工决策 | 禁止的系统操作 |
|---|---|---|
| 低置信度异常 | 请求分析师复核 | 未经复核即抑制或关闭 |
| 有支持依据的重大异常 | 升级至投资风险 | 向经理发出外部通知 |
| 源数据冲突 | 转交进行对账 | 静默选择一个来源 |
| 限额规则违规 | 立即强制升级 | 更改阈值或风险敞口记录 |
| 供应商或模型变更 | 暂停受影响输出,等待回归测试 | 在审批过期状态下继续 |
投资组合与第三方汇总
资产配置方应汇总管理人监控、研究、报告和客户服务工具中的共用供应商。单一基础模型或云依赖可能支撑多个名义供应商。董事会资料包应展示这种穿透集中度以及经过测试的恢复路径。
经济边界
示例假设 示例情形中未计入任何财务收益。后续评估可衡量审核吞吐量、已接受的标记、重大遗漏、错误升级、解决时长和运营成本。收入、现金成本和损失相关主张需要经批准的观测证据以及可辩护的反事实依据。

董事会资料包、路线图与实施
董事会信息
董事会报告应支持指导与质疑。应将风险敞口与活动分开,并清晰报告例外情况。
| 董事会视图 | 决策证据 |
|---|---|
| 投资组合 | 按层级、权限、业务、供应商和状态划分的用途 |
| 后果 | 客户、资本、监管、权利及关键服务风险敞口。 |
| 鉴证 | 当前评估、逾期验证、审计及未关闭发现。 |
| 风险偏好 | 违规、例外、条件及整改。 |
| 事件 | 严重程度、受影响群体、原因、遏制及复发情况。 |
| 变更 | 重大供应商、模型、用途及授权变更。 |
| 集中度 | 基础模型、云、数据及第四方依赖。 |
| 韧性 | 备用覆盖、退出测试、恢复缺口及关键服务。 |
| 人员 | 胜任力、资源、质询及关键人员依赖。 |
| 价值 | 已批准且已观察到的收益、全部成本及未经验证的假设分列。 |
十二个月路线图
| 期间 | 核心成果 | 关卡 |
|---|---|---|
| 第0-30天 | 发起人、范围、临时禁止用途、发现及事件处理路径 | 框架章程已获批准。 |
| 第31-60天 | 清单、权限映射、重要性方法和义务登记册 | 高风险未知事项已上报。 |
| 第61-90天 | 生命周期、证据模板、供应商控制和最低监控要求 | 试点治理已获批准。 |
| 第4-6个月 | 评估重大用途,整改访问权限、日志记录、数据和合同 | 第3级和第4级决策保持最新。 |
| 第7-9个月 | 集中度分析、韧性与退出测试、董事会报告 | 关键依赖项已测试。 |
| 第10-12个月 | 独立鉴证、经验教训、政策更新和下一年度计划 | 剩余风险已接受或已整改。 |
前30天
第一个月应确立权限与可见性。指定负责高管,发布临时数据与权限限制,建立单一受理通道,核对已知应用和订阅,并将 AI 事件接入现有事件管理。优先处理可能影响客户、资本、报告、权利、机密数据或价值转移的用途。
第31至90天
依据适用法律和监管来源建立义务登记册。完成重大用途的分类。创建评估、审批、监控、变更和退役模板。审查关键供应商及内嵌的 AI 功能。建立带到期期限和补偿性控制的例外流程。
第四至十二个月
评估并批准或暂停重大用途。测试访问隔离、故障恢复和供应商退出。核对服务提供商集中度。实施董事会指标和独立鉴证。当 FSB 咨询定稿、NIST 更新 AI RMF 或司法辖区规则变化时,更新框架。
控制成熟度模型
| 级别 | 描述 | 证据 |
|---|---|---|
| 0 未受控 | 用途未知或未受管理 | 事件及临时声明。 |
| 1 可见 | 已存在清单和临时限制 | 已登记用途和问责负责人。 |
| 2 已定义 | 分类、生命周期和标准已具备 | 已批准的政策、模板和角色。 |
| 3 运营 | 重大控制措施已实施并接受监控 | 测试、审批、日志和问题。 |
| 4 保证 | 独立质疑和组合证据机制在运行 | 验证、审计、董事会质疑和整改。 |
| 5 自适应 | 变更、事件和外部发展会及时更新控制措施 | 可衡量的学习、及时更新和经过测试的韧性。 |

局限性、研究议程与结论
本文综合了跨司法辖区的材料;并不确立对特定实体的适用性。要求可能重叠并发生变化。在证据截止时,FSB 的稳健做法仍处于征求意见阶段。欧盟时间表在发布前不久发生变化。美国修订后的模型风险指引明确将生成式和代理式 AI 排除在适用范围之外。标准和自愿性框架并不构成法律合规。
该运营框架需要实证检验。未来研究应比较不同机构间的分类一致性;衡量生成式和代理式工作流的验证可靠性;评估引用和人工复核控制是否能减少重大错误;评估第四方集中度;并测试在供应商退出、模型变更和网络中断情形下的退出计划。在保密性允许的情况下,机构应发布或共享事件分类法和评估方法。
核心结论是,受控采用AI是一个证据问题。完整清单可揭示风险敞口。重要性和权限决定相称的控制。评估确立有边界的适用性。治理机制分配决策权。监控使批准持续有效。事件与退出能力遏制故障。对家族办公室和机构资金配置者而言,这一结构在支持创新的同时,保留投资权限、保密性、可追溯性和韧性。
归因于Matchpoint的收入或客户收入、现金成本降低和损失减少,在经批准的观察证据支持该归因之前,仍为 USD 0。
来源登记表
完整论文记录了适用于这些来源的证据分类、范围和局限性。
- [1] 美国联邦储备系统理事会、美国联邦存款保险公司和美国货币监理署(2026)。*SR 26-2:模型风险管理修订指南*。 开源
- [2] 美国货币监理署(2026)。*OCC发布更新后的模型风险管理指南*。 开源
- [3] 美国联邦存款保险公司(2026)。*FIL-16-2026:各机构修订跨机构模型风险管理指南*。 开源
- [4] 审慎监管局(2026)。*SS1/23:银行模型风险管理原则,2026年4月*。 开源
- [5] 英格兰银行和金融行为监管局(2023)。*FS2/23:人工智能与机器学习*。 开源
- [6] 英格兰银行和金融行为监管局(2024)。*2024年英国金融服务中的人工智能*。 开源
- [7] 英格兰银行和金融行为监管局(2026)。*英格兰银行与FCA 2026年AI调查*。 开源
- [8] 英格兰银行(2026)。*金融稳定报告,2026年7月*。 开源
- [9] 英格兰银行、金融行为监管局和英国财政部(2026)。*关于前沿AI模型与网络韧性的联合声明*。 开源
- [10] 金融稳定理事会(2026)。*金融机构负责任采用AI的稳健实践:咨询报告*。 开源
- [11] 金融稳定理事会(2024)。*人工智能的金融稳定影响*。 开源
- [12] 巴塞尔银行监管委员会(2024)。*金融数字化*。 开源
- [13] 巴塞尔银行监管委员会(2021)。*运营韧性原则*。 开源
- [14] 巴塞尔银行监管委员会(2013)。*有效风险数据加总与风险报告原则*。 开源
- [15] 金融稳定学院(2024)。*金融行业AI监管:近期发展与主要挑战*。 开源
- [16] 阿拉伯联合酋长国中央银行(2026)。*关于阿联酋持牌金融机构消费者保护及负责任采用和使用人工智能与机器学习的指引说明* 开源
- [17] UAE 中央银行、证券与商品管理局、DFSA 和 FSRA(2021)。*采用赋能技术的金融机构指南* 开源
- [18] 迪拜金融服务管理局(2026)。*DFSA 对 DIFC 人工智能风险管理的监管期望* 开源
- [19] 迪拜金融服务管理局(2025)。*2025 年人工智能调查* 开源
- [20] 迪拜金融服务管理局(2025)。*金融服务中的网络与人工智能风险:通过国际对话加强监管* 开源
- [21] 阿布扎比全球市场金融服务监管局(截至 2026 年现行)。*补充指引:数字投资管理* 开源
- [22] 迪拜国际金融中心(截至 2026 年现行)。*数据保护条例;第 10 号条例:通过自主和半自主系统处理的个人数据* 开源
- [23] 阿拉伯联合酋长国政府(2021)。*关于个人数据保护的 2021 年第 45 号联邦法令* 开源
- [24] 欧盟(2024)。*制定人工智能统一规则的 (EU) 2024/1689 号条例*。 开源
- [25] 欧盟委员会(2026)。*AI 综合法案生效* 开源
- [26] 欧盟委员会(2026)。*关于特定 AI 系统提供者和部署者透明度义务的指引* 开源
- [27] 欧盟(2022)。*关于金融行业数字运营韧性的 (EU) 2022/2554 号条例*。 开源
- [28] 欧盟(2016)。*欧盟第 2016/679 号条例《通用数据保护条例》* 开源
- [29] 美国国家标准与技术研究院(2023)。*人工智能风险管理框架 1.0* 开源
- [30] 美国国家标准与技术研究院(2024)。《人工智能风险管理框架:生成式人工智能概况,NIST AI 600-1》。 开源
- [31] 美国国家标准与技术研究院(2024)。*网络安全框架 2.0* 开源
- [32] 英国国家网络安全中心及合作伙伴(2023)。《安全 AI 系统开发指南》。 开源
- [33] 国际标准化组织(2023)。*ISO/IEC 42001:2023,人工智能管理体系* 开源
- [34] 国际标准化组织(2023)。*ISO/IEC 23894:2023,人工智能:风险管理指南* 开源
- [35] 经济合作与发展组织(2024)。*OECD AI 原则*。 开源
- [36] OWASP 基金会(2025)。《OWASP LLM 应用十大风险 v2.0》。 开源
- [37] 瑞士金融市场监管局(2024)。*FINMA 08/2024 号指引:使用人工智能时的治理与风险管理*。 开源
- [38] 瑞士金融市场监管局(2025)。*FINMA 调查:人工智能在瑞士金融机构中应用日益增多*。 开源
- [39] 香港金融管理局(2024)。*关于金融服务领域生成式人工智能的研究论文*。 开源
- [40] 国际证监会组织(2025)。*AI 在资本市场的应用案例*。 开源
| 级别 | 描述 | 证据 |
|---|---|---|
| 0 未受控 | 用途未知或未受管理 | 事件及临时声明。 |
| 1 可见 | 已存在清单和临时限制 | 已登记用途和问责负责人。 |
| 2 已定义 | 分类、生命周期和标准已具备 | 已批准的政策、模板和角色。 |
| 3 运营 | 重大控制措施已实施并接受监控 | 测试、审批、日志和问题。 |
| 4 保证 | 独立质疑和组合证据机制在运行 | 验证、审计、董事会质疑和整改。 |
| 5 自适应 | 变更、事件和外部发展会及时更新控制措施 | 可衡量的学习、及时更新和经过测试的韧性。 |

