---
title: "把上海 AI 新政读成一张合规义务清单：16 条中的 10 项硬性义务与三阶段落地路径"
date: "2026-09-26"
description: "以国家金融监督管理总局上海监管局《推动上海银行业保险业人工智能应用的若干措施》（沪金发〔2026〕19号）16 条原文为唯一事实来源，剥离“鼓励”与“应当”，拎出第（十）至（十三）条的 10 项新增硬性义务：生成式模型备案登记覆盖自研、微调、私有化部署、API 调用四种情形，高风险场景须经风险管理委员会批准，面客场景上线前报告，外包名单制与风险隔离“防火墙”，并给出 30、90、180 天落地清单。"
tags: ["金融科技", "AI治理", "大模型", "智能体", "风险管理", "银行AI", "金融监管", "模型风险管理", "合规管理", "外包风险", "数据安全"]
schema_type: "Article"
references:
  - title: "上海金融监管局关于印发《推动上海银行业保险业人工智能应用的若干措施》的通知（沪金发〔2026〕19号）"
    url: "https://www.nfra.gov.cn/branch/shanghai/view/pages/common/ItemDetail.html?docId=1273268&itemId=998"
    source: "国家金融监督管理总局上海监管局"
# 注：本文件尚未写入 AIGC 标识块。按现行标识要求，AIGC 元数据需包含 Label、ContentProducer、
#     ProduceID、PropagateID、ReservedCode1、ReservedCode2 等字段，其中 ProduceID / ReservedCode
#     须由标识服务平台逐篇签发，不能由作者或生成工具自行推定或编造。因此本文件暂留空位，须由作者
#     在取得平台签发的标识值后补充完整，方可发布。
---

**上海这份 16 条措施里，真正新增"硬性义务"的集中在第（十）到（十三）条，其余各条是方向与支持**

**最容易被漏掉的一句是：生成式 AI 模型的备案或登记，覆盖自研、微调、私有化部署、API 调用四种情形**

**"风险可控、成本集约、价值提升"不是口号，它被写成了高风险应用场景准入的评估原则**

**第（十四）条的弹性监管与容错机制，是这份文件里唯一让义务变得可承受的条款**

---

> **素材说明**：本文唯一事实来源为国家金融监督管理总局上海监管局《推动上海银行业保险业人工智能应用的若干措施》（沪金发〔2026〕19号，2026 年 9 月 18 日签发，9 月 24 日公布）及随文通知原文。文中条款表述、条号、机构名称与文件名均出自该原文；原文未提及的数字、案例、事件、时间与机构，本文一律不补。文中"银行该怎么做"的部分与全部框架，**均为作者基于原文条款的推论，不是文件原文表述，也不构成监管口径或法律意见**。

2026 年 9 月 24 日，国家金融监督管理总局上海监管局公布《推动上海银行业保险业人工智能应用的若干措施》（沪金发〔2026〕19号），9 月 18 日签发，发至辖内各金融机构及上海市银行同业公会、上海市保险同业公会。

文首把它定位为"促进"性文件，落实金融监管总局、上海市政府《关于支持上海国际金融中心建设行动方案》要求。但**分量在动词上**：第（一）至（七）条用"鼓励""支持""推动"；第（十）至（十三）条换成"应当""严格""建立"，并出现"经本机构风险管理委员会批准后实施""应向上海金融监管局报告"。**这份文件因此藏着两套东西：一套给资源，一套要交作业。本文只做后者。**

## 一、先分清"鼓励"与"应当"：16 条的三层结构

| 层级 | 条目 | 典型动词 | 实际含义 |
|---|---|---|---|
| 方向与支持层 | 第（一）至（七）条（数智赋能）、第（九）条（人才培养）、第（十五）（十六）条 | 鼓励、支持、推动 | 是"可以做的空间"，不是"必须做的动作" |
| 治理要求层 | 第（八）条（完善治理架构） | 推动……建立并完善、纳入 | 落在战略与治理架构上，需规划文件承接 |
| **硬性义务层** | **第（十）（十一）（十二）（十三）条** | **应当、严格、建立、经……批准、应向……报告** | **新增合规义务，需制度、流程、台账、报告同步落地** |

**分不清哪几条是义务，就会出现"把真正的义务写成工作亮点"的情况，而这是会被检查出来的。** 这四条还有一个共同特征：它们被放在"二、夯实基础支撑"一节——**监管把合规、外包、模型风险、安全定位为"基础支撑"而非"风险防范"，含义是不具备这四项，前面的场景应用就不具备落地条件。**

## 二、义务一至三：备案、批准与报告（第（十）条）

