生成式人工智能服务备案与算法备案材料清单（含安全评估报告）

章节结构（10）

1. 1. 一、适用性判定：是否具有舆论属性或社会动员能力

   备案与安全评估义务的触发前提是服务"具有舆论属性或者社会动员能力"。《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》第二条把这类服务界定为两种情形：开办论坛、博客、微博客、聊天室、通讯群组、公众账号、短视频、网络直播、信息分享、小程序等信息服务或者附设相应功能；开办提供公众舆论表达渠道或者具有发动社会公众从事特定活动能力的其他互联网信息服务。第三条进一步列出五类应当自行开展安全评估的情形：具有舆论属性或社会动员能力的信息服务上线，或者信息服务增设相关功能的；使用新技术新应用，使信息服务的功能属性、技术实现方式、基础资源配置等发生重大变更，导致舆论属性或者社会动员能力发生重大变化的；用户规模显著增加，导致信息服务的舆论属性或者社会动员能力发生重大变化的；发生违法有害信息传播扩散，表明已有安全措施难以有效防控网络安全风险的；地市级以上网信部门或者公安机关书面通知需要进行安全评估的其他情形。对 AI 企业，面向公众的对话产品、内容生成平台、带社区或分发功能的应用通常会被认定命中；纯企业内部部署、不向公众提供的版本一般不触发，但开放公开试用入口即可能改变判定。把判定过程、依据与判定人写下来，这是后续一切材料的前提。

   需要附的证据

   • · 舆论属性/社会动员能力判定记录（对照第二条两种情形、第三条五类情形）
   • · 产品功能清单与面向对象说明（To C / To B / 内部）
   • · 公开试用入口、社区功能、内容分发能力的说明与截图
   • · 用户规模统计与增长记录（触发第三条第三项时）
   • · 主管部门书面通知（若收到）

   常见失分点

   • · 以"我们只做 To B"为由认定不触发，但产品有公开试用页面或可对外分享的生成结果；
   • · 判定只在首次上线时做过一次，后续增设社区、分享、订阅功能未重新判定；
   • · 用户规模显著增长后未重新评估，第三条第三项情形被忽略；
   • · 判定无书面记录，检查时无法说明当初的判断依据。

2. 2. 二、备案主体与服务信息填报项（算法推荐规定第二十四条）

   第二十四条明确了通过互联网信息服务算法备案系统应当填报的信息：服务提供者的名称、服务形式、应用领域、算法类型、算法自评估报告、拟公示内容等。时限为**提供服务之日起十个工作日内**，这意味着备案必须与产品上线计划同步排期，而不是上线后再启动。第二十五条规定：网信部门收到备案材料后，材料齐全的应当在三十个工作日内予以备案、发放备案编号并进行公示；材料不齐全的不予备案，并应当在三十个工作日内通知备案人并说明理由。本节产出一张填报底稿：主体信息（名称、统一社会信用代码、注册地、ICP 证照情况、负责人与联系方式）、服务信息（服务名称、服务形式如网站/App/小程序/API、应用领域、上线时间、用户规模）、算法信息（算法名称、算法类型、算法用途、运行机制概述）、以及拟公示内容（对外公示版本，措辞要与产品实际一致且不含商业秘密）。填报口径要与工商登记、ICP 备案、产品实际形态三者一致——不一致是最常见的不予备案原因。

   需要附的证据

   • · 备案填报底稿（主体/服务/算法/拟公示内容四组字段）
   • · 营业执照、统一社会信用代码证件与 ICP 备案或许可证明
   • · 服务上线日期的证据（发布记录、应用市场上架时间、公告）
   • · 十个工作日时限的内部排期表与实际提交时间
   • · 拟公示内容的法务与业务会签记录
   • · 备案系统提交回执与受理状态截图

   常见失分点

   • · 把十个工作日理解为从"备案材料准备好"起算，实际从提供服务之日起算，极易逾期；
   • · 主体名称与营业执照、ICP 备案主体不一致（常见于集团内由不同主体运营）；
   • · 拟公示内容写得过于笼统，与产品实际功能对不上，后续被要求更正；
   • · 把材料齐全后的三十个工作日理解为可自由占用的准备期。

