大模型备案自评估报告模板

很多团队是在备案材料被退回、或者被要求补正的时候，才发现自评估报告根本没写清「评了什么、依据是什么、结论怎么来的」。这篇不替你下结论，只给一份可套用的报告结构、每个字段该填什么口径、以及数据来源、安全评估、日志留存这几块常见的补正原因，最后说清什么情况下不能直接用这套模板。

很多团队是在备案材料被退回、或者被要求补正的时候，才发现自评估报告根本没写清「评了什么、依据是什么、结论怎么来的」。评审要看的是三件事之间的对应关系：你做了什么措施、拿什么证据证明、谁对这条负责。模板能帮你省排版和结构上的力气，但它替不了你下结论。

下面给一份可以直接套用的报告骨架，再逐节讲填写口径，最后说清哪些情况不能照抄。需要先对齐术语的话，去 /ai-dict/category/safety 过一遍分类说明，避免把算法备案和大模型备案的材料口径混着写。

自评估报告到底要评哪几块

先分清算法备案和大模型备案是两套东西，材料有重合但报送口径不同，别把一份报告套两个用途。术语和分类上的差异，可以到 /ai-dict/category/safety 把定义对齐。报告主体通常绕不开：语料来源合法性、模型能力与安全措施、服务提供方式、用户与内容管理、应急处置，缺一块基本会被要求补正。

• 先写「评估范围与时间点」：覆盖哪些模型、哪些对外服务形态、面向哪类用户；范围写模糊，后面每一条措施都会被追问适用范围
• 按服务形态分配笔墨：面向公众的交互式服务、企业内部自用、只对外提供 API，三种形态的重点章节不一样，API 形态要多写调用方管理
• 结论部分写清「符合/基本符合/不满足」三种档位及理由，全篇清一色「符合」反而容易被质疑
• 事前把「这份报告回答谁的问题」想清楚：是给评审看合规性，还是内部留档备查，两种目标下详略安排不同

模板骨架：直接从这几节往下填

下面这套结构适合大多数企业，节标题可按自身服务形态微调，但别删节。每节统一用三段式写：现状描述（客观事实）、对照要求（引哪条依据，写法规名称不写内部编号）、差距与整改计划（有时间点、有责任人角色）。现状描述里只写能拿出证据的事。

模板可以复用，但填写口径要按自己的服务形态改，尤其是「用户与内容管理」这一节，To C 和 To B 要写的东西差别很大。别把别人的报告整段复制过来，评审对千篇一律的措辞很敏感。

数据来源与日志这两块最容易写空

语料部分要说清来源渠道、授权方式、清洗与过滤规则、有没有做去重和敏感内容剔除。只写「数据来自公开互联网」，基本会被要求补正。涉及个人信息或用户数据的，要单独说明采集目的、存储位置、留存期限和删除机制，别混在语料那一段一笔带过。

1. 列数据来源清单把每个来源渠道、获取方式、授权凭证对应列出来，一条来源一行，没有凭证的标为待补。
2. 写清洗与过滤规则说明去重、去噪、敏感内容剔除的标准和工具，规则要能对应到实际处理记录。
3. 单列个人信息处理把用户数据的采集目的、存储位置、留存期限、删除机制单独成段，不要塞进语料章节。
4. 把日志口径写实说明记录了哪些字段、留存多久、谁能查、怎么防篡改，并留一份字段清单备查。

第三方模型或托管服务要在报告里点名，说明数据是否出网、出网到哪。这块和私有化部署的判断逻辑，可以对照 /safety 里的合规说明一起看。日志留存期限的具体口径，各行业要求有差异，去站内对应页面核对当时的说明，别照抄别家的数字。

提交前自己先过一遍的检查清单

报告写完不等于可以交。下面这份清单建议由不参与撰写的人来走一遍，自己查自己容易漏。逐条检查「措施→证据→责任人」是否闭环，任何一条只有措施没有证据的先补证据清单。

• 核对报告里出现的模型名称、服务名称和营业执照、ICP 等主体材料是否完全一致，名称对不上是第一轮退回的常见原因
• 把结论页和整改计划页对一遍：结论写「符合」的项目，不能在整改计划里又出现同类问题
• 检查每一处「依据」是否写到了法规名称层级，不要写成内部编号或缩写
• 留一份版本记录：评估时间点、报告版本、参与人角色，后续模型或服务变更时便于说明差异
• 检查数据与日志章节是否给出了可验证的记录位置，而不是只有流程描述

最后说清什么情况下不能直接用这套模板：一是你的服务形态明显偏离常见场景，比如涉及未成年人、医疗、金融等专门领域，要额外补充对应要求；二是主体架构复杂，比如多主体联合运营，责任划分必须单独成节写清；三是模型或服务在评估期间发生变更，报告和实际情况对不上，先改材料再提交。