**义务一：面向公众服务的生成式 AI 模型须备案或登记。**

> 严格按照网信部门规定，对面向公众服务的生成式人工智能模型进行备案或登记，**包括但不限于**自研、微调、私有化部署、API 调用等情形。

三点决定执行难度：**"面向公众服务"**是触发条件，不是"是否自研"；**"包括但不限于"**是开放式列举；四种情形含义各异。

| 情形 | 银行典型场景 | 义务落点（本文推论） |
|---|---|---|
| 自研 | 自主训练的垂域模型，对应第（三）条鼓励路径 | 立项阶段应把备案可行性设为前置条件 |
| 微调 | 在开源或采购基座模型上做行业数据微调 | 微调改变行为边界，不能沿用原模型已备案的结论 |
| 私有化部署 | 部署在本行机房或专有云 | 私有化解决数据不出域，**不解决备案义务** |
| API 调用 | 通过接口调用第三方大模型服务 | 即使提供方已备案，使用方仍在本条范围内 |

**这张表把"技术部署形态"与"合规义务"解耦**：私有化常被当作合规答案，API 调用常被当作"把责任留给厂商"的答案，第（十）条把两者都否掉了——**备案义务跟着业务事实走，不跟着"模型是谁的"走。**

**义务二：高风险应用场景准入须经风险管理委员会批准。**

> 建立人工智能高风险应用场景准入控制机制，**并经本机构风险管理委员会批准后实施**。

**准入决定权被明确放在风险管理委员会，而不是科技部门、业务部门或某个 AI 治理工作组**——委员会批准意味着有会议记录、有表决过程、可被追责。**推论：AI 场景准入是否已进入风险管理委员会的议题清单和议事规则？** 只要最终批准人不是委员会，这一条就没有被满足。同条给出准入原则"**风险可控、成本集约、价值提升**"，并要求"防止技术滥用，**防范数字形式主义**"——**准入不能只看"用没用 AI"，还要看结果。**

**义务三：面客或高风险场景上线前，向上海金融监管局报告。**

> 对于面向公众服务或高风险场景应用使用生成式人工智能技术的，**在场景上线前应向上海金融监管局报告**。

它必须与"备案或登记"严格区分，因为实务中两者极易被当成一件事。

| 动作 | 对象 | 时点 | 依据 |
|---|---|---|---|
| 备案或登记 | **网信部门** | 按网信部门规定 | 第（十）条前半段 |
| 报告 | **上海金融监管局** | **场景上线前** | 第（十）条末句 |

**这是两条并行动作，不是一条动作的两个环节。** 推论：机构需要"双线台账"，分别跟踪网信侧备案与金融监管侧报告，两者不能互相替代。原文未给出报告的格式与时限，**本文不补充原文之外的报送细则；首次执行前应向属地监管确认报告形式。**

同条还要求"定期对人工智能系统进行安全评估和审计"，"加强对高风险应用关键环节的人工监测，建立人工干预机制"，并"将模型底座与上层应用解耦，准备多模型部署、人工接管等替代手段"。**把"解耦"写进合规条款，说明监管关注的不是技术先进性，而是可替换性。**

## 三、义务四至六：外包风险的三道闸门（第（十一）条）

第（十一）条针对的是第（二）条"租购并举"算力模式与第（三）条模型采购策略必然带来的外部依赖，它设了三道闸门。

**闸门一，并入既有体系：** 使用外部智能算力资源、模型服务、数据处理时，"应将其纳入**信息科技外包风险管理体系**进行统筹管理"。**AI 外包不新设体系**——推论是既有外包制度、名单与评估模板都增加"AI 类外包"维度，而不是另建平行制度。

**闸门二，防火墙 + 名单制：** 同条要求"设立有效的风险隔离'防火墙'，对外包合作机构实行**名单制管理**，严格评估外部引入模型的**优缺点和适配性**"。**"名单制"对采购影响最直接**——AI 外部服务商不能走"一事一批"的临时通道；**只写优点的评估报告，形式上就不满足这一条。**

**闸门三，重要外包提前报告：** 须"准确识别**集中存储或处理重要数据和客户个人敏感信息、对业务运营具有重要影响**等重要外包情形，**按规定提前向上海金融监管局报告**"。两个识别维度（**数据**、**业务影响**）以顿号并列，**不要求同时满足**——把客户信息送入外部模型的场景，即使业务量不大，也应先按数据维度归类判断。

## 四、义务七至十：模型、数据与安全（第（十二）（十三）条）