3. 3. 三、算法自评估报告

   算法自评估报告是第二十四条明列的填报项之一。内容上应当覆盖算法本身与其治理两条线。算法线：算法名称与版本、算法类型（生成合成类、个性化推送类、排序精选类、检索过滤类、调度决策类）、算法原理与机制机理概述、输入特征与输出形式、训练数据来源与规模、评测方法与主要指标、已知局限与失败模式。治理线：依第七条落实算法安全主体责任并建立的各项管理制度（算法机制机理审核、科技伦理审查、用户注册、信息发布审核、数据安全和个人信息保护、反电信网络诈骗、安全评估监测、安全事件应急处置等）与其执行情况；依第八条定期审核、评估、验证算法机制机理、模型、数据和应用结果的安排与最近一次结果；依第九条至第十条的用户模型与用户标签管理；依第十六条至第十七条的透明度告知、不针对个人特征的选项与一键关闭；依第十八条至第二十一条对未成年人、老年人、劳动者、消费者的专门保护。生成式服务还应覆盖训练语料合法性、数据标注治理与内容安全措施——GB/T 45654-2025《网络安全技术 生成式人工智能服务安全基本要求》是目前通行的对照口径。自评估报告与后述安全评估报告在证据上可以共用，但结论与视角不同：前者面向算法本身，后者面向服务的整体安全。

   需要附的证据

   • · 算法自评估报告全文（算法线与治理线两部分）
   • · 第七条八项管理制度的文本与执行记录（审批流水、会议纪要、培训签到）
   • · 第八条定期审核评估验证的方案与最近一次报告
   • · 用户标签体系说明与违法不良信息不记入兴趣点的技术措施
   • · 透明度告知文本、非个性化选项与一键关闭的实现截图
   • · 未成年人/老年人/劳动者/消费者专门保护措施的实现证据
   • · GB/T 45654-2025 对照自查表与差距清单（生成式服务）

   常见失分点

   • · 自评估报告只描述算法技术方案，完全没有治理制度与执行记录；
   • · 八项管理制度以文件形式存在但无任何执行痕迹；
   • · "一键关闭"入口藏在多级菜单里，或关闭后实际仍在个性化推送；
   • · 定期审核评估验证写了机制但从未产出过一份报告；
   • · 生成式服务未对照 GB/T 45654-2025 做自查，训练语料与内容安全部分空洞。

4. 4. 四、安全评估报告（安全评估规定第五条、第六条）

   第四条允许互联网信息服务提供者自行实施安全评估，也可以委托第三方安全评估机构实施。第五条要求对信息服务和新技术新应用的合法性、落实法律行政法规部门规章和标准规定的安全措施的有效性、防控安全风险的有效性等情况进行全面评估，并**重点评估**八项：确定与所提供服务相适应的安全管理负责人、信息审核人员或者建立安全管理机构的情况；用户真实身份核验以及注册信息留存措施；对用户的账号、操作时间、操作类型、网络源地址和目标地址、网络源端口、客户端硬件特征等日志信息，以及用户发布信息记录的留存措施；对用户账号和通讯群组名称、昵称、简介、备注、标识，信息发布、转发、评论和通讯群组等服务功能中违法有害信息的防范处置和有关记录保存措施；个人信息保护以及防范违法有害信息传播扩散、社会动员功能失控风险的技术措施；建立投诉、举报制度，公布投诉、举报方式等信息，及时受理并处理有关投诉和举报的情况；建立为网信部门依法履行互联网信息服务监督管理职责提供技术、数据支持和协助的工作机制的情况；建立为公安机关、国家安全机关依法维护国家安全和查处违法犯罪提供技术、数据支持和协助的工作机制的情况。第六条要求：发现存在安全隐患的应当及时整改直至消除；经评估符合法律、行政法规、部门规章和标准的，应当形成安全评估报告，报告应当包括四项内容：互联网信息服务的功能、服务范围、软硬件设施、部署位置等基本情况和相关证照获取情况；安全管理制度和技术措施落实情况及风险防控效果；安全评估结论；其他应当说明的相关情况。

   需要附的证据

   • · 安全评估报告（按第六条四项结构，覆盖第五条八项重点内容）
   • · 安全管理负责人与信息审核人员任命文件、编制与排班
   • · 真实身份核验方案与核验成功率统计
   • · 日志留存配置（字段、期限）与抽样验证记录
   • · 违法有害信息防范处置的技术方案与处置台账
   • · 投诉举报入口截图、受理时长与处理结果统计
   • · 配合网信、公安、国安工作机制的文件与联系人
   • · 整改台账（发现的隐患、整改措施、消除证据）
   • · 第三方评估机构的资质与报告（若委托）

   常见失分点

   • · 八项重点内容漏项（最常漏的是日志留存字段不全、以及配合执法的工作机制无具体安排）；
   • · 报告只写"已建立制度"，没有第六条第二项要求的"落实情况及风险防控效果"；
   • · 信息审核人员编制与服务规模明显不匹配（如日活百万而审核团队数人）；
   • · 投诉举报入口存在但无处理时长数据，无法证明"及时受理并处理"；
   • · 发现隐患但整改未闭环即出具报告，与第六条"整改直至消除"相悖。

