企业官网建设流程全解析

1. 两套备案体系到底在管什么

先把结论摆在前面：大模型备案和互联网算法备案，管的根本不是同一件事，虽然它们经常被放在一起讨论，甚至很多团队在实操中会把材料搞混。

我接触过不少做AI产品的团队，有做对话助手的，有做推荐系统的，也有做图像生成的。几乎每一家在准备合规材料的时候，都会问同一个问题：“我们到底要不要做大模型备案？算法备案是不是也得做？两个都做的话，材料能不能复用？”

这个问题的答案取决于你的产品形态、技术路径和业务场景。我先把两套体系的核心定位拆开讲。

大模型备案，全称通常指向“生成式人工智能服务备案”，它的监管对象是面向公众提供生成式AI服务的产品。关键词是“生成式”和“面向公众”。你的产品如果能让用户输入一段话、生成一段文字或图片，并且这个服务是对外开放的，那大概率就落在这个范围里。它关注的是模型本身的安全性、生成内容的可控性、训练数据的合规性，以及服务上线后的持续管理能力。

互联网算法备案，全称是“互联网信息服务算法备案”，它的监管对象更宽泛，指的是利用算法技术向用户提供互联网信息服务的产品。这里的关键词是“算法技术”和“信息服务”。推荐算法、排序算法、检索算法、调度决策算法，甚至一些简单的个性化推送逻辑，都可能被纳入这个范畴。它关注的是算法机制的可解释性、是否存在歧视或偏见、是否对用户权益造成损害、是否影响舆论生态。

用一个不太严谨但很好理解的类比：大模型备案像是给“会自己写东西的机器”上牌照，算法备案像是给“会自己决定给你看什么的系统”上牌照。前者管的是生成能力，后者管的是分发和决策能力。

但现实情况是，很多产品两者都占。比如一个AI写作助手，它既用了大模型来生成内容，又用了推荐算法来决定给用户展示哪些模板或历史记录。这种情况下，两套备案可能都需要考虑。

我见过最典型的误区是：团队觉得“我们用的是开源模型，没有自己训练，应该不用备案吧？”这个判断是不准确的。备案的核心不是你有没有训练模型，而是你有没有面向公众提供服务。你用开源模型做了一层封装，接入了API，用户能直接使用，那这个服务就是你提供的，责任就在你身上。

另一个常见误区是：“我们只是内部用，不对公众开放，应该不用管。”这个判断相对安全，但要注意“内部”的边界。如果你们的“内部”是一个几百人的公司，那可能还好；如果是一个面向大量外部用户的“内测”，那就很难说清楚。监管看的是实质，不是名义。

还有一个容易被忽略的点：API调用方和API提供方的责任划分。如果你是通过API调用别家的大模型能力，然后包装成自己的产品，那备案责任怎么分？一般来说，提供API的那一方需要完成模型侧的备案，而你作为服务提供方，需要完成服务侧的备案。但具体到每个地方的通管局，执行口径可能有差异，这个后面会详细讲。

2. 大模型备案的核心门槛与材料准备

2.1 什么情况下必须做大模型备案

先划一条线：面向境内公众提供生成式人工智能服务，且服务具有舆论属性或社会动员能力的，需要做备案。这句话里的每一个限定词都很关键。

“面向境内公众”意味着你的服务对象是中国大陆的用户。如果你的产品只面向海外用户，那不在这个体系的管辖范围内。但要注意，如果海外用户里混着境内用户能访问到的通道，那就不好说了。

“生成式人工智能服务”指的是能生成文本、图片、音频、视频等内容的服务。纯粹的判别式AI，比如只做分类、只做打分、只做检测的，一般不落在这个范围里。但如果你用判别式模型做了一个“AI评分”然后生成一段评语，那就沾上生成了。

“具有舆论属性或社会动员能力”这个限定词在实际执行中弹性比较大。理论上，一个只有几十个用户的小工具，舆论属性很弱。但实际操作中，很多地方的通管局会要求只要是对公众开放的生成式AI服务，都来做备案。所以我的建议是：不要自己判断要不要做，直接去问当地通管局。问的成本很低，不问的代价可能很高。

