大模型备案流程

团队把模型包好、接口也跑通了，准备对外开服务，这时候才有人问一句「备案做了吗」，然后发现没人说得清走哪条路、要交什么。这篇不讲法条原文，只给一套可执行的判断顺序：先定位自己属于哪类主体和哪种服务形态，再列材料清单，最后说清各环节常见的退回原因。具体口径和数量要求以站内合规页面当时的版本为准。

模型包好了，接口也跑通了，准备对外开服务，这时候才有人问一句「备案做了吗」，然后发现没人说得清走哪条路、要交什么。这种事很常见，因为备案不是一次性提交动作，而是一条从判断主体到准备材料、再到对齐线上实际配置的链子。

这篇不讲法条原文，只给一套可执行的顺序：先定位自己属于哪类主体和哪种服务形态，再列材料清单，最后说清各环节常见的退回原因。具体口径和材料数量要求会变，写死的数字不靠谱，要去站内合规页面核对当时版本。站内指南中心和资料库把名词和流程口径都对齐过一遍，动手前先翻一遍能省掉大量返工。

先定位：你到底走哪条路

大多数团队的返工不是材料写错，而是路走错了。同样一个模型，自研对外提供、拿第三方模型做应用、只在企业内部使用，这三类要做的动作完全不同。先用十分钟把下面两个维度各自对一遍，再决定后面怎么写材料。

还有一条边界要先说清：企业内网自用、不对外提供服务的场景，通常不适用对外备案那套流程。别照着别人的清单硬套，别人的主体类型和服务形态可能跟你完全不一样。判断不清时，先在站内把术语对齐，用错名词是材料被退回的常见原因之一。

材料准备清单：按这四类攒

材料不要按别人给的模板一条条抄，而是按类攒。同一类里的东西互相之间有关联，改一处要同步改另一处。下面四类基本覆盖大多数团队要准备的内容，具体份数和格式去站内合规页面核对当时的数字。

• 主体与资质类：营业执照、法人信息、相关许可与承诺文件，先确认有效期和一致性，别出现主体名称前后不一致
• 模型与语料类：模型来源说明、训练或调用方式、语料来源与授权情况；用第三方模型要写清是哪条通道、有没有做过二次训练
• 安全与内容管理类：内容审核机制、应急处置流程、投诉举报入口、日志留存方案，这部分最容易只写一句「已接入」就交上去
• 用户与数据类：个人信息处理说明、未成年人保护措施、数据是否出境的判断；接口类服务还要写清调用方准入和管理方式

攒材料时同步做一件事：给每个字段标一个「来源系统」和「负责人」。比如日志留存这段，标清对应哪个日志系统、谁在维护。评审前自己先按这张表过一遍，能提前发现「文档里写了、线上其实没做」的段落。

推进顺序：别一上来就写文档

很多团队的顺序是反的：先开一个文档，边写边想。结果写到一半发现服务边界还没定，安全机制线上也没实现，只能推倒重来。正确的顺序是先定边界、再定技术口径、最后才动笔。

1. 画清服务边界回答谁能用、给什么能力、数据落在哪三个问题。边界不清，后面所有材料都会返工；边界写下来，让产品和技术各签一遍。
2. 定技术口径确认审核是自建还是接第三方、日志留多久、故障怎么降级。写进文档之前，先确认线上真的能做到，做不到就改方案，不要靠文字凑。
3. 动笔并对照系统边写边对照自己系统的实际配置。写一套、跑一套是退回率最高的原因，写完一段就找对应系统的负责人确认一遍。
4. 做内部对照表每个字段对应哪个系统、哪个负责人列成一张表。评审前自己先过一遍，把对不上的地方先改掉。

推进过程中要有人对整体负责，不能四类材料分散在四个人手里各自为战。主体信息、模型来源、安全机制、用户数据这几块之间是有引用关系的，改一处往往要牵动另一处。

常见卡点与排查顺序

被退回时不要从头乱翻，按固定顺序查：主体资格 → 服务边界 → 安全机制 → 材料一致性。按这个顺序查，多数问题在前两步就能定位，别跳步。跳步的代价是你以为在改安全机制，其实问题出在主体信息上。

高频退回原因集中在三处：语料来源写不清、审核机制只有一句「已接入」、主体信息与承诺文件对不上。这三处都属于「看起来写了、其实没法核实」，改的时候要给出可验证的做法，而不是换一个说法。

• 上线后再变更功能、换模型、加接口的，要重新评估是否需要更新材料，别默认一次过就永久有效
• 换模型通道、调整审核策略、新增数据字段，都属于可能触发重新评估的变更，留一份变更记录
• 不同地区、不同服务类型的具体要求会有差异，本文只给方法不给结论
• 具体口径、份数、时限以站内合规页面当时的内容为准，动手前先去核对一遍

把上面这套顺序走一遍，至少能保证你不是在错的方向上勤奋。备案这件事没有一劳永逸的做法，功能一变、模型一换、数据流向一调，就要回来重新对一遍。