文章目录 01 GB/T 45654-2025 实施后，真正变化在哪里 02 先判断路径：完整备案，还是上线登记 03 调用第三方API，不等于没有应用层责任 04 备案材料不是孤立文件，而是一条证明链 05 不同 AI 产品，最容易卡的问题不一样 06 安全评估为什么最容易卡住 07 测试题库和关键词库，不能只是"凑数量" 08 语料合规是很多企业忽视的底层问题 09 企业到底要准备哪些材料 10 上线前，做一次备案准备度自查

很多 AI 产品不是卡在技术上线，而是卡在合规上线。

前端页面做好了，模型 API 接好了，知识库也能正常问答了，客户甚至已经准备试用，但到了真正对外发布前，企业才发现几个关键问题还没判断清楚：

这个产品到底是完整备案，还是上线登记？

调用了已备案模型，应用层还要不要准备材料？

安全评估报告有没有测试题库、关键词库？

知识库、训练语料、用户上传文件的来源和授权能不能说清楚？

GB/T 45654-2025 实施后，大模型备案材料准备的重点，已经不是"有没有写文件"，而是"文件背后有没有真实的安全评估、数据治理、内容风控和整改闭环"。

如果你的企业已经有智能客服、知识库问答、AI 写作工具、行业大模型应用、数字人问答系统，或者正在通过 API 调用第三方大模型能力对外提供服务，建议在正式上线前，先判断三件事：

1. 产品到底属于完整备案，还是上线登记；

2. 现有材料能否支撑安全评估；

3. 哪些材料缺口会影响后续审核和上线节奏。

如果这三个问题没有提前说清楚，后面再补测试、补语料说明、补整改记录、补制度文件，往往会带来更多返工成本

01、GB/T 45654-2025 实施后，真正变化在哪里

过去不少企业准备大模型备案材料时，容易把重点放在"流程怎么走""表格怎么填""材料怎么凑齐"。

但真正推进时，往往卡在更底层的问题：

• 模型来源说不清；

• 语料来源说不清；

• 是否微调、是否二次开发说不清；

• 调用第三方 API 后，本应用承担什么安全责任说不清；

• 安全评估报告过于模板化；

• 测试题库覆盖不足；

• 关键词库只是简单堆敏感词；

• 没有越狱攻击、提示注入、违规诱导、过度拒答测试；

• 没有整改记录、复测记录和处置闭环；

• 服务协议、投诉举报、日志留存、应急机制之间无法相互对应。

GB/T 45654-2025 的实际价值，不是让企业材料变厚，而是让生成式人工智能服务安全要求变得更可拆解、可测试、可证明。

对企业来说，它可以帮助企业把"我们有安全机制"这种主观表述，转化成"有分类、有样本、有测试、有记录、有整改"的证据体系。 

备案看的是产品能不能合规上线，国标提供的是安全评估和材料准备的重要参考。两者结合起来，才是现在 AI 产品上线前更稳妥的准备方式。

02、先判断路径：完整备案，还是上线登记日

企业最容易误判的第一个问题是：我的产品到底要不要做完整备案？

判断路径时，不能只看"有没有自研大模型"，还要综合看产品是否面向公众、是否具备生成能力、模型能力从哪里来、是否做了微调或二次开发、是否形成独立生成式人工智能服务。

可以先看几个核心维度：

一般来说，如果企业是自研大模型，或者基于开源模型、第三方模型进行了微调、训练、能力改造，并面向公众提供生成式人工智能服务，通常需要重点评估是否涉及完整备案。

如果企业通过 API 接口或其他方式直接调用已备案模型能力，且主要是在应用层提供生成式人工智能功能，一般应重点关注是否属于地方网信办登记路径，同时仍需落实应用层内容安全、数据处理、日志留存、投诉举报和公示等要求。

需要注意的是：调用第三方已备案模型，并不等于企业完全没有合规责任。底层模型已经备案，只能说明模型服务本身具备相应备案基础。你的产品是否需要登记、是否需要公示、是否需要做应用层安全测试，还要结合具体产品形态判断。

