大模型备案材料被退：不是少文件，是证明链断了

+cyobobo大模型备案&算法备案

378人浏览 · 2026-06-11 11:57:22

+cyobobo大模型备案&算法备案 · 2026-06-11 11:57:22 发布

「材料明明很齐全，为什么还是被退了？」

在大模型备案、生成式人工智能服务备案、上线登记过程中，企业材料被退回或被要求补正，表面原因通常表现为文件缺失、说明不充分、截图不完整或制度表述不清。但从实际项目经验看，根本原因往往不是「少一个文件」，而是产品、模型、数据、安全测试、整改记录和上线管理之间没有形成可验证的证明链。

1不是少文件，是证明链断了

在很多企业的理解中，大模型备案或上线登记是一项「材料提交工作」。因此，一旦材料被退回，企业通常会先问：是不是少了一份制度？是不是少了一张系统截图？是不是安全评估报告写得不够长？是不是需要再补一份承诺函？

这些问题并非没有意义，但它们只停留在表层。从备案审查逻辑看，监管关注的并不是企业是否准备了一堆文件，而是企业能否证明以下事实：

产品到底是什么；
产品是否具备生成式人工智能服务属性；
模型来源是否清楚；
数据来源是否合法、可追溯；
安全评估是否真实开展；
风险整改是否形成闭环；
上线后是否具备持续管理能力......

如果这些问题之间不能相互印证，即使文件数量很多，也容易出现材料逻辑断裂。例如：产品说明写的是「企业知识库问答系统」，但语料说明只写「公开数据」，没有解释客户上传文档、内部资料和业务数据如何处理；模型说明写的是「调用第三方已备案大模型 API」，但安全评估报告却像是在评估自研模型，没有说明应用层输入输出审核、日志留存和投诉举报机制。

图示：提交至网信办过审版本材料

这些问题不是「材料缺页」，而是「证明链断点」。备案材料被退，往往不是因为文件不够多，而是因为文件之间无法相互证明。

2备案材料不是文件集合，而是证据系统

为了避免泛泛讨论，可以先给出一个分析定义。本文所说的「大模型备案材料证明链」，是指企业围绕一个具体 AI 产品，能够连续证明以下事实的一组材料、记录和系统截图：

产品真实存在，模型来源清楚，数据来源可解释，安全测试可验证，风险整改可追溯，上线管理可落地，持续监管有机制。

也就是说，备案材料不是孤立文件，而是一个证据系统。该系统至少包括七个环节：

1.产品定位

说明产品名称、功能、服务对象、应用场景、输入输出方式

2.模型来源

说明自研、开源部署、微调、私有化部署或第三方 API 调用情况

3.数据来源

说明训练数据、知识库数据、测试数据、用户上传数据的来源和处理方式

4.安全评估

说明测试题库、关键词库、攻击测试、正常问题测试和评估结果

5.整改闭环

说明风险发现、原因分析、措施调整、复测确认和留痕记录

6.上线管理

说明服务协议、投诉举报、显著标识、日志留存和用户提示

7.持续监管

说明上线后监测、关键词库更新、风险样本复盘和版本迭代机制

如果其中某一环无法被前后材料支撑，就会形成断点。

3路径判断：先确定属于哪类问题，再准备材料

在实际项目中，很多材料问题不是出在写作能力，而是出在路径判断错误。企业常见的误判包括：调用第三方已备案大模型 API，就认为自己完全不需要备案或登记；原有 SaaS 系统只是新增 AI 功能，就认为不需要重新判断合规路径；知识库问答系统只回答企业文档，就认为不属于生成式 AI 服务；产品还在内测，就认为不需要做任何安全评估和材料准备；已经做了算法备案，就认为不需要再关注生成式 AI 备案或上线登记。

这些判断都过于粗糙。从企业实操角度，可以先将问题拆成几个变量：

这些变量共同决定企业更接近哪类路径：

完整备案

通常适用于以生成式人工智能服务提供者身份，对外提供具有生成能力的模型服务或产品服务的情形。材料重点通常覆盖产品、模型、语料、安全评估、服务协议、标识、投诉举报、日志留存和持续管理。

上线登记

通常适用于直接调用已备案模型能力形成应用或功能的情形，但仍需结合产品是否面向公众、是否形成独立服务、是否存在微调或组合改造等因素判断。

