算法备案 20 个高频知识点：从判断到填表

说明：本文梳理的知识点均以公开发布的法规文本、备案系统填报指南与各地网信部门公开口径为依据。涉及具体判断的，请以属地网信部门答复为准；本文不构成法律意见。

0 这份清单解决什么问题

算法备案这件事，卡人的往往不是流程太长，而是在某个判断点上不确定。

不确定要不要办、不确定备哪一类、不确定某一栏怎么填、不确定手上这串数字是什么。每一个不确定都可能导致两种代价：多做了不需要做的事，或者做错了方向导致返工。

下面 20 个知识点，按三组组织：

• A 组（1–7）：判断类——要不要办、办哪一种、走哪条通道
• B 组（8–14）：填表类——算法名称、类型、模态、功能描述怎么定
• C 组（15–20）：易混类——那些名字很像的东西到底是什么

每个知识点给三样：结论、依据、常见误判。

A 组：判断类（你要不要办、办哪一种）

1 算法备案到底备的是什么

结论：备的是算法本身——向网信部门报送算法的名称、类型、功能、输入输出、基本原理、运行机制、应用场景，以及一份算法安全自评估报告；经属地省级网信办初审、中央网信办复审后公示并下发编号。

依据：《互联网信息服务算法推荐管理规定》《互联网信息服务深度合成管理规定》。触发条件是两个同时成立——提供算法服务，且该服务具有舆论属性或社会动员能力。

常见误判：把它理解成"产品上线许可"。它是报送公示，不是许可审批。但这个区别不能理解为"可以先上线后补"——未按规定履行义务的，会被责令限期改正；拒不改正的，可责令暂停信息更新并处罚款。

2 三个"备案"不是一回事，先分清自己在哪一条

结论：至少有三个容易混的东西。

依据：三者依据不同法规，分属不同系统（算法备案走 beian.cac.gov.cn，公安联网备案走 beian.mps.gov.cn）。

常见误判：以为办了一个就都覆盖了。三者独立，不互相替代。 公安联网备案还有时限要求——网络正式联通之日起 30 日内，且不收费。

3 算法备案能替代生成式服务备案吗

结论：不能。 两条线并行，不互相替代。

依据：算法备案管"算法机制透明"，生成式服务备案（或登记）管"生成式服务提供行为"。同一项服务可能两条线都要走。

常见误判：只做算法备案就上线，可能被指出"应备未备"。这是实务中较常见的一类问题。

4 生成式服务那一条，走备案还是走登记

结论：看三个问题。

1. 模型是自己训的或做了微调吗
2. 有没有对模型做出影响生成内容的调整（注入私有语料、调整输出组织逻辑、场景深度定制）
3. 上游模型是否已备案

自己训／微调，或做了上述调整 → 走备案；只是调用已备案模型且未做调整 → 走登记。

依据：登记路径的适用前提，各地公告里有原文表述，通常写作"通过 API 接口或其他方式直接调用已备案大模型能力"的应用或功能。上游是否已备案，是登记的前提之一。

常见误判：以为"我只是做了个壳"就不用管。只做界面封装、面向公众提供服务，自身仍是服务提供者，需要以自己主体完成登记或备案。

5 接入私有语料（RAG）会改变路径吗

结论：会。 RAG 通常构成"影响生成内容的调整"，登记的前提就不成立了。

依据：登记的前提是"未对模型做出影响生成内容的调整"。私有语料注入、输出逻辑改造、场景深度定制属于这一类。

常见误判：把 RAG 当成普通功能。它在技术上看就是常规迭代，但从路径判断的角度，它改变的是决定权归属——参考答案由谁提供、以什么优先级拼接、冲突时相信谁，都由你的工程决定。

6 内部的 AI 要不要备案

结论：先判断服务对象，不是看技术或部署方式。

判断变量只有一个：是否向境内公众提供服务。纯内部使用、不对外提供的，通常不适用生成式服务那一层；数据、个人信息、商业秘密、等保等义务仍在。

依据：《生成式人工智能服务管理暂行办法》第二条，明确"未向境内公众提供"的情形不适用该办法，且把企业列为豁免主体之一。

