API 中转站被处罚：这条路以前被认为没人管

本文依据公开材料整理，不含任何产品与厂商推荐，不构 API 中转站被处罚：这条路以前被认为没人管成法律意见；涉及法规适用与个案判断的，请以正式发布文本、属地口径及具体案情为准。

0 先说结论

第一，这起处罚罚的不是"做中转"，是"没做安全评估"。 国家网信办 2026 年 9 月 15 日发布的执法典型案例中，第 10 起为"江苏某科技股份有限公司提供生成式人工智能服务未按规定进行安全评估案"：该企业运营的 2 个网站以"API 中转站"方式调用多个大模型产品接口，提供对话、问答等服务，未按规定开展安全评估工作，存在内容安全风险，违反《生成式人工智能服务管理暂行办法》《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》等规定，属地网信办依法责令其改正、从严处理责任人，予以警告处罚。处罚未指向"中转"这一模式本身。

第二，这是"中转站"第一次进入公开执法视野。 此前关于中转站的合规讨论基本停留在行业传闻层面——上游模型已经备过案、自己不训练不微调、只做接口聚合，很多经营者据此认为自己不在监管范围内。这一案例把这层假设打掉了。

第三，责任判定不看你调的是谁的模型，看你以谁的名义把能力提供给了谁。《生成式人工智能服务管理暂行办法》第二十二条把"通过提供可编程接口等方式提供生成式人工智能服务"明确写进了服务提供者的定义；第十七条规定提供具有舆论属性或社会动员能力的生成式人工智能服务应开展安全评估并履行算法备案。两句话放在一起，中转站的定性问题基本就清楚了。

第四，这一案例中最容易踩的坑，是"备用调用没有纳入评估"。 中转站按定义会接多个模型，形成主用与备用路径。即使某个模型只在故障时启用，它仍是这套服务预设的运行方式之一，属于评估对象。

1 案例还原：这起处罚到底罚了什么

1.1 官方表述

先把官方口径完整放在这里。2026 年 9 月 15 日，国家网信办发布近期网络安全、数据安全、个人信息保护等领域执法典型案例，其中第 10 起为：

同一批通报的第 9 起可以对照看：四川某科技有限公司运营的微信小程序提供 AI 文本对话、图片生成等服务，未对生成合成内容添加显式标识，未在文件元数据中添加隐式标识，未在提供导出功能时添加显式标识，同时未按规定落实安全评估要求，被责令下线该小程序。

两起案例合起来给出一个很清楚的信号：执法关注的是"义务有没有履行"，而不是"业务叫什么名字"。

1.2 三个容易被忽略的细节

细节一：只指出了"未做安全评估"，没有指出其他违规项。 这通常意味着两件事中的一件——要么其他项确实做了，要么这一项是最容易证明、最不容争辩的一项。安全评估的义务是"有没有组织过、有没有提交过报告"，属于程序事实，举证门槛低，执法确定性高。这也是它成为第一个突破口的原因。

细节二：处罚组合是"责令改正 + 从严处理责任人 + 警告"。 "从严处理责任人"这一句值得单独注意。它意味着责任不只在公司层面，还指向了具体的人。对内部而言，这一条的传导力比罚款更强——它把合规义务从"公司的形式动作"变成了"个人要承担后果的事"。

细节三：涉及的是"2 个网站"。 多站点运营在中转站业务里很常见——一个做展示、一个做调用入口，或者不同域名面向不同客户群。它带来的直接问题是：评估与公示的义务范围是"服务"而不是"网站"，多站点不构成多份豁免，也不构成"主站评估了分站就不用"。

1.3 罚则的上限在哪

《暂行办法》第二十一条写得很明确：违反本办法规定的，由有关主管部门依照《网络安全法》《数据安全法》《个人信息保护法》《科学技术进步法》等法律、行政法规予以处罚；法律、行政法规没有规定的，由有关主管部门依据职责予以警告、通报批评，责令限期改正；拒不改正或者情节严重的，责令暂停提供相关服务。构成违反治安管理行为的依法给予治安管理处罚；构成犯罪的依法追究刑事责任。

也就是说，这一起落在"责令改正 + 警告"这一档，属于该条文的起点位置，而它的上方还有"责令暂停提供相关服务"和治安、刑事两条路径。首案没有顶格，不代表下一次也如此。

2 为什么这一起值得单独拿出来看

2.1 中转站的商业价值是真实的

先把话说清楚：中转站这种业务形态本身不违法，它解决的是一组真实存在的需求——集中采购调用额度以降低单价、屏蔽不同厂商接口差异、提供多模型一键切换、代充值与账单合并。对没有海外支付能力、没有多厂商对接人力的小团队来说，这类服务省下的时间成本是实打实的。

