我最早听到"大模型登记"这四个字的时候，下意识以为就是去某个平台填一张信息表、传两份资质文件，等几天出个编号就算完事。后来真带着团队走完一遍才发现，这件事的复杂程度远超预期：提交材料里的模型参数、训练数据来源、内容安全测试记录、甚至抽样问答对，都会被一条一条翻出来核对，补正意见经常能写满三页纸。

这篇文章把自己团队近期完成的一次大模型登记全流程记录下来，重点拆解三件事：登记到底要交哪些材料、每一步的真实耗时和坑在哪、以及通过之后还要持续做什么。不论你是自研大模型的服务方，还是基于已有模型做二次开发的团队，只要产品要面向公众提供服务，这套流程大概率都躲不过。提前搞清楚，比临到上线被卡住再折腾要省太多事。

1. 为什么登记不是"填一张表"：先搞清楚流程定位和适用对象

1.1 登记解决的核心问题：面向公众服务的前置动作

很多开发者对"大模型登记"的理解停留在"备案"两个字上，觉得它就是一次性的行政手续。实际做下来你会发现，它更像一次围绕模型安全能力的产品评审，核心目的只有一个：确认你这个模型在面向不特定公众提供服务时，不会出现严重的内容安全和数据合规问题。

这里要先区分两个经常被混为一谈的东西：一类是针对算法推荐、深度合成等服务的算法备案，侧重"算法机制"层面的说明；另一类是针对生成式人工智能服务的登记备案，也就是我们常说的"大模型登记"，它更侧重模型本身：训练数据怎么来的、安全对齐怎么做的、有害内容能不能拦住、用户投诉怎么处理。两项有时会被要求同时办理，但材料体系和审核角度差异挺大。团队在实际操作中如果把它们混着写，很容易出现"答非所问"的补正意见。

1.2 谁必须登记、谁不用登记：先判断适用场景

判断标准说来也简单：你的模型或服务如果直接面向公众开放，不管是通过网页、App、小程序还是 API 对外提供生成式回复能力，基本都在登记范围内。

但有几个容易误判的边界。第一种是只做内部工具，比如公司内部的知识库问答机器人，不对外部用户开放，这类通常不触发大模型登记，但要留意内部使用是否涉及个人信息处理，数据合规层面另有要求。第二种是调用别人已经完成登记的模型 API，自己只做界面封装和业务逻辑，这种情况下一般不需要重复做模型侧登记，但你作为服务提供方，自己仍有服务侧的主体登记、用户协议、投诉处理等义务。第三种是拿开源模型做了微调再对外提供服务，这个判断就要谨慎了——只要你的对外服务核心能力依赖这个微调模型，基本就落到了登记范围内，别抱着侥幸心理。

1.3 不登记的后果不能赌

这一点我在多个同行那里得到过一致反馈：登记编号不是"锦上添花"，而是很多下游环节的硬性前提。App 上架审核会查、域名和服务器相关资质核验会涉及、甚至你的企业客户在采购 AI 服务时也会先让你提供登记情况。更直接的是，如果服务已经被实际投入使用而登记状态异常，主管部门要求暂停服务整改的情况并不少见。

所以我的建议是：把登记当成产品上线清单里的一个例行项，而不是运营过程中被拉响的警报。凡是计划对外提供生成式服务的新项目，立项第一天就把登记负责人指定好。

2. 登记前的临战准备：三类材料、两方协调和一份时间表

2.1 材料清单速览：先知道要交什么

我们团队把材料归成主体资质、技术材料、安全材料、服务材料四类，每一类对应不同的责任人。这里先给一份我整理后的清单，方便你对照查漏：

这里要额外提醒一句：很多团队把精力全放在技术材料和安全材料上，忽略了用户协议和隐私政策。实际上审核时这两份对外文档会被逐条核对，比如有没有写明用户不能输入违法内容、有没有提供投诉渠道、个人信息处理规则是否清晰。到了补正环节再去改线上文档，又得重新走一轮内部评审，耽误的是整体时间。

2.2 内部协调往往比写材料更耗时

登记不是一个部门能独立干完的事。算法团队要出模型技术说明，安全团队要做内容安全测试并留痕，产品团队要梳理使用场景和用户协议，法务要盯主体资质和对外承诺，最后还得有一个人把所有材料汇总统稿。最容易被低估的是统稿这一步：我们第一次汇总时，算法说明里的模型参数量、安全报告里的测试样本数、产品文档里的服务名称，三个地方各写各的，审核意见里好几条都在指这类不一致。

