大模型备案的工作量,通常被企业明显低估。一个完整的备案项目,往往要牵扯到五类人员:产品负责人、技术负责人、安全负责人、法务合规负责人、运营管理人员。同时还至少牵涉六类系统或材料来源:模型服务系统、内容审核系统、用户管理系统、日志系统、知识库系统、投诉举报系统。

已经过审版材料

一、备案审核底层看的是风险证明


不少企业接到备案任务,第一反应是"赶紧把资料填好"。于是内部开始分工:产品出功能介绍,技术出模型参数,法务出服务协议,安全团队补一份评估报告,最后合规人员打包提交。

这种做法最大的问题,在于各部门交上来的材料是相互孤立的——产品说的是一套,安全评估测的是另一套,服务协议承诺的又是第三套,日志系统还支撑不了追溯。材料看起来挺全,但治理体系根本没有闭合。

备案审核,其实就看三件事:

① 你清不清楚自己的AI服务属于什么场景——是内部工具还是对外服务?只生成文本还是图文音视频都能生成?有没有调用工具、操作业务系统的能力?

② 这个场景下的主要风险,你有没有识别完整——违法违规内容、数据来源、提示注入、幻觉误导、工具越权、用户滥用、未成年人保护、日志不可追溯……

③ 针对这些风险,你有没有建立真正的控制措施,而且能拿出证据——不是一句"已建立审核机制"就完事,而是要说明规则是什么、流程怎么走、技术怎么实现、拦截记录在哪里。

从这个角度来说,大模型备案材料至少要能回答下面四个层次的问题:

审核关注点

企业要证明什么

常见材料载体

服务是否应纳入备案范围

服务对象、使用场景、生成能力、开放方式是否清楚

产品说明、功能截图、服务流程图

风险是否识别完整

模型、数据、内容、用户、工具、日志等风险是否被识别

安全自评估报告、风险清单、测试题库

控制措施是否真实存在

是否有制度、系统、人员、流程、技术策略支撑

管理制度、审核策略、系统截图、拦截记录

结果是否可追溯

用户、输入、输出、模型版本、处置记录是否可回溯

日志字段说明、留存截图、工单记录、整改台账

二、备案至少涉及7类控制域


大模型安全不能只靠几道"护栏"或者一套敏感词库。输入输出审核只是其中一项能力,覆盖不了模型来源、语料来源、插件调用、个人信息保护、日志审计、违法内容处置这些环节。

对照 NIST AI 风险管理框架、ISO/IEC 42001 人工智能管理体系、OWASP 大模型应用风险分类、MITRE ATLAS 攻击技术框架,再加上国内生成式AI服务监管的要求,企业至少要把下面这7类控制域建起来。

控制域

备案审核中的实际含义

企业应准备的证明材料

治理与责任

企业是否有明确的AI安全责任体系

AI安全管理制度、岗位职责、审批流程、责任人清单

场景与风险分级

不同模型服务是否按风险程度分类管理

场景说明、服务对象说明、风险分级表、上线准入规则

模型与应用评测

模型是否经过安全测试、红队测试和回归测试

测试题库、测试记录、安全评估报告、整改记录

语料与数据安全

训练数据、知识库数据、用户输入是否来源合法、处理合规

语料来源说明、授权证明、清洗规则、标注规则、抽检记录

内容安全管控

输入和输出是否能识别、拦截、处置违法违规内容

审核规则、关键词库、语义审核策略、拦截截图、人工复核流程

运行时控制

模型调用、工具调用、接口调用是否有边界

模型调用链路图、权限控制规则、限流策略、工具白名单

监测审计与响应

是否能复盘问题、定位责任、形成整改

日志留存说明、投诉举报记录、事件处置流程、整改闭环台账

这7类控制域共同构成备案的安全治理体系。如果企业只准备服务协议和模型介绍,语料说明、安全测试、日志追溯、内容审核和应急处置材料都没有,那备案资料就很容易出现"看起来完整、实质上断链"的问题。

三、备案材料要形成完整的证明链


判断备案材料专不专业,看的不是文件数量,而是材料之间能不能互相印证。一套相对完整的备案证明链,至少应该覆盖下面这6个环节:

① 模型证明链

说清楚模型从哪来、版本是什么、能干嘛、干到什么程度,以及安全测试结果如何。

② 数据证明链