第（十二）条与第（十三）条中，构成独立编号义务的是第 7 至 10 项；表中后两行是同一批条款内的数据与安全要求，为便于对照一并列出，不计入义务条数。

| # | 义务 | 原文关键表述 | 银行落点（本文推论） |
|---|---|---|---|
| 7 | 建立模型风险管理体系 | 制定模型风险管理制度和流程 | 与既有信用风险等模型风险管理体系合并还是分立，须明确 |
| 8 | 四维评估检测 | 模型**架构、训练方法、数据质量、输出结果** | 四维均须有可举证记录，不能只测"输出结果" |
| 9 | 防范三类风险 | 模型**自身缺陷、数据质量、应用或管理不当** | "管理不当"意味着责任不只在模型，也在流程与人员 |
| 10 | 提高可解释性 | 避免**价值偏离、不公平决策、歧视性内容** | 须能回答"为什么这样输出"，尤其在信贷、核赔等场景 |
| — | 训练数据安全机制 | 明确**数据获取、标注、训练、服务构建**四环节要求 | 四环节对应四类合规问题，不能用一份总则覆盖 |
| — | 防范新技术风险 | 探索**深度伪造**与滥用风险防范；防范**幻觉、黑箱、大模型安全漏洞** | 深度伪造须同时考虑"被伪造"与"被用于伪造"两向 |

第（十二）条另有一句："坚持以人民为中心，践行人工智能向善理念，确保人工智能应用符合**伦理道德和社会价值观**"。**这句话被放在"模型风险管理"而非"企业文化"条款里，是明确的方法论信号：价值偏离和不公平决策被定性为风险，而不是失误**——推论是模型风险报告应设"公平性/价值偏离"指标。

第（十三）条另有一句对技术采购有直接约束力："采用**安全可信的芯片、软件、工具、算力、模型算法和数据资源**"。这把"安全可控"从原则变成对六个具体对象的要求，推论是选型评审需在技术维度外增加"可信性"维度。

## 五、第（十四）条：唯一让义务变得可承受的条款

第（十四）条提供了对冲，两句原文分别是"探索建立生成式人工智能大模型在金融领域应用的**试点机制**……**允许金融机构在可控环境下逐步开展直接面客的大模型应用**，并与网信部门的生成式人工智能服务**备案、应用登记机制相衔接**"，以及"研究**包容审慎、分类分级**的人工智能**弹性监管框架**，探索建立人工智能应用的**容错机制**，对不同风险等级事件建立**差异化容忍**"。

| 第（十）条的约束 | 第（十四）条的对冲 |
|---|---|
| 面向公众服务的生成式模型须备案或登记 | 试点机制与网信部门**备案、应用登记机制相衔接** |
| 面客或高风险场景上线前须报告 | 允许在**可控环境**下逐步开展直接面客应用 |
| 定期安全评估和审计 | **分类分级**弹性监管，不同风险等级事件**差异化容忍** |

**这组对照是理解全文的关键：门槛明确，但跨门槛的过程被允许试错。** **其一，主动争取试点资格的价值凸显**；**其二，容错不等于免责**——"差异化容忍"的前提是事件已被分级、已被报告。同条还提到"备案、应用登记机制"，**说明备案与应用登记是两个不同机制**，第（十）条的"备案或登记"正对应于此。

## 六、落地清单：30 / 90 / 180 天

以下动作只依赖制度、流程与台账。

**前 30 天——让义务"看得见"：**① 按第（十）至（十三）条建立义务对照表，逐条标注状态并附证据索引（合规 + 科技）；② 立项模板增设"是否面向公众服务""模型来源形态"两栏，存量项目回填（科技）；③ 建立网信侧备案 + 金融监管侧报告的"双线台账"，每个面客或高风险场景在两列均有明确状态（合规）；④ 梳理 AI 外部服务商形成初版名单，含准入标准草案，名单外服务使用可被叫停（采购 + 科技）；⑤ 盘点已上线的面客或高风险生成式 AI 场景，与报告义务逐一对应，未报告的明确补报路径（业务 + 科技）。

**第 31 至 90 天——让义务"跑得动"：**⑥ 将 AI 高风险场景准入纳入风险管理委员会议事规则与议题清单，准入决议有会议记录；⑦ 制定场景准入评估框架，评估表含风险、成本、价值三栏且价值栏有度量口径；⑧ 增设可替换性审查，核心场景至少验证一次备用模型或人工接管路径；⑨ 外包制度增设 AI 维度，评估模板强制含"缺点"栏；⑩ 制定重要外包情形识别标准（数据、业务影响两维度），存量 AI 外包完成识别并形成提前报告清单；⑪ 建立模型风险管理制度的 AI 分册，四维评估均有模板与留存要求；⑫ 模型风险报告增设"可解释性与公平性"项，至少形成一期定性评估结论；⑬ 按四环节拆分训练数据安全要求；⑭ 明确人工监测点、干预触发条件与处置流程；⑮ 完善应急处置流程并纳入业务连续性管理，预案含模型服务中断、输出异常两类情形。

