大模型登记要注意的问题：一条简化通道的适用边界与落地清单

声明：本文基于公开发布的法规文本、备案系统填报口径与各地网信部门公开公告整理，不含任何产品推广，也不构成法律意见。涉及具体项目的判断，请以属地网信部门答复与属地最新要求为准。

0 先说结论

大模型登记是三条备案线里最轻的一条，也是最容易被误用的一条。

它的材料比备案薄，周期比备案短，但它的适用前提比很多人以为的窄：上游模型必须已经完成备案，并且你自己没有对生成内容的决定权做出改变。这两个前提同时成立，登记才成立；任何一个不成立，这条路从一开始就走不通。

多数团队真正吃亏的地方，不是材料写得不好，而是在前提还没验证的情况下，按登记准备了一整套材料。等被驳回再换路径，损失的不是返工那几天，是整整一个周期。

所以这篇文章不写"登记材料怎么填"，而是把三件事讲清楚：

1. 登记与备案的分界到底划在哪；
2. 什么动作会动摇登记前提，动摇之后该怎么处置；
3. 登记走通之后，还有哪些义务不会因为手续轻而减少。

一句话概括全文：登记是"输出内容的决定权不在你这边"时的简化程序；一旦这个决定权回到你手上，就该走备案。

1 先把三条线摆在一起

三条线并行，不是三选一，也不能互相替代。很多人出问题不是选错了，而是从一开始就默认"办一个就都覆盖了"。

三行里最需要记住的是最后一行和第一行的关系：登记不会替代算法备案。 算法备案管的是算法机制透明，登记管的是调用行为的落地，两者管的东西不一样。只做了登记就上线，仍可能被指出"应备未备"。

反过来也一样：做了算法备案，不意味着模型那一层的手续可以省。判断顺序应该是先确认自己在哪几条线上有义务，再谈各条线怎么走，而不是先挑一条最好走的。

关于周期，有两个使用上的提醒。第一，三个量级差距很大，产品排期要按最长的那条倒推，不能按最短的排。第二，周期口径存在属地差异，本文给的是量级，不是承诺；具体排期以属地答复为准。

2 登记的前提只有两条，但两条都要能证明

登记的门槛不在材料数量，而在前提是否成立。前提是两条，且必须同时成立。

这两条里，第二条是绝大多数问题的来源。它问的不是"你用了什么技术"，而是"最终呈现给用户的内容，是谁决定的"。

处置原则上，这里有一个和内容审核同源的思路值得借用：不确定就不放行。用工程语言说就是 fail-closed——规则没覆盖、结论没把握的情形，一律转人工复核，不做默认通过。

理由可以算一笔账：按登记准备、被驳回、再改走备案，损失的是一个完整周期；而多备一层，损失的是工作量。两个方向的代价不对称，所以默认值应该偏保守。

3 前提一：上游的合规状态要核到哪一层

"上游已备案"这句话，落到实操上至少要核四件事。

两类不构成登记前提的情形，单独拎出来说：

第一，下载开源权重自行部署。 开源协议的授权和监管备案是两件事。权重下载到你自己的环境里由你运行、由你对外提供服务，这属于你自己提供模型，走的是备案；"模型是开源的"不构成登记理由。

第二，调用境外未按要求完成备案的模型。 这类调用无法构成登记前提。上线前如果模型来源这一环就说不清，后面的材料写得再细也没有意义。

还有一个高频误判：厂商备案了，不等于你备案了。 厂商的备案解决的是厂商自己的义务。你面向公众提供服务，你就是服务提供者，要以自己的主体办手续，不能套用厂商的编号，也不能把厂商的合规承诺函当成自己的合规依据（见第 6 节）。

4 前提二：什么算"影响生成内容的调整"

这是全文最需要逐条对照的一张表。

这张表不需要背下来，用一句判据就能覆盖大多数情形：

不要问这个技术新不新，要问这条链路里，谁在实质决定输出内容。

如果答案是"模型厂商决定，我只是转发"，登记的前提通常成立；如果答案是"结果长什么样是我的工程决定的"，前提就动摇了，应当按备案评估。

一个可以自查的实操方法：试着用半小时，把从用户提问到模型返回的完整链路说清楚——哪些环节处理过、每一环改了什么。 说不清，说明这个前提还没有被验证过；说得清，这份链路说明本身就是登记材料里最有价值的一份底稿。

5 最容易踩的一条：RAG

私有语料注入之所以是最高频的踩坑点，有两个原因。

第一，它在技术上就是一个常规功能。 把它加进产品是日常迭代的一部分，加的时候没有人会联想到备案路径。很多团队是在被问起来时，才发现自己的链路里已经有这一环。

第二，"注入了语料"这个描述听起来不像改造模型。 但监管关心的从来不是你有没有动模型的权重，而是输出内容由谁决定。

RAG 动摇登记前提的机理，可以拆成三个决定权：