尤其是以下几类产品，更应提前判断路径：

• 智能客服

• AI 写作工具

• 企业知识库问答

• 行业大模型助手

• 数字人问答系统

• AI 辅助决策工具

• 基于第三方 API 封装的 SaaS 产品

• 面向外部客户开放的 AI 插件或 API 服务

03、调用第三方 API，不等于没有应用层责任

现在很多 AI 应用不是自研基座模型，而是调用通义、文心、腾讯混元、智谱、豆包、DeepSeek 等第三方模型能力，再叠加自身业务系统、知识库、提示词、前端交互、工具调用和权限管理。

这类企业经常会有一个误判：

"底层模型已经备案了，我们只是调用 API，所以不用管备案和安全评估。"

这个判断存在明显风险。

因为监管关注的不只是底层模型，还包括你最终向用户提供的生成式人工智能应用或功能。

应用层可能引入新的风险：

• 接入企业知识库，可能涉及商业秘密；

• 开放用户上传文档，可能涉及个人信息和第三方权利；

• 设计系统提示词，可能影响模型输出边界；

• 增加插件、工具调用、联网搜索，可能扩大输出风险；

• 面向特定行业提供建议，可能涉及专业责任边界；

• 对外宣传"智能顾问""自动决策""专业诊断"，可能提高用户依赖程度；

• 保存用户输入和输出日志，可能涉及数据安全和个人信息保护；

• 对外上线后未公示所调用模型的备案或登记服务信息，可能存在展示不充分问题。

因此，调用第三方 API 的企业，至少应提前完成三件事：

1. 确认所调用模型的备案或登记信息

   以及供应商授权、服务协议和接口调用关系。

2. 判断自身产品是否属于直接调用已备案模型能力的应用或功能

   是否需要办理上线登记。

3. 围绕自身应用场景做应用层安全测试和材料准备

   而不是完全依赖底层模型供应商。

04、备案材料不是孤立文件，而是一条证明链

很多企业准备材料时，会把产品说明、模型说明、安全评估报告、服务协议、制度文件、测试记录分开写。

表面上看，每份文件都有内容，但合在一起却无法形成闭环。

备案材料真正要解决的是一条证明链：

• 产品是什么；

• 使用什么模型；

• 模型能力从哪里来；

• 训练或调用的数据从哪里来；

• 可能产生哪些安全风险；

• 企业如何测试这些风险；

• 测试发现问题后如何整改；

• 整改后如何复测；

• 上线后如何监测、处置、留痕和持续优化。

如果这条链断了，材料就容易显得空。

例如，安全评估报告里写"已建立内容安全机制"，但没有测试题库、关键词库、人工复核记录、整改记录支撑，就会显得像模板话术。

再比如，产品说明里写"本产品用于企业知识库问答"，但语料说明里没有说明知识库资料来源、授权范围、更新机制、脱敏规则、用户上传内容处理方式，就会出现数据来源和服务能力不匹配的问题。

再比如，技术说明里写"调用第三方已备案模型"，但没有说明本应用是否有提示词工程、RAG 检索增强、插件调用、联网搜索、工具调用、用户画像、数据回传、日志留存，就无法判断应用层风险是否已经被充分识别。

因此，GB/T 45654-2025 实施后，企业准备材料时更应该按照"产品—模型—语料—测试—整改—上线—持续监管"的逻辑来组织，而不是简单把文件堆在一起。

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

05、不同 AI 产品，最容易卡的问题不一样

大模型备案或上线登记不能只看产品名称。不同产品形态，材料准备重点也不一样。

这也是为什么很多企业不能简单套用同一份模板。

智能客服的材料重点，和 AI 写作工具不一样；行业大模型的安全评估重点，和普通聊天机器人也不一样；调用第三方 API 的 SaaS 产品，和自研模型服务的备案路径也不完全一样。

真正有用的材料，必须围绕产品实际功能、服务对象、模型来源、数据流转和风险场景展开。

06、安全评估为什么最容易卡住

大模型备案最容易卡住的，通常不是"有没有提交材料"，而是安全评估是否能证明产品具备安全可控能力。

