随着《生成式人工智能服务管理暂行办法》持续落地，大模型安全评估、算法备案已成为AI产品上线的硬性合规门槛。不少研发与合规从业者存在疑惑：早期备案曾要求补充基座裸模型风险测试，如今网信办明确不再要求企业提交无审核模型的相关资料。这背后的逻辑，绝非监管对裸模型风险的忽视，而是审查焦点的战略转移——从“验证模型有多危险”转向“核验防护措施有多牢固”。

监管深知原始基座的“原生风险”客观存在，因此不再纠结于证明这一点，而是将重心放在企业对外服务的输出内容安全性及全流程防护能力上。同时需明确，网信办的审核标准并非一成不变，而是伴随AI技术迭代与新型风险动态更新。

一、两类模型核心概念区分

1. 附加审核策略模型（合规上线标准版本）

这是企业面向公众提供服务的唯一合法形态，构建了“模型+网关+运营”的三维防御体系：

1. 模型层：通过RLHF/DPO进行安全对齐微调，植入安全系统提示词（System Prompt）；

2. 网关层：建立输入前置审核与输出后置审核的双链路风控机制，确保“不安全不出域”；

3. 运营层：具备违规内容拦截、改写、会话熔断、全链路日志留存及恶意账号管控能力。

   所有公网API、网页、小程序及客户端产品，均强制使用该版本，核心目标是确保输出内容的绝对安全。

2. 不附加审核策略裸模型（原始基座）

未经安全对齐、无外置风控网关的原生基座，缺乏内容过滤逻辑：

1. 仅允许在企业内网隔离部署，用于红队安全对抗、算法漏洞挖掘及科研测试；

2. 禁止公网开放，禁止对外提供调用。它非服务品，不具备面向公众服务的合法资质。

二、附加审核模型 VS 无审核裸模型完整对比表

对比维度	附加审核策略（合规上线版本）	无审核裸模型（原始基座）
核心定位​	对外服务的“成品”：强调安全可控	内部研发的“原材料”：强调能力上限
运行机制​	安全微调+双链路风控网关，具备拦截、拒答、熔断能力	仅原始基座推理，无对齐、无过滤、无风控逻辑
输出表现​	能有效识别拦截违法、暴力等内容；对边界问题具备风险缓释能力	无任何拒答逻辑，易被诱导输出训练数据中的违规内容
合规重点​	重点核验其防护能力与输出安全性	作为内部风险参考
法律风险​	风险可控，日志可溯源，符合法规要求	极高。若外流，企业将面临下架、罚款及责任人追责
适用场景​	C端产品、对外API、政企公开服务、金融/教育/医疗	仅限纯离线内网科研、红队演练，严禁联网

三、最新要求，备案过程中，监管不要求提交无审核策略的测试入口

许多从业者误以为监管“放过”了裸模型，实则是审查逻辑发生了深刻变化：不再关注“源头有多脏”，而是严查“水龙头过滤得干不干净”。

1. 法规层面：审查标的是“服务”，而非“资产”

《生成式人工智能服务管理暂行办法》明确规定，仅面向境内公众提供AI服务需履行备案义务。

• 裸模型属于企业的技术资产或研发工具，在内网封闭环境下使用，不直接触达公众，因此不属于备案审查的直接对象。

• 带审核模型是企业对外提供的服务实体。监管审查的是企业最终交付给用户的产品安全性。只要企业不将裸模型公网化，监管便默认其处于受控状态，无需事前报备。

2. 审查价值层面：从“证明有风险”转向“证明能防护”

早期要求提交裸模型报告，是为了建立风险基线。但在实践中发现：

1. 结论同质化：所有裸模型均存在风险，测试结果无区分度，无法体现企业安全建设的优劣。

2. 能力错配：备案的核心是考核企业的安全工程能力（如审核网关的拦截率、误拦率、响应速度），而非模型的“作恶能力”。

