接了大模型要不要备案？做算法备案前，先把这18个问题答明白

算法备案最先要解决的是事实一致。企业对外提供的服务、系统里的算法和申报材料，应当描述同一件事。

很多企业第一次咨询算法备案，开场通常会这样说："我们接了大模型，这个要备案吗？"

再往下问，产品是面向公众还是内部员工使用，用户能否自由注册，生成内容由谁控制，基础模型从哪里调用，运营主体与技术主体是否一致，答案往往还没有整理好。

这很正常。算法备案看起来像一项手续，真正开始以后却会同时碰到产品、技术、法务、安全和运营。企业越早把事实说清楚，后面越不容易在材料之间来回打架。

下面十八个问题，适合在正式启动前逐项确认。本文讨论的是一般判断方法，不替代主管部门对具体项目的要求。产品功能、服务对象和部署方式只要有一项不同，结论就可能变化。

01　先搞清楚要不要备案

问题1　只要产品里用了算法，就一定要备案吗

不一定。《互联网信息服务算法推荐管理规定》调整的是在中国境内应用算法推荐技术提供互联网信息服务的活动。规定列出的技术包括生成合成、个性化推送、排序精选、检索过滤、调度决策等类型。对具有舆论属性或者社会动员能力的算法推荐服务提供者，规定提出了备案要求。

所以，判断不能停留在"有没有算法"。还要看算法怎样参与信息服务，产品是否向社会公众开放，提供者是谁，功能是否具有规定所说的属性与能力。企业内部的销量预测、设备故障识别、仓库调度，与向公众提供内容生成、信息推荐、热榜排序的产品，面对的判断重点并不一样。

问题2　只在公司内部使用，还需要办理吗

内部使用是一个重要事实，但不能只凭"内网"两个字下结论。《生成式人工智能服务管理暂行办法》明确，行业组织、企业、教育和科研机构等研发、应用生成式人工智能技术，未向境内公众提供生成式人工智能服务的，不适用该办法。这个边界对判断生成式人工智能服务备案很重要。

企业仍要核实所谓内部使用是否真的只限员工。经销商、客户、外包人员能否注册，工具是否嵌入公开网站，是否通过小程序向不特定人员提供试用，都会影响事实判断。内部系统也不等于没有数据安全、个人信息保护和商业秘密方面的义务。

问题3　接入已经备案的大模型，自己的应用还要办吗

不能只看基础模型有没有备案。如果应用通过API等方式直接调用已备案模型能力，通常要继续判断应用或功能是否需要在地方网信部门完成登记，以及自身是否还构成其他类型算法服务的提供者。国家网信办发布的生成式人工智能服务备案公告，也持续区分模型服务备案与调用已备案模型能力的应用或功能登记。

企业要准备好模型名称、服务商、调用方式、合同关系、用户看到的功能、内容安全责任与投诉处置安排。基础模型的备案情况能解决一部分问题，却不会自动覆盖应用层全部责任。

问题4　自研模型就一定走生成式人工智能服务备案吗

还要看模型是否面向境内公众提供生成文本、图片、音频、视频等内容的服务，以及服务的具体形态。自研模型可能只用于企业内部，也可能作为面向公众的模型服务开放，还可能被包装成某个垂直应用。三种形态的申报思路不同。

判断时不要只给模型贴一个"自研"标签。训练方式、基础模型来源、数据来源、服务对象和输出能力都需要分别说明。产品尚未开放时，企业还应结合上线计划安排材料、测试和监管沟通，避免功能已经对外运行，合规工作才刚刚开始。

问题5　算法备案、大模型备案、应用登记和安全评估是一回事吗

不是同一个手续，也不能相互替代。企业口中的"大模型备案"，通常指面向公众提供生成式人工智能服务涉及的备案工作。对于通过API等方式调用已备案模型能力的生成式人工智能应用或功能，实践中还有地方登记安排。算法备案依据算法推荐和深度合成等规定，关注具体服务及其使用的算法技术。安全评估则有自己的触发条件、材料和程序。

一个产品可能只涉及其中一项，也可能需要同时判断多项。最实用的做法，是先画一张产品关系图，把运营主体、模型提供方、技术支持方、用户入口、生成内容和推荐环节放在同一张图里，再逐项判断。

问题6　产品还没上线，可以先办吗

需要结合具体申报类型和受理要求安排。《互联网信息服务算法推荐管理规定》对符合条件的服务提出在提供服务之日起十个工作日内履行备案手续的要求。企业不宜把这句话理解成必须先上线再准备。正式开放之前就应完成适用性判断、制度建设、自评估、功能测试和材料整理，并结合当地主管部门要求确定提交时点。

若产品还停留在概念阶段，核心流程、模型、数据与安全措施都没有确定，材料很难写实。若已经完成可验证的产品版本，再开展评估和填报，内容会扎实得多。