安全评估不是问几个敏感问题，也不是让模型拒答几次就结束。

真正有用的安全评估，至少应关注以下几个方面：

很多企业只关注"违规内容不能输出"，却忽视了两个问题。

第一，模型不能只会拒答。如果正常业务问题、合法咨询、合规内容也大量被拒绝，说明模型安全策略可能过度保守，影响用户正常使用。安全评估既要测"该拒绝时是否拒绝"，也要测"该回答时是否能正常回答"。

第二，测试必须有整改闭环。如果测试发现模型存在风险输出，企业不能只写"后续优化"。更稳妥的做法是记录风险样本、命中类别、问题原因、整改措施、复测结果、责任人员和完成时间。

这样才能体现企业具备持续改进能力。

07、测试题库和关键词库，不能只是"凑数量"

不少企业会问：大模型备案测试题库要准备多少条？关键词库要怎么做？

这个问题不能只看数量，更要看覆盖范围、风险分类、业务相关性和可复测性。

一套相对可用的安全测试题库，通常应当具备以下特点：

1. 覆盖通用安全风险。

   包括违法违规内容、不良信息、虚假有害信息、歧视偏见、暴力极端、个人信息泄露、知识产权侵权、商业秘密泄露等。

2. 覆盖具体业务场景。

   例如智能客服要测试售后纠纷、投诉引导、诱导交易、虚假承诺；法律问答要测试非法规避、误导性建议、敏感案件；金融场景要测试投资建议、收益承诺、风险误导；医疗健康场景要测试诊断建议、用药建议、危急症状处置。

3. 覆盖攻击性输入。

   包括越狱攻击、角色扮演、提示注入、多轮诱导、编码绕过、拆分表达、反向指令、要求模型忽略系统规则等。

4. 覆盖正常问题。

   测试模型是否对正常业务咨询、一般知识问答、合理内容创作请求进行过度拒答。

5. 保留测试记录。

   每条测试样本应当记录问题、预期结果、实际输出、风险判断、是否通过、整改措施和复测结论。

图示：系统分类好的安全评估测试题

关键词库也是同样逻辑。它不是简单把敏感词复制进表格，而应当与风险类别、业务场景和处置规则对应起来。

关键词库至少要回答几个问题：

• 这个关键词对应哪类风险；

• 命中后是直接拦截，还是进入人工复核；

• 是否存在误伤正常业务表达的可能；

• 是否有同义词、变体词、拼音、谐音、缩写、拆分表达；

• 是否定期根据测试样本、投诉举报和实际风险事件更新。

如果企业只有一份静态敏感词表，没有分类、没有命中策略、没有复核机制、没有更新记录，很难说明关键词库真正发挥了安全治理作用。    

图示：系统分类好的拦截词/关键词

08、语料合规是很多企业忽视的底层问题

大模型备案材料里，语料问题往往是企业最容易低估的部分。

很多团队更关注模型效果、产品功能和接口调用，却没有提前整理语料来源、授权证明、开源协议、商业数据合同、用户数据授权、数据清洗记录和可追溯记录。

等到准备备案材料时，才发现自己说不清楚训练数据、优化数据、知识库数据、评测数据分别来自哪里。

尤其是行业大模型、知识库问答系统、企业智能助手、AI 写作工具、数字人问答产品，常见语料来源可能包括：

• 公司自有业务资料；

• 客户提供的行业知识库；

• 合作方提供的数据；

• 公开网页内容；

• 开源数据集；

• 用户上传文档；

• 业务系统日志；

• 历史问答记录；

• 人工构造测试样本；

• 第三方采购数据。

这些数据能不能用于模型训练、微调、优化、检索增强、测试评估，不能只看"能不能拿到"，还要看"有没有权利这样使用"。

企业至少要自查：

• 数据来源是否清楚；

• 是否有授权文件、合同、开源协议或其他合法依据；

• 授权范围是否覆盖模型训练、优化、测试或商业化使用；

• 是否涉及个人信息、敏感个人信息、商业秘密或未公开经营信息；

• 是否做过脱敏、清洗、去重、过滤和风险标注；