算法备案

主要关注互联网信息服务算法应用，如生成合成类、个性化推送类、排序精选类、检索过滤类等。它与大模型备案、上线登记存在交叉，但不能简单等同。

内部合规整改

对于尚未面向公众、处于内测或企业内部使用阶段的 AI 功能，可能暂不进入完整备案流程，但仍应提前完成安全测试、数据合规、权限控制、日志留存和风险处置机制建设。

4第三方 API ：模型责任不等于应用责任

第三方 API 调用是目前最容易产生误判的场景。很多智能客服、知识库问答、AI 写作、SaaS AI 功能和数字人问答产品，并不自研大模型，而是调用通用大模型或行业大模型 API。企业常见理解是：「底层模型已经备案了，我只是调用接口，所以风险应该由模型服务商承担。」这个理解只成立一部分。

底层模型服务商承担的是模型能力相关责任，而应用方仍然需要承担应用层责任。原因很简单：用户实际接触的是你的产品，而不是底层模型接口。

应用层至少涉及以下问题：

用户输入是否经过安全审核；
模型输出是否经过安全审核；
是否接入企业知识库、客户资料或用户上传文件；
是否设置敏感问题拒答机制；
是否有日志留存；
是否有投诉举报入口；
是否在显著位置公示所使用的 AI 能力；
是否在服务协议中说明 AI 生成内容的局限；
是否对用户数据进入模型处理流程作出说明；
是否保留 API 调用合同、接口配置、控制台截图和调用说明。

换句话说，调用第三方 API 可能影响备案路径，但不会自动消除应用方的合规义务。对于 API 调用型产品，材料证明链通常应包括：第三方模型名称、模型服务商信息、接口调用方式、API 合同或采购证明、控制台配置截图、系统架构图、输入输出审核机制、日志留存机制、投诉举报机制、服务协议与用户提示、上线页面显著公示截图。如果企业只提供「我们调用的是某某大模型 API」这一句话，而没有后续证明材料，通常无法形成完整说明。

5证明链断点一：产品说明和真实功能不一致

备案材料的第一环是产品定位。产品定位不是宣传文案，而是后续所有材料的基础变量。一个合格的产品说明至少要回答：产品服务谁、解决什么问题、用户输入什么、系统输出什么、是否具备生成能力、是否接入知识库或业务数据、是否面向公众用户、是否存在多端入口（例如网页、App、小程序、API 或企业系统插件）。

如果产品说明写不清，后续材料都会失焦。例如：智能客服产品如果只写「提升客服效率」，但不说明是否自动生成回复、是否支持人工转接、是否接入客服知识库，就无法判断安全评估重点；知识库问答产品如果只写「基于资料回答问题」，但不说明资料来源、权限隔离、上传文件处理方式，就无法判断语料合规重点；SaaS AI 功能如果只写「提供智能分析能力」，但不说明 AI 功能嵌入在哪些业务模块，就无法判断是否形成独立生成式 AI 服务；数字人问答产品如果只写「提供智能交互」，但不说明文本、语音、形象、视频输出边界，就无法判断标识、授权和内容安全要求。

6证明链断点二：模型来源说不清

模型来源是第二个关键断点。企业应区分以下几种情况：

自研模型；
开源模型本地部署；
在开源模型基础上微调；
调用第三方商业模型 API；
多模型组合调用；
检索增强生成（RAG）；
外部模型加企业知识库；
外部模型加业务规则、提示词工程或审核模型。

不同来源对应的证明材料不同。如果是自研或微调模型，通常需要说明模型架构、训练语料、训练过程、评估方法和安全控制。如果是开源模型部署，通常需要说明开源模型名称、版本、许可证、部署方式、是否微调、是否商业使用。如果是第三方 API 调用，通常需要说明服务商、模型名称、接口地址、调用范围、合同或控制台证明。如果是 RAG 知识库问答，则不能只讲底层模型，还要说明知识库如何构建、文件如何上传、向量库如何管理、检索结果如何进入提示词、回答是否引用知识来源。

模型来源说不清，后续安全评估和语料合规都会出现问题。例如，企业写「本产品基于大模型能力生成答案」，但没有说明到底是自研、开源部署还是 API 调用。此时，监管无法判断企业应承担的是模型层责任、应用层责任，还是两者都有。

7证明链断点三：数据来源被一句「合法来源」代替

