首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >2026 年 7-8 月 AI 备案名单出炉!新增了哪些大模型,企业可以抄哪些作业

2026 年 7-8 月 AI 备案名单出炉!新增了哪些大模型,企业可以抄哪些作业

原创
作者头像
AI算法大模型备案当当
发布2026-09-18 09:46:36
发布2026-09-18 09:46:36
400
举报

声明:本文基于国家网信办及各地网信办公开发布的备案与登记信息整理,用于行业观察与合规工作参考,不含任何产品与厂商推广,亦不构成法律意见。涉及法规判断请以属地网信部门口径为准。文中数据截至 2026 年 8 月 31 日。

0 先说结论

2026 年 9 月 14 日,国家网信办发布《关于发布生成式人工智能服务已备案信息的公告(2026 年 7 月至 8 月)》。这份看似例行的季度成绩单,有三个值得单独拎出来的信息:

第一,体量已经过了临界点。 累计备案 1112 款、登记 731 款,备案加登记的总数突破 1800。备案从"少数玩家的门槛"变成了"产品上线的常规动作"。

第二,本批次最有分量的变化是端侧。 7 款手机端侧生成式 AI 服务集中备案,这是国内首次为端侧 AI 单列在公告中体现。它改变的不只是手机厂商的节奏,而是"模型要在哪里运行"这个基础问题的合规答案。

第三,真正能给企业抄的不是名单本身,而是名单背后的三件事:路径怎么选(备案还是登记)、主体怎么定、上线后要公示什么。名单是别人的结果,这三件事才是可复制的方法。

本文分四层:先看数字 → 再看本批次的结构性变化 → 再按属地和行业拆解 → 最后落到"企业可以抄哪五份作业、哪三件抄不了"。


1 四个数字:这批名单的体量

指标

2026 年 7-8 月新增

截至 8 月 31 日累计

生成式人工智能服务备案

124 款(含 7 款手机端侧)

1112 款

生成式人工智能应用或功能登记

133 款

731 款

合计

257 项

1843 项

三条读法:

一是备案与登记是两条并行的路,不是一条路上的两个阶段。 两个月里备案 124 款、登记 133 款,数量基本相当。这说明相当一部分企业走的并不是"自己训模型"那条路,而是"调用已备案模型能力、自己做成应用或功能",由地方网信办完成登记。对绝大多数做产品的团队来说,登记才是更常见的那条路,但它的关注度远低于备案。

二是新增节奏已经稳定下来。 两个月 124 款,折算月均 60 款以上,而累计规模从 2024 年《生成式人工智能服务管理暂行办法》施行至今走到 1112 款。这个速度意味着:备案不再是"要不要做"的判断题,而是排期问题。

三是 7 款端侧服务单独点名,是这次公告里唯一被特别说明的结构性信息。 其余 117 款没有分类说明,唯独端侧被点出来——这个处理方式本身就说明了政策关注点在哪。


2 本批次最该划重点的变化:端侧 AI 第一次单列

7 款手机端侧生成式 AI 服务于 2026 年 7 月 8 日集中完成备案,覆盖了国内外主流手机厂商:

序号

大模型名称

备案主体

属地

1

Apple 智能

苹果技术开发(上海)有限公司

上海

2

华为小艺 AI 大模型

华为软件技术有限公司

江苏

3

AndesGPT 大模型

OPPO 广东移动通信有限公司

广东

4

vivo 蓝心端侧大模型

维沃移动通信有限公司

广东

5

小米澎湃 AI

小米科技有限责任公司

北京

6

盖乐世 AI

三星(中国)投资有限公司

北京

7

努比亚豆包手机大模型

上海申启纪元智能终端有限责任公司

上海

2.1 为什么"端侧单列"这件事比数量重要

第一,它回答了一个长期悬着的问题:模型跑在用户手机里,算不算"向境内公众提供服务"。

先前的普遍困惑是:模型权重随设备下发,推理发生在本地,服务提供者既看不到用户输入,也无法在服务端做内容干预。这种情况到底适用不适用《暂行办法》?

本批次的处理给出了明确答案:要备案,并且单独列示。 判断依据仍然是"服务对象"而不是"部署位置"——设备是用户自己的,但服务是你提供的。这一点与内部知识库那个问题的判断逻辑完全一致:不问技术形态,只问有没有面向不特定公众。

第二,端侧备案的材料结构和云端不同,这是真正的门槛。

端侧的评审关注点会落到几个云端不太涉及的地方:模型体积与设备适配、端侧推理框架的自主可控程度、本地数据的处理与留存边界、端云协同时的数据流向、以及无网络或弱网络场景下的行为边界。这些恰恰是"把云端模型裁小塞进手机"这种做法最容易出问题的地方。 如果你的端侧方案只是云端模型的量化版,评审时几乎一定会被追问数据流向。

