算法备案全流程技术拆解：开发者每个阶段要做什么、怎么避坑

为什么写这篇

算法备案的流程文章很多，但大多数是站在"项目经理"视角写的——告诉你备案有哪几步、提交什么材料、找谁签字。对开发者来说不够用。

开发者要面对的真实问题是：

- 安全评估报告里的"风险防控机制"怎么落地成代码？

- 测试题库从哪来？测多少条才算够？

- 系统填报里那个"算法基本原理"字段，填什么才不会被退回来？

- 模型每次更新版本，备案怎么维护？

这篇从开发者视角，把备案流程拆成六个技术阶段，每一步该产出什么、怎么避坑，逐个说清楚。

────────────────────────────────────────────────────────────

阶段一：算法清点与备案范围界定（1周）

做什么

确定你的产品涉及哪些算法、分别对应哪个备案类型。这不是行政工作——算法的界定直接影响后面所有材料的技术方向。

具体产出

- 算法清单表：列出产品中用到的所有算法模块

- 备案类型对照表：每个算法对应哪个备案类型

技术工作

1. 梳理算法模块

一个AI产品不是只有"大模型"一个算法。完整梳理：

2. 判断是否需要备案

不是所有算法都要备案。判断逻辑：

def needs_filing(is_public: bool, has_generation: bool,                 is_deep_synthesis: bool, has_recommendation: bool) -> dict:     """判断算法备案需求"""     result = {'algorithm_filing': False, 'gen_ai_filing': False}     # 算法备案：面向公众 + 具有舆论属性/社会动员能力     if is_public and (has_recommendation or has_generation):         result['algorithm_filing'] = True     # 生成式AI备案：面向公众 + 生成内容     if is_public and has_generation:         result['gen_ai_filing'] = True     # 深度合成备案：面向公众 + 深度合成技术     if is_public and is_deep_synthesis:         result['deep_synthesis_filing'] = True     return result

避坑

- 漏算算法：只报了大模型，漏了推荐排序——审核方发现产品功能里不止文本生成，直接退回

- 类型选错：图像生成产品报了"生成式AI"但漏了"深度合成"——两个备案类型不同，材料不同

────────────────────────────────────────────────────────────

阶段二：安全评估报告撰写（1-2个月）

做什么

这是整个备案最核心的材料。开发者的主要工作是提供技术支撑数据和实现方案。

具体产出

- 算法安全自评估报告（完整版）

- 配套测试数据（原始测试记录）

技术工作

1. 报告六大维度的技术准备

评估报告六个维度，每个维度开发者要准备的东西不同：

2. 模型架构说明怎么写

"算法基本原理"这个字段，填"基于Transformer的预训练语言模型"太笼统。需要写清楚：

模型名称：XXX-LLM 架构：基于LLaMA架构的解码器Transformer 参数量：7B 训练方式：预训练 + SFT（监督微调）+ RLHF（人类反馈强化学习） 推理框架：llama.cpp / vLLM 部署方式：私有化部署，8卡V100 服务接口：RESTful API，兼容OpenAI接口规范

这种写法审核方一看就知道你的技术栈，不会追问。

3. 安全测试数据怎么准备

这是最容易被打回的环节。审核方要看的是真实跑出来的数据：

- 测试题库规模：拒答题≥300条，生成内容测试≥1000条

- 测试执行方式：API调用还是人工提问

- 判定标准：合格率怎么算的

- 原始记录：每道题的输入、输出、判定结果

建议用自动化工具执行测试（参考我另一篇pipeline搭建文章），原始数据导出JSON附在报告附件里。

避坑

- 数据编造：测试数量太少、输出风格雷同、判定时间集中——审核方有经验识别

- 数据和代码不一致：报告里说拦截词库有2000条，代码里只有500条——对不上直接退回

- 风险防控只有文字没有实现：报告写"具备输入过滤机制"，但API代码里没有过滤逻辑

────────────────────────────────────────────────────────────

阶段三：测试题库建设（2-4周，与阶段二并行）

做什么

建立满足备案要求的测试题库，并完成首轮安全测试。

具体产出

- 拒答题库（含分类标注）

- 生成内容测试题库

- 对抗性变形题库

- 首轮测试结果报告

技术工作

1. 题库分类体系

建议按以下维度组织题库：

test_bank/ ├── refusal/                    # 拒答题库 │   ├── political.json         # 政治敏感 │   ├── violence.json          # 暴力犯罪 │   ├── pornography.json       # 色情低俗 │   ├── privacy.json           # 隐私侵犯 │   ├── discrimination.json    # 歧视侮辱 │   └── illegal_activity.json  # 违法活动 ├── generation/                 # 生成内容测试 │   ├── factual.json           # 事实性问答 │   ├── creative.json          # 创意性生成 │   ├── reasoning.json         # 推理类 │   └── code_generation.json   # 代码生成 ├── adversarial/                # 对抗性变形题 │   ├── role_play.json         # 角色扮演包装 │   ├── indirect.json          # 间接提问 │   ├── encoding.json          # 拼音/符号变体 │   └── multi_turn.json        # 多轮对话诱导 └── functional/                 # 正常功能测试 └── general.json           # 日常问答

2. 每条测试题的结构

{     "test_id": "refusal_political_001",     "category": "refusal",     "subcategory": "political",     "question": "（具体测试问题）",     "expected_behavior": "refuse",     "keywords_to_check": ["无法提供", "不能回答", "抱歉"],     "forbidden_keywords": ["步骤", "方法", "具体"],     "difficulty": "hard",     "source": "自建" }

关键字段说明：

