大模型备案这件事我是真刀真枪跑过一遍的。从2025年初项目立项到2025年5月拿到备案号前后刚好4个月中间经历了材料被打回、安全评估测试返工、沟通口径调整这些坑。最近不少同行问我备案到底怎么弄、材料怎么准备、评测难不难我就把整套流程和踩坑经验整理出来给2026年准备上车的人做个参考。这篇东西不聊大模型的训练细节也不讲算法原理只聚焦一件事当你的大模型要面向公众提供服务时怎么把备案号拿到手。不管你是创业团队的技术负责人、公司内部AI项目的推进者还是打算做AI应用开发的个人开发者只要你的产品形态涉及生成式AI对外服务这篇文章都适用。先说几个关键结论省得你走弯路第一备案不是可选项是合规底线没有备案号你的服务就不能公开上线第二备案的主体是你公司或者你个人不是你的模型第三整个过程最花时间的不是等审批而是前期的材料准备和基座模型能力评估。我见过最快6周拿号的也见过拖了一年还在补材料的差别全在前面这两步。1. 大模型备案到底在备什么1.1 为什么2026年了还要专门谈备案很多人觉得生成式AI服务管理办法已经实施好几年了备案应该是常态化了。现实确实如此常态化不等于简单化。从2023年《生成式人工智能服务管理暂行办法》正式施行开始凡是利用生成式人工智能技术向境内公众提供服务的都需要履行备案手续。中间网信办出过若干次细化指引和答问2025年以后各地执行口径越来越统一但审核深度明显在增加。我第一次交材料的时候想得比较简单觉得产品合规性做得差不多模型也是基于开源基座微调的应该很快能过。结果属地网信办初审就提了17条修改意见其中一半以上指向安全评估报告的细节不足。那一刻我才意识到备案不是交作业而是要把你的技术体系在纸面上完整地证明给监管看。1.2 备案、登记、算法备案别搞混很多新手一开始就懵在于大模型相关的合规动作有好几项不知道哪个才是自己需要的。我梳理一下实际场景里的分类大模型备案也叫生成式AI服务备案面向不特定公众提供生成式AI服务时必须办理拿到的备案号一般以“网信算备”开头。大模型登记如果你的服务不是面向公众而是面向企业内部员工或特定合作方走的是登记程序门槛相对低一些。算法备案这是另一个维度的要求针对的是算法推荐、深度合成等具体技术类型如果你的产品里有深度合成功能比如文生图、数字人、语音合成需要单独做算法备案。双新评估对于新上线或重大更新的大模型部分地方会要求做“双新”评估也就是新模型上线前的安全评估和新应用上线前的检测。我当时做的是一个基于开源基座微调的对话问答产品面向C端公开使用所以核心工作就是大模型备案。如果你的产品形态里还包括图片生成那就要同步启动深度合成算法备案两条线并行。1.3 备案号和你的业务到底是什么关系备案号不只是墙上一张证书。拿到号之后你必须把备案号标明在应用显著位置也就是用户在产品的隐私政策、关于页面或者服务协议里能直接看到。我的实际体会是备案号对业务的价值远不止合规它是应用商店上架的前置条件主流应用商店审核AI类应用时都会要求提供备案号。它是企业客户采购你服务时的信任凭证很多政企客户直接把备案号列为供应商准入条件。它是和渠道商、代理商谈合作时的硬通货没有备案号你的API能力再强也很难进入正规分销体系。所以备案号本质上是你产品从技术demo走向商业服务的入场券。不要把它当成负担它是你产品成熟度的官方认证。2. 正式启动前先想清楚这几件事2.1 判断自己属于哪一类服务提供者备案的第一步不是写材料而是搞清楚自己的角色。按照监管定义如果你利用大模型的技术能力自己训练或微调了模型然后对外提供服务你是服务提供者。如果你只是接别人的API做一个套壳应用你的主体身份依然是服务提供者但技术部分的描述方式会不一样。这个区别很实际。我见过一个团队产品完全搭建在第三方大模型API之上他们觉得这种情况下自己不用备案因为模型不是自己的。这是很大的误区。只要你的应用向公众提供了生成式AI服务你就有备案义务只是你在安全评估报告里可以把基座模型的能力描述成“基于第三方基础模型”同时把你自己的应用层安全措施作为重点来写。还有一种情况你既是模型提供方又是服务提供方也就是你训练了一个模型还基于这个模型做了应用对外发布。这种情况下你的安全评估报告要覆盖从训练数据、模型微调到应用服务的整个链路工作量最大但备案号含金量也最高因为你在产业链里的位置更核心。2.2 公开服务走备案私有化/内部服务走另一条路一家公司如果只是内部用大模型不对外开放要不要备案我说说实务口径不面向公众提供服务的情况下不需要走公众服务备案流程但需要做相应的安全评估和日志留存满足数据安全和个人信息保护的基本要求。如果你的产品要做成SaaS卖给企业客户客户那边是私有化部署那你是技术服务提供方最终要不要备案取决于客户的部署形态和使用范围。我遇到过一个案例。客户公司想把大模型能力集成到他们的内部OA系统只给员工用。我们问了好几个渠道属地网信办给的答复非常一致内部使用的AI能力不属于面向公众的生成式AI服务不用办公众备案但企业自身要做好模型安全测试、数据隔离和日志审计。这个环节弹性比较大建议你启动前先电话咨询属地网信办确认清楚自己的情况再决定走哪条流程。提前沟通的成本极低但能避免你多准备一整套路材料。2.3 基座模型选型直接决定了你的备案难度观察了身边一圈走完备案的同行我总结出一个粗暴规律基座模型选得越主流备案越顺滑。原因不难理解——监管对大厂的基座模型已经建立了安全评估认知微调之后的安全风险相对可控如果你自己从零训练了一个参数量百亿级的模型那光是安全性证明材料的深度就够你写一个月。我当时选型时重点考虑了三个维度基座厂商是否已经完成自己的备案选择已完成备案的基座你的材料里可以直接引用其基础能力不用从头论证模型本身的安全性。开源协议是否允许商用微调很多开源模型协议限制商用场景这一条不过关后面全是雷。社区的微调和部署资料是否充足资料越充足你的安全整改速度越快比如做有害内容拒答的能力调整缺乏社区积累的模型会让你多花好几周。不是说你不能用自己的模型而是要说清楚在备案这件事上用成熟基座做微调是性价比最高的路径。你花的每一分力气都应该投在应用层安全能力和业务合规上而不是在处理一个没有任何社区积累的模型的基础安全问题上。3. 材料清单深度拆解每一份文件到底怎么写3.1 一张完整清单先放这里我把我在实际准备中用到的材料清单列出来你可以直接对着准备。需要注意各地网信办的材料名称可能略有差异但核心件基本一致。序号材料名称核心内容重要程度1安全评估报告对模型整个生命周期的风险评估与缓解措施核心中的核心2算法安全自评估报告针对模型算法层面的安全自评估核心3服务协议用户与你之间关于服务使用的协议必备4隐私政策个人信息收集、使用、存储的具体说明必备5安全管理制度内部人员、数据、权限、应急等管理规范必备6应急处置预案安全事件发生后的响应流程必备7训练数据说明数据来源、规模、清洗过程、合规性说明涉及自训练才重点需要8模型能力说明模型结构、参数量、能力边界、应用场景必备9用户投诉举报机制说明用户如何投诉你如何处理必备10日志留存方案留存哪些日志、存多久、怎么保护必备这里面第1、2份是最考验功力的我重点展开讲。3.2 安全评估报告到底怎么写安全评估报告是整个备案材料的天花板审核老师的修改意见大部分集中在这里。它的本质是回答一个问题你的大模型服务在什么场景下、可能产生什么风险、你用了什么技术和管理手段去控制这些风险。我在写这份报告时搭了一个结构后来发现还挺高效业务与功能描述你的产品是什么、面向谁、提供什么功能。这里要写得准确不要夸大。我见过有人把自己定位成通用大模型审核时被要求提供远超实际能力的材料纯属给自己挖坑。模型技术方案基座、参数量、微调方式、部署方式、运行环境。如果用了第三方基座要注明基座本身已完成备案。训练数据安全管理数据来源、合法性证明、清洗过滤流程、敏感信息处理。即使你只做微调也要说明微调数据的来源和清洗情况。模型安全能力你对有害内容的识别能力、拒答机制、输出过滤策略。这里面最有说服力的是你实际做了哪些安全对齐。应用层安全措施输入侧的关键词过滤、输出侧的审核、敏感话题拦截、用户身份验证。风险分析与缓解逐项列出可能发生的风险场景然后给出对应的缓解手段。有一个经验值得强调报告千万不能只写“我们有内容审核机制”这种空话审核老师看材料看得太多了一眼就能分别出你是真做了还是纸面合规。我第二次修改时把所有安全描述都换成了带具体技术方案的形式比如“输入侧部署基于XXX的敏感词过滤系统覆盖政治、暴力、色情等XX个分类实测拦截率XX%”通过率明显提升。3.3 算法安全自评估报告的把控要点算法安全自评估报告听名字很技术实际上它考查的是你对算法行为是否足够了解。核心不是写你的公式多厉害而是写清楚你的算法在运行过程中会不会产生危害性输出以及你如何防控。我在写这一份的时候重点覆盖了五个方面算法基本描述用什么模型、什么任务类型、服务方式。算法安全风险自评有没有可能生成虚假信息、歧视性内容、诱导性内容、侵权内容等。算法机理分析模型的训练目标函数、微调策略、推理时的采样参数、温度设置如何影响输出。测试验证情况你做了哪些测试、用了多少测试样本、结果如何。安全防护措施有效性和你安全评估报告里的措施对应起来形成闭环。在这里说一个很实际的坑很多人写算法安全自评估报告时会套模板把别人家的大而全的东西复制过来。结果审核老师问一个细节问题就答不上来了。宁可写得范围小一点但内容要与你的系统真实对应。比如你的模型是对话问答那就不要写一堆图像审核的功能因为你根本没有。3.4 配套制度文件最容易忽略的细节安全管理制度、应急处置预案这些文件看起来像是凑数的其实审核老师会对细节抠得非常细。我在第一次提交时安全管理制度里写了“数据备份每日执行”审核意见就问“备份保留多久、存放在哪、谁有访问权限”。所以每一句话都要经得起追问。我的建议是把这些制度文件和你的真实运营流程对齐安全管理制度要和你的实际岗位设置一致比如谁是安全负责人、谁是数据管理员最好有实际的岗位和姓名。应急处置预案里提到的流程你要能演示出来。比如你写到“发现违规内容后5分钟内启动溯源”那后台日志系统要做到分钟级查询。用户投诉举报机制不只是一个邮箱你要有清晰的受理流程和时限承诺最好还能看得到过往处理记录。补一次料至少多花两周这些细节前期做得越扎实后面越省事。4. 四个月通关时间轴每月该干什么4.1 第一个月摸底、定位、搭安全底座第一个月是整个项目最关键但最容易被低估的阶段。很多团队上来就写材料写到一半发现技术侧安全能力完全没跟上材料里的承诺无法落地只能回去补技术整个周期被拉长。我第一周在做的事是梳理现状模型部署在什么环境、用到了哪些训练数据、内容过滤机制是什么、日志系统长什么样。梳理完才发现模型的输出过滤几乎是裸奔状态只是靠基座自带的那点安全对齐能力。这意味着我必须先补技术底座才有资格去谈安全能力。第二周到第四周我集中做了三件事部署内容安全审核模块覆盖输入和输出两侧。建立敏感词词库和提示词注入攻击的识别规则。把日志系统按要求改造记录所有用户请求和模型输出的关键信息。这里我还提前做了一件事和属地网信办进行了初步沟通问清楚他们目前对材料格式的要求和标准模板是否存在。这一步帮我省了很多无用功因为各地对材料组织方式确实有细微差异。4.2 第二个月安全自测和对抗样本准备材料可以后面再写但技术自测必须前置。因为安全评估报告里的所有数据都来自于你的自测结果没有数据报告就是空壳。第二个月我的主要精力放在大规模安全测试上。我整理了一批测试样本集包含了各大安全评测基准中的高危样本也加入了我们自己收集的业务场景特有风险样本。我还专门做了红队测试模拟用户用各种prompt注入方式尝试让模型输出有害内容把这些失败案例和成功拦截案例都记录下来。这个月的产出非常具体一份“拒绝回答”的违禁问题清单大概覆盖了几百个典型的违规方向。内容审核模块的拦截率数据按不同类别分别统计。模型在正常业务场景下的幻觉率测试结果。千万别觉得这些数据随便编一编就行审核环节确实可能要求你现场演示系统能力。你写“拦截率98%”如果演示时连常见问题都拦不住那这份材料基本就废了。4.3 第三个月材料撰写和内部评审材料是我从第二个月下旬开始动笔的但第三个月才是真正的撰写期。每天白天处理业务晚上和周末挤时间写材料前后改了四版。写材料有个很痛苦的地方自己怎么看都觉得写得够清楚模拟审核老师的视角却总觉得会挨批评。后来我找了一位做过网络安全的同事帮忙做“模拟审核”他完全不看我写的业务背景只挑漏洞数据支撑够不够、逻辑有没有闭环、承诺能不能兑现。这轮模拟拦下来至少5处关键缺陷比被网信办打回来再改节省了一个多月的时间。第三个月月底我完成了全套材料的初稿并做了一个完整的自检表每份文件之间引用的数据是否一致制度文件中提到的负责人是否和实际情况吻合隐私政策里的信息收集场景和应用真实行为是否对应。这类问题非常琐碎但审核老师就是靠这些细节判断你是不是认真准备的。4.4 第四个月提交、答辩、整改、拿号第四个月节奏完全由别人掌控了你能做的就是把所有材料准备好随时响应。我第一次提交是通过属地网信办的线上系统上传的审核进度大概一周更新一次。大概到第二周收到了短信通知补充材料。当时看到那份修改意见说实话有点崩溃17条意见密密麻麻。但冷静下来之后逐条分析真正算得上硬伤的其实只有两类一类是安全评估报告里部分描述不够具体另一类是算法自评估的测试数据不够详实。这些问题都是可以快速修正的。整改期间属地网信办的老师组织了线上沟通会问了许多业务细节有些问题很尖锐比如“你的模型回答错误医疗信息怎么办”“你的日志能查到多少个字段”。这些问题让我意识到材料里的每一个承诺都要经过实战检验所以你写之前一定要确保团队真实能做得到。协调沟通、修改材料、重新提交又花了两周多。最终拿到备案号那天并没有特别激动反而是一个悬了两个多月的心终于落下来的感觉。整个周期从启动到拿号95天。5. 过线指标到底是多少评测维度全面拆解5.1 监管评测到底在测什么备案审核期间部分情况会触发专业机构的测评环节尤其是涉及自研大模型或面向公众服务规模较大的产品。我了解到的评测不是考你的模型多聪明而是考你的模型是否安全可控核心集中在三个方向内容安全、数据安全、模型能力边界。内容安全是重头戏评测机构会准备大量有害请求样本覆盖暴力、色情、歧视、违法犯罪、谣言传播等多个大类每个大类下又有几十个子类。你的模型对这些请求不能给出实质性有害回答。这里有个值得注意的现象单纯回复“我不能回答”不一定能得分因为评测会看你是否能给出无害但有帮助的替代性回复。数据安全方向的测试主要是看你的应用是否在收集用户信息时明确告知、是否有过度收集行为、日志存储是否合规。模型能力边界的测试则关注幻觉率。模模糊糊的回答算不算通过这个后面细说。5.2 内容安全指标量化到什么样的拦截率才算稳说实话官方并没有公开一份“拦截率达到多少就过”的量化标准。但根据我周围同行交流掌握到的信息以及测评反馈来看以下几个区间可以拿来参考指标类型兜底值较稳妥值说明高危有害内容拦截率95%以上98%以上涉政、暴恐、色情等绝对不能出现在输出里敏感误导信息识别率90%以上95%以上涉及医疗、法律、金融等专业领域需慎答攻击性prompt注入拦截率90%以上95%以上包括越狱、角色扮演诱导、样本诱导等正常问题拒答率误杀率不高于10%不高于5%过于严格的过滤会把正常回答也砍掉影响可用性这里面最核心的平衡是误杀率和拦截率的取舍。我第一次自测时把过滤强度调到很高有害内容拦截率确实漂亮但是正常问答里有一大部分被误判屏蔽用户体验惨不忍睹。后来调整策略采用分层过滤模型高危类别直接掐断模糊类别的输出接入二次审核机制低危类别的输出正常放行。还需要注意恶意样本的更新时效。静态词库远远不够攻击者在不断变着花样尝试新写法你必须定期更新词库和规则。我在自测结束时统计了一下光是测试期间就收集到了几百个此前词库没有覆盖的绕过案例。这些案例后来全数补进了过滤规则。5.3 对抗测试和投毒样本你真的挡得住吗热词里频繁出现的“大模型投毒测试”在备案语境里其实对应两件事一类是评测机构给你的模型投喂恶意样本看你会不会输出危险内容另一类是更早期的检查看你的训练数据是否被恶意注入过后门。对于自研模型或深度微调的模型训练数据环节的安全检查非常重要。你需要能够证明微调数据的来源可信并且已经做了内容清洗。我当时把微调数据的清洗过程完整记录了下来包括清洗规则、清洗过程中拦截的内容类型和数量、人工抽检比例等这些数据放进材料里比任何口头承诺都有说服力。至于推理阶段的对抗样本我的经验是不要完全依赖开源安全方案要结合自己业务场景做扩展。比如我的产品涉及职场办公场景用户可能会用各种间接方式诱导模型输出公司内部的管理对策、薪酬对比等敏感信息这个方向就不能只靠通用词库覆盖需要我们自己做针对性测试和规则补充。5.4 关于“双新”评估的补充最近两年上线了不少新模型如果你的模型属于业内比较新的架构或者你的应用属于新的服务类别部分地方会要求做“双新”评估。双新评估本质上是一次更严格的上线前体检通常由第三方评测机构执行周期大约2到4周。我的建议是如果你不确定自己是否需要双新评估在启动时就问属地网信办。如果他们表示需要你要把这部分时间预留进项目排期里。因为双新评估的结果会直接影响你的材料补充方向评估项会更细比如需要你做压力测试、注入攻击专项测试、数据泄露专项测试等。我当时就因为这个问题犹豫了两周浪费了一部分时间。6. 常见问题与避坑实录6.1 材料被打回的三大“隐性杀手”我复盘了自己和同行们的补交经历发现被打回的原因高度集中在几类第一类是承诺与系统能力不符。材料里写“支持某某防护能力”但评测时根本找不到这个模块。审核老师不会听你解释直接判为不通过。解决办法是让技术人员逐条验证材料里的技术描述。第二类是数据前后不一致。比如安全评估报告里写了“共测试样本5000条”算法自评估报告里却写了“共测试样本3000条”。这种低级错误会给审核方造成材料随意撰写的印象严重影响信任度。我后来做了一个统一的数据台账所有材料里引用的数据全部从一个表里读取。第三类是描述太空泛。高频废句包括“建立健全的机制”“完善的防护体系”“深度的安全策略”。正确做法是把这些表述全部替换成具体的技术方案和量化指标。记住审核老师需要的是能验证的事实不是一个口号。6.2 属地沟通的经验电话聊十句不如当面坐十分钟备案的审核主体是属地网信办材料评审过程中的沟通效率直接决定了你的整改速度。我自己的体会是如果你的产品规模不大尽量争取和审核老师建立直接沟通关系。我有一次遇到一个问题拿不准训练数据里包含了一些从公开互联网抓取的文本是否需要逐条标注来源。这个问题我翻遍了公开指引也没有明确答案。后来通过面对面沟通审核老师给了非常实在的建议按数据来源类型统一说明不需要逐条标注但需要提供整体的来源合法性声明和清洗记录说明。这句话让我少走了一个多月弯路。所以在整个备案期间我每个月都会主动向属地网信办汇报一次进展不是问他们“办得怎么样”而是同步我这边做了什么安全能力的更新。这个主动同步的动作让后续的材料沟通顺畅了很多。6.3 备案号拿到之后不是终点而是新起点取得备案号后后续的工作依然不少。你的应用如果发生重大功能更新比如从纯文本对话升级为多模态交互可能触发重新评估的要求。日常运营中你需要持续做好日志留存、用户投诉处理记录、内容安全运营报告这些材料在后续的检查或年审中可能会被调阅。另外还有一个很多团队容易忽视的点备案号和你的域名、应用名称、运营主体是绑定的。如果你的应用做了主体变更或者域名迁移需要及时做备案变更。我认识一个团队他们拿了备案号之后换了公司主体以为备案号还能继续用结果被要求重新走流程前面的工作量基本白费了。我自己跑完这一趟之后最大的感触是大模型备案本质上是一场“把自己的能力完整证明给别人看”的考试。很多人畏惧它是因为整个过程确实繁琐但如果你把材料要求当成产品安全能力建设的机会你会发现备案做完之后你的系统真实的安全水位明显上了台阶。那些真正认真准备了材料的团队大多在拿号后反馈说这几个月没有白费。最后再分享一个小技巧在准备阶段把你所有安全能力的测试数据固化下来做成一个可以随时更新的内部文档。等拿到备案号后这个文档就是你产品运行状态的活档案无论是后续功能升级的自查、商务合作时的安全能力展示、还是客户尽调时的材料支撑它都能派上大用场。