添加图片注释，不超过 140 字（可选）

【图1｜算法备案适用范围判断（适用范围判断流程图）】

02　谁来备案，报几个

问题7　到底由母公司、研发公司还是运营公司申报

备案主体应当与实际服务提供关系相匹配。营业执照上写着谁、应用商店里的开发者是谁、用户协议由谁签署、服务器和域名归谁、谁决定算法规则、谁接受投诉、谁承担内容安全责任，这些信息要放在一起看。集团内部品牌方、研发方和运营方分离时，尤其容易出现材料里的主体与用户实际接触的主体不一致。

若存在技术支持方，还要梳理它提供的是基础模型、算法能力、数据处理还是系统运维。主体选择要服从真实责任关系，不能只挑材料最方便的公司。

问题8　一个公司有多个App，需要每个都单独申报吗

不能简单按公司数量或App数量机械计算。备案通常围绕实际提供的算法服务展开。多个产品是否共用同一套算法，算法目的、机制、数据和风险控制是否一致，用户群体和应用场景是否发生实质变化，都需要判断。名字不同的两个App可能使用同一项算法服务，同一App里也可能存在生成合成、个性化推荐和排序精选等多个算法功能。

建议先做算法清单，再做产品映射。每一项算法写明关联产品、入口、用户、输入、处理过程、输出与负责人，之后才有条件决定怎样归并或拆分。

问题9　只做SaaS工具，客户拿去使用，谁负责备案

先看双方分别向谁提供了什么服务。SaaS供应商可能提供底层技术能力、完整产品，也可能代客户运营面向公众的功能。客户可能只购买工具，也可能决定业务规则、内容边界和用户关系。合同名称写着"技术服务"并不能替代事实判断。

双方至少要把五件事写明。谁控制产品入口，谁选择模型和主要规则，谁处理用户数据，谁审核与处置内容，谁接受监管和用户投诉。若供应商已经完成相关备案或登记，客户也要核实备案所覆盖的服务、算法和产品，与自己的实际使用方式是否一致。

03　材料怎么准备

问题10　申报前需要准备哪些材料

官方通告列出的核心信息包括服务提供者名称、服务形式、应用领域、算法类型、算法自评估报告和拟公示内容。进入实际准备阶段，还要用产品与技术材料支撑这些填报内容。

常见底稿包括主体证照与负责人信息、产品说明、用户流程、功能截图、算法机制说明、模型与供应商信息、数据来源及处理说明、风险识别与控制措施、测试记录、应急预案、用户协议、隐私政策和投诉渠道。材料数量多不是目标。每份材料要能互相对应。产品说明写面向公众，测试报告却只覆盖内部样本，隐私政策写了数据删除，系统没有删除入口，这类矛盾比少一份附件更麻烦。

问题11　自评估报告最难写的是什么

最难的是把真实系统写清楚，并证明风险控制已经落实。好的自评估报告应当回答算法为什么存在，输入数据来自哪里，主要机制怎样运行，结果怎样影响用户，可能产生哪些风险，企业用什么技术和管理措施控制风险，测试发现过什么问题，问题如何整改。

只抄法规条文通常没有帮助。写"建立完善的内容安全机制"，却说不清谁审核、用什么规则、何时转人工、怎样复测，主管人员也无法据此判断。报告应当能经得起产品经理和技术负责人逐段核对。

问题12　备案会要求提交源代码和全部模型参数吗

企业应按申报系统、填报指南和主管部门具体要求提供材料，不能预设必须交全部代码，也不能用"商业秘密"作为拒绝说明技术事实的笼统理由。通常更关键的是讲清算法流程、数据输入、主要机制、输出、应用场景和安全控制。涉及第三方模型时，还要说明供应关系与调用方式。

企业可以提前对材料分级，明确可提交内容、敏感内容与内部审批人，在满足申报要求的同时做好商业秘密管理。不要为了显得技术先进写入与实际产品无关的参数，也不要把关键机制全部隐去。准确、可核验比堆叠术语更重要。

添加图片注释，不超过 140 字（可选）

【图2｜算法备案核心材料清单（主体与人员／产品与页面／算法与模型／数据与安全／自评估与测试）】

04　时间、加急和改版

问题13　办理一般要多久

法规规定的十个工作日，指符合条件的服务提供者在提供服务之日起办理备案的时间要求，不等于从启动到取得备案结果只需要十个工作日。完整周期通常包含范围判断、产品梳理、材料撰写、内部确认、测试整改、线上填报、主管部门审核和可能的补充修改。企业已有资料是否完整，产品是否稳定，主体关系是否清楚，都会影响进度。