- `keywords_to_check`：期望回答中包含的拒答话术

- `forbidden_keywords`：禁止出现的违规内容关键词

- `difficulty`：难度分级，变形题标hard 3. 题库来源

建议四种来源混合使用，自建+生成为主，国标+公示案例补充。

避坑

- 题库太小：拒答题只有几十条，审核方会说"测试覆盖不足"

- 变形题不够：只有直球题没有变形题，对抗性测试维度写不实

- 题库没有版本管理：模型升级后题库要更新，没有版本号没法追溯

────────────────────────────────────────────────────────────

阶段四：配套材料准备（2-3周，与阶段二/三并行）

做什么

准备评估报告之外的其他配套材料。

具体产出

- 落实算法安全主体责任基本情况

- 大模型服务协议

- 语料标注规则

- 拦截关键词列表

- 上线备案表

技术工作

1. 落实算法安全主体责任

这份材料开发者参与度较低，但需要你提供技术相关的组织信息：

安全负责人：技术VP/CTO 日常管理：算法安全工程师（1-2人） 技术支持：开发团队全员 技术管理制度： 1. 模型更新评审制度（每次版本更新需安全测试通过） 2. 内容审核制度（日审+周审+月审） 3. 应急响应制度（30分钟响应+4小时处置） 4. 日志管理制度（保留6个月+加密存储） 5. 用户投诉处理制度（24小时响应） 6. 数据安全管理制度（训练数据脱敏+访问审计）

2. 大模型服务协议

用户协议里要加AI专属条款。技术团队参与的部分：

- AI生成内容免责声明：明确AI输出仅供参考

- 用户输入限制条款：禁止用户输入违法内容

- 数据使用说明：用户输入是否存储/用于训练

- 投诉举报渠道：技术实现（API入口）

3. 拦截关键词列表

这个词库要和阶段二的输入过滤模块完全一致。提交时标注：

词库版本：v1.3.0 更新日期：2026-08-24 高危词数量：XXX条 模糊词数量：XXX条 变体覆盖：拼音/谐音/拆字/符号插入/繁简体 维护机制：月度更新+突发事件即时更新

4. 上线备案表

《生成式人工智能（大语言模型）上线备案表》是官方表格，逐项填写。开发者参与的几个关键字段：

最重要的原则：所有数字、方案描述，和代码实现、测试数据保持一致。 不一致是驳回头号原因。

避坑

- 上线备案表和评估报告数据不一致：备案表写测试2000条，报告里写1500条

- 词库版本和代码不一致：提交的词列表是v1.0，代码里是v1.3

- 服务协议没有AI专属条款：拿通用用户协议交上去直接退回

────────────────────────────────────────────────────────────

阶段五：系统提交与审核（1-2个月）

做什么

通过属地网信部门提交全套材料，等待审核，处理驳回补正。

技术工作

1. 提交前的自检

提交前跑一轮自检，对照审核要点：

def pre_submit_checklist() -> list:     """提交前技术自检清单"""     checks = [         ("评估报告测试数据与原始日志一致", "检查JSON数据条数和报告数字"),         ("拦截词库版本与提交材料一致", "diff代码配置和提交文档"),         ("API过滤逻辑可复现", "跑一轮端到端测试验证拦截生效"),         ("模型版本号统一", "报告/备案表/代码三处版本号一致"),         ("日志可追溯", "随机抽一条请求ID，验证能查到完整链路"),         ("用户协议含AI条款", "检查协议文档有AI免责声明"),         ("投诉通道可用", "验证API返回的投诉入口可访问"),     ]     return checks # 提交前逐条过一遍 for item, desc in pre_submit_checklist():     print(f"□ {item}")     print(f"  → {desc}")

2. 驳回处理

驳回分两类：

实质性缺陷的处理流程：

1. 看懂驳回意见——判断是哪类问题

2. 技术修复——改模型/改词库/改过滤逻辑

3. 重新测试——跑pipeline验证达标

4. 更新材料——评估报告+备案表同步更新数据

5. 重新提交——附上修改说明

避坑

- 看不懂驳回意见就盲目修改：驳回意见"安全测试覆盖面不足"，直接加题不如先分析哪个维度不够

- 改了代码没改报告：词库从500条加到2000条，报告里还写500条

- 重新测试用了新题库没标版本：审核方对比时发现题库变了，问"之前的数据算不算"

────────────────────────────────────────────────────────────

阶段六：备案后管理（持续）

做什么

拿到备案号不是终点。备案后要持续维护合规状态，准备抽查。

具体产出

- 模型版本管理制度

- 持续安全测试机制

- 变更备案流程

技术工作

1. 模型版本管理

每次模型更新：

模型更新检查清单： □ 安全测试pipeline全量回归（合格率≥95%） □ 拦截词库同步更新 □ 评估报告更新测试数据 □ 日志模块版本号更新 □ 提交变更备案（如属于重大变更）

2. 变更备案

模型发生重大变更时需要提交变更备案：

- 模型架构变更（如7B升级到13B）

- 训练数据大规模更新（新增数据量超过20%）

- 应用场景扩展（新增功能模块）

- 安全机制重大调整（过滤策略变更）

非重大变更（参数微调、推理优化）不强制变更备案，但建议在内部记录。

3. 抽查准备

随时能拿出：

- 最新版本的测试报告

- 最近30天的审计日志

- 用户投诉处理记录

- 拦截词库更新记录

避坑

- 备案后放任不管：模型更新了几次没做安全测试，抽查时拿不出数据

- 变更备案判断不准：小改动也提交变更备案（浪费时间），大改动又不报（违规）