2.2 备案材料里最容易踩坑的几项

大模型备案的材料清单在网上能搜到很多版本，但真正实操过的人都知道，材料不是重点，重点是材料背后的实质工作有没有做到位。

安全评估报告是核心中的核心。这份报告不是让你写一篇作文，而是要求你真正做过安全测试、有测试记录、有整改闭环。我见过团队临时补材料，把测试报告写得漂漂亮亮，但一问测试环境怎么搭的、测试用例怎么设计的，就露馅了。通管局的人不一定懂技术，但他们懂逻辑。你的报告里如果只有结论没有过程，很容易被退回。

训练数据来源说明是另一个高频退回点。你需要说清楚训练数据从哪来、有没有授权、有没有做清洗、有没有做去重、有没有做敏感内容过滤。如果你用的是开源数据集，要说明数据集名称和来源；如果你用的是自采数据，要说明采集方式和授权情况；如果你用的是用户生成内容，要说明有没有获得用户授权。这里最忌讳的是含糊其辞，写“来自公开渠道”这种话基本等于没写。

模型架构和参数说明不需要你公开全部技术细节，但需要说清楚模型的基本类型、参数量级、训练方式、推理方式。如果你是调用第三方API，那就说明调用的是哪家、什么版本、有没有做二次微调。这里有一个实操心得：如果你调用的是已经完成备案的第三方大模型，你的备案材料可以简化很多，但你需要提供第三方的备案证明和合作协议。

内容安全管理制度是很多技术团队容易忽视的。这份制度不是写给通管局看的，是写给你自己团队看的。它应该包括：内容审核流程、违规内容处置流程、用户投诉处理流程、应急响应流程、定期安全评估机制。我见过一个团队，制度写得很好，但问他们“如果用户生成了违规内容，你们多久能发现、多久能处置”，回答是“我们人力有限，可能得等用户举报”。这种回答在备案审核中是很危险的。

2.3 备案流程的时间线和实操节奏

大模型备案的流程大致是：准备材料 → 提交申请 → 初审 → 技术评测 → 复审 → 公示。听起来简单，但每一步都有坑。

准备材料阶段，我的建议是至少留出一个月。不是材料写一个月，而是把材料里要求的事情做一个月。比如安全测试，你得真的搭环境、真的跑用例、真的记录结果。比如数据清洗，你得真的做一遍、真的留下日志。

提交申请阶段，要注意各地通管局的受理窗口和材料格式要求可能不一样。有的地方要求纸质材料加电子版，有的地方只收电子版。有的地方要求法人签字，有的地方要求法人签字加盖章。这些细节看起来小，但一旦搞错就得重新排队。

技术评测阶段是最关键的。评测机构会从多个维度测试你的模型，包括但不限于：生成内容的准确性、安全性、鲁棒性、拒答能力。我见过一个团队，模型能力很强，但拒答能力很弱，用户稍微绕一下就能让它生成不该生成的内容。这种在评测中基本过不了。

复审和公示阶段相对可控，但要注意公示期间如果有异议，可能会被重新审查。所以公示前最好自己先做一轮舆情监测，看看有没有明显的负面反馈。

3. 互联网算法备案的适用范围与操作细节

3.1 算法备案的触发条件比你想的宽

很多人以为只有推荐算法才需要做算法备案，这个理解是不完整的。根据《互联网信息服务算法推荐管理规定》，需要备案的算法包括但不限于：生成合成类、个性化推送类、排序精选类、检索过滤类、调度决策类。

生成合成类算法，指的是能自动生成或合成内容的算法。这个和大模型备案有重叠，但算法备案更侧重于算法的机制和逻辑，而不是生成内容的安全性。

个性化推送类算法，就是常见的“猜你喜欢”。只要你的产品里有“根据用户行为推荐内容”的功能，不管这个推荐逻辑是复杂的深度学习模型还是简单的规则引擎，都可能需要备案。

排序精选类算法，指的是对信息进行排序或精选的算法。比如热搜榜、排行榜、精选列表，这些背后都有排序逻辑，都可能需要备案。

