2026年最新｜大模型备案资料规范指南

一、为什么大模型备案资料越来越强调规范性

大模型备案资料，并不只是"把文件写清楚"那么简单。随着生成式人工智能服务从技术验证走向公开应用，你可以把备案资料理解成验收报告，只有所有环节都到位了、都可追溯，才算合规。

一句话总结：大模型备案资料，要把企业的AI服务说清楚、把风险控制讲明白、把责任链条立起来。

二、搞懂大模型备案资料规范底层逻辑

很多企业咨询我的时候，会先问："需要哪些文件？"但还不够，更关键的是："这些文件之间要证明什么？"

大模型备案资料的底层逻辑，可以概括为四个字：可审、可信、可控、可追。

"可审"，是指主管部门能够通过材料看懂产品。产品是什么、服务谁、在哪里使用、是否面向公众、是否生成文本、图片、音频、视频等内容，这些基本问题必须清楚。如果连产品边界都模糊，后续材料再完整，也容易陷入解释成本。

"可信"，是指企业提供的事实能够相互印证。备案表里写的是智能客服，模型说明里却写成内容创作；产品说明里说只用于企业内部，服务协议又面向公众开放；安全评估里写已覆盖输出审核，技术流程图里却没有输出审核节点。这类前后不一致，是资料规范中最常见的问题。

"可控"，是指企业必须说明风险控制措施，而不是只作原则性承诺。不能只写"系统具备内容安全能力"，而要写清楚输入端如何审核、模型端如何约束、输出端如何检测、人工如何复核、问题如何整改。

"可追"，是指生成内容、用户行为、审核记录、投诉处理、整改过程能够留痕。大模型服务不是一次生成结束，真正的合规管理要能在风险发生后回溯原因、定位责任、形成闭环。

备案资料像一张工程图。工程图的价值不在于画得复杂，而在于让人一眼看清结构、承重、管线和风险点。大模型备案资料也是如此，真正重要的不是文字多少，而是逻辑是否完整。

一句话总结：资料规范的核心，不是"写得多"，而是"写得清、对得上、查得到、能整改"。

企业在正式准备大模型备案资料前，建议先完成一次"资料证明链自查"：主体、产品、模型、语料、安全评估、内容标识、服务协议是否能够相互印证。很多资料被反复修改，并不是因为少了一份文件，而是因为材料之间没有形成闭环。

三、大模型备案资料的整体框架

大模型备案资料组成部分：

第一层是主体与产品资料，解决"谁在提供什么服务"的问题。包括企业主体、产品名称、服务入口、服务对象、上线状态、使用场景等内容。

第二层是模型与算法资料，解决"服务能力从哪里来"的问题。包括模型来源、模型名称、版本信息、部署方式、调用方式、算法原理、技术流程等内容。

第三层是训练数据与语料资料，解决"模型和知识来源是否合法、可靠"的问题。包括训练数据、微调数据、知识库数据、提示词库、测试题库等不同类型数据的来源、规模、用途和处理方式。

第四层是安全评估资料，解决"上线前是否充分测试风险"的问题。包括语料安全、模型安全、生成内容安全、透明性、用户权益保护等评估内容。

第五层是内容安全机制资料，解决"服务运行中如何防控风险"的问题。包括输入审核、输出审核、拒答策略、人工复核、日志留存、投诉处置等。

第六层是生成内容标识资料，解决"用户是否知道内容由AI生成、平台是否能够识别追溯"的问题。包括显式标识、隐式标识、标识样式、标识位置、标识触发条件等。

第七层是服务协议与用户权益资料，解决"用户如何被告知、如何使用、如何投诉、如何救济"的问题。包括服务协议、用户规则、投诉举报入口、处理流程、反馈时限等。

主体资料说清责任，产品资料说清场景，模型资料说清能力，语料资料说清来源，安全评估说清风险，安全机制说清控制，用户权益资料说清外部治理。

一句话总结：大模型备案资料不是文件目录，而是一套从"能不能上线"到"如何安全运行"的证明体系。

四、主体与产品基础资料规范

主体与产品资料是备案材料的第一道门。它决定了主管部门如何理解企业身份、产品边界和服务对象。

主体资料：

• 写清企业全称

• 统一社会信用代码

• 注册地址

• 联系人、联系方式等基本信息

这里看似简单，但实际工作中经常出现主体混乱。例如，产品由A公司运营，技术由B公司提供，域名在C公司名下，协议又使用D公司的名称。多主体合作并不一定有问题，但责任关系必须说清楚。

产品资料：

• 重点说明产品名称

• 服务名称

• 服务入口