第三,它把"任务入口"的竞争摆到了台面上。

名单里有一个信号值得注意:努比亚豆包手机大模型这种"终端厂商 + 模型方联合"的形态已经出现。端侧 AI 的合规化,意味着手机厂商可以从"应用入口"往"任务入口"走——不再只是提供一堆 App,而是直接承接用户的意图并调用服务。这对所有做应用层的团队是一个需要重新评估的变量。

2.2 端云协同的三种模式,材料要求不一样

同样叫"端侧 AI",实现方式不同,需要说明的问题也不同:

模式

典型形态

评审关注点

纯端侧

模型完全在设备本地推理,无服务端回传

模型来源与体积、本地数据留存边界、无网络场景下的行为

端侧优先 + 云端兜底

简单任务本地处理,复杂任务上云

分流规则、上云时的数据最小化、用户是否可感知

云端为主 + 端侧缓存

推理在云端,端侧只做缓存与加速

缓存内容与留存期限、清除机制、是否构成新的数据留存

判断方法:把用户的一次提问从输入到输出画成一条线,标出每一段发生在哪一侧。如果这条线画不出来,端侧材料基本过不了。

2.3 端侧这条线释放的三个判断

  1. 如果你在做终端侧或私有化部署的 AI 功能,合规身份要在产品定义阶段就定下来,不要在量产前补。
  2. 端云协同的数据流向必须能画清楚,这是端侧材料的核心,也是云端材料里最容易含糊过去、端侧含糊不过去的一页。
  3. "本地推理就不用管"这个假设已经不成立了。

3 按属地看:备案资源集中在哪

从 7-8 月各地网信办公开的备案信息看,格局呈现明显的梯队分布:

梯队

地区

累计备案规模

本批次代表性主体

第一梯队

北京

约 296 款

腾讯云计算(Echo)、快手(KwaiKeye)、北京日报社(京报校助、京报写作)、北京航空航天大学(基石)、水利部信息中心(水信息)、中国铁塔(擎天数智、擎天运维)

第一梯队

上海

约 205 款

上海大数据中心(数智底座)、卡西欧中国(启慧教育)、福特汽车中国(AI 智能助手)、上海成电福智(AI 调解通)

第一梯队

广东

约 193 款(其中大模型备案 164 款,居全国首位)

TCL 伏羲 AI、广州文石(小文)、招商银行(智能银行管家小招)、广东省政务服务和数据管理局("深小 i"AI 政务助手、粤省事政务服务智能体)、深圳韶音(Shokz AI 听记大模型)

第二梯队

浙江 / 江苏 / 山东 / 福建

各省持续放量

宇树科技(UnifoLM 机器人统一大模型)、苏州加乘(PlusTimes 低空世界大模型)、云鼎科技(矿山行业大模型)、帝视科技(河图影像大模型)、厦门大学(思源轻量化多模态大模型)

第三梯队

四川 / 重庆 / 广西 / 天津 / 山西 / 河北等

差异化布局

华西数字医疗(华数智医大模型)、成都哈瑞特医疗(玲珑智能问诊)、雄安兴元(兴元百慧大模型)

注:分省数据来自各地网信办分批公告的汇总统计,口径与时点可能不完全一致,用于观察趋势而非精确比较。深圳一地累计 63 款,约占全国的 5.7%。

3.1 三个观察

观察一:北京本批次出现了明显的"体制内入场"特征。

央媒(北京日报社)、部委直属信息中心(水利部信息中心)、央企(中国铁塔)、高校(北京航空航天大学)都在这一批完成备案。这个信号比数量更重要——它说明AI 备案已经从互联网公司的动作,变成了各类机构的常规信息化工作。对做 B 端生意的团队来说,这意味着客户侧的采购要求很快会标准化。

观察二:广东的优势不是单点,是链条。

广东的关键不在于 164 款这个数字,而在于"备案 + 生态 + 合规支撑"的组合——备案规模、产业密度、以及配套的合规服务能力同时存在。这种结构性的领先很难在短期内被单点追平。对企业的实际含义是:如果你的产品面向粤港澳市场,属地选择和合规服务的可获取性会明显优于其他区域。

观察三:行业模型的属地化特征很强。

山东出矿山行业模型、四川出医疗模型、江苏出低空经济模型、厦门出高校轻量化多模态模型。行业模型的密集区往往与当地支柱产业高度对应。 这对做垂类的团队是个提示:你的属地产业基础,既影响备案材料的说服力(真实的落地场景),也影响后续的客户获取。