**第 91 至 180 天——让义务"经得起查"：**⑯ 完成首次 AI 系统安全评估与审计，报告覆盖第（十）条"安全评估"与"审计"两项；⑰ 建立"价值牵引"复盘机制，无效场景有退出决定；⑱ 就试点、报告形式与备案登记衔接与属地监管沟通，形成书面记录；⑲ 制定全生命周期管理与考核机制，承接第（八）条，使治理架构、责任分工、考核机制文件化；⑳ 将 AI 应用风险纳入全面风险管理体系并做一次推演。

**其中①③⑥⑨最应立刻推进**：①决定机构是否知道自己缺什么；③对应两条不能互相替代的报送义务；⑥是第（十）条唯一指定决策主体的要求；⑨对应的外包风险，是第（二）（三）条鼓励外部资源必然带来的敞口——**鼓励用外部资源、同时要求管住外部资源，是这份文件最需要平衡的一对关系。**

## 结语

把动词挑出来看，第（十）到（十三）条用了"应当""严格""建立"，并指定了批准主体（风险管理委员会）、报告对象（上海金融监管局）和报告时点（场景上线前）。**这三样凑在一起，就不再是"措施"，而是"要求"。**

最务实的读法是：**把第（一）至（九）条当作争取资源的依据，把第（十）至（十三）条当作必须完成的作业，把第（十四）条当作作业可以分步完成的制度承诺。** 三节之间不是并列，而是"应用场景—基础支撑—保障机制"的递进；基础支撑一节里的合规义务，是前面所有场景能够成立的前提。

## FAQ

**Q1：我们用的是外部厂商模型、只做 API 调用，备案是不是厂商的事？**

A1：第（十）条明确把"API 调用"列入范围，且以"包括但不限于"作开放式列举。本文推论是：条款约束的是"面向公众服务"这一业务事实，而非模型所有权归属。具体备案与登记要求仍按网信部门规定执行。

**Q2：向上海金融监管局报告和向网信部门备案，是一件事吗？**

A2：第（十）条把它们写成两件事：备案或登记的依据是"网信部门规定"，报告的对象是"上海金融监管局"、时点是"场景上线前"。第（十四）条又提到与网信部门的"备案、应用登记机制"相衔接，说明监管一侧也把两条线视为互不替代。

**Q3：第（十四）条的容错机制，是否意味着出问题可以免责？**

A3：原文表述是"对不同风险等级事件建立差异化容忍"。"差异化"的前提是"分级"。推论：容错对象是已被识别、已按等级报告的事件；未分级、未报告的事件不在这项机制的射程内。

**Q4：中小机构资源有限，最短路径是什么？**

A4：建议抓四项：立项表单一栏（是否面客、模型来源形态）；双线台账；把 AI 高风险场景准入塞进现有风险管理委员会议题，不新建委员会；外包评估模板强制含"缺点与适配性"栏。

## 事实来源

- **唯一事实来源**：国家金融监督管理总局上海监管局《推动上海银行业保险业人工智能应用的若干措施》（沪金发〔2026〕19号，2026 年 9 月 18 日签发，2026 年 9 月 24 日公布），含 16 条措施。本文引用条号包括第（一）（二）（三）（八）（九）（十）（十一）（十二）（十三）（十四）（十五）（十六）条，重点展开第（十）（十一）（十二）（十三）（十四）条。
- **原文提及的其他文件（本文未补充任何条款细节或链接）**：金融监管总局、上海市政府《关于支持上海国际金融中心建设行动方案》；《国家金融监督管理总局关于银行业保险业人工智能安全开发应用的指导意见》（载于原文末段落实要求中）；原文以"网信部门规定"统称生成式人工智能服务的备案与应用登记要求（相关规章包括《生成式人工智能服务管理暂行办法》，本文未引述其任何条款细节）。
- **本文作者推论部分（非原文表述）**："16 条三层结构""10 项编号义务"、第（十）条四种情形的对照表、"备案或登记"与"向上海金融监管局报告"的双线区分、"三道闸门"框架、30/90/180 天落地清单，以及全部 FAQ 回答。

*（内容由AI生成，仅供参考）*