常见误判：把"内部"当成一个是非题。它其实是一条光谱——从纯内网仅员工，到外包劳务、经销商、供应商、私有化交付、SaaS 多租户，再到"卖给企业、企业拿去面客"。其中"卖给企业、企业拿去面客"这一格最容易被误判，因为它看起来是 B2B，但最终仍面向不特定公众。

7 什么情况下算"已经提供"，什么时候该办

结论：关键时间点是提供服务之日起 10 个工作日内。

依据：时限要求为提供服务之日起 10 个工作日内办理备案；变更为 10 个工作日；注销为 20 个工作日。材料齐全的，国家和省级网信部门应在 30 个工作日内予以备案、发编号并公示。

常见误判：把"内测""免费""只做接口"当成不构成提供。判断依据是是否面向不特定对象——公开注册、公开卖额度、没有实质准入审核，都构成面向不特定对象，与收不收费无关。

B 组：填表类（每一栏怎么定）

8 算法类型怎么选

结论：五个类型选一个——生成合成类、个性化推送类、排序精选类、检索过滤类、调度决策类。

依据：生成合成类的定义关键是"自动或辅助生成、编辑文本、图像、语音、视频等网络信息内容的算法"——关键动词是生成与编辑。

常见误判：把"识别"按生成合成类备，或反过来。判据是有没有产出新内容：识别与解析本身不产出新内容，所以不属生成合成类。

另外说明一处：如果走的是深度合成服务算法备案这个通道，是按深度合成场景选（如文本生成、图像生成），和上面五类不是同一套选项。

9 算法名称怎么写

结论：两条要求——稳定，以及让人看懂。

依据：算法名称会同时出现在备案系统、自评估报告、产品页面公示、材料附件等多处。四处口径必须一致。

常见误判：用产品名代替算法名，或者写出一个只有内部能看懂的代号。建议让名称体现核心能力（比如"XX 问答与报告生成算法"），而不是把某个中间环节当主名（比如"文档解析"）。

10 模态怎么填（这一栏漏得最多）

结论：看输入什么、输出什么；不看中间环节，看内容本质不看文件格式。

依据：模态由服务的输入与输出决定，中间的处理环节不单独定模态。

几组具体判断：

常见误判：输入漏写图片。 只要产品能收扫描件、拍照件、截图，输入栏就必须写图片。这是最常被指出的一处。

另注意：如果后续新增语音提问（语音转文字），输入模态要加音频，这属于备案信息变更，不是改个字段那么简单。

11 功能描述怎么写

结论：跟系统里实际在跑的东西一致。

依据：备案里典型的一类问题是"功能描述与实际不符"。

常见误判：判别类功能里出现"生成"字样。虽然已有先例（某 OCR 算法的用途描述写作"提取识别图片中文字，生成提取后的文本信息"）也不影响其识别类定性，但填报时建议功能描述落在"提取／识别……输出文本"，避免引起类型误判。

12 垂直领域怎么填

结论：按实际场景写，不要默认填"回答通用问题"。

依据：垂直领域用于描述服务实际面向的场景。

常见误判：无论做什么产品都填"回答通用问题"。如果是法律咨询、财税、招投标研判这类明显场景定制的服务，按实际场景写更准确——写"通用"反而与产品实际不符。

13 主体资格有没有限制

结论：备案主体须具备独立法人资格。 自然人与个体工商户均无法通过备案系统的主体认证。

依据：备案系统的主体认证环节需要营业执照、法人信息等企业资质。

常见误判：把"非个人主体"等同于"独立法人"。个体工商户属于非个人主体，但不是独立法人——它可能过得了某些平台的主体门槛，却过不了备案系统。实操中通常需要注册有限责任公司。

14 调用第三方已备案模型，是不是就不用自己办

结论：不是。 面向公众提供服务时，自身即为服务提供者，须以自己主体完成登记，不能套用模型厂商的备案号。

依据：《生成式人工智能服务管理暂行办法》对服务提供者的定义明确"包括通过提供可编程接口等方式"。

