大模型备案自查清单：数据、模型、运营三线落地指南

做算法备案和大模型备案这件事，我们组前后推过三轮自查，才把材料整理得能真正见人。第一次以为只是填几份表，翻到训练数据情况说明时才发现一堆细节对不上——某个公开数据集当初是怎么清洗的、过滤规则跑过几版、测试样本是谁抽的，全都没有留痕，当场抓瞎。后来把自查清单逐步标准化，变成逐条可勾选的表格，整个流程才顺畅起来。这篇内容就是把我们实际落地用过的一套快速自查清单整理出来，按数据、模型、运营三条线展开，每条都对应到可执行的动作和材料，适合正在准备大模型备案材料的技术负责人、算法工程师，以及负责产品和合规接口的同事先通读一遍。

算法备案不是单点动作，而是从模型开始训练到上线运营全流程都要对得上的一套证据链。很多人以为备案只看评估报告，真实情况是审查方会从训练语料授权、过滤规则、测评记录、日志留存、投诉处理等不同角度交叉确认。所以自查的意义在于提前把这条证据链补完整，而不是临时抱佛脚凑材料。

1. 为什么要把备案自查当作独立工程来做

1.1 先判断你的产品属于哪一类

备案自查的第一步不是拉文档模板，而是先给自家产品定性。同样是接入大模型，行为不同，需要准备的检查项差别很大。我们内部把常见情况分成三类：

• 自研或深度微调基础模型，面向公众提供生成式服务。这类最复杂，训练数据说明、模型安全自测、评估报告、日志方案全都跑不掉。
• 使用已有API但做了产品化封装，比如给模型加了知识库、Agent工具或特定业务指令。这类重点在服务侧的合规机制，比如输入输出过滤、用户提示限制、日志留存和投诉反应。
• 纯内部工具，不直接面向公众。相对轻一些，但也要确认是否涉及对外输出能力、账号权限是否闭环、日志是否留存。

我遇到过几个团队，上来就按“自研模型”全套准备，辛苦做了一堆模型训练数据文档，实际上产品只是站在API基础上做了一层界面，最后发现重心完全放错了。反过来，也有团队只调API，误以为什么都不用做，等渠道方找上来要备案编号才着急。所以第一件事就是把你自己的技术架构、服务对象、数据流转路径画清楚，再决定查什么。

画这个图不需要很复杂，一张A4纸足够：输入侧是什么，模型侧是自己的还是第三方的，输出侧到哪里，日志存哪里，审核和过滤在哪个环节生效。把这条链路画出来后，再对应自查项就一目了然了。

1.2 自查覆盖的三条主线

我们最终把全套自查项收敛成三条主线：内容侧、技术侧、运营侧。

内容侧管的是“模型学什么、说什么”。包括训练语料的来源是否合规、有没有包含违法违规内容、是否存在侵犯个人信息或知识产权的情况、生成内容是否会出现误导性信息。这条线最容易出问题，因为很多模型训练时语料来源本身就比较杂，公开数据集、爬虫数据、第三方采购数据混在一起，要逐项说清楚需要花大量时间。

技术侧管的是“模型怎么防、防得怎么样”。包括是否接了输入输出过滤、有没有设置拒答与安全指令、对抗攻击和越狱输入的测试结果如何、以及在遇到安全对抗时系统是否会退化为不可用或直接泄露底层指令。常见误区是只跑了几组测试样例就觉得够了，实际上审查方更看重测试设计的系统性和结果分布的合理性。

运营侧管的是“服务上线后怎么管”。这里包括日志留存时长与权限控制、用户实名和协议告知、投诉处理流程、违规内容快速下线和账号处置机制、生成内容的标识方式。运营侧文档做得好不好，往往比技术测评更能体现一个团队的管理成熟度。

三条主线不是三张独立表，而是要互相咬合。比如技术侧说“我们接了关键词过滤和分类模型”，运营侧就要有对应日志记录每次过滤触发的详情；内容侧说“训练语料已清洗”，技术侧就要有清洗规则和实际执行的版本记录。自查时最怕的就是材料之间对不上。

