1. 两套备案体系到底在管什么先把结论摆在前面大模型备案和互联网算法备案管的根本不是同一件事虽然它们经常被放在一起讨论甚至很多团队在实操中会把材料搞混。我接触过不少做AI产品的团队有做对话助手的有做推荐系统的也有做图像生成的。几乎每一家在准备合规材料的时候都会问同一个问题“我们到底要不要做大模型备案算法备案是不是也得做两个都做的话材料能不能复用”这个问题的答案取决于你的产品形态、技术路径和业务场景。我先把两套体系的核心定位拆开讲。大模型备案全称通常指向“生成式人工智能服务备案”它的监管对象是面向公众提供生成式AI服务的产品。关键词是“生成式”和“面向公众”。你的产品如果能让用户输入一段话、生成一段文字或图片并且这个服务是对外开放的那大概率就落在这个范围里。它关注的是模型本身的安全性、生成内容的可控性、训练数据的合规性以及服务上线后的持续管理能力。互联网算法备案全称是“互联网信息服务算法备案”它的监管对象更宽泛指的是利用算法技术向用户提供互联网信息服务的产品。这里的关键词是“算法技术”和“信息服务”。推荐算法、排序算法、检索算法、调度决策算法甚至一些简单的个性化推送逻辑都可能被纳入这个范畴。它关注的是算法机制的可解释性、是否存在歧视或偏见、是否对用户权益造成损害、是否影响舆论生态。用一个不太严谨但很好理解的类比大模型备案像是给“会自己写东西的机器”上牌照算法备案像是给“会自己决定给你看什么的系统”上牌照。前者管的是生成能力后者管的是分发和决策能力。但现实情况是很多产品两者都占。比如一个AI写作助手它既用了大模型来生成内容又用了推荐算法来决定给用户展示哪些模板或历史记录。这种情况下两套备案可能都需要考虑。我见过最典型的误区是团队觉得“我们用的是开源模型没有自己训练应该不用备案吧”这个判断是不准确的。备案的核心不是你有没有训练模型而是你有没有面向公众提供服务。你用开源模型做了一层封装接入了API用户能直接使用那这个服务就是你提供的责任就在你身上。另一个常见误区是“我们只是内部用不对公众开放应该不用管。”这个判断相对安全但要注意“内部”的边界。如果你们的“内部”是一个几百人的公司那可能还好如果是一个面向大量外部用户的“内测”那就很难说清楚。监管看的是实质不是名义。还有一个容易被忽略的点API调用方和API提供方的责任划分。如果你是通过API调用别家的大模型能力然后包装成自己的产品那备案责任怎么分一般来说提供API的那一方需要完成模型侧的备案而你作为服务提供方需要完成服务侧的备案。但具体到每个地方的通管局执行口径可能有差异这个后面会详细讲。2. 大模型备案的核心门槛与材料准备2.1 什么情况下必须做大模型备案先划一条线面向境内公众提供生成式人工智能服务且服务具有舆论属性或社会动员能力的需要做备案。这句话里的每一个限定词都很关键。“面向境内公众”意味着你的服务对象是中国大陆的用户。如果你的产品只面向海外用户那不在这个体系的管辖范围内。但要注意如果海外用户里混着境内用户能访问到的通道那就不好说了。“生成式人工智能服务”指的是能生成文本、图片、音频、视频等内容的服务。纯粹的判别式AI比如只做分类、只做打分、只做检测的一般不落在这个范围里。但如果你用判别式模型做了一个“AI评分”然后生成一段评语那就沾上生成了。“具有舆论属性或社会动员能力”这个限定词在实际执行中弹性比较大。理论上一个只有几十个用户的小工具舆论属性很弱。但实际操作中很多地方的通管局会要求只要是对公众开放的生成式AI服务都来做备案。所以我的建议是不要自己判断要不要做直接去问当地通管局。问的成本很低不问的代价可能很高。2.2 备案材料里最容易踩坑的几项大模型备案的材料清单在网上能搜到很多版本但真正实操过的人都知道材料不是重点重点是材料背后的实质工作有没有做到位。安全评估报告是核心中的核心。这份报告不是让你写一篇作文而是要求你真正做过安全测试、有测试记录、有整改闭环。我见过团队临时补材料把测试报告写得漂漂亮亮但一问测试环境怎么搭的、测试用例怎么设计的就露馅了。通管局的人不一定懂技术但他们懂逻辑。你的报告里如果只有结论没有过程很容易被退回。训练数据来源说明是另一个高频退回点。你需要说清楚训练数据从哪来、有没有授权、有没有做清洗、有没有做去重、有没有做敏感内容过滤。如果你用的是开源数据集要说明数据集名称和来源如果你用的是自采数据要说明采集方式和授权情况如果你用的是用户生成内容要说明有没有获得用户授权。这里最忌讳的是含糊其辞写“来自公开渠道”这种话基本等于没写。模型架构和参数说明不需要你公开全部技术细节但需要说清楚模型的基本类型、参数量级、训练方式、推理方式。如果你是调用第三方API那就说明调用的是哪家、什么版本、有没有做二次微调。这里有一个实操心得如果你调用的是已经完成备案的第三方大模型你的备案材料可以简化很多但你需要提供第三方的备案证明和合作协议。内容安全管理制度是很多技术团队容易忽视的。这份制度不是写给通管局看的是写给你自己团队看的。它应该包括内容审核流程、违规内容处置流程、用户投诉处理流程、应急响应流程、定期安全评估机制。我见过一个团队制度写得很好但问他们“如果用户生成了违规内容你们多久能发现、多久能处置”回答是“我们人力有限可能得等用户举报”。这种回答在备案审核中是很危险的。2.3 备案流程的时间线和实操节奏大模型备案的流程大致是准备材料 → 提交申请 → 初审 → 技术评测 → 复审 → 公示。听起来简单但每一步都有坑。准备材料阶段我的建议是至少留出一个月。不是材料写一个月而是把材料里要求的事情做一个月。比如安全测试你得真的搭环境、真的跑用例、真的记录结果。比如数据清洗你得真的做一遍、真的留下日志。提交申请阶段要注意各地通管局的受理窗口和材料格式要求可能不一样。有的地方要求纸质材料加电子版有的地方只收电子版。有的地方要求法人签字有的地方要求法人签字加盖章。这些细节看起来小但一旦搞错就得重新排队。技术评测阶段是最关键的。评测机构会从多个维度测试你的模型包括但不限于生成内容的准确性、安全性、鲁棒性、拒答能力。我见过一个团队模型能力很强但拒答能力很弱用户稍微绕一下就能让它生成不该生成的内容。这种在评测中基本过不了。复审和公示阶段相对可控但要注意公示期间如果有异议可能会被重新审查。所以公示前最好自己先做一轮舆情监测看看有没有明显的负面反馈。3. 互联网算法备案的适用范围与操作细节3.1 算法备案的触发条件比你想的宽很多人以为只有推荐算法才需要做算法备案这个理解是不完整的。根据《互联网信息服务算法推荐管理规定》需要备案的算法包括但不限于生成合成类、个性化推送类、排序精选类、检索过滤类、调度决策类。生成合成类算法指的是能自动生成或合成内容的算法。这个和大模型备案有重叠但算法备案更侧重于算法的机制和逻辑而不是生成内容的安全性。个性化推送类算法就是常见的“猜你喜欢”。只要你的产品里有“根据用户行为推荐内容”的功能不管这个推荐逻辑是复杂的深度学习模型还是简单的规则引擎都可能需要备案。排序精选类算法指的是对信息进行排序或精选的算法。比如热搜榜、排行榜、精选列表这些背后都有排序逻辑都可能需要备案。检索过滤类算法指的是搜索引擎、站内搜索、内容过滤等算法。你做一个搜索功能背后有相关性排序和结果过滤这就落在这个范围里。调度决策类算法指的是用于资源调度、任务分配、路径规划等决策的算法。比如外卖平台的派单算法、网约车的派单算法都属于这一类。我见过一个做内容社区的团队觉得自己没有推荐算法因为“我们就是按时间倒序排列”。但他们的“热门”标签下有一个按互动量排序的列表这个排序逻辑就构成了排序精选类算法需要备案。所以不要用“我们算法很简单”来安慰自己监管看的是功能实质不是技术复杂度。3.2 算法备案的材料重点和常见退回原因算法备案的材料相对大模型备案要轻一些但有几个地方特别容易出问题。算法基本原理和运行机制说明是核心材料。这份说明不需要你公开源代码但需要你用自然语言把算法的逻辑讲清楚。我见过很多团队在这里写得太技术化满篇公式和术语审核人员看不懂直接退回。正确的做法是用“输入-处理-输出”的框架来描述配合一个具体的例子。比如“当用户打开首页时系统会读取用户的历史点击记录计算每个候选内容的匹配分数按分数从高到低排序展示前20条。”算法应用场景和目的说明要具体。不要写“用于提升用户体验”这种空话要写“用于在首页信息流中向用户展示可能感兴趣的内容目的是提高内容点击率和用户停留时长。”目的越具体审核越容易通过。算法对用户权益的影响评估是很多团队会忽略的。你需要说明这个算法可能对用户产生哪些影响比如是否会导致信息茧房、是否会影响用户的知情权和选择权、是否有歧视性后果。然后说明你采取了哪些措施来缓解这些影响。这里最忌讳的是写“没有影响”因为任何算法都有影响写“没有影响”等于没做评估。用户申诉和关闭选项是硬性要求。如果你的产品有个性化推荐功能必须提供关闭选项。如果没有备案基本过不了。我见过一个团队产品上线两年了用户协议里没有提到算法推荐设置里也没有关闭按钮后来补这个功能花了不少时间。3.3 算法备案的变更和注销流程算法备案不是一劳永逸的。如果你的算法发生了重大变更比如从规则引擎换成了深度学习模型或者推荐逻辑发生了本质变化需要做变更备案。如果算法下线了需要做注销备案。变更备案的触发条件各地执行口径不太一样。我的经验是如果算法的输入、输出、核心逻辑、应用场景中任何一个发生了实质性变化就应该做变更。如果只是调参、换模型版本、优化性能一般不需要。但为了保险建议在变更前咨询当地通管局。注销备案相对简单但要注意注销后如果重新上线类似算法需要重新备案不能沿用原来的备案号。4. 两套备案的交叉地带与实操策略4.1 什么情况下两套备案都要做最典型的情况是你的产品既用了生成式AI来生成内容又用了推荐算法来分发内容。比如一个AI写作社区用户可以用AI生成文章同时首页有推荐流展示其他用户的文章。这种情况下生成式AI服务需要做大模型备案推荐算法需要做算法备案。还有一种情况是你的产品核心功能是生成但生成结果的展示方式涉及排序或推荐。比如一个AI绘画工具用户输入提示词生成图片同时工具会推荐“相似风格的作品”。这个推荐功能如果构成了个性化推送就需要算法备案。我见过一个团队产品是一个AI对话助手用户可以和AI聊天同时首页有一个“热门对话”列表。他们只做了大模型备案没有做算法备案。后来被提醒“热门对话”列表的排序逻辑属于排序精选类算法需要补做算法备案。补做的时候发现因为产品已经上线很多材料需要追溯比上线前做要麻烦得多。4.2 材料复用的可能与边界两套备案的材料有一些可以复用的部分比如公司资质、产品介绍、安全管理制度。但核心材料不能复用。大模型备案的安全评估报告侧重于生成内容的安全性。算法备案的算法机制说明侧重于算法逻辑的透明性。这两份材料的视角和重点完全不同不能互相替代。训练数据说明在大模型备案里是重点在算法备案里通常不是必须的除非你的算法本身涉及对训练数据的使用。内容安全管理制度在两套备案里都需要但侧重点不同。大模型备案更关注生成内容的审核和处置算法备案更关注算法结果的公平性和用户权益保护。我的建议是如果两套备案都要做先做大模型备案再做算法备案。因为大模型备案的周期更长、材料更重先做重的后面做轻的会轻松一些。而且大模型备案过程中建立的安全管理制度和测试流程可以为算法备案提供基础。4.3 备案后的持续合规工作备案通过不是终点而是起点。两套备案都有持续合规的要求。大模型备案后需要定期做安全评估一般是一年一次。如果模型有重大更新需要做变更备案。如果发现生成违规内容需要及时处置并报告。算法备案后需要持续监测算法运行效果定期评估算法对用户权益的影响。如果算法有重大变更需要做变更备案。如果收到用户投诉需要及时处理并记录。我见过一些团队备案通过后就把材料锁进柜子再也不看了。等到下一次检查或者用户投诉的时候才发现制度没执行、记录没留存、流程没落地。这种“备案归备案、运营归运营”的做法风险很大。实操心得把备案要求融入日常研发流程。比如每次模型更新前先跑一遍安全测试用例每次算法调整前先评估对用户权益的影响每次上线新功能前先检查是否需要做变更备案。这样比事后补材料要轻松得多。5. 常见问题速查与避坑指南5.1 备案相关高频问题对照表问题常见误解实际情况用开源模型要不要备案开源模型不用备案面向公众提供服务就需要和模型来源无关只做内部使用要不要备案内部使用不用备案取决于“内部”的边界大规模内测可能被视为面向公众API调用方要不要备案谁提供API谁备案服务提供方也需要备案责任可能共担算法很简单要不要备案简单算法不用备案监管看功能实质不看技术复杂度备案后要不要年检备案一次管终身需要定期安全评估和变更备案两套备案能不能一起做可以同时申请建议先做大模型备案再做算法备案备案材料能不能复用材料可以通用核心材料视角不同不能互相替代备案不通过能不能重来不通过就完了可以整改后重新提交但周期会拉长5.2 实操中最容易踩的五个坑第一个坑低估准备时间。很多团队觉得备案就是写材料两周就能搞定。实际上从准备到通过大模型备案通常需要两到三个月算法备案通常需要一到两个月。如果材料被退回时间会更长。所以产品上线前至少提前三个月启动备案准备。第二个坑材料写得太技术。审核人员不一定是技术背景你写满篇Transformer架构、注意力机制、损失函数他们看不懂就容易退回。正确的做法是用业务语言描述技术逻辑配合具体例子。第三个坑忽视用户权益保护。算法备案特别关注用户权益如果你的产品没有提供关闭个性化推荐的选项没有用户申诉渠道没有算法说明页面基本过不了。这些功能需要在产品设计阶段就考虑进去。第四个坑安全测试走过场。大模型备案的安全测试不是形式评测机构会真的跑用例。如果你的模型拒答能力弱、容易被诱导、生成内容不可控评测就过不了。建议在提交备案前自己先做一轮红队测试。第五个坑备案后不维护。备案通过后如果模型更新了、算法调整了、产品功能变了没有及时做变更备案被检查到会有风险。建议指定专人负责备案维护每季度检查一次是否有需要变更的事项。5.3 不同产品形态的备案策略建议纯生成类产品比如AI写作、AI绘画、AI对话重点做大模型备案。如果产品内有任何形式的推荐或排序功能补充算法备案。纯推荐类产品比如内容社区、电商平台、信息流应用重点做算法备案。如果产品内用了生成式AI来生成推荐理由或摘要补充大模型备案。混合类产品比如AI社交、AI教育、AI客服两套备案都要做。建议先做大模型备案再做算法备案材料准备上可以统筹安排。工具类产品比如AI翻译、AI摘要、AI代码助手如果只是单次调用、不涉及内容分发通常只需要大模型备案。但如果工具有历史记录、有推荐模板、有排序展示就需要考虑算法备案。企业服务类产品如果只面向企业客户、不面向公众备案要求相对宽松。但要注意“企业客户”的终端用户如果也是公众那可能还是落在大模型备案的范围里。6. 从备案要求反推产品设计6.1 把合规做进产品架构里备案不是产品做完之后贴上去的标签而是应该在产品设计阶段就考虑进去的约束条件。我见过太多团队产品上线了才想起来备案然后发现要改架构、加功能、补流程成本很高。内容审核模块应该作为基础能力内置。不管是生成内容还是推荐内容都需要有审核机制。审核可以是机器审核加人工审核可以是前置审核加后置审核但必须有。而且审核记录要留存备案和检查的时候要用。用户控制选项应该在产品设计时就规划好。个性化推荐要有开关算法说明要有入口用户申诉要有渠道。这些不是额外功能是合规要求。数据管理模块要能支持备案材料的需求。训练数据来源、清洗记录、授权情况这些信息要在数据管理系统中留痕。不要等到备案的时候才去翻邮件、找合同。日志和监控模块要能支持持续合规。生成内容的日志、算法运行的日志、用户投诉的日志这些都要有记录、可查询、可导出。6.2 备案材料准备的实操清单大模型备案材料清单备案申请表营业执照和法人身份证明安全评估报告训练数据来源和清洗说明模型架构和参数说明内容安全管理制度用户协议和隐私政策第三方API调用证明如适用其他通管局要求的材料算法备案材料清单备案申请表营业执照和法人身份证明算法基本原理和运行机制说明算法应用场景和目的说明算法对用户权益的影响评估用户申诉和关闭选项说明安全管理制度其他通管局要求的材料实操建议在准备材料之前先给当地通管局打个电话或者去窗口咨询一次。问清楚材料清单、格式要求、受理时间、审核周期。这个动作花不了多少时间但能避免很多返工。6.3 备案时间线的合理规划假设你的产品计划在2026年6月上线那么备案时间线应该这样规划2026年1月启动备案准备确定备案类型咨询当地通管局收集材料。2026年2月完成安全测试和算法评估整理训练数据说明编写安全管理制度。2026年3月提交大模型备案申请同步准备算法备案材料。2026年4月配合技术评测根据反馈整改。2026年5月大模型备案公示提交算法备案申请。2026年6月两套备案完成产品上线。这个时间线是理想情况实际可能会有延迟。所以建议至少留出半年的缓冲期。7. 一些来自实操的经验之谈备案这件事说难不难说简单也不简单。难的是它涉及技术、法务、产品、运营多个部门协调成本高。简单的是只要你真的把该做的事情做了材料只是把做过的事情写出来。我见过最顺利的团队是那种在产品设计阶段就把合规要求考虑进去的团队。他们的安全测试是研发流程的一部分用户权益保护是产品设计的一部分数据管理是日常运营的一部分。备案的时候只是把这些日常工作的记录整理出来很轻松就过了。我见过最痛苦的团队是那种产品上线两年了才想起来备案的团队。他们要补测试、补制度、补功能、补记录还要面对可能的下架风险。补的过程中发现很多历史数据找不到了很多流程没有留痕很多功能需要重构。所以我的核心建议是不要把备案当成一个项目来做要把它当成产品能力的一部分来建设。备案的要求本质上也是产品安全、用户权益保护、数据治理的要求。这些能力建好了不仅备案轻松产品本身也更健康。还有一个实操细节和当地通管局保持沟通。备案政策在执行层面有很多细节不同地方的口径可能不一样。定期关注通管局的官网通知有问题及时咨询比闭门造车要高效得多。最后分享一个我自己的教训有一次帮一个团队准备算法备案材料算法机制说明写得很详细但忽略了“用户权益影响评估”这一项。提交后被退回要求补充。补充的时候发现因为产品设计时没有考虑用户关闭选项需要临时加功能耽误了两周。从那以后我每次做备案咨询第一件事就是问“你们的用户能不能关掉推荐有没有申诉渠道”这两个问题如果答案是“没有”那就得先补产品功能再谈备案。备案不是终点是产品合规运营的起点。把该做的事情做到位后面的路会越走越顺。
大模型备案与算法备案：核心区别、实操要点与避坑指南
1. 两套备案体系到底在管什么先把结论摆在前面大模型备案和互联网算法备案管的根本不是同一件事虽然它们经常被放在一起讨论甚至很多团队在实操中会把材料搞混。我接触过不少做AI产品的团队有做对话助手的有做推荐系统的也有做图像生成的。几乎每一家在准备合规材料的时候都会问同一个问题“我们到底要不要做大模型备案算法备案是不是也得做两个都做的话材料能不能复用”这个问题的答案取决于你的产品形态、技术路径和业务场景。我先把两套体系的核心定位拆开讲。大模型备案全称通常指向“生成式人工智能服务备案”它的监管对象是面向公众提供生成式AI服务的产品。关键词是“生成式”和“面向公众”。你的产品如果能让用户输入一段话、生成一段文字或图片并且这个服务是对外开放的那大概率就落在这个范围里。它关注的是模型本身的安全性、生成内容的可控性、训练数据的合规性以及服务上线后的持续管理能力。互联网算法备案全称是“互联网信息服务算法备案”它的监管对象更宽泛指的是利用算法技术向用户提供互联网信息服务的产品。这里的关键词是“算法技术”和“信息服务”。推荐算法、排序算法、检索算法、调度决策算法甚至一些简单的个性化推送逻辑都可能被纳入这个范畴。它关注的是算法机制的可解释性、是否存在歧视或偏见、是否对用户权益造成损害、是否影响舆论生态。用一个不太严谨但很好理解的类比大模型备案像是给“会自己写东西的机器”上牌照算法备案像是给“会自己决定给你看什么的系统”上牌照。前者管的是生成能力后者管的是分发和决策能力。但现实情况是很多产品两者都占。比如一个AI写作助手它既用了大模型来生成内容又用了推荐算法来决定给用户展示哪些模板或历史记录。这种情况下两套备案可能都需要考虑。我见过最典型的误区是团队觉得“我们用的是开源模型没有自己训练应该不用备案吧”这个判断是不准确的。备案的核心不是你有没有训练模型而是你有没有面向公众提供服务。你用开源模型做了一层封装接入了API用户能直接使用那这个服务就是你提供的责任就在你身上。另一个常见误区是“我们只是内部用不对公众开放应该不用管。”这个判断相对安全但要注意“内部”的边界。如果你们的“内部”是一个几百人的公司那可能还好如果是一个面向大量外部用户的“内测”那就很难说清楚。监管看的是实质不是名义。还有一个容易被忽略的点API调用方和API提供方的责任划分。如果你是通过API调用别家的大模型能力然后包装成自己的产品那备案责任怎么分一般来说提供API的那一方需要完成模型侧的备案而你作为服务提供方需要完成服务侧的备案。但具体到每个地方的通管局执行口径可能有差异这个后面会详细讲。2. 大模型备案的核心门槛与材料准备2.1 什么情况下必须做大模型备案先划一条线面向境内公众提供生成式人工智能服务且服务具有舆论属性或社会动员能力的需要做备案。这句话里的每一个限定词都很关键。“面向境内公众”意味着你的服务对象是中国大陆的用户。如果你的产品只面向海外用户那不在这个体系的管辖范围内。但要注意如果海外用户里混着境内用户能访问到的通道那就不好说了。“生成式人工智能服务”指的是能生成文本、图片、音频、视频等内容的服务。纯粹的判别式AI比如只做分类、只做打分、只做检测的一般不落在这个范围里。但如果你用判别式模型做了一个“AI评分”然后生成一段评语那就沾上生成了。“具有舆论属性或社会动员能力”这个限定词在实际执行中弹性比较大。理论上一个只有几十个用户的小工具舆论属性很弱。但实际操作中很多地方的通管局会要求只要是对公众开放的生成式AI服务都来做备案。所以我的建议是不要自己判断要不要做直接去问当地通管局。问的成本很低不问的代价可能很高。2.2 备案材料里最容易踩坑的几项大模型备案的材料清单在网上能搜到很多版本但真正实操过的人都知道材料不是重点重点是材料背后的实质工作有没有做到位。安全评估报告是核心中的核心。这份报告不是让你写一篇作文而是要求你真正做过安全测试、有测试记录、有整改闭环。我见过团队临时补材料把测试报告写得漂漂亮亮但一问测试环境怎么搭的、测试用例怎么设计的就露馅了。通管局的人不一定懂技术但他们懂逻辑。你的报告里如果只有结论没有过程很容易被退回。训练数据来源说明是另一个高频退回点。你需要说清楚训练数据从哪来、有没有授权、有没有做清洗、有没有做去重、有没有做敏感内容过滤。如果你用的是开源数据集要说明数据集名称和来源如果你用的是自采数据要说明采集方式和授权情况如果你用的是用户生成内容要说明有没有获得用户授权。这里最忌讳的是含糊其辞写“来自公开渠道”这种话基本等于没写。模型架构和参数说明不需要你公开全部技术细节但需要说清楚模型的基本类型、参数量级、训练方式、推理方式。如果你是调用第三方API那就说明调用的是哪家、什么版本、有没有做二次微调。这里有一个实操心得如果你调用的是已经完成备案的第三方大模型你的备案材料可以简化很多但你需要提供第三方的备案证明和合作协议。内容安全管理制度是很多技术团队容易忽视的。这份制度不是写给通管局看的是写给你自己团队看的。它应该包括内容审核流程、违规内容处置流程、用户投诉处理流程、应急响应流程、定期安全评估机制。我见过一个团队制度写得很好但问他们“如果用户生成了违规内容你们多久能发现、多久能处置”回答是“我们人力有限可能得等用户举报”。这种回答在备案审核中是很危险的。2.3 备案流程的时间线和实操节奏大模型备案的流程大致是准备材料 → 提交申请 → 初审 → 技术评测 → 复审 → 公示。听起来简单但每一步都有坑。准备材料阶段我的建议是至少留出一个月。不是材料写一个月而是把材料里要求的事情做一个月。比如安全测试你得真的搭环境、真的跑用例、真的记录结果。比如数据清洗你得真的做一遍、真的留下日志。提交申请阶段要注意各地通管局的受理窗口和材料格式要求可能不一样。有的地方要求纸质材料加电子版有的地方只收电子版。有的地方要求法人签字有的地方要求法人签字加盖章。这些细节看起来小但一旦搞错就得重新排队。技术评测阶段是最关键的。评测机构会从多个维度测试你的模型包括但不限于生成内容的准确性、安全性、鲁棒性、拒答能力。我见过一个团队模型能力很强但拒答能力很弱用户稍微绕一下就能让它生成不该生成的内容。这种在评测中基本过不了。复审和公示阶段相对可控但要注意公示期间如果有异议可能会被重新审查。所以公示前最好自己先做一轮舆情监测看看有没有明显的负面反馈。3. 互联网算法备案的适用范围与操作细节3.1 算法备案的触发条件比你想的宽很多人以为只有推荐算法才需要做算法备案这个理解是不完整的。根据《互联网信息服务算法推荐管理规定》需要备案的算法包括但不限于生成合成类、个性化推送类、排序精选类、检索过滤类、调度决策类。生成合成类算法指的是能自动生成或合成内容的算法。这个和大模型备案有重叠但算法备案更侧重于算法的机制和逻辑而不是生成内容的安全性。个性化推送类算法就是常见的“猜你喜欢”。只要你的产品里有“根据用户行为推荐内容”的功能不管这个推荐逻辑是复杂的深度学习模型还是简单的规则引擎都可能需要备案。排序精选类算法指的是对信息进行排序或精选的算法。比如热搜榜、排行榜、精选列表这些背后都有排序逻辑都可能需要备案。检索过滤类算法指的是搜索引擎、站内搜索、内容过滤等算法。你做一个搜索功能背后有相关性排序和结果过滤这就落在这个范围里。调度决策类算法指的是用于资源调度、任务分配、路径规划等决策的算法。比如外卖平台的派单算法、网约车的派单算法都属于这一类。我见过一个做内容社区的团队觉得自己没有推荐算法因为“我们就是按时间倒序排列”。但他们的“热门”标签下有一个按互动量排序的列表这个排序逻辑就构成了排序精选类算法需要备案。所以不要用“我们算法很简单”来安慰自己监管看的是功能实质不是技术复杂度。3.2 算法备案的材料重点和常见退回原因算法备案的材料相对大模型备案要轻一些但有几个地方特别容易出问题。算法基本原理和运行机制说明是核心材料。这份说明不需要你公开源代码但需要你用自然语言把算法的逻辑讲清楚。我见过很多团队在这里写得太技术化满篇公式和术语审核人员看不懂直接退回。正确的做法是用“输入-处理-输出”的框架来描述配合一个具体的例子。比如“当用户打开首页时系统会读取用户的历史点击记录计算每个候选内容的匹配分数按分数从高到低排序展示前20条。”算法应用场景和目的说明要具体。不要写“用于提升用户体验”这种空话要写“用于在首页信息流中向用户展示可能感兴趣的内容目的是提高内容点击率和用户停留时长。”目的越具体审核越容易通过。算法对用户权益的影响评估是很多团队会忽略的。你需要说明这个算法可能对用户产生哪些影响比如是否会导致信息茧房、是否会影响用户的知情权和选择权、是否有歧视性后果。然后说明你采取了哪些措施来缓解这些影响。这里最忌讳的是写“没有影响”因为任何算法都有影响写“没有影响”等于没做评估。用户申诉和关闭选项是硬性要求。如果你的产品有个性化推荐功能必须提供关闭选项。如果没有备案基本过不了。我见过一个团队产品上线两年了用户协议里没有提到算法推荐设置里也没有关闭按钮后来补这个功能花了不少时间。3.3 算法备案的变更和注销流程算法备案不是一劳永逸的。如果你的算法发生了重大变更比如从规则引擎换成了深度学习模型或者推荐逻辑发生了本质变化需要做变更备案。如果算法下线了需要做注销备案。变更备案的触发条件各地执行口径不太一样。我的经验是如果算法的输入、输出、核心逻辑、应用场景中任何一个发生了实质性变化就应该做变更。如果只是调参、换模型版本、优化性能一般不需要。但为了保险建议在变更前咨询当地通管局。注销备案相对简单但要注意注销后如果重新上线类似算法需要重新备案不能沿用原来的备案号。4. 两套备案的交叉地带与实操策略4.1 什么情况下两套备案都要做最典型的情况是你的产品既用了生成式AI来生成内容又用了推荐算法来分发内容。比如一个AI写作社区用户可以用AI生成文章同时首页有推荐流展示其他用户的文章。这种情况下生成式AI服务需要做大模型备案推荐算法需要做算法备案。还有一种情况是你的产品核心功能是生成但生成结果的展示方式涉及排序或推荐。比如一个AI绘画工具用户输入提示词生成图片同时工具会推荐“相似风格的作品”。这个推荐功能如果构成了个性化推送就需要算法备案。我见过一个团队产品是一个AI对话助手用户可以和AI聊天同时首页有一个“热门对话”列表。他们只做了大模型备案没有做算法备案。后来被提醒“热门对话”列表的排序逻辑属于排序精选类算法需要补做算法备案。补做的时候发现因为产品已经上线很多材料需要追溯比上线前做要麻烦得多。4.2 材料复用的可能与边界两套备案的材料有一些可以复用的部分比如公司资质、产品介绍、安全管理制度。但核心材料不能复用。大模型备案的安全评估报告侧重于生成内容的安全性。算法备案的算法机制说明侧重于算法逻辑的透明性。这两份材料的视角和重点完全不同不能互相替代。训练数据说明在大模型备案里是重点在算法备案里通常不是必须的除非你的算法本身涉及对训练数据的使用。内容安全管理制度在两套备案里都需要但侧重点不同。大模型备案更关注生成内容的审核和处置算法备案更关注算法结果的公平性和用户权益保护。我的建议是如果两套备案都要做先做大模型备案再做算法备案。因为大模型备案的周期更长、材料更重先做重的后面做轻的会轻松一些。而且大模型备案过程中建立的安全管理制度和测试流程可以为算法备案提供基础。4.3 备案后的持续合规工作备案通过不是终点而是起点。两套备案都有持续合规的要求。大模型备案后需要定期做安全评估一般是一年一次。如果模型有重大更新需要做变更备案。如果发现生成违规内容需要及时处置并报告。算法备案后需要持续监测算法运行效果定期评估算法对用户权益的影响。如果算法有重大变更需要做变更备案。如果收到用户投诉需要及时处理并记录。我见过一些团队备案通过后就把材料锁进柜子再也不看了。等到下一次检查或者用户投诉的时候才发现制度没执行、记录没留存、流程没落地。这种“备案归备案、运营归运营”的做法风险很大。实操心得把备案要求融入日常研发流程。比如每次模型更新前先跑一遍安全测试用例每次算法调整前先评估对用户权益的影响每次上线新功能前先检查是否需要做变更备案。这样比事后补材料要轻松得多。5. 常见问题速查与避坑指南5.1 备案相关高频问题对照表问题常见误解实际情况用开源模型要不要备案开源模型不用备案面向公众提供服务就需要和模型来源无关只做内部使用要不要备案内部使用不用备案取决于“内部”的边界大规模内测可能被视为面向公众API调用方要不要备案谁提供API谁备案服务提供方也需要备案责任可能共担算法很简单要不要备案简单算法不用备案监管看功能实质不看技术复杂度备案后要不要年检备案一次管终身需要定期安全评估和变更备案两套备案能不能一起做可以同时申请建议先做大模型备案再做算法备案备案材料能不能复用材料可以通用核心材料视角不同不能互相替代备案不通过能不能重来不通过就完了可以整改后重新提交但周期会拉长5.2 实操中最容易踩的五个坑第一个坑低估准备时间。很多团队觉得备案就是写材料两周就能搞定。实际上从准备到通过大模型备案通常需要两到三个月算法备案通常需要一到两个月。如果材料被退回时间会更长。所以产品上线前至少提前三个月启动备案准备。第二个坑材料写得太技术。审核人员不一定是技术背景你写满篇Transformer架构、注意力机制、损失函数他们看不懂就容易退回。正确的做法是用业务语言描述技术逻辑配合具体例子。第三个坑忽视用户权益保护。算法备案特别关注用户权益如果你的产品没有提供关闭个性化推荐的选项没有用户申诉渠道没有算法说明页面基本过不了。这些功能需要在产品设计阶段就考虑进去。第四个坑安全测试走过场。大模型备案的安全测试不是形式评测机构会真的跑用例。如果你的模型拒答能力弱、容易被诱导、生成内容不可控评测就过不了。建议在提交备案前自己先做一轮红队测试。第五个坑备案后不维护。备案通过后如果模型更新了、算法调整了、产品功能变了没有及时做变更备案被检查到会有风险。建议指定专人负责备案维护每季度检查一次是否有需要变更的事项。5.3 不同产品形态的备案策略建议纯生成类产品比如AI写作、AI绘画、AI对话重点做大模型备案。如果产品内有任何形式的推荐或排序功能补充算法备案。纯推荐类产品比如内容社区、电商平台、信息流应用重点做算法备案。如果产品内用了生成式AI来生成推荐理由或摘要补充大模型备案。混合类产品比如AI社交、AI教育、AI客服两套备案都要做。建议先做大模型备案再做算法备案材料准备上可以统筹安排。工具类产品比如AI翻译、AI摘要、AI代码助手如果只是单次调用、不涉及内容分发通常只需要大模型备案。但如果工具有历史记录、有推荐模板、有排序展示就需要考虑算法备案。企业服务类产品如果只面向企业客户、不面向公众备案要求相对宽松。但要注意“企业客户”的终端用户如果也是公众那可能还是落在大模型备案的范围里。6. 从备案要求反推产品设计6.1 把合规做进产品架构里备案不是产品做完之后贴上去的标签而是应该在产品设计阶段就考虑进去的约束条件。我见过太多团队产品上线了才想起来备案然后发现要改架构、加功能、补流程成本很高。内容审核模块应该作为基础能力内置。不管是生成内容还是推荐内容都需要有审核机制。审核可以是机器审核加人工审核可以是前置审核加后置审核但必须有。而且审核记录要留存备案和检查的时候要用。用户控制选项应该在产品设计时就规划好。个性化推荐要有开关算法说明要有入口用户申诉要有渠道。这些不是额外功能是合规要求。数据管理模块要能支持备案材料的需求。训练数据来源、清洗记录、授权情况这些信息要在数据管理系统中留痕。不要等到备案的时候才去翻邮件、找合同。日志和监控模块要能支持持续合规。生成内容的日志、算法运行的日志、用户投诉的日志这些都要有记录、可查询、可导出。6.2 备案材料准备的实操清单大模型备案材料清单备案申请表营业执照和法人身份证明安全评估报告训练数据来源和清洗说明模型架构和参数说明内容安全管理制度用户协议和隐私政策第三方API调用证明如适用其他通管局要求的材料算法备案材料清单备案申请表营业执照和法人身份证明算法基本原理和运行机制说明算法应用场景和目的说明算法对用户权益的影响评估用户申诉和关闭选项说明安全管理制度其他通管局要求的材料实操建议在准备材料之前先给当地通管局打个电话或者去窗口咨询一次。问清楚材料清单、格式要求、受理时间、审核周期。这个动作花不了多少时间但能避免很多返工。6.3 备案时间线的合理规划假设你的产品计划在2026年6月上线那么备案时间线应该这样规划2026年1月启动备案准备确定备案类型咨询当地通管局收集材料。2026年2月完成安全测试和算法评估整理训练数据说明编写安全管理制度。2026年3月提交大模型备案申请同步准备算法备案材料。2026年4月配合技术评测根据反馈整改。2026年5月大模型备案公示提交算法备案申请。2026年6月两套备案完成产品上线。这个时间线是理想情况实际可能会有延迟。所以建议至少留出半年的缓冲期。7. 一些来自实操的经验之谈备案这件事说难不难说简单也不简单。难的是它涉及技术、法务、产品、运营多个部门协调成本高。简单的是只要你真的把该做的事情做了材料只是把做过的事情写出来。我见过最顺利的团队是那种在产品设计阶段就把合规要求考虑进去的团队。他们的安全测试是研发流程的一部分用户权益保护是产品设计的一部分数据管理是日常运营的一部分。备案的时候只是把这些日常工作的记录整理出来很轻松就过了。我见过最痛苦的团队是那种产品上线两年了才想起来备案的团队。他们要补测试、补制度、补功能、补记录还要面对可能的下架风险。补的过程中发现很多历史数据找不到了很多流程没有留痕很多功能需要重构。所以我的核心建议是不要把备案当成一个项目来做要把它当成产品能力的一部分来建设。备案的要求本质上也是产品安全、用户权益保护、数据治理的要求。这些能力建好了不仅备案轻松产品本身也更健康。还有一个实操细节和当地通管局保持沟通。备案政策在执行层面有很多细节不同地方的口径可能不一样。定期关注通管局的官网通知有问题及时咨询比闭门造车要高效得多。最后分享一个我自己的教训有一次帮一个团队准备算法备案材料算法机制说明写得很详细但忽略了“用户权益影响评估”这一项。提交后被退回要求补充。补充的时候发现因为产品设计时没有考虑用户关闭选项需要临时加功能耽误了两周。从那以后我每次做备案咨询第一件事就是问“你们的用户能不能关掉推荐有没有申诉渠道”这两个问题如果答案是“没有”那就得先补产品功能再谈备案。备案不是终点是产品合规运营的起点。把该做的事情做到位后面的路会越走越顺。