• 上线状态

• 服务对象和使用场景

产品名称要与对外展示名称、系统后台名称、服务协议名称保持一致。服务入口要具体，不能只写"网站""小程序""APP"，而应说明用户从哪里进入、使用什么功能、调用什么服务。

使用场景尤其要谨慎。场景写得过宽，会放大审核范围；场景写得过窄，又可能与实际产品不一致。比如一个智能客服产品，如果实际只用于ETC业务咨询、账单查询、售后解释，就不宜泛化为"全行业智能问答平台"。场景不是宣传口号，而是审核边界。

服务对象也要准确区分

• To C公众用户

• To B企业客户

• 内部员工

• 政企客户

合规判断和材料重点并不完全相同。企业不能为了显得业务广泛，把所有可能场景都写进去。

主体资料要稳，产品边界要准；备案材料里，宁可写实，不宜写虚。

五、模型与算法说明资料规范

模型与算法说明，是大模型备案资料中最容易被合规人员写虚的一部分。

很多材料会写："本服务基于大模型技术，具备自然语言理解和生成能力。"这句话并不能支撑审核。主管部门需要看到的不是一句技术概括，而是完整的技术路径：模型从哪里来，部署在哪里，如何调用，输入如何处理，输出如何生成，安全审核嵌入在哪些节点等等。

模型来源必须明确。常见情况包括自研模型、开源模型、第三方API、私有化部署模型、多个模型混合调用。不同来源对应不同说明重点。

• 自研模型要说明研发训练情况

• 开源模型要说明开源协议、权重来源、改造方式

• 第三方API要说明供应商、接口调用、责任边界

• 私有化部署要说明部署环境、版本管理和安全策略

模型名称和版本不能模糊。不能只写"通用大模型""行业大模型""国产大模型"，而应尽可能说明具体模型名称、版本、参数规模、部署方式和使用范围。模型是备案资料中的"发动机"，发动机型号不清，整车性能就无法判断。

算法说明要避免两个极端。一个极端是过于技术化，堆砌Transformer、Embedding等术语，却没有解释这些技术在产品里具体做什么。另一个极端是过于业务化，只写"帮助用户回答问题、生成内容、提升效率"，看不到模型处理过程。

规范写法应当按照"输入—处理—生成—审核—输出—留存"的顺序展开。例如，用户输入文本或语音后，系统先完成格式处理和内容安全校验；语音场景需要经过ASR转写；通过安全校验后进入大模型推理或知识库检索；生成结果再经过输出审核；审核通过后返回用户，并按要求添加标识和留存日志。

如果产品使用RAG知识库、插件调用、工具调用、多模型路由、ASR、TTS、数字人驱动等能力，也不能遗漏。很多备案资料被要求修改，并不是因为核心大模型没有写，而是因为旁路能力没有纳入说明。审核看的是完整服务链路。

六、训练数据与语料来源资料规范

语料资料是大模型备案材料中的重难点。它直接关系到模型能力来源、内容安全、版权风险、个人信息保护和数据合规。

企业首先要区分不同类型的数据。训练语料、微调语料、知识库数据、提示词库、测试题库、日志数据，不能混为一谈。

• 训练语料用于模型能力形成

• 微调语料用于特定任务优化

• 知识库数据用于检索增强

• 提示词库用于生成约束

• 测试题库用于安全评估

• 日志数据用于运行追溯

每一类数据用途不同，规范要求也不同。

数据来源要写清楚。常见来源包括

• 自有业务数据

• 公开数据

• 授权数据

• 合作方数据

• 人工构造数据

• 开源数据集等

这里最容易出现的问题，是把"网上公开"理解为"可以直接使用"。公开可访问，不等于无条件可训练；能下载，不等于有权用于商业化模型服务。对于涉及版权、个人信息、商业秘密的数据，应当说明授权依据、脱敏处理、过滤规则和使用边界。

语料规模要与业务实际匹配。规模可以用文件大小、样本数量、Token数量、数据条数等方式表达，但口径要一致。

对于行业模型或垂直应用，还应说明行业语料的覆盖范围，例如

• 客服问答

• 产品说明

• 业务规则

• 政策文件

• 知识库文档

• 历史工单等

语料处理流程要写出管理动作。包括

• 数据采集

• 清洗

• 去重

• 脱敏

• 分类

• 标注

• 质检

• 风险过滤

• 入库管理等环节。

这里不能只写"已完成清洗"，而要说明清洗什么、过滤什么、谁来质检、抽检比例如何、发现问题如何处理。