覆盖训练数据、微调数据、知识库数据、用户输入数据的来源、授权、清洗、标注、脱敏和质量控制。

③ 内容证明链

输入审核、输出审核、拒答策略、敏感词库、语义识别、人工复核、违法内容处置——这些机制都要有。

④ 用户证明链

用户注册、实名认证、服务协议、个人信息处理规则、投诉举报和账号处置机制,都要说得清楚。

⑤ 日志证明链

用户ID、输入内容、输出内容、模型版本、调用时间、IP、设备信息、审核结果、处置动作——这些字段留没留?

⑥ 处置证明链

出了问题之后,企业怎么发现、怎么分级、怎么处置、怎么上报、怎么整改、怎么复测——要有完整的闭环记录。

这6条链路不是各管各的。安全评估报告里发现了某类风险,内容审核策略里就要有对应的拦截规则;服务协议里承诺了投诉举报,系统页面上就要有入口截图;日志留存制度写明了不少于6个月,后台系统就要能提供字段样例和留存策略。

材料之间对不上时,通常会有这些表现:

常见问题

表面表现

实质原因

模型说明写得很完整,但安全评估很薄

有模型参数,没有风险验证

模型能力没有转化为测试维度

服务协议承诺很多,但系统无入口

有文本,没有产品实现

用户权益保护没有落地

日志制度写了留存,但无字段样例

有制度,没有技术证明

追溯能力无法核验

内容审核写了"自动审核",但无规则

有结论,没有审核依据

内容安全机制不可解释

语料说明写"公开数据",但无来源清单

有概括,没有凭证

数据合法性证明不足

四、备案审核中最容易被低估的9类安全能力


很多企业觉得,大模型备案最重要的就是"内容审核",只要把敏感词库建好就差不多了。这个判断只对了一半——内容安全确实是重点,但绝不是全部。

从实际备案准备和AI安全治理的角度来看,企业至少要把下面这9类能力补齐。

1、AI资产台账能力

先搞清楚内部有哪些大模型应用、调用了哪些模型、有没有接外部API、有没有RAG知识库、有没有插件或工具调用能力、是不是面向公众开放的。连AI资产清单都没有,后面的风险分级、安全评估、日志审计和变更管理根本无从谈起。

2、场景风险分级能力

同样是大模型问答,内部办公助手、客服系统、医疗咨询、金融营销、未成年人陪伴产品、智能体执行系统——这些场景的风险等级完全不是一个量级的。分级不能只看模型参数大小,要看五个维度:服务对象是谁、数据有多敏感、暴露面有多大、自动化程度多高、出问题会造成什么社会影响。

3、模型安全评测能力

备案材料里不能只写一句"模型效果良好"就完事。企业要围绕违法违规内容、歧视偏见、危险能力、个人信息泄露、提示注入、幻觉误导、拒答稳定性这些维度,建立起自己的测试题库。建议至少形成三类测试集:基础安全测试集、业务场景测试集、整改复测测试集。每次模型版本升级,高风险题目都要做回归测试。

4、输入输出内容审核能力

内容审核不是简单匹配敏感词就够用了。企业要建立起"关键词规则+语义识别+模型审核+人工复核+处置记录"这套组合机制。输入侧重点防的是用户提交违法违规内容、诱导越狱的提示词、恶意攻击指令、涉敏感数据等;输出侧重点防的是模型生成违法违规、虚假误导、侵权、低俗、危险指导、个人信息泄露等内容。

5、语料与知识库治理能力

大模型服务的数据来源通常有好几类:训练数据、微调数据、提示词模板、RAG知识库、用户反馈数据、业务文档。每一类数据都要说清楚来源是什么、有没有授权、怎么清洗的、怎么去重脱敏的、标注规则是什么、怎么抽检质量的、更新机制是什么。备案时最容易出问题的就是"语料来源概括化"——比如只写"来源于公开互联网数据",但说不清楚具体来源类别、采集方式、授权依据和清洗规则,这种表述很难支撑合规证明。

6、模型和插件供应链管理能力

企业用开源模型、接第三方模型API、装社区插件、连MCP Server、调外部知识库、用第三内容审核接口——这些本质上都是在引入外部供应链。供应链管理至少要说清楚三件事:模型或组件来源可不可信、调用权限有没有受控、异常或停服时有没有替代或降级方案。

7、智能体工具权限控制能力