5. 5. 五、训练语料与数据标注治理材料

   生成式服务的备案与安全评估中，语料合法性是被追问最密集的一块。依《生成式人工智能服务管理暂行办法》第七条，提供者应当依法开展预训练、优化训练等训练数据处理活动，遵守以下规定：使用具有合法来源的数据和基础模型；涉及知识产权的，不得侵害他人依法享有的知识产权；涉及个人信息的，应当取得个人同意或者符合法律、行政法规规定的其他情形；采取有效措施提高训练数据质量，增强训练数据的真实性、准确性、客观性、多样性；以及网络安全法、数据安全法、个人信息保护法等法律行政法规和有关主管部门的相关监管要求。第八条要求在进行数据标注时制定符合本办法要求的清晰、具体、可操作的标注规则，开展数据标注质量评估、抽样核验标注内容的准确性，并对标注人员进行必要培训、监督指导标注人员规范开展标注工作。《网络数据安全管理条例》第十九条另有专条：提供生成式人工智能服务的网络数据处理者应当加强对训练数据和训练数据处理活动的安全管理，采取有效措施防范和处置网络数据安全风险；第十八条则约束语料采集手段——使用自动化工具访问、收集网络数据的，应当评估对网络服务带来的影响，不得非法侵入他人网络，不得干扰网络服务正常运行，爬取类语料的合规说明应当正面回应这一条。材料准备上，建议做成一份语料台账加四份说明：语料台账（来源、获取方式、许可依据、规模、模态、是否含个人信息、是否含敏感个人信息、清洗与过滤措施）；来源合法性说明；知识产权风险处置说明（含权利人投诉与移除机制）；个人信息处理合法性说明（与 PIPIA 交叉引用）；以及数据标注治理说明（标注规则、质量评估方法、抽样核验结果、标注人员培训记录）。

   需要附的证据

   • · 训练语料台账（字段如上，按数据集逐条）
   • · 基础模型来源与许可文件（含是否允许商用与再分发）
   • · 数据采购合同与供应商权利保证条款
   • · 知识产权投诉与移除机制说明及处理台账
   • · 个人信息处理合法性说明与 PIPIA 交叉引用
   • · 数据标注规则文本、质量评估方法与抽样核验记录
   • · 标注人员培训记录与监督指导安排
   • · 语料清洗与有害内容过滤的方案与效果评估

   常见失分点

   • · 语料台账只到"数据集名称"粒度，说不清来源与许可依据；
   • · 基础模型许可禁止商用或要求署名，实际使用中未遵守；
   • · 标注规则只有内部口头约定，无文本、无培训记录、无抽样核验；
   • · 知识产权投诉机制不存在或入口不可达，权利人只能诉诸监管举报；
   • · 语料中个人信息的处理未与 PIPIA 衔接，两份材料对同一事实说法不一。

6. 6. 六、生成合成内容标识材料（标识办法第十二条 + GB 45438-2025）

   《人工智能生成合成内容标识办法》第十二条要求：服务提供者在履行算法备案、安全评估等手续时，应当按照本办法提供生成合成内容标识相关材料，并加强标识信息共享，为防范打击相关违法犯罪活动提供支持和帮助。第十一条要求标识活动符合相关法律、行政法规、部门规章和强制性国家标准的要求——即 GB 45438-2025《网络安全技术 人工智能生成合成内容标识方法》（发布 2025-02-28，实施 2025-09-01，现行，强制性）。备案材料中的标识说明应覆盖两条线。显式标识：依第四条按模态在指定位置添加显式标识，并确保用户下载、复制、导出的文件中保留显式标识——文本、音频、图片、视频、虚拟场景各自的标识位置与呈现方式要分别写明并附截图。隐式标识：依第五条在文件元数据中添加隐式标识，包含生成合成内容属性信息、服务提供者名称或编码、内容编号等制作要素信息；第十一条要求其符合强制性国家标准。此外还应说明：服务协议中关于标识规范的说明条款（第八条）、对不含显式标识输出的日志留存不少于六个月（第九条）、以及作为传播平台时的核验与提示义务（第六条）。材料与线上实现必须一致——备案材料所述标识实现与实际产品不符，是后续检查中最容易被抓到的问题。

   需要附的证据

   • · 各模态显式标识的位置与呈现方式说明及产品截图
   • · 导出/下载/复制后标识保留的实测记录
   • · 隐式标识（元数据）字段说明与技术实现文档
   • · GB 45438-2025 符合性自查表与差距清单
   • · 服务协议中标识规范说明条款的原文
   • · 不含显式标识输出的日志留存配置（不少于六个月）与留存证据
   • · 作为传播平台时的核验、提示与传播要素回写实现说明
   • · 备案材料与线上实现的一致性核对记录

   常见失分点

   • · 只在页面上加了水印，用户导出文件后标识丢失；
   • · 隐式标识字段不符合强制性国家标准的编码要求；
   • · 备案材料写了完整标识方案，线上产品只实现了一部分；
   • · 不含显式标识输出的日志未留存或留存不足六个月；
   • · 作为传播平台的一侧完全未做核验与提示，只做了生成侧。