问题不在模式，在模式自带的三个模糊地带：

这三个模糊地带长期无人触碰，很大程度是因为没人被罚过。执法空白期里，行业自然形成了一套自我安慰的解释：我没有终端产品、我不训练模型、我技术上改不了模型的输出，所以我不承担内容责任。

2.2 这一案例把"名称豁免"这条路堵上了

从这个案例能读出的最直接一句是："API 中转站"这个叫法不产生任何法律效果。 监管看的是你实际做了什么——你有没有以自己名义向境内公众提供生成式人工智能服务、你有没有决定模型选择与功能范围、你有没有设定用户准入与调用规则。

换个说法：把产品叫中转站、聚合平台、套壳应用还是智能助手，都不改变它实际构成的服务。 名称是市场语言，不是法律语言。

3 第一个问题永远是角色：你到底是谁

3.1 三类业务形态，三种角色

同为"调用多个模型接口"，业务组织方式不同，角色与义务就完全不同。这张表建议直接拿去对照自己的业务：

3.2 五个判据问题

不确定自己属于哪一类时，用下面五个问题过一遍。只要有一问答"是"，就应当按服务提供者设计义务，而不是先按"我不是"来设计。

1. 用户看到的是你，还是上游模型厂商？
2. 模型选择、功能范围、用户准入、调用规则，这四件事由谁决定？
3. 你有没有面向不特定对象开放的注册或使用入口（含免费试用、邀请码之外的公开入口）？
4. 你是否以自己名义对外签署使用协议、公示条款、承担用户投诉？
5. 你对外呈现的产品名称，是否独立于上游模型名称？

"没有终端界面"或"只向企业客户提供服务"都不足以单独得出豁免结论。 这是这一案例中最需要记住的一句判断——B 端不当然豁免，没有界面也不当然豁免。判断的锚点始终是"服务对象是否是境内公众"，而"公众"的边界看的是对象的确定性，不是有没有登录页。

4 四个听起来都成立的误解

误解一：模型不是我训练的，内容责任不在我

《暂行办法》第二十二条对服务提供者的定义是：利用生成式人工智能技术提供生成式人工智能服务（包括通过提供可编程接口等方式提供生成式人工智能服务）的组织、个人。定义落在"提供服务"上，没有附加"必须自己训练模型"这个前提。

同时该办法第九条规定，提供者应当依法承担网络信息内容生产者责任，履行网络信息安全义务；涉及个人信息的，依法承担个人信息处理者责任。这两项责任与模型所有权无关。

误解二：上游已经备案了，我就不用做事了

这是最普遍的误解，也是这次处罚的落点。备案、登记、安全评估是三条独立的核查线，不能互相替代：

备案信息公告里的表述是"对于通过 API 接口或其他方式直接调用已备案模型能力的生成式人工智能应用或功能，由地方网信办开展登记"。这句话给的是一条路径，不是一张免检单——它说明登记这条路存在，同时登记与安全评估要分别核查。上游模型已备案是需要核查的事项，但不能据此推定下游应用已经履行全部要求。

登记这条路的规模也已经不小：截至 2026 年 8 月 31 日，累计 1112 款生成式人工智能服务完成备案、731 款应用或功能完成登记；仅 2026 年 7 月至 8 月，新增备案 124 款、新增登记 133 款——单期新增登记数量已经超过备案数量。这个结构说明，绝大多数参与者的角色是"调用已备案模型能力的应用方"，而不是"训练模型的模型方"。也正因为走这条路的人多，登记事项与安全评估义务被混为一谈的情况才最常见。

误解三：我只面向企业客户，不算向公众提供

B 端不当然豁免。判断的关键是"服务的对象是否具有不确定性"：向任意企业开放注册、通过公开渠道售卖额度、没有实质性的准入审核，对象就是不确定的，与是否面向个人用户无关。

真实场景里还有一层：你的客户可能拿你的能力再对它的客户提供服务。 这一层会改变整个链路的暴露面，也是上游厂商在协议中限制转售的原因之一。

误解四：我改不了模型参数，做不了评估

评估的对象不是模型内部，而是你如何组织这项服务、如何控制风险。《安全评估规定》第五条的八项评估重点里，没有一项要求你掌握模型权重——它问的是安全管理负责人与审核人员的配置、用户真实身份核验、日志留存、违法有害信息的防范处置、个人信息保护的技术措施、投诉举报机制，以及为网信、公安依法履职提供技术数据支持协助的工作机制。