4 按行业看:257 个项目落在哪五条赛道

把本批次新增的备案与登记项目按行业归类,集中在五条赛道:

赛道

典型形态

本批次代表

一句话判断

AI + 政务

政务助手、政策问答、公文辅助

广东省政数局"深小 i"、粤省事政务服务智能体、水利部信息中心

从演示走向"上岗",采购流程正在标准化

AI + 教育

校助、备考、教辅、学科工具

京报校助、卡西欧启慧教育、知鸟教育、兴元兴智教育

规模化最快,各省均有专属模型,竞争激烈

AI + 医疗

智能问诊、辅助诊疗、健康管理

华数智医大模型、玲珑智能问诊、三师共管 AI 大模型

合规壁垒最高,叠加主管部门规定,反成护城河

AI + 法律 / 咨询

法律检索、合同审查、调解辅助

AI 调解通、律鉴 AI 大模型、MatterSeek

专业服务的新基建,正在替代部分咨询环节

AI + 机器人 / 具身智能

统一机器人大模型、多模态融合

宇树 UnifoLM、PlusTimes 低空世界大模型、行者具身智能模型

最值得关注的新增方向,与端侧备案同步推进

4.1 一个容易被忽略的结构性事实

行业模型的数量已经明显超过通用模型。名单里的多数项目是面向具体行业的垂类模型,通用基座只占少数。

这背后是一条清晰的路径选择逻辑:通用基座是少数团队的赛道,垂类模型是多数团队的机会。 而垂类模型恰好更依赖场景数据和行业 Know-how,这两样东西无法通过采购获得——这也是为什么垂类模型在留存和合规上,都比"套壳通用模型"更有底气。

4.2 两条叠加监管的赛道要单独提醒

医疗和金融方向的服务,除备案外还要叠加主管部门的规定。 本批次四川的医疗模型集中备案,值得注意的不是数量,而是它们很可能已经同时走完了卫健部门的合规路径。如果你在这两个方向做产品,排期时必须把叠加审批的时间算进去——这一层通常比备案本身更慢。


5 企业可以抄哪些作业

名单是结果,抄不了。但名单背后的五件事是可以复制的。

作业一:抄"路径怎么选"的判断方式

从本批次 124 款备案与 133 款登记并行的结构可以看出,两条路径是并列的,不存在"先登记后备案"的升级关系。

你的产品形态

走哪条路

大致周期

判断依据

自研或微调模型,面向境内公众提供服务

生成式人工智能服务备案

较长(省级初审 + 中央复审)

服务面向不特定公众且模型来源为自有

直接调用已备案模型能力,未对输出做影响生成内容的调整

登记(由地方网信办开展)

较短

模型来源为已备案的第三方,自身不做生成侧改造

调用已备案模型,但做了私有语料注入、输出逻辑改造、场景深度定制

实务倾向按备案

较长

属于"对模型做出影响生成内容的调整",登记前提不成立

面向公众的推荐、检索、过滤等算法应用(具舆论属性或社会动员能力)

另做算法备案

视情况

与生成式服务备案并行、不互相替代

抄作业的要点是最后一行的思路:先判断"是否面向境内公众",再判断"是否对生成内容有实质影响",最后才落到具体走哪条路。顺序反了,材料就会白做。

作业二:抄"主体怎么定"

从名单的主体栏能读出三种典型形态:

  1. 运营主体独立备案——最常见,即以实际面向用户提供服务的那家公司申报。
  2. 技术方与运营方同属一个体系但为不同法人——如手机厂商的软件技术公司与通信公司分别申报,说明主体划分跟着"谁在提供服务"走,而不是跟着组织架构图走。
  3. 联合研发形态——如"终端厂商 + 模型方"的命名方式,说明合作研发不改变申报主体的唯一性。

可抄的判断标准是:备案主体等于实际面向公众提供服务、且承担主体责任的那一方。落到自查上有三处名称必须一致:产品域名的 ICP 主体、收款主体、应用商店开发者账号主体。这三处不一致的,先解决一致性,再谈材料。

作业三:抄"模型名称与功能描述的写法"

本批次名单的命名有清晰规律,可以直接借鉴命名思路:

命名类型

例子

适用

能力 + 大模型

华数智医大模型、UnifoLM 机器人统一大模型

有明确能力或领域指向的自研模型

主体/品牌 + AI

TCL 伏羲 AI、盖乐世 AI

品牌承载型产品

名称 + 助手

"深小 i"AI 政务助手、智能银行管家小招

面向具体使用场景的功能

名称 + 智能体