我的经验是尽早指定一个"总接口人"，所有材料经过他的手统一格式和口径，对外只由他一个人提交和接收意见。内部每周固定过一遍进度，别靠微信群零散同步，否则临近提交节点很容易出现某个材料还没签完字的情况。

2.3 时间预算：按两轮补正倒排计划

从我们周边团队的反馈来看，从首次提交到最终拿到登记编号，比较顺利的也要一个半月到两个月，材料问题较多的拖到三四个月也不稀奇。首次提交一次性通过的情况极少，几乎都会经历至少一轮补正，所以排计划时别把"提交日"当成终点去倒排，要按"提交后预留两轮补正时间"来算。

如果产品有明确的上线日期，我建议把登记启动时间至少提前到上线前三个月。倒排的逻辑是这样：第一个月完成材料撰写和内部评审，第二个月提交并等待首次反馈，第三个月专门用于补正和终审。你永远不知道补正意见会不会要求补做一轮安全测试，而测试本身又需要时间。

3. 核心材料怎么写：安全自评报告和算法说明的实战逻辑

3.1 安全自评报告：结构上建议怎么搭

安全自评报告是整个材料包里篇幅最大、也最需要用心的一份。我们最终采用的结构是五个模块：模型概况、风险分析、应对措施、测试评估、应急处置预案。

模型概况部分把模型定位、主要功能、服务对象说清楚，相当于给审核人员一个快速语境。风险分析部分别泛泛写"可能存在有害内容风险"，要落到具体风险类型上，比如色情暴恐、违法违规信息、虚假谣言、价值观偏差等，每种风险说明触发场景和可能的用户表达方式。应对措施部分对应写模型侧的对齐策略、输入输出侧的内容安全拦截策略、人工审核兜底安排。测试评估部分附上测试方法、测试数据集说明、关键指标结果。应急处置预案单独成节，写清楚发现有害内容后的响应时间、负责人、处置步骤和上报路径。

3.2 训练数据说明：口径统一是重中之重

训练数据这块审核得很细，因为数据是模型行为的根源。我们当时被追问最多的几个问题是：数据从哪里采集的、采集方式是否合规、去重和清洗怎么做、低质量数据和有害数据怎么过滤、中文数据的占比多少、有没有引入合成数据。

这里有一个特别容易踩的坑：算法团队嘴里说的"数据清洗"和材料里写的"数据清洗"经常不是一回事。团队内部觉得是常规操作，但材料里只写一句"已进行数据清洗"，审核看到的就是缺乏支撑。正确做法是把清洗流程拆成可验证的步骤：先做格式过滤和语言识别，再做去重和近似去重，再做敏感信息识别，最后做有害内容分类过滤，每一步给出大致数据量和留存比例。不需要精确到商业机密级别，但要有"我们确实做了"的可信度。

3.3 内容安全测试：留痕比测试本身更重要

很多团队平时确实做了不少安全测试，但到登记时拿不出像样的记录，这才是最亏的。审核要的不是你口头说"我们测过"，而是可追溯的测试报告：测试用例覆盖了哪些风险类别、每个类别用了多少条样本、触发率是多少、针对未通过的样本做了哪些优化、优化后复测结果如何。

这里分享一个我们后来一直在用的做法：从立项第一天就建一个安全测试台账，每轮测试记录日期、测试人员、测试集版本、通过率、问题样本示例、修复动作和复测结果。登记时直接基于台账整理报告，数据全部能对上。如果项目已经进行到一半才开始补记录，很多细节是补不出来的，审核较真起来很容易露馅。

3.4 算法说明怎么写审核更愿意看

算法说明最容易犯的毛病是写成产品宣传稿，满屏"基于先进的大语言模型技术"这类话。审核需要的恰恰是相反的东西：具体的模型参数量级、采用什么结构和训练方法、SFT 和 RLHF/对齐阶段怎么做的、推理部署用的什么方案、生成参数如何设置、是否限制了输出长度和敏感话题兜底策略。

写的时候心里要有数：这是一份给技术评审人员看的技术文档，不是给客户看的方案介绍。宁可写得朴素，也要把关键参数和环节交代清楚。我们第一次交的算法说明里对"对齐方式"只写了一句话，补正意见直接要求展开说明安全对齐的具体手段和数据构造方式，后来补了三页才过关。

4. 从提交到公示：受理、补正、评审的时间线和常见节奏

4.1 线上申报入口与首次提交

整个登记过程在主管部门的线上备案平台完成。首次提交前，先在平台上完成主体注册和实名认证，然后把前面整理的四类材料按平台要求的格式逐项上传。