"不能修改模型"与"不能组织评估"是两件事。 你可能无法修复模型内部的缺陷，但你可以决定是否把这个模型纳入你的产品、在什么条件下调用它、它的返回结果是否经过与其他路径相同的检查流程。评估的作用，正是为这些决定提供依据。

5 安全评估到底评什么

5.1 什么情况下必须评估

《安全评估规定》第三条列了五种情形，触发其一即应当自行开展评估并对结果负责：

该规定第二条对"具有舆论属性或社会动员能力"的列举里，明确包含小程序、短视频、网络直播、公众账号、聊天室、通讯群组、信息分享等功能形态。

5.2 评估的八项重点

《安全评估规定》第五条要求对服务的合法性、安全措施有效性、风险防控有效性进行全面评估，并重点评估以下八项。中转站可以把它当作一份核对表：

• [ ] 确定与所提供服务相适应的安全管理负责人、信息审核人员，或建立安全管理机构
• [ ] 用户真实身份核验以及注册信息留存措施
• [ ] 用户账号、操作时间、操作类型、网络源地址与目标地址、网络源端口、客户端硬件特征等日志信息，以及用户发布信息记录的留存措施
• [ ] 对账号与群组名称、昵称、简介、备注、标识，以及信息发布、转发、评论等服务功能中违法有害信息的防范处置和有关记录保存措施
• [ ] 个人信息保护，以及防范违法有害信息传播扩散、社会动员功能失控风险的技术措施
• [ ] 建立投诉举报制度，公布投诉举报方式，及时受理并处理
• [ ] 建立为网信部门依法履行监督管理职责提供技术、数据支持和协助的工作机制
• [ ] 建立为公安机关、国家安全机关依法维护国家安全和查处违法犯罪提供技术、数据支持和协助的工作机制

5.3 一个几乎必然被漏掉的对象：备用调用

中转站按定义就会接多个模型，因此天然存在主用与备用两条路径。这里有一条容易被忽略的判断：即使备用模型只在主模型故障时才启用，它仍然是这套服务预设的运行方式之一，属于评估对象。

由此推出三个具体动作：

1. 评估范围要画到"运行方式"这一层，而不是只画"默认配置"。主用、备用、灰度、降级，都属于要覆盖的对象。
2. 切换条件本身要能说明清楚：切换是否仅由故障触发、哪些请求会被转交、转交后是否仍经过相同的检查流程。
3. 备用路径不能绕过拦截环节。这是最容易出问题的地方——主路径接了完整的内容审核，备用路径为了"快速兜底"变成直连，等于在系统里留了一条无检查的通道。

5.4 评估方式与提交时点

《安全评估规定》第四条明确，可以自行实施，也可以委托第三方机构实施。第七条对提交作了具体规定：

第六条还规定，评估中发现存在安全隐患的应当及时整改直至消除；符合条件的应当形成评估报告，报告需包含服务基本情况与证照获取情况、安全管理制度与技术措施落实情况及风险防控效果、评估结论等。第八条说明，网信与公安部门会对报告进行书面审查，发现内容项目缺失或评估方法明显不当的，可责令限期重新评估。

6 中转站特有的六类风险

这六类风险与"有没有备案"无关，而是这种业务形态自带的结构性缺口。它们也是评估时要回答的问题。

其中**"审核标准不一致"最隐蔽**：单个上游都合规，聚合之后整体却可能出现更宽松的通道。用户会选择哪条通道，取决于你的路由策略——而路由策略是你决定的，这正是责任落在你的原因。

7 把义务变成可核验项

这一节是把前面几节的判断落成可执行的东西。三张表加三个配置块，都是可以直接抄改的骨架。

7.1 角色判定规则

把"我属于哪一类"从一次性讨论变成规则，规则未覆盖的组合一律转人工，不做默认放行。

# 角色判定规则表：判定结果直接映射义务集# 设计原则：default 为 needs_review，即规则未覆盖一律转人工version: 2026-09default: needs_reviewrules:  - id: R1    when:      all:        - user_facing_interface: true        # 存在面向不特定用户的对话/生成入口        - uses_generative_model: true    role: service_provider    obligations: [security_assessment, algorithm_filing, content_labeling, complaint_channel, log_retention]  - id: R2    when:      all:        - serves_public: true        - model_self_trained_or_finetuned: true    role: service_provider    obligations: [security_assessment, llm_filing, content_labeling, complaint_channel]  - id: R3    when:      all:        - serves_public: true        - upstream_model_filed: true          # 上游已取得备案凭证        - output_behavior_modified: false     # 未做影响生成内容的调整    role: application_provider    obligations: [registration, content_labeling, complaint_channel]  - id: R4    when:      all:        - serves_contracted_developers_only: true        - no_public_interface: true    role: technical_service    obligations: [contract_disclosure, upstream_status_check]notes:  - 角色判定输入为事实字段，不接受"我们只是转型"这类描述性说明  - output_behavior_modified 包含私有语料注入、输出组织逻辑改造、场景深度定制

