算法备案和ICP备案的区别

很多团队做 AI 产品，第一次被问到「备案办了吗」时都愣一下：手里明明有 ICP 备案号，怎么又冒出个算法备案？反过来也有只办了算法备案、结果域名在国内根本打不开的。这篇不讨论政策原文，只把两件事的管辖对象、触发条件、办理先后和容易踩的坑讲清楚，给一个能照着走的判断顺序。

很多团队做 AI 产品，第一次被合作方或平台问「备案办了吗」时都会愣一下：手里明明有 ICP 备案号，怎么又被问一个算法备案？反过来也有只盯着算法侧材料、结果域名在国内打不开的情况。这两件事名字都带「备案」，但管的根本不是同一个对象，混在一起想就会反复返工。

这篇不抄政策原文，只把两件事各自管什么、什么形态下会触发、先办哪个、材料怎么分人，讲成一个能照着走的判断顺序。看完你至少能给自己的产品画一张「两条线」的对照表，知道哪一项必须办、哪一项还得去确认。如果你还想看各家模型和 API 的公开资料，可以顺手到 /models 核对当时的条目，但那跟备案是两条独立的事，别混。

两者根本不是同一件事：一个管内容，一个管渠道

ICP 备案

管的是「你这个域名和接入能不能在国内正常提供服务」，看的是主体、域名、服务器接入这一层，不关心你在上面跑什么业务。

算法备案

管的是「你对外提供的算法服务本身」，看的是算法能力、应用形态和它的影响范围，跟域名解析在哪、服务器摆在哪没有直接关系。

所以一家公司完全可能出现四种状态：两个都有、只有 ICP、只有算法、两个都还没办。哪一种算「该办没办」，取决于你实际在做什么，而不是取决于同行办了什么。

什么情况下必须办哪一个：按形态对号入座

• 先把「服务对象」写死：是内部同事、是付费客户、还是完全不特定的大众，这三种情况判断结果不一样。
• 再看「入口形态」：小程序、App、网页、开放接口，入口不同要说明的材料也不同。
• 最后看「能力类型」：纯检索、排序、生成、对话，各自关注点不同，别拿一个模板套所有产品。
• 遇到拿不准的项，标注「待确认」并记上责任人，别在群里投票决定。
• 形态变化（比如从网页扩到 App、从自研模型换成外部接口）之后，上面三步要重跑一遍。

有一点要提醒：面向公众、且具备舆论属性或社会动员能力的算法服务，才真正进入算法备案的讨论范围。你的产品是不是落在这个范围里，不是自己拍脑袋定的，建议对照站内 /guides 里关于算法服务形态的说明，再结合自己实际入口判断。什么情况下不适用？纯内部工具、不对外提供服务、或者只是把别人的成品能力原样转卖，这几类判断口径都不同，别直接抄隔壁团队的结论。

办理顺序与相互依赖：先做哪个不纠结

1. 第一步：先跑接入侧把域名、主体、服务器接入这一层先理清楚，因为很多后续材料都要填「服务入口在哪」「主体是谁」。验证方式：能不能稳定填出一份完整的主体与入口信息表，填不出来就是还没准备好。
2. 第二步：并行准备算法侧材料这条线周期通常更长，涉及内容审核机制、日志留存、安全措施等描述。做法：在开发阶段就同步整理，别等上线前一周才补；验证方式：把每一项材料对应到具体负责人和交付时间。
3. 第三步：互相校验一致性两条线里填的主体、服务名称、入口信息必须能对上。做法：交叉比对一遍，对不上的以接入侧实际信息为准去修正。
4. 第四步：形态变更后重跑产品从一种形态扩到另一种、或模型来源发生变化时，回到第一步重新对照。验证方式：在排期表里单独留一行「形态变更触发复查」。

如果你还在选接入和中转方案，可以到 /sites 看各家的接入方式与公开资料，再到 /price-watch 核对当时的计费口径。这些页面上的数字会变，别拿截图当结论，以你查看当时的页面为准。

给团队的落地清单：四步走完再排期

• 不要用「同行都办了」当判断依据，形态不同结论就不同。
• 待确认项不要自己拍板，标出来集中问，比事后返工便宜。
• 主体资质、内容审核机制、日志留存说明这三类材料最容易拖，提前分人。
• 产品形态、模型来源、部署方式任一发生变化，回到第一步重跑。
• 把两条线的材料放在同一个目录下，避免两边填的信息对不上。

这份清单不保证你一次过，但能保证你不会把两件事当成一件事办。真正卡住团队的多半不是政策理解，而是没人把「我们对谁提供什么」写清楚，导致两条线来回改。