这里要特别留意平台对文件格式和大小的限制，比如扫描件是否接受、PDF 是否有页数限制、盖章文件必须盖什么颜色的章。我们第一次就栽在"承诺书必须由法定代表人签字并加盖公章"这个细节上，办公室把章寄错了地方，硬生生多花了三天。

提交前最后检查一遍：所有材料里的主体名称是否一致、模型名称是否和对外服务展示名称一致、材料版本号是否清晰标识。每次提交都用"提交日期+版本号"的方式命名压缩包，方便后面定位哪份材料对应哪轮审核。

4.2 第一次补正几乎必然出现

首次提交后的反馈周期一般是两到四周，具体看审核队列和材料复杂程度。补正意见通常分三类：材料不齐全、描述口径不清晰、证据支撑不足。

材料不齐最好解决，缺什么补什么。描述口径不清晰麻烦一点，比如使用场景写得过于宽泛、风险分析和应对措施对不上、预案缺少具体责任人，这类需要组织相关团队重新统稿。证据支撑不足最耗时，比如安全测试记录过于简单、没有原始测试日志、训练数据说明缺少中间处理环节，可能需要补做测试或补充文档。

收到补正意见后我建议别急着当天回复，先把意见拆解成可执行清单，逐条分给对应负责人，明确每条补充材料的更新位置和完成时间。一次性把材料做扎实，比连续两次来回补正要省时间得多。

4.3 专家评审阶段别当甩手掌柜

材料补正通过后会进入评审阶段，这个阶段偶尔会有电话问询或补充交流的机会。我们当时收到过一次关于模型在特定场景下回答边界的问题，电话里直接给了答复，同时承诺在材料里补充对应说明。

我的建议是：从提交到公示全程保持信息渠道畅通，指定算法团队里最了解模型细节的人作为技术答辩人，法务或接口人负责对外沟通。不要等审核主动来问，在材料里预留联系方式，主动说明"如有技术问题可联系某某，电话多少"。这种细节看似不起眼，但能显著减少来回沟通的轮次。

4.4 获得登记编号后的公示

终审通过后，登记信息会进入公示流程，公示期满后拿到登记编号。这个编号不是终点，后面章节会讲日常义务。要提醒的是：公示信息和平台信息里的模型名称、服务名称必须和线上产品一致。很多团队登记时填的是内部项目代号，上线时又起了一个对外营销名，两边对不上，后续变更报备时平白多了一轮材料。

5. 十个高频驳回点拆解：拿真实台账对照着自查

以下十个问题来自我们自己和周边团队的实际登记记录，每一类都对应过真实的补正意见。提交前对照着自查一遍，能省下至少一轮补正。

5.1 使用场景写得太大太空

"赋能多行业多场景"这类表述在审核这里基本等于没写。审核希望看到的是具体使用场景：是面向 C 端用户的智能助手，还是面向特定行业的客服机器人，还是内容创作辅助工具。场景越具体，风险分析越好做，应对措施越好写。我们第一版写了四个行业八个场景，补正后被要求收窄到两个主打场景，后续整个报告的针对性一下就清晰了。

5.2 数据来源描述与实际不符

这是最危险的一类问题。材料里写的数据来源和实际情况对不上，轻则补正，重则影响整个登记的公信力。比如材料说训练数据全部来自公开网络爬取，但实际用了某个渠道购买的语料，或者使用了未经充分授权的数据，这类瑕疵一旦被发现，很难解释清楚。

我的建议是：训练数据说明必须由真正负责数据处理的人来写，写完后让法务做一遍合规审查，确认每一个数据来源都有相应依据。宁可写得保守，也不要为了显得"规范"而写与实际情况不符的描述。

5.3 安全测试样本雷同

审核人员会看测试样本的实际内容。如果十类风险各放了十条样本，但样本之间高度相似，换几个关键词就凑数，一眼就能看出来。我们第一次的测试样本里，"违法违规信息"类目下二十条样本有五条表达结构几乎一致，补正意见直接点了出来。

正确做法是按风险类目细化测试子类，每个子类单独设计样本表达模式。比如做"虚假信息"测试，至少要覆盖医疗谣言、金融诈骗、灾害谣言、政策误读等子类，每种子类用不同的场景和措辞构造样本。

5.4 模型名称与对外展示名称不一致

这个坑看着小，踩的人不少。登记材料里用的是算法版本内部代号，产品上用的是营销名称，导致审核人员无法对应。建议在登记前就确定对外展示名称，材料里所有出现模型名称的位置全部统一。如果后续要改名，按变更流程报备，别默默改。