7. 7. 七、服务协议、使用边界与未成年人保护材料

   《生成式人工智能服务管理暂行办法》第九条要求提供者承担网络信息内容生产者责任，履行网络信息安全义务，涉及个人信息的还要承担个人信息处理者责任；并与注册其服务的使用者签订服务协议，明确双方权利义务。第十条要求明确并公开其服务的适用人群、场合、用途，指导使用者科学理性认识和依法使用生成式人工智能技术，采取有效措施防范未成年人使用者过度依赖或者沉迷生成式人工智能服务。第十一条要求依法保护使用者输入信息和使用记录，不得收集非必要个人信息，不得非法留存能够识别使用者身份的输入信息和使用记录，不得非法向他人提供使用者的输入信息和使用记录，并及时受理和处理个人关于查阅、复制、更正、补充、删除其个人信息的请求。备案材料中应准备：服务协议全文（含权利义务、禁止性使用、知识产权、责任限制、争议解决）、适用人群/场合/用途的公开说明、未成年人防沉迷措施说明（时长提示、内容分级、监护人工具）、以及输入信息与使用记录的保护说明（收集范围、留存期限、访问控制、不用于非必要目的的承诺与技术保障）。第十四条、第十五条要求的违法内容处置、模型优化训练与报告义务，以及投诉举报机制，也应一并附上制度与台账。

   需要附的证据

   • · 服务协议全文与用户接受记录（版本与生效时间）
   • · 适用人群、场合、用途的公开说明与展示位置截图
   • · 未成年人识别与防沉迷措施的实现证据
   • · 输入信息与使用记录的收集范围、留存期限与访问控制配置
   • · 个人查阅、复制、更正、补充、删除请求的受理流程与台账
   • · 违法内容发现—处置—模型优化—报告的闭环台账（第十四条）
   • · 投诉举报入口与处理结果台账（第十五条）

   常见失分点

   • · 服务协议直接沿用普通 App 模板，未写明生成内容的使用边界与责任分配；
   • · 适用人群/场合/用途只写在帮助中心深处，未在显著位置公开；
   • · 防沉迷措施只有一句"建议合理使用"，无任何技术措施；
   • · 用户输入被默认长期留存并用于训练，未在协议与隐私政策中明确，也无关闭选项；
   • · 违法内容处置台账只记录删除动作，未体现第十四条要求的模型优化训练与报告。

8. 8. 八、备案编号公示与对外披露一致性

   第二十六条要求：完成备案的算法推荐服务提供者应当在其对外提供服务的网站、应用程序等的显著位置标明其备案编号并提供公示信息链接。这是一项持续义务而非一次性动作，需要落到产品发布流程里：每一个对外服务入口（官网、Web 应用、iOS/Android 应用、小程序、开放平台文档）都要有备案编号与公示链接，并在改版、换域名、新增端时同步更新。同时要确保对外披露口径一致：备案系统中的公示内容、产品内的算法说明、隐私政策中的自动化决策说明、以及对外宣传材料关于模型能力的表述，四者不应互相矛盾。宣传口径尤其需要注意——对外宣称的模型能力与备案材料中的算法说明差距过大，既是备案材料不实的风险，也可能触发广告与消费者保护方面的问题。建议设一个季度性的一致性核对，由法务牵头，产品与市场参与。

   需要附的证据

   • · 各服务入口的备案编号与公示链接展示截图（含移动端）
   • · 备案编号展示的发布流程检查项（作为上线门禁）
   • · 四份对外材料的一致性核对表（备案公示 / 产品内说明 / 隐私政策 / 宣传材料）
   • · 季度一致性核对记录与整改项
   • · 域名、端、品牌变更时的同步更新记录

   常见失分点

   • · 只在官网页脚标注备案编号，App 与小程序内没有；
   • · 换域名或改版后备案编号与公示链接失效；
   • · 宣传材料声称的能力远超备案材料中的算法说明；
   • · 隐私政策中的自动化决策说明与产品内算法说明互相矛盾。