检索过滤类算法，指的是搜索引擎、站内搜索、内容过滤等算法。你做一个搜索功能，背后有相关性排序和结果过滤，这就落在这个范围里。

调度决策类算法，指的是用于资源调度、任务分配、路径规划等决策的算法。比如外卖平台的派单算法、网约车的派单算法，都属于这一类。

我见过一个做内容社区的团队，觉得自己没有推荐算法，因为“我们就是按时间倒序排列”。但他们的“热门”标签下有一个按互动量排序的列表，这个排序逻辑就构成了排序精选类算法，需要备案。所以不要用“我们算法很简单”来安慰自己，监管看的是功能实质，不是技术复杂度。

3.2 算法备案的材料重点和常见退回原因

算法备案的材料相对大模型备案要轻一些，但有几个地方特别容易出问题。

算法基本原理和运行机制说明是核心材料。这份说明不需要你公开源代码，但需要你用自然语言把算法的逻辑讲清楚。我见过很多团队在这里写得太技术化，满篇公式和术语，审核人员看不懂，直接退回。正确的做法是：用“输入-处理-输出”的框架来描述，配合一个具体的例子。比如“当用户打开首页时，系统会读取用户的历史点击记录，计算每个候选内容的匹配分数，按分数从高到低排序，展示前20条。”

算法应用场景和目的说明要具体。不要写“用于提升用户体验”这种空话，要写“用于在首页信息流中向用户展示可能感兴趣的内容，目的是提高内容点击率和用户停留时长。”目的越具体，审核越容易通过。

算法对用户权益的影响评估是很多团队会忽略的。你需要说明这个算法可能对用户产生哪些影响，比如是否会导致信息茧房、是否会影响用户的知情权和选择权、是否有歧视性后果。然后说明你采取了哪些措施来缓解这些影响。这里最忌讳的是写“没有影响”，因为任何算法都有影响，写“没有影响”等于没做评估。

用户申诉和关闭选项是硬性要求。如果你的产品有个性化推荐功能，必须提供关闭选项。如果没有，备案基本过不了。我见过一个团队，产品上线两年了，用户协议里没有提到算法推荐，设置里也没有关闭按钮，后来补这个功能花了不少时间。

3.3 算法备案的变更和注销流程

算法备案不是一劳永逸的。如果你的算法发生了重大变更，比如从规则引擎换成了深度学习模型，或者推荐逻辑发生了本质变化，需要做变更备案。如果算法下线了，需要做注销备案。

变更备案的触发条件，各地执行口径不太一样。我的经验是：如果算法的输入、输出、核心逻辑、应用场景中任何一个发生了实质性变化，就应该做变更。如果只是调参、换模型版本、优化性能，一般不需要。但为了保险，建议在变更前咨询当地通管局。

注销备案相对简单，但要注意：注销后如果重新上线类似算法，需要重新备案，不能沿用原来的备案号。

4. 两套备案的交叉地带与实操策略

4.1 什么情况下两套备案都要做

最典型的情况是：你的产品既用了生成式AI来生成内容，又用了推荐算法来分发内容。比如一个AI写作社区，用户可以用AI生成文章，同时首页有推荐流展示其他用户的文章。这种情况下，生成式AI服务需要做大模型备案，推荐算法需要做算法备案。

还有一种情况是：你的产品核心功能是生成，但生成结果的展示方式涉及排序或推荐。比如一个AI绘画工具，用户输入提示词生成图片，同时工具会推荐“相似风格的作品”。这个推荐功能如果构成了个性化推送，就需要算法备案。

我见过一个团队，产品是一个AI对话助手，用户可以和AI聊天，同时首页有一个“热门对话”列表。他们只做了大模型备案，没有做算法备案。后来被提醒“热门对话”列表的排序逻辑属于排序精选类算法，需要补做算法备案。补做的时候发现，因为产品已经上线，很多材料需要追溯，比上线前做要麻烦得多。

4.2 材料复用的可能与边界

两套备案的材料有一些可以复用的部分，比如公司资质、产品介绍、安全管理制度。但核心材料不能复用。

大模型备案的安全评估报告，侧重于生成内容的安全性。算法备案的算法机制说明，侧重于算法逻辑的透明性。这两份材料的视角和重点完全不同，不能互相替代。