7.2 评估范围台账

台账的核心是把"运行方式"当作一等对象，主用与备用分别登记，谁没纳入评估一眼可见。

7.3 调用与密钥治理

same_pipeline_across_routes 与 lowest_standard_used_as_baseline 这两项，直接对应第 6 节里"备用路径绕过拦截"和"审核标准不一致"两个风险。

7.4 公示与标识

备案信息公告的要求是：已上线的生成式人工智能应用或功能，应在显著位置或产品详情页面公示所使用已备案或登记生成式人工智能服务情况，注明模型名称、备案号或上线编号。

落到操作上，三个高频漏点是：只写在隐私政策或用户协议里（不算显著位置）、写了"已备案"但没有模型名与编号的对应关系、用了多个模型却只公示一个。

8 责任与技术限制：能力不足能不能免责

这一节回答一个几乎所有中转站经营方都会问的问题：我确实改不了上游模型的输出，这能作为免责理由吗？

8.1 法律上的位置

《行政处罚法》第三十三条第二款规定，当事人有证据足以证明没有主观过错的，不予行政处罚，法律、行政法规另有规定的除外。

关键在于"足以证明"四个字，以及证明的对象。 确认义务未履行之后，仍要依法审查处罚条件。但针对"未按规定开展安全评估"这一行为，仅证明自己不能修改模型参数，尚不足以解释为什么没有组织评估——因为评估的对象本来就不是模型内部，而是你如何组织服务。

8.2 哪些事实真正影响判断

同样是"依赖第三方"，下面两组事实在过错审查里的分量完全不同：

8.3 合同里该写什么

采购阶段就能把协作要求写成合同事项，比事后解释有效得多。四项建议纳入：

1. 接口与版本说明：明确提供所采购接口对应的模型版本与安全能力说明；
2. 变更通知：上游模型版本迭代、内容策略调整时的通知义务与时限；
3. 测试配合：允许为评估目的进行有限度的测试；
4. 整改支持：发现风险时的配合整改与必要支持。

同时要注意：仅约定"合规责任全部由供应商承担"，解决不了实际评估中的资料缺口和能力缺口。 评估报告要由你提交、由你对结论负责。

8.4 资料缺口怎么处理

不能以一份概括性的"产品合规承诺"替代具体判断。 这句话在评估场景里是硬要求：报告要说明的是"基于什么材料得出了什么结论"，而不是"我们确认合规"。

8.5 评估缺口如何影响上线决策

如果某项必要判断因资料缺失无法完成，影响应该落到上线范围和运行配置上，而不是停在文档里。例如备用路径无法完成评估时，可考虑先关闭自动切换，围绕实际启用的配置完成相应工作；但这不等于合规——是否足够取决于调整后的服务能否满足适用要求。如果后续重新启用备用路径，需要重新判断它是否被已有评估覆盖。

未解决的技术限制，合适的处理时点是评估和上线决策阶段，而不是风险出现之后用来解释。 这句话值得写进内部流程说明里。

9 排期：P0 / P1 / P2

P0——不完成不建议继续扩大服务范围

• [ ] 角色判定完成，结论有书面记录并注明失效条件
• [ ] 已上线的对话或生成入口完成安全评估并按规定提交报告
• [ ] 全部运行方式（主用、备用、降级）纳入评估范围，未覆盖的路径已关闭
• [ ] 备用路径与主路径使用同一套内容检查流程
• [ ] 显著位置或产品详情页面公示模型名称与备案号或上线编号
• [ ] 生成合成内容标识覆盖全部出口路径（含导出、下载）
• [ ] 投诉举报入口、处理流程与反馈时限已公布

P1——三个月内完成

• [ ] 日志字段可还原单条请求的输入、模型、路径与策略命中
• [ ] 密钥按用户隔离，共享密钥与额度转售已梳理
• [ ] 审核标准以最严口径为基准，不以最松路径为准
• [ ] 与上游的合同补齐版本说明、变更通知、测试配合、整改支持四项
• [ ] 模型池与路由策略变更纳入变更管理，触发重新判断

P2——持续机制