• 参考答案由谁提供——由你的知识库提供，不再只由模型内部知识决定；
• 检索结果如何拼接进上下文——拼接顺序、截断策略、注入位置，都是你的工程选择；
• 冲突时信谁——检索到的内容与模型自身判断矛盾时，谁的优先级更高，由你的规则决定。

这三件事过去都在模型这一侧，现在都在你这一侧。所以正确的表述是：RAG 改变路径，不是因为它技术新，而是因为决定内容的人换了。

顺着这条线还有一个容易忽略的推论：动摇前提的不一定是 RAG。 只要链路里存在一个由你决定"最终呈现什么"的环节，哪怕不是检索、不是语料，也应该重新判断。

6 登记不等于把安全责任交给上游

把登记理解成"我调的是别人的模型，安全该由上游负责"，是一个方向性错误。登记通常要能证明三件事。

第三点是关键：不得把安全责任全部推给上游模型。 上游提供的是模型能力，你在应用层面向用户，应用层的风控责任在你。

另外有一条容易被误解的文件：上游的合规承诺函不能当作自己的安全评估依据。 它是一份商务文件，说明对方愿意承担的责任边界，不能用来替代你自己的安全评估与风控建设。

最后要分清"轻"在哪：登记使手续变轻，但只有程序那一部分变轻。面向公众提供服务，你仍然是服务提供者。内容安全、个人信息保护、数据安全、网络安全等级保护这些基础义务与走哪条线无关；安全评估、生成合成内容标识、投诉举报渠道、日志留存这些义务各自独立，各有各的时间点。

7 主体与材料：容易被退的几处

登记材料比备案轻，但不代表没有明确的核对点。下面这张表的右两列可以直接当整改方向用。

这张表里解释成本最高的是"调用链路说明"。它不是格式问题，是能力问题：写不出链路，通常意味着前提本身没有被验证过。 如果一份链路说明需要临时找人拼凑，那说明这条链路平时没有对应的台账或文档，也就没有可核验的基础。

8 编号与公示：登记线公示的是上线编号

三类编号的格式、来源、公示要求都不同，混用是公示不规范最常见的成因。

公告层面有一条面向已上线产品的落地要求：应在显著位置或产品详情页面公示所使用已备案或登记的服务情况，注明模型名称、备案号或上线编号。

执行时有三个"不算"，几乎每一条都对应过真实的整改意见：

• 写在隐私政策里不算显著位置。 隐私政策是合规文本，不是产品展示位，用户不会去那里看服务用的是哪个模型。
• 写占位符不算完成。 "备案中""办理中""待补充"这类字样，在核验时等同于未公示。
• 多个模型只公示一个不算完整。 用了几个模型，就要对应公示几个，不能合并、不能省略。

最后一个提醒：编号不是宣传素材。 备案编号不得用于宣传和其他商业用途，这条对备案线与登记线同样适用。公示是履行义务，不是能力背书。

9 变更与升级：登记什么时候会变成备案

登记不是一次性的动作。下面这张表列出常见的变更触发，建议直接做成内部清单。

这里有一处最容易排错期的地方：模型发生重要更新后再次自行组织安全评估，与更新备案或登记信息，是两项独立的工作量。 很多团队把它们当成一件事排期，结果一项做完了另一项没动，两边都对不上。排期时应当分开计算。

时间要求上，算法备案线有相对明确的口径（变更 10 个工作日、注销 20 个工作日，材料齐全的应在 30 个工作日内完成备案、发号并公示）。登记线的时间要求以属地答复为准，但有一条原则是共通的：变更之后不能沿用旧编号。

10 上线前核验清单

以下条目可直接作为上线前检查表使用。标注"反向"的那几条，是实践中最容易为了省事而放宽的。

A 前提确认（6）

• [ ] 已确认实际调用的模型本身已完成备案或登记，并留存可核验凭证
• [ ] 已取得对应到该接口的商业授权合同或采购证明
• [ ] 已按"谁在实质决定输出内容"逐环节审查链路，结论为未动摇前提
• [ ] 审查结论有书面记录（谁看的、看了哪些环节、结论是什么），不是口头确认
• [ ] 链路中含私有语料或输出组织改造的，已按备案路径评估，而不是按登记处理
• [ ] 结论不确定时，已按前提不成立处理（反向：没有默认放行）

B 主体与材料（7）

• [ ] 申报主体、域名 ICP 主体、收款主体、应用商店开发者账号为同一主体
• [ ] 调用链路说明写到模型、接口、版本、环节粒度
• [ ] 输入输出模态按实际能力列全，含截图、扫描件、拍照件等易漏项
• [ ] 涉及多模态输出的，输出侧模态与实际一致
• [ ] 模型名称与编号在系统、材料、产品页面、附件四处完全一致
• [ ] 安全责任人为本单位正式员工，在职证明已备
• [ ] 全文术语统一，备案、登记、上线编号不混用

C 公示（5）

• [ ] 公示位置为显著位置或产品详情页面，不是仅放在隐私政策里
• [ ] 登记线标明的是上线编号，未误写为备案号
• [ ] 模型名称与编号成对公示，无占位符
• [ ] 多模型场景逐个公示，不合并、不省略
• [ ] 公示文案不含能力背书，不作为宣传素材