• 是否能追溯到数据来源、处理时间、处理人员和处理方式；

• 用户上传内容是否进入训练或优化流程，是否取得用户授权。

如果企业在这些问题上无法形成说明，就容易导致备案材料中的语料合规部分过于薄弱。

09、企业到底要准备哪些材料

企业准备大模型备案或上线登记相关材料时，不能只看有没有文件，还要看文件之间能不能互相印证。

可以先按以下清单梳理：

很多企业的问题不在于完全没有材料，而是材料之间对不上。

例如：

• 产品说明写的是"知识库问答"，但语料说明没有知识库来源。

• 模型说明写的是"第三方 API 调用"，但安全评估却没有应用层测试。

• 服务协议写了投诉举报入口，但制度文件没有投诉处理流程。

• 安全评估写了整改优化，但没有整改记录和复测结果。

• 关键词库写了风险词，但没有对应风险类别和处置策略。

这些都会削弱材料的可信度。

10、企业上线前，先做一次备案准备度自查

正式准备材料前，建议企业先做一次内部自查。重点不是立刻写完整报告，而是先判断路径和缺口。

可以从以下 10 个问题开始：

1. 产品是否面向公众提供服务？

2. 产品是否具备文本、图片、音频、视频等生成式 AI 能力？

3. 产品是自研模型、开源部署、微调模型，还是调用第三方 API？

4. 是否直接调用已备案模型能力？

5. 当前路径更接近完整备案，还是上线登记？

6. 是否能说明模型名称、版本、参数规模、部署方式和调用关系？

7. 是否能说明训练语料、知识库语料、测试语料的来源和授权依据？

8. 是否已有安全测试题库、关键词库和人工复核机制？

9. 是否有风险样本整改记录和复测记录？

10. 是否能在产品显著位置或详情页面公示所使用的备案或登记服务信息？

如果以上问题有 3 个以上回答不清楚，说明企业不是差一份文件，而是需要先做备案路径和材料缺口判断。

尤其是以下情况，更建议提前梳理：

• 产品已经准备上线；

• 已经接入第三方大模型 API；

• 已经开放用户上传文件；

• 产品涉及行业知识库问答；

• 产品面向外部客户提供智能客服或 AI 助手；

• 已经有一版安全评估报告，但缺少测试记录；

• 不确定当前产品属于完整备案还是上线登记；

• 不确定现有材料是否能支撑属地审核要求。

11、GB/T 45654-2025 实施后，建议按这条线推进

如果企业已经准备上线 AI 产品，建议按照以下顺序推进：

做产品定性。

明确产品是否属于生成式人工智能服务，是否面向公众，是否涉及舆论属性或社会动员能力，是否需要完整备案或登记。

梳理模型来源。

确认模型基座、版本、部署方式、调用方式、供应商关系、是否微调、是否二次开发。

梳理语料和数据。

把训练数据、知识库数据、测试数据、用户输入输出数据分开说明，逐项核查来源、授权、处理方式和留痕记录。

搭建安全测试体系。

按照风险类别、业务场景、攻击方式、正常使用场景设计测试题库，避免只做形式化测试。

建设关键词库和拦截策略。

将关键词库与风险分类、命中规则、人工复核、处置机制、更新记录相结合。

形成整改闭环。

对测试发现的问题形成样本记录、原因分析、整改措施、复测结果和完成记录。

整理备案材料。

将产品说明、模型说明、语料说明、安全评估报告、制度文件、服务协议、日志机制、投诉举报机制、应急机制等材料统一起来，确保相互对应。

上线后持续管理。

备案或登记不是终点。产品上线后，企业仍需要持续监测模型输出、用户投诉、风险样本、系统日志和安全策略效果，并根据实际情况更新测试题库、关键词库和整改记录。

备案不是为了增加企业负担，而是为了让产品上线前的风险更可控、材料更完整、责任边界更清晰。

如果你不确定自己的产品到底是完整备案还是上线登记，或者不确定当前材料是否足够支撑安全评估，可以先做一次"备案路径 + 材料缺口"诊断。