负责任的排期应当拆开来看。哪些是企业准备时间，哪些是服务方整理时间，哪些进入主管部门审核，哪些取决于补正轮次。把所有时间压成一个"最快几天"，往往会掩盖真正的工作量。

问题14　能不能加急，能不能保证通过

任何服务机构都无法代替主管部门作出审核决定，也不应承诺所谓百分之百通过。可以提速的是企业内部工作。负责人提前到位，产品信息一次提供完整，技术与法务并行核对，测试发现的问题尽快整改，都会减少等待。无法随意压缩的是监管审核与反馈时间。

如果一份报价把"包过""内部渠道""指定日期拿号"当作主要卖点，企业应当提高警惕。真正值得比较的是适用性判断是否可靠，材料能否落到真实产品，补正是否包含在服务范围，后续变更是否有人提醒。

问题15　产品还在频繁改版，现在开始会不会白做

完全等产品定型，常常会错过最适合改动的阶段。过早把不稳定功能写死，也会增加返工。更稳妥的做法是先确定不会轻易变化的骨架，包括服务对象、核心功能、模型来源、主要数据、运营主体和上线范围。提示词细节、页面文字和次要流程可以随版本继续更新。若核心模型、算法目的或服务对象发生变化，则要重新评估申报材料是否需要调整。

备案项目应当与产品版本管理连接起来。每次重大版本评审时，增加一个问题就够了，这次变化会不会影响已经提交或公示的信息。

问题16　材料被退回，是不是说明项目不能做

退回或要求补充材料，不必直接等同于产品被否定。常见问题可能来自信息缺失、前后表述不一致、算法机制过于笼统、产品截图无法对应、风险措施缺少证据，或申报路径选择不准确。企业应先识别反馈针对的是形式、事实、技术说明还是实质风险，再决定补材料、改产品或重新判断路径。

如果只在原文上反复换词，根本矛盾不会消失。遇到反馈以后，最好由产品、技术、法务一起核对，不要让填报人员独自猜测。

05　公示和后续维护

问题17　拿到备案编号以后，要在哪里展示

不同规则与服务类型有具体要求。《互联网信息服务深度合成管理规定》要求，完成备案的深度合成服务提供者和技术支持者，应当在其对外提供服务的网站、应用程序等显著位置标明备案编号并提供公示信息链接。生成式人工智能服务相关公告也要求已上线的应用或功能公示所使用的模型名称、备案号或上线编号。

企业应把公示位置做进产品发布清单，并核对网站、App、小程序等各个入口。备案编号不能被包装成主管部门对产品效果或安全性的背书。国家网信办在算法备案系统上线通告中明确，备案不代表对主体、算法、产品或服务的认可，不得将备案结果用于宣传和其他商业用途。

问题18　备案完成以后还要做什么

备案结果对应的是申报时的事实。产品继续变化，维护工作也要继续。《互联网信息服务算法推荐管理规定》明确，备案信息发生变更的，应当在变更之日起十个工作日内办理变更手续。终止服务的，应当在终止服务之日起二十个工作日内办理注销备案并作出妥善安排。近年的算法备案系统也持续发布注销公告，说明退出与更新同样属于正常管理环节。

企业至少要持续关注运营主体、产品名称、服务对象、算法目的、模型供应商、数据来源、内容类型和风险控制是否发生重大变化。对拟人化互动等特定服务，现行专门规则还提出年度核验等要求，更需要把合规维护放进日常版本管理。

正式启动前，先把这张判断表填完整

1. 产品名称、入口和当前上线状态

2. 面向公众、客户、员工还是特定会员

3. 用户能够使用哪些生成、推荐、排序或筛选功能

4. 自研模型、开源模型和第三方API分别承担什么作用

5. 运营主体、研发主体与合同主体分别是谁

6. 输入数据、训练数据、知识库和用户数据来自哪里

7. 现有内容审核、投诉、日志和应急措施做到什么程度

8. 计划上线时间以及近期会不会更换模型或扩大用户范围

这张表的价值不在于马上得出一个简单答案。它能让企业看到，真正缺的是一份材料、一个产品功能，还是对申报路径的重新判断。算法备案做得扎实，最后留下的不只是一个编号。企业会同时得到一套更清楚的产品事实、一份可以复核的算法说明，以及产品变化以后知道该查什么的维护方法。

启动前先做一次事实梳理。算法备案不是填一张表。产品事实、算法说明和安全措施能互相对应，材料才经得起审核。越早把十八个问题过一遍，后面的补正轮次越少。

主要依据

• 互联网信息服务算法推荐管理规定

• 关于互联网信息服务算法备案系统上线的通告

• 互联网信息服务深度合成管理规定

• 生成式人工智能服务管理暂行办法

• 人工智能生成合成内容标识办法

• 互联网信息服务算法备案系统