5.5 登记主体与运营主体不一致

有时产品运营主体和模型研发主体是两家公司，特别是集团下面有多个实体时容易出这种问题。审核要求登记主体与实际对外服务提供主体一致，如果不一致，需要补充关联关系说明和授权文件。我们在材料里遇到这个问题时，临时去补了一份关联关系证明，折腾了一周。

5.6 用户协议里缺必要条款

对外服务必须让用户知道自己在和什么系统交互，并且明确禁止行为。我们被指出过用户协议里缺少"不得输入违法和不良信息"的明确条款，以及未说明对生成内容的参考与甄别提示。这类条款不提前写好，到了补正阶段就要协调线上产品一起改，动静很大。

5.7 测试报告版本与提交材料版本对不上

如果模型已经经过了多轮迭代，提交的安全测试报告对应的模型版本必须和算法说明、模型介绍里的版本一致。我们当时同时维护了三个测试版本，统稿时差点把旧版报告提交上去。最后靠的是"材料版本控制表"，每一份材料都登记对应的模型版本号和日期，提交前由接口人逐项核对。

5.8 应急预案没有细化到人

"我们将及时处理"这句话在审核这里没有说服力。应急预案要写清楚：监测发现有害内容后由哪个系统触发告警、值班人员在多长时间内响应、处置分几步、每一步由谁负责、什么情况下升级上报。我们最终把预案改成了带流程图和责任人表格的版本，才过了这一关。

5.9 忽视了模型变更的启动机制

登记通过不意味着模型不能迭代，但重大更新需要报备。很多团队在登记阶段完全没有想过变更机制，等模型升级了大版本才发现需要补做安全评估，导致新版本迟迟不能上线。建议在登记材料里就把变更管理机制写清楚，内部也建立"模型版本变更触发登记评估"的流程。

5.10 材料里的数字互相打架

不同材料之间的数据一致性是审核重点。模型参数量、训练数据规模、测试样本量、拦截率指标，任何两个地方出现冲突都会被追问。我们吃过一次亏：安全报告里写的测试集样本数是三万，算法说明里写的训练数据规模附了一张表，两者在数据处理环节的数字对不上，补正意见专门列了一条。后来所有关键数字统一维护在一张"数据事实表"里，谁写材料都从这张表取数。

6. 登记通过之后还有日常义务清单

6.1 重大变更要主动报备

登记编号拿到之后，日常义务比很多人以为的多。最核心的一条是模型重大变更的主动报备，包括但不限于：模型大版本升级、训练数据来源发生重大变化、核心功能或使用场景调整、对外服务主体变更。触发报备的标准建议提前和相关部门确认清楚，别等着被抽查了再补。

我们内部建了一条规则：算法侧任何涉及模型版本升级的发布流程里，都加一个"是否需要登记报备"的检查节点，由接口人判断。这个节点已经帮我们拦下了好几次"差点直接上线"的情况。

6.2 日常巡检和内容抽查记录

登记通过后，内容安全的日常运营记录也要保留好。审核侧关注的不只是你登记那一刻的安全能力，更是你持续运营中的安全表现。用户投诉处理记录、内容巡查日志、模型回答被举报的处置记录，这些都建议按月归档，形成固定的运营台账。

6.3 抽查应对清单

日常运营期间存在被抽查的可能。抽查通常要求提供模型运行情况说明、安全事件处理记录、用户投诉处理记录等材料。我们准备了一个"随时可交"的抽查材料包，内容包括最新的模型版本说明、最近三个月的安全运营台账、应急预案联系人名单和处置流程说明，每季度更新一次。这样无论什么时候接到通知，都能在一天内整理出完整的材料。

最后再分享两个实际体会

走完这一轮登记流程，我最大的感受是：这件事考的不是技术难度，而是团队的流程纪律。技术再好，数据说明说不清楚、测试记录没做留痕、跨部门材料口径不一致，照样会被一次次打回。与其到提交前疯狂补材料，不如立项第一天就把登记当成产品需求的一等公民来排期。

另一个小技巧是文件命名：统一用"登记材料_材料名_版本号_提交日期"的格式归档，每次补正后同步更新版本号和日期，别用"最终版""最终版2"这种命名方式。等你好几个月后做变更报备时，想找回某份材料对应的原始版本，会发现这个习惯救了大命。整个登记流程走完，留下的这套材料和版本管理机制，后续做任何合规类申报都能直接复用。