训练数据说明在大模型备案里是重点，在算法备案里通常不是必须的，除非你的算法本身涉及对训练数据的使用。

内容安全管理制度在两套备案里都需要，但侧重点不同。大模型备案更关注生成内容的审核和处置，算法备案更关注算法结果的公平性和用户权益保护。

我的建议是：如果两套备案都要做，先做大模型备案，再做算法备案。因为大模型备案的周期更长、材料更重，先做重的，后面做轻的会轻松一些。而且大模型备案过程中建立的安全管理制度和测试流程，可以为算法备案提供基础。

4.3 备案后的持续合规工作

备案通过不是终点，而是起点。两套备案都有持续合规的要求。

大模型备案后，需要定期做安全评估，一般是一年一次。如果模型有重大更新，需要做变更备案。如果发现生成违规内容，需要及时处置并报告。

算法备案后，需要持续监测算法运行效果，定期评估算法对用户权益的影响。如果算法有重大变更，需要做变更备案。如果收到用户投诉，需要及时处理并记录。

我见过一些团队，备案通过后就把材料锁进柜子，再也不看了。等到下一次检查或者用户投诉的时候，才发现制度没执行、记录没留存、流程没落地。这种“备案归备案、运营归运营”的做法，风险很大。

实操心得：把备案要求融入日常研发流程。比如每次模型更新前，先跑一遍安全测试用例；每次算法调整前，先评估对用户权益的影响；每次上线新功能前，先检查是否需要做变更备案。这样比事后补材料要轻松得多。

5. 常见问题速查与避坑指南

5.1 备案相关高频问题对照表

5.2 实操中最容易踩的五个坑

第一个坑：低估准备时间。很多团队觉得备案就是写材料，两周就能搞定。实际上，从准备到通过，大模型备案通常需要两到三个月，算法备案通常需要一到两个月。如果材料被退回，时间会更长。所以产品上线前至少提前三个月启动备案准备。

第二个坑：材料写得太技术。审核人员不一定是技术背景，你写满篇Transformer架构、注意力机制、损失函数，他们看不懂，就容易退回。正确的做法是用业务语言描述技术逻辑，配合具体例子。

第三个坑：忽视用户权益保护。算法备案特别关注用户权益，如果你的产品没有提供关闭个性化推荐的选项，没有用户申诉渠道，没有算法说明页面，基本过不了。这些功能需要在产品设计阶段就考虑进去。

第四个坑：安全测试走过场。大模型备案的安全测试不是形式，评测机构会真的跑用例。如果你的模型拒答能力弱、容易被诱导、生成内容不可控，评测就过不了。建议在提交备案前，自己先做一轮红队测试。

第五个坑：备案后不维护。备案通过后，如果模型更新了、算法调整了、产品功能变了，没有及时做变更备案，被检查到会有风险。建议指定专人负责备案维护，每季度检查一次是否有需要变更的事项。

5.3 不同产品形态的备案策略建议

纯生成类产品，比如AI写作、AI绘画、AI对话，重点做大模型备案。如果产品内有任何形式的推荐或排序功能，补充算法备案。

纯推荐类产品，比如内容社区、电商平台、信息流应用，重点做算法备案。如果产品内用了生成式AI来生成推荐理由或摘要，补充大模型备案。

混合类产品，比如AI社交、AI教育、AI客服，两套备案都要做。建议先做大模型备案，再做算法备案，材料准备上可以统筹安排。

工具类产品，比如AI翻译、AI摘要、AI代码助手，如果只是单次调用、不涉及内容分发，通常只需要大模型备案。但如果工具有历史记录、有推荐模板、有排序展示，就需要考虑算法备案。

企业服务类产品，如果只面向企业客户、不面向公众，备案要求相对宽松。但要注意“企业客户”的终端用户如果也是公众，那可能还是落在大模型备案的范围里。

6. 从备案要求反推产品设计

6.1 把合规做进产品架构里

备案不是产品做完之后贴上去的标签，而是应该在产品设计阶段就考虑进去的约束条件。我见过太多团队，产品上线了才想起来备案，然后发现要改架构、加功能、补流程，成本很高。