D 变更与持续义务（6）

• [ ] 变更触发事项清单已固化，内部责任人明确
• [ ] 换底座模型、新增语料注入等动作已纳入变更流程
• [ ] 模型更新后的再次安全评估与信息更新，已作为两项工作量分别排期
• [ ] 生成合成内容标识已按强制要求落地（显式与隐式，导出下载不丢失）
• [ ] 投诉举报渠道、日志留存已就位
• [ ] 若服务具舆论属性，算法备案线已单独安排，未因做登记而省略

11 十个常见误判

1. 拿厂商的备案号当自己的。 厂商备的是厂商的义务，你要以自己的主体办。
2. 以为只提供接口就不必办。 通过提供可编程接口等方式提供服务，同样属于提供服务。
3. 以为开源权重自部署也算调用已备案模型。 那是自己提供模型，走备案。
4. 以为加了 RAG 只是常规功能。 它动摇的前提是决定权，而不是技术栈。
5. 以为前端做内容过滤是合规动作所以不算改造。 出发点没问题，但改造发生在输出链路上，要如实披露并逐案判断。
6. 以为登记拿到编号后可以沿用。 换模型、加语料之后，旧编号不再适用。
7. 以为做了登记就覆盖了算法备案。 两条线管的东西不同，不能互相替代。
8. 以为拿到编号就结束了。 标识、公示、投诉渠道、日志是各自的独立义务。
9. 以为编号可以拿来做宣传。 编号不得用于宣传和其他商业用途。
10. 以为登记轻所以可以先上线再补。 备案与登记在性质上是报送公示，不是许可审批，但未按规定履行仍会被责令改正，拒不改正可被责令暂停信息更新并处罚款。

12 FAQ

Q1 我怎么知道自己该走备案还是登记？

先看两条前提：上游模型是否已完成备案，你自己的链路是否改变了输出的决定权。两条都成立走登记，任一条不成立按备案评估。判断之前，先确认自己是否真的需要履行这条义务——这一步看的是服务对象，不是技术方案。

Q2 我只是调用接口，也要办吗？

要。面向公众提供服务时，你自身就是服务提供者。上游合规不构成你的免责。

Q3 上游说他们已经备案了，我能直接用吗？

不能直接等同。要拿到可核验的编号或凭证，并留存对应到实际调用接口的授权或采购证明。

Q4 我加了 RAG，还有可能走登记吗？

按现行实务口径，RAG 私有语料注入通常被认定动摇登记前提，倾向按独立生成式服务走备案。存在个案差异的，以属地答复为准，但不要默认可以走登记。

Q5 登记大概要多久？

量级在 1–3 个月，部分属地实际按 3–4 个月推进，比备案短很多。具体排期以属地答复为准，产品排期仍应按最长的线倒推。

Q6 登记之后换模型怎么办？

换底座模型属于前提变动，需重新判定路径，并判断是否需要办理变更。旧编号不能沿用。

Q7 我已有算法备案号，还需要做登记吗？

需要判断。算法备案管算法机制透明，登记管调用行为，两者不是替代关系。很多"应备未备"的情形就出现在这里。

Q8 登记材料里最容易被打回来的是哪一项？

调用链路说明。它被打回的原因通常不是格式，而是内容本身说不清——说明前提没有被真正验证过。

13 结语

把这篇的要点收敛成一句：登记的轻，轻在程序；不轻在前提，也不轻在责任。

前提那两条，一条在上游，一条在自己。上游那条要落到实处的方式是"拿到可核验的凭证"；自己那条要落到实处的方式是"能说清链路"。这两件事都不难，但它们都有一个共同点——需要平时就留下记录，而不是在被问起时临时拼凑。

如果你只从这篇里拿走一个动作，就拿走这一个：现在花半小时，把从用户提问到内容返回的链路完整写一遍，写清每一环做了什么。写得出来，登记的前提就有了可核验的基础；写不出来，说明你真正需要解决的还不是填报问题。

附一 主要依据

• 《生成式人工智能服务管理暂行办法》（适用范围、服务提供者定义、安全评估与算法备案义务）
• 《互联网信息服务算法推荐管理规定》《互联网信息服务深度合成管理规定》（算法备案与变更、注销手续）
• 《人工智能生成合成内容标识办法》及配套强制性国家标准（显式标识与隐式标识）
• 国家网信部门历次生成式人工智能服务已备案信息公告（备案与登记的公示要求、编号口径）

附二 可以自己动手核验的三件事

1. 核模型。 按模型名称与备案单位，在官方已备案信息公告中检索比对，确认你实际调用的模型在名单内。
2. 核链路。 用半小时把从用户提问到内容返回的链路写一遍，标出每一环由谁决定内容。
3. 核公示。 打开自己的产品页面，确认模型名称与对应编号（备案号或上线编号）成对出现、位置显著、没有占位符。