粤省事政务服务智能体

具备任务编排能力的服务形态

两条可抄的纪律:

  • 名称要稳定、可读、无夸大。 不要出现"最强""第一""国家级"这类表述,名称一旦备案,产品页、宣传物料、材料三处都要同口径。
  • 功能描述要落到"输入是什么、输出是什么"。 从名单里可以看到,描述清楚的条目几乎不会在补正环节被反复追问;而描述含糊的条目,往往要花几轮把"到底做的是什么"解释清楚。

作业四:抄"上线后必须做的那个动作"

这是本批次公告里唯一一条面向所有已上线产品的落地要求,也最容易被漏:

已上线的生成式人工智能应用或功能,应在显著位置或产品详情页面公示所使用的已备案或登记生成式人工智能服务情况,注明模型名称、备案号或上线编号

三个高频漏点:

  1. 只写在隐私政策或用户协议里。 这不算"显著位置"。
  2. 只在官网写了,App 内没有。 公告里的"显著位置或产品详情页面"主要指向用户实际使用产品的位置,以及应用商店的产品详情页。
  3. 用了多个模型,只公示一个。 只要有调用,就应逐一对应公示。

这条之所以值得单独抄,是因为它的成本极低、风险却很实在——它属于"检查时一眼就能看到"的项目,做不到位没有解释空间。

作业五:抄"变更与核验纪律"

从名单的更新节奏可以发现,备案信息是持续变化的状态,不是一次性的结论。

三条纪律:

  1. 换底座模型属于实质性变更,需要更新备案信息,不可沿用原编号。 这一条对做产品的团队尤其重要——很多人把"升级模型"当成技术迭代,实际上它是合规事件。
  2. 属地核验场景在增加。 政企招投标、B 端客户采购、应用商店上架都在核验备案或登记状态。这意味着备案从一个"监管事项"变成了一个"商业准入事项"。
  3. 不要只做备案,漏掉叠加义务。 若涉及拟人化互动服务,还有年度核验与特定情形安全评估;若涉及医疗、金融,还有主管部门规定。

作业六:抄"登记"这条路的做法(多数企业真正要走的路)

这是本批次最容易被忽略的一条信息:登记 133 款,比备案的 124 款还多。

被忽略的原因是关注度分配不均。 媒体和行业讨论几乎都在讲备案,因为备案的名单更好看、主体更有名。但对绝大多数做产品的团队来说,自己训模型并不是现实选项——真正要走的恰恰是登记这条路。

登记的两个前提,缺一不可:

前提

具体含义

常见问题

上游模型已完成备案

调用的模型本身要有备案号,且处于有效状态

调用境外未备案模型,客观上无法取得合规身份

未对模型做出影响生成内容的调整

没有私有语料注入、输出逻辑改造、场景深度定制等

做了 RAG 或输出重构,却仍按登记申报

四条可抄的纪律:

  1. 先确认上游模型的备案状态,再谈自己的申报。 上游没有备案号,下游登记无从谈起。
  2. 能说明"我只是调用"要有证据。 不是口头说明,而是调用链路、参数传递方式、输出是否原样透出——这些要能对应上真实实现。
  3. 做了生成侧改造就不要按登记走。 RAG 私有语料注入、输出逻辑改造、场景深度定制属于对生成内容有实质影响,档位应当按备案准备。
  4. 换上游模型同样要更新。 登记信息里的模型信息发生变化,是需要更新的,不是可以自动延续的。

一个实用判断:如果你无法在半小时内说清"从用户提问到模型返回,中间经过了哪些处理环节、每一环改变了什么",说明登记的前提还没有被真正验证过。这一份链路说明,是登记材料里最有价值的一页。


6 抄不了的三件事

这一节比上一节更重要。名单可以抄结论,但有三样东西抄不了。

6.1 属地口径不能照搬

各省网信部门在材料清单、测评方式、审查关注点上存在差异(例如部分地区对线下测评、关键词库规模有具体要求)。A 省通过的材料结构,拿到 B 省可能需要重构。 正确做法是先确认属地要求,再组织材料,而不是先写材料再找属地。

6.2 材料是产品事实的映射,文字补不上系统

这是所有材料工作里最关键的一条判断:

报告里写的算法、数据、页面、安全措施,都要能在系统、制度或测试记录里找到对应证据。产品没做到的事,文字补不上。

从名单看,能顺利通过的项目,通常不是材料写得最漂亮的,而是产品本身已经把该做的功能做在了系统里(关闭入口、标识、内容过滤、日志留存)。抄别人的材料结构可以,抄别人的结论不行。

6.3 端侧材料不能照抄云端