大模型从"回答问题"变成"执行动作"以后,风险会明显上升。智能体可能会去调用数据库、发邮件、改配置、建工单、提交代码、生成合同、直接触达用户。这类场景必须建立四道控制:工具白名单、动作分级、高风险操作要人工确认、操作日志要完整留存。否则真出了误操作,企业很难证明自己已经尽到了安全管理责任。

8、日志留存和审计追溯能力

日志不是为了"有个记录"而存的,而是出事了以后能还原整个过程。一条有效的日志至少应该能回答这七个问题:谁用了服务、什么时候用的、输入了什么、模型输出了什么、调用的是哪个模型版本、审核有没有通过、系统采取了什么处置动作。备案材料里,日志字段说明、留存期限、访问控制、防篡改机制和样例截图,这些都是关键材料,缺一不可。

9、投诉举报和安全事件处置能力

大模型服务上线以后,不可能完全没有异常输出。审核老师更关注的,是企业有没有发现问题的能力、有没有接收举报的渠道、有没有处置和整改的流程。投诉举报机制要有入口、有时限、有责任人、有处置流程、有反馈机制;安全事件要有分级标准、有上报路径、有止损方案、有记录、有复盘、有复测。光写一句"用户可联系客服反馈",通常是过不了关的。

五、不同应用场景,备案关注点各有侧重


企业做备案准备,不能只套一个通用模板就完事。不同场景对应的风险重点不一样,材料结构也应该有所区别。

应用场景

主要风险

备案材料重点

智能客服

错误答复、用户投诉、个人信息泄露、敏感问题生成

服务流程、知识库来源、内容审核、日志留存、投诉举报

企业知识库问答

内部文档泄露、权限穿透、引用错误、提示注入

权限过滤、RAG检索规则、文档来源、引用校验、访问日志

营销文案生成

虚假宣传、违规广告、侵权内容、诱导性表述

输出审核、行业禁用词、人工复核、内容标识、样本测试

智能硬件/机器人

语音交互、摄像头采集、生活建议、家庭场景数据

个人信息保护、设备权限、使用边界、未成年人保护、日志脱敏

智能体办公

工具越权、误发邮件、误改数据、自动化决策风险

工具白名单、动作分级、人工确认、回滚机制、审计链路

图片/音视频生成

深度合成、肖像侵权、虚假信息、标识缺失

生成内容标识、版权控制、视频审核、传播追溯、元数据管理

特别注意:知识库和智能体场景

知识库问答不只是"问答"那么简单,它牵涉到企业内部文档、客户资料、合同、工单、制度和业务数据。如果权限控制没到位,模型可能把不该看的内容检索出来;如果提示注入防护没到位,外部文档可能诱导模型绕过系统规则。智能体就更不用说了——传统大模型最多生成一段文字,智能体可能直接执行操作,只要牵涉到数据库、邮件、工单、支付、代码仓库、后台配置、客户触达,就必须把工具权限、人工确认和审计回滚写进备案材料。

六、企业至少应形成8组核心文件


大模型备案材料不是越多越好,关键是要覆盖到真正的风险点。通常可以按照下面这8组来组织材料:

01主体与服务基本材料

企业主体信息、产品名称、服务对象、上线方式、服务入口、服务范围、用户规模、部署方式。

02模型来源与能力说明

模型名称、版本号、来源方式、自研或第三方调用情况、模型结构、输入输出模态、能力边界、局限性说明。

03语料与数据合规材料

训练数据、微调数据、知识库数据、标注数据、用户反馈数据的来源说明、授权证明、清洗规则、质量抽检和敏感数据处理机制。

04安全评估与测试材料

测试题库、风险分类、测试维度、测试样本、预期结果、实际结果、整改记录和复测结论。

05内容安全管控材料

输入审核规则、输出审核规则、关键词库、语义审核策略、拒答策略、人工复核、违法内容处置流程。

06用户权益保护材料

服务协议、个人信息处理规则、未成年人保护说明、投诉举报入口、账号管理、注销流程和用户申诉机制。

07生成内容标识材料

显式标识、隐式标识、元数据字段、标识展示位置、标识保留策略和传播追溯说明。

08日志留存与应急处置材料

日志字段、留存期限、访问权限、防篡改措施、安全事件分级、处置流程、整改闭环和复测机制。

Logo

AtomGit AI 社区提供模型库、数据集、Agent、Token等资源

更多推荐