语料资料的本质，是证明模型不是"黑箱吃数据"。数据从哪里来、如何进入系统、如何被处理、如何用于模型能力，都要有轨迹。对主管部门而言，语料资料不是单纯看数量，而是看来源是否可靠、处理是否规范、风险是否可控。

七、安全评估资料规范

安全评估资料是大模型备案材料中的核心证明文件。它用来证明模型上线前已经经过风险测试、问题识别、整改复测和结论确认。

安全评估至少应覆盖几个关键维度：

• 语料安全

• 模型安全

• 生成内容安全

• 透明性

• 用户权益保护

• 安全措施有效性等。

不同类型产品还应结合具体形态增加评估内容。例如文本生成服务要重点关注违法违规内容、虚假信息、歧视偏见、隐私泄露、攻击诱导；图像和视频生成服务还要关注人脸、仿冒、虚假场景、版权和标识；语音服务还要关注仿声、身份混淆和音频标识。

评估资料不能只有结论。仅写"经评估，系统风险可控"，不足以构成有效证明。

规范的安全评估应当包括

• 评估范围

• 评估方法

• 测试题库

• 测试样本

• 测试结果

• 问题清单

• 整改措施

• 复测结果和最终结论

测试题库要有结构。不能简单堆几百条问题，而要按照风险类型分层设计。比如违法违规、政治安全、暴力恐怖、色情低俗、歧视偏见、虚假信息、个人信息泄露、未成年人保护、医疗金融法律高风险建议、提示词攻击、越狱诱导等。每类题目都应有判断标准，不能只靠主观感觉。

评估结果要能反映真实测试过程：

• 哪些题目被拦截

• 哪些题目拒答

• 哪些题目生成了风险内容

• 系统如何整改

• 整改后是否

安全评估最忌"只有合格，没有过程"。没有过程的合格，缺乏说服力。

安全评估还要与技术机制对应。评估报告里说系统具备输出审核，内容安全机制里就要写输出审核方案，技术流程图里也要体现输出审核节点。评估报告不是孤立文件，它必须与技术说明、内容审核、日志留存、整改机制保持一致。

八、内容安全机制资料规范

如果说安全评估是上线前的体检，内容安全机制就是上线后的免疫系统。体检证明的是某个时点的状态，免疫系统决定的是长期运行中的风险防控能力。

内容安全机制应覆盖输入端、模型端、输出端、人工端和管理端。

输入端要说明用户输入如何审核。包括文本、图片、音频、视频等不同输入形态。

对于语音场景，应说明是否先通过ASR转写，再进入文本安全校验；对于图片和视频场景，应说明是否进行图像识别、涉敏检测或其他风险识别。

模型端要说明生成边界如何约束。包括系统提示词、安全策略、拒答规则、上下文限制、敏感场景降级、知识库范围约束等。

输出端要说明生成结果如何审核。文本类内容可以通过关键词、分类模型、审核模型、第三方审核服务和人工复核结合；图片、音频、视频类内容则要根据内容形态设置相应检测方式。输出审核不能只停留在"事后发现"，而应尽可能前置到返回用户之前。

人工复核要说明触发条件。不是所有内容都需要人工审核，但高风险命中、用户投诉、模型不确定、审核争议、重大场景等，应有人工介入机制。

管理端要说明日志留存、投诉处理、问题整改和模型优化。内容安全要形成"发现问题—定位原因—处置内容—优化策略—复测验证"的闭环。

很多企业材料里会写"已接入内容审核系统"，但没有说明审核系统接在哪里、审核什么、如何处理不通过结果。这种写法像在大门口写了"禁止入内"，却没有门禁、没有保安、没有记录。

九、生成内容标识资料规范

生成内容标识，是大模型服务合规资料中越来越重要的一项。它解决的是两个问题：一是用户能不能知道内容由AI生成；二是平台能不能在后续传播中识别和追溯生成来源。

标识通常分为显式标识和隐式标识。显式标识，是用户可以直接感知的提示，例如"本内容由AI生成""AI生成内容，仅供参考"等。隐式标识，是嵌入文件数据、元数据、水印或其他技术字段中的标识，用户未必能直接看到，但平台可以用于识别和追溯。

不同内容形态，标识方式不能完全相同。文本生成服务，可以在生成结果附近、对话界面、稿源说明处进行提示。图片生成服务，可以在图片明显位置添加标识，也可以在元数据中加入生成信息。音频生成服务，可以通过语音提示、音频说明或文件元数据进行标识。视频生成服务，应考虑画面标识、片头片尾提示、角标、水印和隐式元数据。数字人、虚拟场景、拟真内容等，更要重视用户误认风险。