端侧备案在模型体积、推理框架、本地数据处理、端云协同数据流向上有独立的评审关注点。把云端的材料结构直接搬过去,最可能在一处被卡住:数据流向说不清。如果你的端侧方案里,本地处理与服务端回传的边界是模糊的,返工成本会很高。


7 三个从名单里反推出来的常见误判

误判一:"备案是大厂的事,跟我们规模不匹配。"

本批次的名单里,央媒、部委直属信息中心、高校、地方国企、区域教育科技公司、连锁零售企业都在其中。规模不是判断标准,服务对象才是。

误判二:"模型跑在用户设备上,不用备案。"

端侧首次单列备案,正是对这个假设的直接否定。

误判三:"我们用的是别人已经备案的模型,所以不用管。"

调用已备案模型能力的应用或功能,走的是登记——本批次 133 款。这是一条独立的路径,不是"不用管"。


8 一份可直接执行的动作清单

按优先级排列。P0 未完成时,建议不要排入上线计划。

P0

  • [ ] 完成"是否面向境内公众提供服务"的范围判定,并落成一页书面结论
  • [ ] 依据"是否对生成内容有实质影响"确定走备案还是登记
  • [ ] 核对三处主体名称一致性(域名 ICP 主体 / 收款主体 / 应用商店开发者账号)
  • [ ] 确认属地网信部门的最新材料清单与审查方式
  • [ ] 产品内已具备显著位置公示能力(模型名称 + 备案号或上线编号)
  • [ ] 明确底座模型更换时的变更流程与责任人

P1

  • [ ] 备案名称与功能描述定稿,并与产品页、宣传物料口径统一
  • [ ] 若涉及端侧或私有化部署,完成端云数据流向图
  • [ ] 若涉及医疗、金融、未成年人、拟人化互动,梳理叠加审批项与年度核验要求
  • [ ] 建立备案信息的版本台账(判定输入、规则版本、变更记录可回溯)

P2

  • [ ] 把合规状态纳入招投标与客户采购所需材料的标准包
  • [ ] 每季度复核一次范围判定结论是否仍然成立
  • [ ] 建立公开信息跟踪机制(备案公告、属地通知、叠加监管动态)

9 结语

这份名单真正的信息量,不在"新增了哪些大模型",而在三件事上:

体量——累计备案 1112 款、登记 731 款,备案已是产品上线的常规动作,不是门槛竞赛。

结构——端侧首次单列、行业模型数量超过通用模型、体制内机构批量入场。这三条共同说明:AI 的合规主体正在从互联网公司扩散到所有使用 AI 的组织。

可复制性——路径选择、主体确定、名称与描述、上线公示、变更纪律,这五件事是名单背后真正能抄的作业;属地口径、产品事实、端侧的独立材料要求,这三件抄不了。

最后落在一条判断上:

名单告诉你别人做到了什么,判断告诉你自己该做什么。前者的价值在于确认路径可行,后者的价值在于让你不用重走一遍。


本文数据来源:国家互联网信息办公室《关于发布生成式人工智能服务已备案信息的公告(2026 年 7 月至 8 月)》(2026 年 9 月 14 日发布)及各地网信办公开发布的备案与登记信息汇总。分省统计的时点与口径可能不一致,仅用于观察趋势。本文不构成法律意见,具体申报要求请以属地网信部门最新口径为准。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 0 先说结论
  • 1 四个数字:这批名单的体量
  • 2 本批次最该划重点的变化:端侧 AI 第一次单列
    • 2.1 为什么"端侧单列"这件事比数量重要
    • 2.2 端云协同的三种模式,材料要求不一样
    • 2.3 端侧这条线释放的三个判断
  • 3 按属地看:备案资源集中在哪
    • 3.1 三个观察
  • 4 按行业看:257 个项目落在哪五条赛道
    • 4.1 一个容易被忽略的结构性事实
    • 4.2 两条叠加监管的赛道要单独提醒
  • 5 企业可以抄哪些作业
    • 作业一:抄"路径怎么选"的判断方式
    • 作业二:抄"主体怎么定"
    • 作业三:抄"模型名称与功能描述的写法"
    • 作业四:抄"上线后必须做的那个动作"
    • 作业五:抄"变更与核验纪律"
    • 作业六:抄"登记"这条路的做法(多数企业真正要走的路)
  • 6 抄不了的三件事
    • 6.1 属地口径不能照搬
    • 6.2 材料是产品事实的映射,文字补不上系统
    • 6.3 端侧材料不能照抄云端
  • 7 三个从名单里反推出来的常见误判
  • 8 一份可直接执行的动作清单
  • 9 结语
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档