2. 逐项对照：我可直接套用的备案自查清单

2.1 数据和语料侧的自查项

数据这一块是整个自查里面最费时间的，因为很多团队在前期训练时根本没有建立规范的数据管理习惯。我们后来建了一张数据来源登记表，把模型用到的每类数据都列清楚，这张表一直到备案提交都在维护。字段如下：

这份表的价值在于，当被问“某个语料集具体怎么来的”时，你可以直接打开表格定位到那一行，把所有上下文说清楚，而不是靠回忆。我们就有过因为一个爬虫数据集没有记录授权状态，后期被动补材料的经历，光是找原始页面和确认归属就花了好几天。

除了来源登记表，还要准备数据过滤记录。哪怕你的数据清洗脚本很简单，只要跑过，就要把脚本、参数、运行时间和结果量记录下来。审查关注的不只是你“做了什么”，而是你有没有能力证明这件事确实做了。建议从训练开始时就把数据清洗作为一个独立版本管理的流水线，每次改动留commit记录。

2.2 模型能力与生成内容侧的自查项

模型侧的自查不是简单跑几个测试问题看回复正不正常，而是要做成系统性的测评，并且把测评过程记录下来。我把我们实际使用的测试框架整理成以下维度，供你对照：

• 常规安全测试：色情、暴力、违法信息、恐怖主义、仇恨言论、性别/种族歧视等类别，每类准备一批典型问题，观察模型是正常回答、拒答，还是诱导出风险内容。
• 对抗与越狱测试：角色扮演、虚构场景、多轮对话拆解、prompt注入、间接越狱等方式，判断现有安全对齐是否容易被击穿。这类测试用例不需要特别多，几十到上百条都行，关键是覆盖不同的攻击模式，不能只测一种套路。
• 幻觉与误导性内容：涉及医疗、法律、金融、人身安全等高风险领域时，模型是否给出明确建议或编造信息，是否带有免责声明。高风险领域是审查比较关注的场景，建议单列一组用例。
• 多轮与上下文安全性：单独几句没问题不代表多轮对话没问题，需要测试模型在长上下文里是否会被历史信息带偏。
• 拒绝率与误杀率平衡：安全对齐不是越激越好，如果大量正常问题被拒答，在产品上根本没法用。要记录正常问题被误杀的比例，以及拒答话术是否合理。

所有测试都要落成台账。我的习惯是每轮测试建一个文件夹，里面包括测试用例清单、模型版本、测试时间、关键截图和结果汇总。不要只留最终结论，过程记录才是自查最有说服力的部分。

生成内容侧还有一个容易被忽略的环节——模型是否具备对敏感指令的稳定拒绝能力。比如用户要求模拟某个被限制的角色，或者要求输出违规内容时改用另一种说法，模型能不能识别出来。这个能力需要靠system prompt和训练对齐共同保证，自查时可以通过专门的“翻写测试”来验证，即用多组同义替换的请求观察拦截率是否达标。

2.3 产品运营与用户侧的自查项

运营侧的检查经常被技术团队认为“不是我的事”，但备案材料里这部分占比很低往往却很致命。我们按以下项目逐项建了目录：

• 用户协议与隐私政策：要明确写清使用了生成式AI能力、用户输入会怎么处理、数据保存多久、用户有哪些权利。协议版本要有修订日期和生效日期，避免拿三年前的版本凑数。
• 实名认证与未成年人保护：面向公众的服务需要验证或引导实名，未满十四周岁的用户要有单独的保护机制，比如内容限制、消费限制等。即使产品不直接面向未成年人，也要在协议和机制里说明你的判断和对应措施。
• 投诉与举报渠道：用户在哪里可以看到反馈入口，反馈后多长时间响应、流程怎么走，都要有明文制度。不能只留一个邮箱就算完，要有处理时限和升级路径。
• 日志留存机制：记录内容包括用户ID、输入时间、输入内容、模型输出、过滤命中情况等。要说明留存时长、访问权限控制、防篡改措施。这里的难点在于很多团队没有建立统一的日志平台，模型响应日志散落在不同服务里，需要提前做一次收敛。
• 生成内容标识：生成的文字、图片、音频是否需要带提示标识，比如“AI生成”角标或隐蔽水印。这个目前几乎成了必查项，尤其是对外输出图片和长文本的服务。