9. 9. 九、变更、注销与新产品新应用新功能的再评估

   备案不是一次性动作。三条后续路径要事先安排好。变更备案：备案信息（服务形式、应用领域、算法类型、拟公示内容等）发生变化时应当办理变更手续，触发条件要写成可监测清单并挂进产品变更流程。注销备案：服务终止时应当办理注销手续——《生成式人工智能服务管理暂行办法》第十七条明确提到变更、注销备案手续；《互联网信息服务算法推荐管理规定》亦对终止服务未办理注销备案规定了相应处理。新产品新应用新功能的安全评估：《互联网信息服务深度合成管理规定》第二十条要求深度合成服务提供者开发上线具有舆论属性或者社会动员能力的新产品、新应用、新功能的，应当按照国家有关规定开展安全评估；《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》第三条第一项、第二项亦将"上线或增设相关功能""使用新技术新应用导致重大变更"列为应当自行开展安全评估的情形，且第七条要求这两类情形应当在上线或功能增设**前**提交安全评估报告；第三、四、五项情形则应当自相关情形发生之日起 30 个工作日内提交。把这两个时点差异写进发布流程：功能上线前要做的，不能等上线后再补。

   需要附的证据

   • · 变更触发条件清单与监测责任人（挂接产品变更流程）
   • · 历次变更备案办理记录与回执
   • · 新产品新应用新功能的安全评估触发判定与上线前提交记录
   • · 发布流程中的合规门禁配置（备案/评估未完成不得上线）
   • · 服务终止时的注销备案办理记录
   • · 安全评估报告提交渠道与回执（全国互联网安全管理服务平台）

   常见失分点

   • · 把"上线前提交"的情形按"30 个工作日内提交"处理，时点判断错误；
   • · 新增重大功能（如从文本扩展到图像视频生成）未做新的安全评估；
   • · 算法类型或应用领域发生变化未办理变更备案；
   • · 服务下线后未办理注销备案，留下悬空备案记录；
   • · 发布流程无合规门禁，工程团队不知道有备案前置要求。

10. 10. 十、台账、一致性核对与迎检准备

    备案通过之后真正决定风险水平的是日常台账。建议维护六本台账并指定责任人：备案台账（备案编号、填报内容、变更历史、公示链接）；安全评估台账（评估批次、触发情形、报告版本、提交回执、整改闭环）；内容安全台账（违法有害信息发现、处置、报告记录）；投诉举报台账（受理时间、处理时长、结果、回访）；标识台账（各模态实现、版本变更、不含显式标识输出的日志）；以及算法审核台账（第八条定期审核评估验证的批次与结论）。此外准备一份迎检包：把上述台账的最近期摘要、关键制度文本、人员任命与排班、系统配置截图集中在一个索引下，并每季度更新一次。第八条规定网信部门和公安机关应当依据各自职责对安全评估报告进行书面审查，发现内容、项目缺失或者评估方法明显不当的应当责令限期重新评估，内容不清的可以责令补充说明；第九条、第十条还规定了现场检查与专家评审的可能性——因此台账要能支撑"随时被抽查"的状态，而不是临时拼凑。

    需要附的证据

    • · 六本台账的当前版本与责任人清单
    • · 迎检包索引与最近一次更新日期
    • · 书面审查补充说明的历史记录（若发生）
    • · 现场检查记录与整改回复（若发生）
    • · 台账抽查演练记录（内部模拟检查）

    常见失分点

    • · 台账只在迎检前突击补录，时间戳与实际运行不符；
    • · 责任人离职后台账无人接手，中间出现数月空白；
    • · 投诉举报台账只记录数量不记录处理时长与结果；
    • · 被责令限期重新评估后仍按原方法重做，问题未实质解决；
    • · 迎检包分散在多个部门，现场检查时无法在合理时间内提供。