标识资料要具体。不能只写"系统会添加AI标识"，而应说明标识样式、标识位置、触发条件、覆盖范围、是否可被用户删除、下载后是否保留、转发后是否仍可识别。对于生成文件类产品，还要考虑文件导出、二次传播、截图录屏等场景。

十、服务协议与用户权益资料规范

服务协议与用户权益资料，我见过很多企业甚至直接套用通用模板。这是一个常见误区。大模型服务不同于普通互联网产品，它涉及内容生成、用户输入、模型判断、风险拒答、结果误差、投诉处置等问题，协议和规则必须与产品真实功能对应。

服务协议应说明服务范围。用户能用这个产品做什么，不能做什么，生成结果是否仅供参考，是否可用于专业决策，是否存在模型幻觉、错误、延迟或不可用风险，都应作出清晰说明。特别是法律、金融、教育、政务等高风险场景，应避免让用户误以为模型输出可以替代专业判断。

用户规则应说明禁止行为。包括不得输入违法违规内容，不得诱导生成有害信息，不得利用服务制作虚假信息、侵权内容、仿冒内容、攻击内容，不得删除或篡改生成内容标识等。规则不能只写原则，要能够指导具体管理。

投诉举报机制要可访问、可处理、可反馈。材料中应说明投诉举报入口在哪里，用户如何提交，企业如何受理，处理流程是什么，反馈时限如何设置，发现问题后如何下架、屏蔽、修正、限制功能或优化模型。投诉机制不是摆设，它是外部风险进入企业治理闭环的入口。

用户权益资料还应关注个人信息和未成年人保护。用户输入可能包含个人信息，系统日志可能保存交互记录，知识库可能涉及客户资料，这些都需要在资料中说明处理目的、处理范围、留存期限、保护措施和用户权利。未成年人使用场景则应说明防沉迷、防误导、防不当内容触达等措施。

协议资料要与产品功能一致。产品没有图片生成功能，协议却写图片生成责任；产品面向企业内部，协议却按公众用户写；材料说不采集个人信息，系统实际保存完整对话日志。这些不一致都会削弱资料可信度。

一句话总结：用户权益资料不是法律文本的堆砌，而是把用户知情、平台责任和风险处置写成可执行规则。

十一、备案资料常见问题与修改重点

从实际材料准备情况看，大模型备案资料常见问题主要集中在八类。

第一，产品边界不清。企业往往希望把产品能力写得更大，但备案材料强调的是当前实际服务。边界越模糊，审核越难判断。修改重点是收缩场景，明确服务对象、功能范围和输出内容类型。

第二，模型来源不清。材料只写"基于大模型"，没有说明具体模型名称、版本、部署方式和调用关系。修改重点是补充模型来源、模型架构、调用链路、第三方服务关系和责任边界。

第三，语料来源证明不足。只写"公开数据""自有数据""授权数据"，但缺少来源说明、授权依据、处理流程和风险过滤。修改重点是按数据类型拆分，逐类说明来源、规模、用途、清洗、脱敏和质检。

第四，安全评估过于笼统。只有结论，没有测试题库、测试样本、测试过程、整改记录和复测结论。修改重点是补充评估方法、风险分类、测试结果和整改闭环。

第五，内容安全机制写成原则口号。比如"加强内容审核""保障输出安全""防止违法内容生成"，这些表述方向正确，但不具备可审核性。修改重点是把原则拆成流程，把流程落到节点，把节点对应到系统措施。

第六，生成内容标识不完整。只写有标识，没有说明显式标识、隐式标识、位置、样式和文件导出后的保留机制。修改重点是补充标识方案、界面截图、样例文件和触发规则。

第七，服务协议与实际功能不一致。通用模板没有结合大模型服务特点，或者协议内容与备案表、产品说明、技术流程冲突。修改重点是统一名称、功能、场景、风险提示、投诉入口和用户规则。

第八，材料之间无法相互印证。备案表、技术说明、安全评估、服务协议、流程图、截图材料各写各的，形成不了闭环。修改重点是统一口径，建立一张总表，逐项核对主体、产品、模型、数据、安全、标识、投诉、日志等关键信息。

备案资料的高级修改，不是修文字，而是修逻辑；不是补文件，而是补证明链。

对于已经准备了备案材料的企业，不建议直接提交。更稳妥的方式，是先进行一次目录级预审，重点核查产品边界、模型来源、语料证明、安全评估、内容审核、生成标识、投诉机制等关键资料是否完整、是否一致、是否具备可审核性。备案资料的整改，不是简单改文字，而是补齐证明链。材料越早预审，后续返工成本越低。