把上海 AI 新政读成一张合规义务清单:16 条中的 10 项硬性义务与三阶段落地路径

核心摘要

  • 上海这份 16 条措施里,真正新增"硬性义务"的集中在第(十)到(十三)条,其余各条是方向与支持
  • 最容易被漏掉的一句是:生成式 AI 模型的备案或登记,覆盖自研、微调、私有化部署、API 调用四种情形
  • "风险可控、成本集约、价值提升"不是口号,它被写成了高风险应用场景准入的评估原则
  • 第(十四)条的弹性监管与容错机制,是这份文件里唯一让义务变得可承受的条款

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

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

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

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


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

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

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

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

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

二、义务一至三:备案、批准与报告(第(十)条)

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

严格按照网信部门规定,对面向公众服务的生成式人工智能模型进行备案或登记,包括但不限于自研、微调、私有化部署、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 高风险场景准入塞进现有风险管理委员会议题,不新建委员会;外包评估模板强制含"缺点与适配性"栏。

事实来源

(内容由AI生成,仅供参考)

参考文献

  1. 上海金融监管局关于印发《推动上海银行业保险业人工智能应用的若干措施》的通知(沪金发〔2026〕19号) [国家金融监督管理总局上海监管局]

关于作者

毕超,博士、高级工程师(计算机技术专业),金融行业风险管理从业者。

清华大学校友导师,中国人工智能学会终身会员,中国计算机学会学术审稿专家。

研究方向:大语言模型、数字金融、金融科技。2024年获北京市西城区"西融计划"青年拔尖人才。

了解更多:关于作者