3. 实质重于形式：监管现在更看重企业在带审核版本上的红队测试结果。只有通过了带防护的对抗测试，才能证明企业的安全水位达标。

3. 风险管控逻辑：安全闸门必须在服务侧

行业已形成共识：完全消除大模型的“幻觉”或“原生风险”在技术上短期内难以实现。因此，监管策略调整为“源头可控，出口严防”：

• 内网裸模型：风险被物理隔离，由企业内控机制管理。

• 公网服务接口：必须加装“安全闸门”。监管重点核查这道闸门的可靠性——即无论后端模型如何输出，前端呈现给用户的内容必须符合法律法规。

四、从政策调整看网信办三大监管重心转变

取消裸模型备案材料，清晰地折射出国内生成式AI治理思路的成熟：

1. 监管重心：从「管控模型」转向「管控服务行为」

监管不再试图微观干预企业的技术研发过程（如内网怎么训模型），而是牢牢抓住“对外服务”这个牛鼻子。

• 管应用，不管研发：鼓励企业在内网大胆创新、测试极限能力，但产品一旦上线，必须套上“紧箍咒”。

• 谁服务，谁负责：企业必须对最终输出内容的安全性负主体责任。这种转变极大地释放了科研活力，同时守住了安全底线。

2. 审查逻辑：从「形式化材料」转向「实质安全能力」

备案审查不再是“材料堆砌大赛”，而是对企业安全体系的“实战化考核”。

• 去伪存真：不再要求企业重复证明“裸模型有风险”这种常识性问题。

• 聚焦实战：重点核验输入输出双审机制的有效性、越狱提示词的拦截率、全链路日志的完整性以及应急处置的及时性。

• 结果导向：监管关注的是“用户看到的内容是否安全”，而非“模型内部参数是否纯净”。

3. 治理模式：分类分级与全链条闭环

监管采用了更加精细化的治理手段：

• 分类分级：严格区分内网科研与公网商用。对内网研发包容审慎，对公网服务严守红线。

• 全链条闭环：构建“事前准入（备案）+事中监测（巡查）+事后追责（处罚）”的完整链条。备案只是第一道关口，持续性的安全运营能力才是关键。

五、审核要求动态迭代，防护能力需持续进化

监管部门对上线模型的防护能力要求正在不断提高。企业需关注以下迭代趋势：

1. 标准量化与细化：从早期的框架性要求，发展到国标GB/T 45654-2025中明确的31类细分风险及量化指标（如拒答率）。审查颗粒度越来越细。

2. 对抗样本升级：监管的红队测试用例库持续更新，涵盖多模态诱导、嵌套提示词、逻辑陷阱等高级攻击手法。仅靠关键词过滤已无法通过备案，必须引入语义理解、意图识别等高级防护技术。

3. 全生命周期审核：监管不仅看备案时的“快照”，更看上线后的“直播”。常态化巡检要求企业的审核策略必须具备持续学习和迭代的能力。

4. 新场景专项治理：针对AI外呼、智能体（Agent）、Sora类视频生成等新场景，监管正在制定专项审核规则。防护体系需具备扩展性。

六、企业落地规范

1. 对外商用（APP/API/SaaS）：

   • 铁律：必须使用带完整审核策略的模型。

   • 备案：提交材料聚焦于上线版本的安全评估报告，重点展示审核机制的拦截效果、误拦处理流程及日志留存情况。

   • 运维：建立“监管新规-红队测试-策略更新”的快速响应闭环，确保护栏常新。

2. 内部研发/科研：

   • 隔离：裸模型必须物理隔离，严禁连公网。

   • 用途：仅限内部红队测试，用于发现现有审核策略的漏洞，反哺线上安全。

   • 归档：相关测试数据内部存档，无需上报，但需备查。

3. 合规红线警示：

   • 严禁裸奔：无安全防护措施的模型提供公网服务均为重大违规。

   • 严禁僵化：审核策略“一备了之”、长期不更新导致防护失效，将面临整改或关停风险。