运营侧自查的产出不只是一堆文档，更要确保实际动作能对上。比如协议里写了“用户可申请删除个人信息”，那后台就要真有删除入口和处理流程，审查时如果抽查到这个，不能只是嘴上说有。

3. 实操落地：从自查到可提交的全流程

3.1 把自查表转成备案材料目录

自查表是内部用的，最终提交时要转换成一套规范的材料目录。两个东西不是一回事，但内容要一一对应。我建议做一张映射表，列出每个自查项对应提交文件中的哪一节，这样在准备材料时可以直接按自查表逐条索引，不会漏。

我们跑下来，备案材料基本围绕这几份文件展开：

• 安全评估报告：对模型和数据的安全风险进行整体评估，说明风险点与应对机制。
• 算法机制说明：描述模型架构、训练方式和主要运行逻辑，特别要解释“模型具有什么样的行为和能力”。
• 训练数据情况说明：对应数据来源登记表，附过滤记录和授权情况。
• 用户服务协议与隐私政策：运营侧必备，版本信息要齐全。
• 内容安全管理机制：关键词库、过滤规则、分类模型、人工审核流程、应急响应预案。
• 日志留存方案：涵盖系统架构、字段清单、权限控制、留存周期。

这些文件切忌直接丢一个大文件夹就提交。每份文件要有版本号、负责人、更新时间，因为自查过程中一定会改来改去，没有版本管理的材料短期内就会乱到分不清哪份是最新的。

3.2 建立测试台账与测评记录

模型安全测评最容易被人质疑的地方是“你测了哪些用例、为什么测这些”。所以台账一定要能回答这两个问题。测试设计阶段就建议先列测试策略说明，再写具体用例，而不是随手写几十个问题就开跑。

测试用例管理可以用最简单的方式：一个表格外加一个截图目录。字段包括：

每次模型迭代完都要重新跑一轮，而不是只测一次。我们经历过模型更新后原本能拒答的几类问题突然漏了，就是因为没有做回归。备案自查视角下，多轮回归结果可以证明团队对安全性的持续投入，这一点比单次完美报告更有说服力。

3.3 制度建设与留痕管理

很多团队在提交材料时才发现，自己有安全管理制度，但没有执行记录。比如制度里规定了“每月巡检一次”，结果拿不出任何巡检表、会议记录或问题整改单。这本质上和代码没有commit记录一样，等于没做。

好用的做法是把制度文件和留痕文件分开归档，然后在制度里明确引用对应的表格编号。比如：

• 内容安全管理制度 v2.1（2025年X月修订）
• 配套表单1：月度内容安全巡检表（每月更新）
• 配套表单2：违规内容处置登记表（实时更新）
• 配套表单3：用户投诉处理台账（实时更新）

表单比制度文档重要。审查方看你是“实跑”还是“纸面”，基本就看这些记录是否连续、时间是否合理、有没有明显补填痕迹。所以从决定做备案的第一天起，就要把这些记录习惯建立起来，哪怕最初很粗糙，也好过事后编。

3.4 时间规划与分工建议

备案材料的准备周期通常按2到4周规划比较稳妥，具体取决于现有材料完整度。我们实操中的时间分配大致如下：

• 第1周：产品定性与框架梳理，完成数据来源登记表初稿，确定材料责任人。
• 第2周：模型测试台账搭建并启动第一轮测评，补齐过滤规则文档。
• 第3周：运营侧文档完善（协议、举报、日志方案），同步推进安全评估报告撰写。
• 第4周：材料交叉审核、查漏补缺、定稿提交。