常见误判：有一类具体误解值得单独点出——把上游出具的合规承诺函当成评估依据。概括性承诺回答不了"基于什么材料得出什么结论"。上游已备案是需要核查的事项，不能据此推定下游已履行全部要求。

C 组：易混类（名字很像的东西分别是什么）

15 三种编号怎么区分

结论：一家企业名下可能同时挂着几种编号，格式完全不同。

依据：不同系统生成、不同路径取得。

常见误判：公示时写错编号类型。 属地公告的公示要求也不一样——备案这条线通常要求公示"模型名称＋备案编号"，登记这条线要求标明"上线编号"。

一个附带发现：生成式服务备案编号的属地前缀按备案主体注册地，不是按品牌归属地。举例来说，某手机厂商的端侧模型由注册在北京的主体备案，编号前缀即为 Beijing-。

16 算法备案编号那串数字能读出什么

结论：21 位数字分三段。

依据：从官方公开备案清单的编号规律中可以直接观察到。

常见误判：用尾号互相印证。 尾号不是全局唯一的——同批不同主体会出现相同尾号，必须用整串比对。

17 识别类和生成合成类的分界线在哪

结论：有没有产出新内容。

依据：生成合成类的关键动词是"生成、编辑"。

几组判断：

常见误判：以为识别类天然免备案。判据始终是两条——是否对外提供服务、是否带舆论属性。已有 OCR 类算法作为服务提供者完成备案的先例。

另一处容易混：识别类若需要备案，走的是互联网信息服务算法备案（检索过滤类），不是"深度合成服务算法备案"。

18 算法备案、大模型备案、大模型登记，周期差多少

结论：量级不同。

依据：多种公开口径的普遍区间，实际周期受材料质量、是否涉及深度合成、是否需要安全评估影响。

常见误判：按最短的那条排期。 三条路并行推进、材料不同、不能合并提交；建议先启动周期短的那条（线上、材料少），同时准备周期长的那条的材料。

19 拿到编号之后，还有哪些独立的义务

结论：备案完成不等于义务完成。

依据：以下几项各自独立、各有时间点：

• 安全评估（具有舆论属性的服务）
• 生成合成内容标识——显式标识与隐式标识，且导出、下载、复制路径上不能丢
• 公示——在显著位置或产品详情页面注明模型名称与对应编号
• 投诉举报渠道与处理规则
• 日志留存

常见误判：把这几项当成备案材料的一部分。它们是并列的义务，不因为备案完成而自动满足。

另外注意两条：一是备案编号不得用于宣传和其他商业用途，这一点在产品页与市场文案里最容易踩线；二是部分服务类型另有年度核验要求（例如拟人化互动服务），年度核验看的正是材料与系统实际是否一致。

20 什么样的情况必须办变更

结论：凡属实质性变化的，都要办变更。

依据：变更时限为 10 个工作日；变更不沿用原编号。

常见情形：

• 更换底座模型
• 新增 RAG 或调整输出组织逻辑
• 服务形态发生变化
• 主体信息变更
• 从受限访问转为开放公网／开放外部账号
• 服务下线（对应注销，20 个工作日）

常见误判：把"换模型"当成日常迭代。它属于实质性变更——而且要注意，模型重要更新后再次自行组织安全评估，与更新备案信息是两项独立的工作量，排期上要分开算。

附：20 个知识点速查

结语

这 20 个知识点有一个共同特征：它们都不涉及复杂的技术，也不涉及难懂的条文，但每一个都能让人在某个具体动作上卡住。

而卡住的代价往往不是钱，是时间——多写一遍材料、多等一个周期、多改一版公示。

判断这些点，其实只有一个通用方法：先问这条义务成立的前提是什么，再看自己的实际情况是否落在前提内。 前提不成立，义务就不成立；前提成立而自己没做，那就是缺口。

如果手上有具体某一栏拿不准，把产品形态、模型来源、有无改造这三样说清楚，多数问题都能一次性定下来。

本文梳理的内容以公开发布的法规文本、备案系统填报指南与各地网信部门公开公告为依据。具体条款以正式发布文本为准，具体判断请以属地网信部门答复为准。本文不构成法律意见。