• [ ] 用户规模、模型池、服务形态变化的定期复核
• [ ] 违法有害信息处置记录定期复盘
• [ ] 监管口径与执法案例跟踪

10 六个反模式

1. 用名称代替审查——"我们只是中转站""我们只是聚合层"，业务实质不因称谓改变。
2. 用上游备案代替自身义务——备案、登记、安全评估三条线分别核查，互相不能覆盖。
3. 只评估默认配置——主用路径评估了，备用路径没纳入，等于留了一条未审查的通道。
4. 备用路径简化检查——为了"快速兜底"直连上游，绕过内容审核，风险最高且最难发现。
5. 公示写在协议里——隐私政策或用户协议不算显著位置，模型名与编号要成对出现。
6. 把技术限制留到事后解释——无法完成的判断应当写入评估过程并调整服务范围，而不是等风险出现后当作说明。

11 FAQ

问一：我只是调用已备案的模型 API，自己做个界面，需要做什么？

三条线分别判断：备案（自研或微调后对外提供服务的模型）、登记（通过 API 接口或其他方式直接调用已备案模型能力的应用或功能，由地方网信办开展登记）、安全评估（提供具有舆论属性或社会动员能力的服务）。已有备案模型不覆盖后两项。

问二：我只向企业客户提供接口，不面向个人，是否就不算向公众提供？

不能直接这样推。关键看服务对象是否具有不确定性——公开注册、公开售卖额度、无实质准入审核，对象就是不确定的。没有终端界面或者面向企业客户，都不足以单独得出豁免结论。

问三：中转站本身违法吗？

从这一案例看不是。处罚指向的是"未按规定开展安全评估"，不是"从事中转业务"。该业务模式解决的需求是真实的，问题在于配套义务是否履行。

问四：安全评估可以由第三方做吗？

《安全评估规定》第四条允许自行实施，也可以委托第三方机构实施。无论哪种方式，提交主体与责任主体都是服务提供者。

问五：评估报告什么时候提交？

第三条第一、二项情形，在上线或功能增设前提交；第三、四、五项情形，自相关情形发生之日起 30 个工作日内提交。通过全国互联网安全管理服务平台，提交所在地地市级以上网信部门和公安机关。

问六：评估提交之后就一劳永逸了吗？

不是。换上游模型、增加模型池、调整路由策略、用户规模显著增长、出现违法有害信息传播扩散，都可能触发重新评估或评估范围的调整。事前评估也无法永久覆盖后续变化。

问七：上游模型更换版本，我需要做什么？

两件事要分开：一是评估覆盖是否仍然成立（接口版本、安全能力说明是否适用于新版本）；二是相关备案或登记信息是否需要变更。这两项工作量独立，排期上也应分开算。

问八：如果我已经被通知要求整改，第一步做什么？

先把事实层面的范围画清——哪些网站在对外提供服务、每条调用路径走了哪个模型哪个版本、内容检查流程是否统一、标识与公示是否到位。整改的准确性取决于这份范围台账的完整程度，范围画错会导致整改遗漏。

12 结语

这一案例给出的最简洁的结论是：监管责任跟随实际服务提供者，不跟随模型的所有权。

模型能力来自上游，但如何组合这些能力、向哪些用户开放、采用什么风险控制措施，往往由下游经营者决定。技术分工既是划分职责的依据，也是评估需要考察的业务事实——它解释责任为什么这样分，但不能用来解释义务为什么可以不履行。

归纳成三句话：

1. 先定角色，再谈义务。 角色判定用事实字段，不用业务称谓。
2. 评估范围画到运行方式。 主用、备用、降级都是服务的一部分，未覆盖的路径不能开。
3. 能力限制写在评估里，不留在事后解释里。 改不了模型不等于做不了评估。

首案的处理是"责令改正 + 从严处理责任人 + 警告"，属于罚则起点。起点意味着还有余量，也意味着下一次未必从起点开始。

本文引用的事实来源：《国家网信办发布近期网络安全、数据安全、个人信息保护等领域执法典型案例》（2026 年 9 月 15 日，第 9、10 起案例）；《生成式人工智能服务管理暂行办法》（七部门令第 15 号，2023 年 7 月 10 日公布，2023 年 8 月 15 日施行）；《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》（2018 年 11 月 30 日施行）；《关于发布生成式人工智能服务已备案信息的公告（2026 年 7 月至 8 月）》（2026 年 9 月 14 日）；《中华人民共和国行政处罚法》第三十三条第二款。涉及个案与法规适用的具体判断，请以正式发布文本、属地口径及具体案情为准。