语料合规是材料中最容易被低估的部分。很多企业会在材料中写：「本产品数据来源合法合规。」但这句话本身没有证明力。

从备案材料角度，数据至少应分为四类：

不同数据类型不能混写。例如，知识库数据不一定用于训练，但它可能参与生成过程；测试数据不一定来自业务系统，但它可能包含敏感样本；用户上传文件不一定入库，但它可能被模型处理。

因此，语料合规说明至少要回答：数据来源是什么、是否取得授权、授权范围是否覆盖当前用途、是否允许训练测试生成或商业使用、是否包含个人信息商业秘密或知识产权内容、是否经过清洗脱敏和过滤、是否有入库记录使用记录和删除机制、是否区分训练数据知识库数据测试数据和用户上传数据。如果企业知识库、训练语料、用户上传文件来源复杂，建议优先做「语料合规」梳理。很多材料问题不是出在模型，而是出在数据边界不清。

语料合规不是一句声明，而是一套流程：数据来源识别 → 授权证明核验 → 敏感信息识别 → 清洗脱敏 → 风险标注 → 入库留痕 → 定期复核。

8证明链断点四：安全评估只有结论，没有过程

安全评估是备案材料中最容易「纸面化」的部分。常见写法是：「系统已建立内容安全审核机制。」「系统已设置关键词库。」「系统已完成安全测试。」「测试结果符合要求。」这些表述不是不能写，而是不能只写结论。

安全评估的核心不是声明系统安全，而是证明系统经过了系统性测试。一个相对完整的安全评估体系，应当至少包含六类证据：

1.测试题库

包括违法违规内容、不良信息、侵权风险、个人信息、商业秘密、虚假信息、诱导绕过等类型

2.关键词库

包括风险分类、关键词来源、更新频率、命中记录和维护责任人

3.攻击性输入测试

包括角色扮演、拆字、谐音、错别字、编码、多轮诱导、上下文绕过等方式

4.正常问题测试

用于验证系统不是简单拒答，而是在正常业务问题下仍能保持可用性和准确性

5.人工复核机制

对机器审核命中、边界样本、用户投诉和高风险输出进行复核

6.整改和复测记录

说明问题如何发现、原因是什么、采取了什么措施、复测结果如何、责任人是谁、完成时间是什么

如果安全评估报告缺少这些证据，就容易形成「测试—整改」断点。尤其是很多企业只做敏感问题测试，不做正常业务问题测试。结果报告看起来很安全，但无法证明产品可用。安全评估不是让模型什么都不回答，而是让模型在合规边界内稳定回答。

图示：安全评估报告

9证明链断点五：整改闭环没有留痕

备案材料中经常会写「已整改」「已优化」「已完善」。但这些词本身没有证明力。整改闭环至少要包括五个步骤：

风险发现—— 原因分析—— 措施调整—— 复测验证—— 记录留存

例如，安全测试中发现某类诱导问题可以绕过审核，企业不能只写「已优化审核策略」。更完整的写法应当说明：该问题出现在什么测试样本中；触发原因是关键词库未覆盖，还是审核模型漏判；采取了什么措施，例如新增关键词、调整提示词、增加输出审核规则；复测使用了哪些样本；复测结果是否通过；整改记录由谁确认，何时完成。这类记录不一定需要写得复杂，但必须存在。否则，安全评估报告和整改说明之间就接不上。

10证明链断点六：材料写了，但产品没有落地

有些企业材料本身写得很完整，但产品上没有实际入口或截图支撑。例如：服务协议写了投诉举报机制，但页面上没有投诉入口；材料写了 AI 生成内容标识，但产品输出页面没有任何提示；材料写了日志留存，但系统没有日志字段或留存策略；材料写了人工复核，但后台没有审核记录；材料写了显著位置公示，但官网、App 或产品详情页没有展示。

这种情况属于「制度—执行」断点。备案材料不仅要证明企业知道应该做什么，还要证明企业已经在产品中做了相应设计。因此，上线管理材料通常需要配套以下证据：产品页面截图、服务协议截图、用户提示截图、AI 生成内容标识截图、投诉举报入口截图、后台审核记录截图、日志字段说明、权限配置说明、风险处置记录、版本更新记录。如果材料只停留在制度文本，而没有系统截图和执行记录，可信度会明显降低。