分工上建议设一个总接口人，负责材料版本的统一和跨部门进度协调。算法、产品、法务/合规、运维每组都要有明确交付物，很多团队拖进度就是因为没有总接口人，算法以为法务在写协议，法务以为算法在做评估，结果两周后谁都没动。

我们使用的分工表示例：

4. 自查中最常被问到的五个问题

4.1 只做API调用也要准备备案材料吗

这个问题的答案取决于你的产品形态。如果你只是在自己内部用一下，不对外提供生成式服务，通常不需要做全套备案。但只要你的产品面向公众，哪怕底层模型是别人的，运营行为（收集用户输入、生成内容、保存日志）本身就在备案考察范围内。我的判断标准是：用户能不能直接在你的产品里和大模型产生对话或内容生成？能，那就需要准备材料，重点不在模型，在服务和内容管理机制。

4.2 训练数据授权不完整该怎么处理

如果训练数据里有来自公开渠道但不能完全确认授权的部分，先把最新可查的授权状态写清楚，不要含糊。能换掉的数据尽量换，不能换的就要在数据说明里明确处置方案，包括风险分析、过滤动作、以及后续补救计划。我们处理过一批爬虫数据，最终方案是全部重新清洗并用规则匹配删除了有明确版权标识的内容，同时保留了完整的清洗脚本和运行日志。这一套动作下来反而比简单写“已授权”更有说服力，因为审查方看到的是你在努力控制风险。

4.3 测评出现较高误杀率怎么办

误杀率高说明安全策略过于激进，这在实际产品中会影响可用性，备案评估里也不是好信号。处理思路分两步：先看误杀集中在哪些类目，针对具体类目调整过滤阈值或补充白名单规则；然后做一轮回归测试，用之前的正常用例重新验证，把误杀率压到可接受范围。重要的是把整个调整过程记录成版本化的迭代日志，说明每次改动的原因和效果。这比只提交一个最终漂亮数字更显得真实。

4.4 多部门协作材料版本混乱怎么根治

大型团队常见的问题法是材料散落在个人电脑和聊天记录里，版本对不上。我们最终的方式是建了一个共享目录，所有材料按“类型-版本-日期”命名，比如“安全评估报告_v2.3_20250115.docx”，同时维护一张总目录表，标注每份文件的最新版本和责任人。任何修改都先登记再动手，不接受“回头统一处理”这种说法。虽然麻烦，但坚持两周后就会发现这套命名和登记机制省了后面大量的找文件时间。

4.5 自查会不会导致产品功能“越改越保守”

这是一个实际发生过的问题。安全自查做多了之后，产品在某些话题上变得非常敏感，正常内容也被误杀，用户体验明显受损。我的建议是安全策略用分层设计：高敏类目直接拦截，中低敏类目走提示和引导，正常类目完全放行。同时定期统计误杀率，把正常问题的误杀率作为安全策略调整的一个硬指标。备案不是让产品变得不可用，而是让风险可控的同时保证正常能力，这两者需要靠精细化的规则配置来实现平衡。

最后说几句个人体会

整个备案自查走下来，我最深的感受是这套工作最大的价值不在应付审查，而是逼着团队把内容安全从“口头重视”变成“系统能力”。很多团队平时其实做了不少安全工作，比如数据清洗、对抗测试、日志记录，但因为没有统一记录和归档，真到用的时候拿不出证据，等于白做。所以我从第二轮自查开始就把记录习惯放在第一位，任何测试和调整都当场写到台账里，不再依赖回忆补填。

一个小技巧：把自查清单挂到团队的项目文档中心，每周周会花十分钟过一遍状态，而不是集中突击。这样整个过程会平稳很多，材料也会随着项目进展自然积累。希望这份清单能帮你在备案这件事上少走弯路，一次把材料备齐。