内容审核模块应该作为基础能力内置。不管是生成内容还是推荐内容，都需要有审核机制。审核可以是机器审核加人工审核，可以是前置审核加后置审核，但必须有。而且审核记录要留存，备案和检查的时候要用。

用户控制选项应该在产品设计时就规划好。个性化推荐要有开关，算法说明要有入口，用户申诉要有渠道。这些不是额外功能，是合规要求。

数据管理模块要能支持备案材料的需求。训练数据来源、清洗记录、授权情况，这些信息要在数据管理系统中留痕。不要等到备案的时候才去翻邮件、找合同。

日志和监控模块要能支持持续合规。生成内容的日志、算法运行的日志、用户投诉的日志，这些都要有记录、可查询、可导出。

6.2 备案材料准备的实操清单

大模型备案材料清单：

• 备案申请表
• 营业执照和法人身份证明
• 安全评估报告
• 训练数据来源和清洗说明
• 模型架构和参数说明
• 内容安全管理制度
• 用户协议和隐私政策
• 第三方API调用证明（如适用）
• 其他通管局要求的材料

算法备案材料清单：

• 备案申请表
• 营业执照和法人身份证明
• 算法基本原理和运行机制说明
• 算法应用场景和目的说明
• 算法对用户权益的影响评估
• 用户申诉和关闭选项说明
• 安全管理制度
• 其他通管局要求的材料

实操建议：在准备材料之前，先给当地通管局打个电话或者去窗口咨询一次。问清楚材料清单、格式要求、受理时间、审核周期。这个动作花不了多少时间，但能避免很多返工。

6.3 备案时间线的合理规划

假设你的产品计划在2026年6月上线，那么备案时间线应该这样规划：

2026年1月：启动备案准备，确定备案类型，咨询当地通管局，收集材料。

2026年2月：完成安全测试和算法评估，整理训练数据说明，编写安全管理制度。

2026年3月：提交大模型备案申请，同步准备算法备案材料。

2026年4月：配合技术评测，根据反馈整改。

2026年5月：大模型备案公示，提交算法备案申请。

2026年6月：两套备案完成，产品上线。

这个时间线是理想情况，实际可能会有延迟。所以建议至少留出半年的缓冲期。

7. 一些来自实操的经验之谈

备案这件事，说难不难，说简单也不简单。难的是它涉及技术、法务、产品、运营多个部门，协调成本高。简单的是，只要你真的把该做的事情做了，材料只是把做过的事情写出来。

我见过最顺利的团队，是那种在产品设计阶段就把合规要求考虑进去的团队。他们的安全测试是研发流程的一部分，用户权益保护是产品设计的一部分，数据管理是日常运营的一部分。备案的时候，只是把这些日常工作的记录整理出来，很轻松就过了。

我见过最痛苦的团队，是那种产品上线两年了才想起来备案的团队。他们要补测试、补制度、补功能、补记录，还要面对可能的下架风险。补的过程中发现很多历史数据找不到了，很多流程没有留痕，很多功能需要重构。

所以我的核心建议是：不要把备案当成一个项目来做，要把它当成产品能力的一部分来建设。备案的要求，本质上也是产品安全、用户权益保护、数据治理的要求。这些能力建好了，不仅备案轻松，产品本身也更健康。

还有一个实操细节：和当地通管局保持沟通。备案政策在执行层面有很多细节，不同地方的口径可能不一样。定期关注通管局的官网通知，有问题及时咨询，比闭门造车要高效得多。

最后分享一个我自己的教训：有一次帮一个团队准备算法备案材料，算法机制说明写得很详细，但忽略了“用户权益影响评估”这一项。提交后被退回，要求补充。补充的时候发现，因为产品设计时没有考虑用户关闭选项，需要临时加功能，耽误了两周。从那以后，我每次做备案咨询，第一件事就是问：“你们的用户能不能关掉推荐？有没有申诉渠道？”这两个问题如果答案是“没有”，那就得先补产品功能，再谈备案。

备案不是终点，是产品合规运营的起点。把该做的事情做到位，后面的路会越走越顺。