1. 三个资质到底在管什么很多做AI产品的朋友第一次听到“算法备案”“大模型登记”“大模型备案”这三个词脑子里基本是一团浆糊。名字长得像主管口径听起来也像网上搜一圈有人说“做个算法备案就行”有人说“必须做大模型备案”还有人说“登记和备案是两码事”。结果就是产品要上线了法务问你要资质你才发现自己连该办哪个都没搞清楚。我先把这三个东西用一句话拆开你记住这个框架后面所有细节都能挂上去。算法备案管的是“你用算法向公众提供互联网信息服务”这件事。它依据的是《互联网信息服务算法推荐管理规定》核心逻辑是只要你的产品里用了推荐、排序、检索、生成合成等算法并且面向公众提供服务就需要在系统里填报算法信息。它不关心你的模型有多大关心的是“算法有没有在影响用户看到什么”。大模型登记管的是“你用的这个模型是不是已经备过案的上游模型”。它更像一个“接入登记”动作。如果你不是自己从头训模型而是调用已经通过备案的大模型API那你需要做的是登记——把你的产品信息、调用场景、接入方式报上去。可以理解为模型本身已经有“身份证”了你要登记的是“我用它做了什么”。大模型备案管的是“你自己训练或微调了一个大模型并且要对外提供服务”。这是三个里面最重的一个材料多、周期长、审核细。它要求你从模型架构、训练数据、安全评估、内容过滤、应急处置等维度做完整说明。简单说算法备案是“算法层面”大模型登记是“接入层面”大模型备案是“模型层面”。这三个资质不是互斥关系也不是随便选一个就行。实际业务里一个AI产品可能同时涉及多个。比如你做了一个AI写作工具底层调用的是某家已备案的大模型前端有推荐算法决定用户看到哪些模板那你就需要大模型登记因为你调了已备案模型 算法备案因为你有推荐和生成合成算法。如果你是自己微调了一个模型对外服务那大模型备案也跑不掉。我见过最典型的踩坑场景是团队做了个AI客服产品底层调的是某云厂商的模型产品经理觉得“模型是别人的我不用备案”结果上线前被渠道方要求提供算法备案号整个上线计划推迟了两个月。问题就出在把“模型备案”和“算法备案”混为一谈。所以这一章你先建立一个基本认知算法备案看的是你的产品行为大模型登记看的是你的模型来源大模型备案看的是你的模型主权。三个资质对应三种不同的责任边界不是三选一而是按业务实际情况组合。1.1 为什么这三个资质会被同时提出来这三个词之所以总被放在一起说是因为它们共同构成了当前AI产品合规上线的“资质三角”。从监管视角看一个AI产品要对外服务需要回答三个问题你用了什么算法你的模型从哪来模型本身安不安全算法备案回答第一个问题。它要求你把算法的基本原理、运行机制、应用场景、目的意图写清楚。很多人以为这只是填个表其实不是。算法备案的材料里有一项叫“算法安全自评估报告”需要你说明算法可能带来的风险以及你采取了什么措施。这个报告写得好不好直接决定备案能不能过。大模型登记回答第二个问题。它的逻辑是既然你的模型来自已经备案的上游那你的风险就相对可控只需要登记你的使用情况即可。但这里有个细节很多人忽略登记不是“自动通过”你仍然需要提交产品信息、调用场景、内容安全机制等材料。如果上游模型备案被撤销你的登记也会受影响。大模型备案回答第三个问题。这是最完整的一套审核要求你从训练数据来源、数据标注规则、模型架构、安全对齐、内容过滤、用户投诉处理等全链路做说明。周期通常以月计材料动辄几百页。我见过一个团队光“训练数据来源说明”就改了七版因为审核方要求每一类数据都要有合法来源证明。这三个资质放在一起本质上是在回答“你的AI产品凭什么可以安全地对公众提供服务”。不是走形式而是真的在查你的安全能力。1.2 不同产品形态对应的资质组合为了让你更直观地判断自己需要办哪些我整理了一个对照表。这张表是基于我实际接触过的项目经验总结的不是官方文件但基本能覆盖大多数场景。产品形态算法备案大模型登记大模型备案调用已备案大模型API无推荐算法视情况必须不需要调用已备案大模型API有推荐/排序算法必须必须不需要调用未备案模型API必须不可登记必须自己微调模型对外服务必须不需要必须自己从头训练模型对外服务必须不需要必须仅内部使用不对外服务不需要不需要不需要这张表里最容易被误判的是第一行和第二行。很多产品经理觉得“我只是调了个API没有算法”但实际上你的产品里只要有“猜你喜欢”“相关推荐”“搜索结果排序”这类功能就已经构成算法推荐服务算法备案就跑不掉。还有一个常见误区是“内部使用不用备案”。这个判断基本正确但“内部使用”的边界要小心。如果你的产品是给企业客户用的企业客户又拿它去服务自己的用户那你就不是内部使用了。我见过一个做AI合同审查的工具觉得自己是B端产品不用备案结果客户要求提供资质因为客户拿它给外部客户看合同。1.3 不办资质的实际后果很多人问“不办会怎样”。我直接说实际会遇到的情况不绕弯子。第一应用商店和渠道方会卡你。现在主流应用商店在上架审核时对AI类产品基本都会要求提供算法备案号或大模型备案号。没有的话直接驳回。你连上架都上不了后面的事都不用谈。第二合作方会要求你提供。如果你做的是B端产品大客户在采购流程里会要求你提供合规资质。没有资质连投标资格都没有。这不是监管直接罚你而是商业流程把你筛掉了。第三监管检查时会被要求整改。这个不用展开说做互联网产品的都懂。第四如果出了内容安全问题没有备案会让你的责任认定更被动。备案本质上是一种“我已经按要求做了安全措施”的证明。没有这个证明出了问题很难说清楚。我个人的经验是不要等到产品要上线了才去办。算法备案的周期通常在一到三个月大模型备案更长。如果你等到上线前才启动基本一定会延期。正确的做法是在产品立项阶段就把资质规划进去该准备的材料提前准备。2. 算法备案的实操拆解算法备案是三个资质里最常被要求、也最容易被低估的一个。很多人觉得它就是填个表实际上它的材料准备量不小而且审核口径在逐渐收紧。这一章我把算法备案的完整流程拆开讲包括系统入口、材料清单、填写要点和常见退回原因。2.1 算法备案的适用判断先判断你要不要办。根据《互联网信息服务算法推荐管理规定》以下五类算法需要备案生成合成类包括文本生成、图像生成、音频生成、视频生成等个性化推送类包括推荐、排序、个性化展示等排序精选类包括热搜、榜单、精选等检索过滤类包括搜索、筛选、排序等调度决策类包括派单、定价、资源分配等你对照一下自己的产品只要有其中任何一类并且面向公众提供互联网信息服务就需要备案。注意“面向公众”这个限定。如果你的产品只在公司内网用不对外那不需要。但只要对外哪怕是小范围公测也算。这里有个细节很多产品同时涉及多类算法。比如一个AI社区产品既有生成合成AI生成内容又有个性化推送推荐流还有检索过滤搜索。这种情况下你需要在备案系统里分别填报多个算法每个算法单独填一份信息。我建议的做法是先把产品里所有涉及算法的功能列出来然后按上述五类归类。归类完之后再判断哪些是“对用户产生实质影响”的。比如一个简单的按时间倒序排列通常不算个性化推送。但如果你根据用户行为调整了排序那就属于。2.2 备案系统的填报流程算法备案的入口是“互联网信息服务算法备案系统”。整个流程分四步注册账号、填报算法信息、提交安全自评估报告、等待审核。注册账号这一步没什么好说的用企业信息注册。需要注意的是填报主体必须是实际提供服务的公司主体不能用母公司或关联公司代替。我见过一个团队用集团名义填报结果被退回因为实际运营主体是子公司。填报算法信息是核心环节。系统里需要填的内容包括算法名称建议用“产品名算法类型”的格式比如“XX写作助手生成合成算法”算法类型从五类里选可以多选应用场景说明这个算法用在产品的哪个功能里算法基本原理用通俗语言说明算法怎么工作的不需要写代码但要让人看懂运行机制说明算法的输入、处理、输出过程目的意图说明你为什么用这个算法想达到什么效果数据来源说明算法用到的数据从哪来这里最容易出问题的是“算法基本原理”和“运行机制”。很多人写得太技术化堆了一堆术语审核人员看不懂直接退回。正确的写法是用“人话”解释。比如你写“基于Transformer架构的多头注意力机制”不如写“通过分析用户输入文本的语义特征生成符合语境的回复内容”。安全自评估报告是另一个重头。它要求你从算法安全、数据安全、用户权益保护等角度做自我评估。这份报告没有固定模板但通常需要包含以下内容算法可能带来的风险比如生成有害内容、加剧信息茧房、侵犯用户隐私等你采取的安全措施比如内容过滤、人工审核、用户举报机制等应急处置方案如果出现安全问题你怎么处理用户权益保护用户如何关闭算法推荐、如何投诉等我个人的经验是这份报告不要写得太空。审核人员看多了套话你写“我们高度重视用户权益”不如写“我们在产品设置页提供了关闭个性化推荐的开关关闭后推荐流按时间倒序展示”。具体措施比态度表述有用得多。2.3 材料准备中的高频退回原因我整理了几个实际项目中被退回最多的原因你提前避开能省很多时间。退回原因具体表现正确做法算法原理描述不清堆砌技术术语审核看不懂用通俗语言说明输入输出和处理逻辑应用场景不具体只写“用于内容推荐”没说在哪推荐写明具体功能模块和用户可见位置安全措施太笼统只写“有内容审核机制”写明审核方式、频率、责任人数据来源不明确只写“公开数据”写明具体来源和合法性依据主体信息不一致填报主体和实际运营主体不同用实际提供服务的公司主体填报除了这些还有一个容易被忽略的点算法备案填报的信息要和产品实际情况一致。我见过一个团队备案时写的是“仅用于内容推荐”结果产品里还有AI生成功能没报后来被检查时要求补充备案。所以填报前一定要把产品功能梳理完整不要漏报。2.4 备案后的持续义务算法备案不是一劳永逸的。拿到备案号之后你还有几件事要做。第一在产品显著位置公示备案号。通常是在关于页面或设置页面展示。这个公示不是可选项是规定动作。第二算法有重大变更时要更新备案。什么叫重大变更比如你从规则推荐换成了模型推荐或者应用场景发生了实质变化。如果只是调参通常不算。第三配合监管检查。备案之后监管可能会要求你提供算法运行情况说明。平时把算法相关的文档和记录整理好检查时就不会手忙脚乱。我个人的做法是把算法备案的相关材料放在一个共享文档里产品、法务、技术都能访问。每次产品功能有变化先判断是否影响备案信息如果有影响就及时更新。这样不会等到检查时才发现信息对不上。3. 大模型登记的关键细节大模型登记是三个资质里最“轻”的一个但轻不代表可以随便做。它的核心逻辑是你用的模型已经备案了你只需要登记你的使用情况。但实际操作中登记也有不少细节需要注意。3.1 什么情况下需要做登记判断标准很简单你调用了已经通过备案的大模型API并且对外提供服务就需要做登记。这里的关键词是“已经通过备案”。如果上游模型没有备案你没法做登记只能自己做备案。怎么确认上游模型是否备案通常模型提供方会在文档里说明自己的备案号。如果没有直接问他们的商务或法务。不要假设“大厂模型肯定备案了”我见过一些垂直领域的模型其实没有备案调用方以为有结果登记时才发现不行。还有一个细节如果你用的是开源模型自己部署那不属于“调用已备案模型”不能做登记。开源模型没有备案主体你要对外服务就得自己做备案。这一点很多人搞混以为开源模型可以随便用。开源指的是代码开放不代表合规资质自动获得。3.2 登记流程和材料大模型登记的入口和算法备案是同一个系统但填报的内容不同。登记需要填的信息包括产品信息产品名称、服务形式、上线时间模型信息模型名称、备案号、提供方调用方式API调用、私有化部署等应用场景模型在你的产品里承担什么功能内容安全机制你怎么确保模型输出安全这里最重要的是“内容安全机制”。登记的逻辑是模型本身已经备案了但你在使用过程中仍然要承担内容安全责任。所以你需要说明自己做了什么来确保输出安全。比如你有没有做输出过滤、有没有人工审核、有没有用户举报入口。我见过一个团队登记时只写了“调用XX模型API”内容安全机制那栏空着结果被退回要求补充。补充的时候写“我们信任模型提供方的安全能力”又被退回。正确的写法是写你自己的措施比如“我们在API返回结果后增加了敏感词过滤层对生成内容进行二次校验”。3.3 登记与备案的关系这里要特别说清楚一个容易混淆的点大模型登记不能替代算法备案。很多人以为“我做了大模型登记就不用做算法备案了”这是错的。大模型登记管的是“模型来源”算法备案管的是“算法行为”。如果你的产品里只有模型调用没有推荐、排序、检索等算法那可能只需要登记。但只要你有这些算法行为算法备案仍然要做。我通常建议的做法是先判断产品涉及哪些算法类型该做算法备案的做算法备案同时判断模型来源该做登记的做登记。两个动作可以并行不冲突。还有一个细节如果你的上游模型备案被撤销了你的登记也会失效。所以选择模型提供方时要关注他们的备案状态是否稳定。我一般建议选主流的大模型提供方备案状态相对可靠。3.4 登记后的注意事项登记完成后你会拿到一个登记号。这个号也需要在产品里公示。公示的位置和算法备案号类似通常在关于页面。如果更换了模型提供方需要更新登记。比如你原来用A模型后来换成B模型那登记信息要改。如果只是模型版本升级但备案主体没变通常不需要更新。还有一点登记信息要和实际调用情况一致。我见过一个团队登记时写的是“仅用于文本生成”结果产品里还用模型做了图像理解被检查时要求补充说明。所以登记前把模型的所有用途梳理清楚不要漏报。4. 大模型备案的完整路径大模型备案是三个里面最重的。如果你的产品是自己训练或微调模型对外服务这个备案绕不开。它的周期长、材料多、审核细需要提前规划。4.1 备案的触发条件什么情况下必须做大模型备案简单说你自己训练了一个模型或者你在开源模型基础上做了实质性微调并且对外提供服务。这里的关键是“实质性微调”。如果你只是调了调提示词那不算微调模型本身还是上游的做登记就行。但如果你用了自己的数据对模型参数做了更新那就属于微调需要备案。我见过一个团队用开源模型做了领域微调觉得“模型底座是开源的不用备案”结果上线后被要求补办。判断标准不是模型底座是否开源而是你是否对模型做了实质性修改并对外服务。还有一个边界情况如果你微调后的模型只在内部使用不对外那不需要备案。但只要对外哪怕是通过API提供给其他企业用也需要。4.2 备案材料清单大模型备案的材料比算法备案多得多。我按实际项目经验整理了一份清单供你参考。材料类别具体内容准备难度模型基本信息模型名称、架构、参数规模、训练框架低训练数据说明数据来源、规模、标注规则、合法性证明高安全评估报告模型安全能力、风险点、防护措施高内容过滤机制输入输出过滤规则、人工审核流程中应急处置方案安全事件响应流程、责任人中用户协议和隐私政策与模型服务相关的条款低测试报告模型性能、安全测试结果中这里面最耗时间的是“训练数据说明”和“安全评估报告”。训练数据说明要求你交代每一类数据的来源和合法性。如果你用了爬取的数据需要说明爬取范围、是否遵守robots协议、是否涉及个人信息。如果用了第三方数据集需要提供授权证明。安全评估报告要求你从多个维度评估模型安全包括但不限于生成有害内容的风险、偏见歧视风险、隐私泄露风险、被滥用风险。每个风险都要说明你采取了什么措施。这份报告通常需要技术、法务、产品一起写不是一个人能搞定的。4.3 备案周期和节奏把控大模型备案的周期通常在三到六个月具体取决于材料质量和审核进度。我见过最快的两个月最慢的八个月。影响周期的因素主要有两个材料是否一次过、是否需要补充测试。材料一次过的关键是“具体”。审核人员最怕看到笼统的表述。你写“我们采取了安全措施”不如写“我们在模型输出层部署了敏感词过滤覆盖XX类敏感词过滤准确率XX%”。数字和细节能大幅提高通过率。如果需要补充测试周期会拉长。补充测试通常是审核方要求你对模型进行特定场景的安全测试比如生成特定类型内容时的表现。这个环节需要技术团队配合提前准备好测试环境。我的建议是如果你确定要做大模型备案在产品立项阶段就启动材料准备。不要等模型训练完了才开始那样时间会很紧。训练数据和测试报告可以提前准备安全评估报告可以在模型基本定型后开始写。4.4 备案后的持续合规拿到大模型备案号之后事情还没完。你需要做几件事第一公示备案号。在产品显著位置展示。第二模型有重大更新时更新备案。什么叫重大更新比如模型架构变了、训练数据规模大幅增加、应用场景扩展了。如果只是小版本迭代通常不需要。第三持续做内容安全监测。备案不是终点监管会持续关注你的模型输出。建议建立日常监测机制对模型生成内容做抽样检查。第四配合监管抽查。监管可能会要求你提供模型运行日志、安全测试记录等。平时把这些文档整理好抽查时就不会被动。我个人的经验是大模型备案的合规成本主要在前期材料准备和后期持续监测。前期把材料做扎实后期把监测做到位整体就不会太吃力。最怕的是前期糊弄后期被要求反复补充反而更耗时间。5. 三个资质的协同规划单独看每个资质都有各自的流程但实际项目中三个资质往往需要协同推进。这一章我讲一下怎么把三个资质放在一张时间表里规划避免互相等待。5.1 资质组合的判断逻辑先判断你的产品需要哪些资质。判断逻辑分三步第一步看模型来源。自己训练或微调需要大模型备案调用已备案模型需要大模型登记。第二步看算法行为。有推荐、排序、检索、生成合成等算法需要算法备案。第三步看服务对象。只对内不对外通常不需要对外服务以上判断都适用。这三步走完你就能确定自己的资质组合。我建议把这个判断做成一个检查清单产品每次有重大变化时重新过一遍。5.2 时间线的合理安排三个资质的周期不同算法备案通常一到三个月大模型登记通常一个月左右大模型备案三到六个月。如果都需要办时间线怎么排我的建议是大模型备案最先启动因为周期最长。算法备案和大模型登记可以并行因为它们共用同一个系统材料有部分重叠。具体节奏可以这样安排第1个月梳理产品功能和模型来源确定资质组合开始准备大模型备案材料第2个月提交算法备案和大模型登记同时继续完善大模型备案材料第3个月跟进算法备案和登记审核提交大模型备案第4到6个月跟进大模型备案审核处理补充材料这个节奏是理想情况实际会有波动。关键是不要等到产品要上线了才启动那样一定会延期。5.3 材料复用的技巧三个资质的材料有重叠部分可以复用。比如产品介绍、安全机制说明、用户权益保护措施这些内容在三个资质里都需要。我通常的做法是先写一份“合规基础文档”把产品信息、安全措施、用户权益等内容写清楚然后根据不同资质的要求裁剪。这样做的另一个好处是信息一致。如果三个资质分别写容易出现表述不一致的情况审核时可能被质疑。用同一份基础文档裁剪能保证口径统一。5.4 常见协同问题实际推进中最常见的问题是“等”。等算法备案下来再做大模型登记等登记下来再做备案结果时间全浪费在等待上。正确的做法是并行推进材料准备阶段就同步做。另一个问题是“漏”。产品功能梳理不完整导致某个资质漏报。比如只报了生成合成算法漏了推荐算法。避免的方法是做一份完整的产品功能清单逐项对照算法类型。还有一个问题是“变”。产品在资质办理过程中发生了功能变化导致已提交的材料和实际不符。这种情况需要及时更新材料不要等到审核问询时才改。6. 实操中的避坑经验这一章我分享一些实际项目中踩过的坑和总结的技巧。这些内容在官方文档里看不到但实际做的时候很关键。6.1 材料写作的实用技巧写备案材料不是写技术文档也不是写公关稿。它的目标是让审核人员快速理解你的算法和模型并判断风险可控。基于这个目标我总结了几条写作技巧。第一用“输入-处理-输出”框架描述算法。不管你用什么技术都可以套这个框架。输入是什么处理逻辑是什么输出是什么。审核人员一看就懂。第二安全措施要具体到可验证。不要写“我们有内容审核”要写“我们在输出层部署了关键词过滤覆盖XX个敏感词同时有人工审核团队审核响应时间在XX分钟内”。第三风险描述要诚实。不要写“我们的算法没有风险”这不现实。写“我们的算法可能存在XX风险我们采取了XX措施来降低风险”。诚实描述反而更容易通过。第四数据来源要可追溯。每一类数据都要说明来源和合法性依据。如果是公开数据集写明数据集名称和获取方式。如果是自有数据写明收集方式和用户授权情况。6.2 与审核方沟通的注意事项审核过程中可能会有问询怎么回复也有讲究。第一回复要及时。问询通常有时间要求拖太久会影响进度。第二回复要针对问题。不要答非所问也不要过度解释。问什么答什么简洁清楚。第三补充材料要标注清楚。如果需要补充材料在材料里标注“补充材料-对应问询第X条”方便审核人员对照。第四不确定的先问清楚。如果对问询内容不理解可以先通过系统或电话确认不要凭猜测回复。6.3 产品变更时的资质维护产品上线后会有迭代资质信息也要跟着维护。我建议建立一个简单的变更评估流程产品每次发版前评估是否影响资质信息如果影响判断是“重大变更”还是“一般变更”重大变更需要更新备案一般变更记录在案即可更新备案时同步更新公示信息这个流程不需要很复杂一个检查清单就够了。关键是养成习惯不要等到检查时才发现信息对不上。6.4 常见问题速查最后整理一个常见问题速查表方便你快速定位。问题可能原因解决方向算法备案被退回算法原理描述不清用通俗语言重写突出输入输出大模型登记被退回内容安全机制缺失补充自己的过滤和审核措施大模型备案周期长材料需要反复补充提前准备材料写具体渠道方要求提供资质产品涉及AI服务确认资质组合尽快办理产品变更后资质失效未及时更新备案建立变更评估流程不确定是否需要备案对规则理解不清对照五类算法和模型来源判断这些问题的共同点是提前规划就能避免。最怕的是产品要上线了才发现缺资质那时候再急也没用。我个人在实际操作中的体会是合规资质这件事早做比晚做好做扎实比做快好。材料准备的过程其实也是梳理产品安全能力的过程认真做一遍对产品本身也有好处。后续如果产品要扩展新功能可以在这个基础上快速判断是否需要更新资质不会每次都从头来。