企业官网建设流程全解析

做AI生成类应用的同行，最近应该都在关注最新的深度合成算法备案公示消息。第十六批备案清单出来了，779项算法一次性入列，数量上是历次公示里最多的一批。这个数字看着也许只是统计意义上的增量，但放在行业语境里，背后反映的是整个生成式AI产品落地的节奏在加快，也是备案这件事从“少数人操心”变成“上线前必过的一道坎”的明确信号。

我前前后后帮自己和朋友的产品跑过好几轮备案，从第一批摸着石头过河，到现在顺手就能整理出一套材料清单，中间踩过的坑也不算少。这篇就把我对这次779项备案的观察、备案本身的适用范围判断、完整申报流程，以及几个最容易导致驳回的细节一次性说清楚，给准备做深度合成类应用的朋友一个可参考的底稿。

1. 先看懂这批备案：779项算法入列背后的三个信号

单纯看“779项”这个总数，很容易忽略一件事：深度合成算法备案公示不是今天才开始，而是已经走到第十六批。把时间线拉长看，早期每批公示数量往往只有几十项，很多还集中在头部大厂的平台型算法。到了这一批，一次性779项，可以说是行业成熟度和备案制度成熟度共同作用的结果。

第一个信号是申报主体明显多元化。早几批的申报者大多是有专门法务和合规团队的大公司，小团队普遍是观望状态。现在779项里面，能看到大量中小开发团队的影子，产品形态也五花八门，从图像生成、语音合成、数字人驱动到视频编辑，细分赛道都覆盖到了。这说明“做深度合成算法必须备案”已经从纸面要求变成大家的共识，没人敢拿上线风险去赌。

第二个信号是算法类型从单一生成向“生成+服务”扩散。很多人以为深度合成备案只针对大模型或换脸类产品，其实不是。文本对话、声音复刻、图片风格化、数字人播报，甚至提供API给第三方调用的算法服务，都在这批清单里。只要你的产品里有“从无到有生成内容”或者“对已有内容做逼真编辑”的环节，基本都属于深度合成算法范畴，这也是为什么这次数量会一下子涨这么多。

第三个信号是“一次性通过最多一次”这个表述确实有信息量。备案不是交材料就行，要经过功能测试和技术审核。一批能过779项，至少说明申报材料整体质量的均值在提高，大家对材料怎么写、安全措施怎么描述、测试入口怎么留，已经积累了足够多的共识。对还没做过备案的团队来说，这其实是个好消息，意味着现在有大量合规案例可以参考，不用再像早批申报那样全靠自己猜。

2. 到底哪些业务必须备案：适用边界和判断逻辑

我接触过不少团队，最常问的一句话是：“我这个产品到底算不算深度合成？”这个问题不搞清楚，后面所有工作都白做。深度合成的定义说人话就是：利用技术手段生成、编辑或合成文本、图像、音频、视频、虚拟场景等内容，而且生成的成果在感官上很难和真实内容区分。

判断要不要备案，我一般建议用一个简单模型来套：你的产品里有没有一个环节，输入是“非内容”或“原始素材”，输出是“看起来像真实拍摄或真实发生过的内容”？有，就基本跑不掉。比如输入一段文字生成一段数字人播报视频，这属于语音、人脸、姿态合成；输入一张照片生成一段唱歌视频，属于对人脸和声音的编辑；输入一句话生成一段逼真的语音，属于语音合成。这些都在这批779项算法覆盖的范围内。

还有几个边界情况容易被忽略。第一种是“算法不自研，接第三方API”。很多人觉得我调用别人备案过的算法接口，自己是不是就不用备案了，这个想法不太对。如果你是把算法能力包装成自己的产品功能对外提供服务，通常还是需要以你自己作为申报主体去备案，只是算法原理、训练数据这些可以直接引用提供方的说明，并附加双方合作协议。第二种是“只在海外上线，国内没有运营”。如果你的产品主要面向海外用户，境内不提供访问，那确实不在备案适用范围内。但凡是国内应用商店上架、国内用户能访问、国内服务器部署，都应该先申报备案再上线。第三种是“纯分类、纯推荐、纯检索”。比如只做内容审核的模型、只做个性化推荐的模型，它们不生成新内容，不属于深度合成，不需要申报。但如果审核之外附带一个AIGC功能，还是要看成深度合成场景。

判断边界还有一种常见情况，就是企业内部自用。比如公司内部做一个营销文案生成工具，只给市场部员工用，不对外公开。这种情况下是否需要备案，行业里的普遍理解和做法是“自用内部且不对外提供服务”的算法，通常不需要走公示备案流程。但产品一旦开放给外部用户注册使用，或者通过API给第三方调用，就要纳入备案范畴。我倾向于建议：只要对外提供服务，不做侥幸判断，先报上去再说，宁可多一次申报，不要被要求下架时再补。

3. 从准备材料到测试通过：备案全流程实操

备案本身说复杂也复杂，说简单也简单。流程走顺了，就是“填表格、交材料、等测试、拿公示”四步。但每一步都有不少容易被卡住的细节，我按实际操作顺序拆开讲。

3.1 第一步：注册账号和确定申报主体

备案入口在主管部门的互联网信息服务算法备案系统上，首次申报要先注册企业账号，需要上传营业执照、法人身份证信息、联系人信息等。这里有一点要特别注意：申报主体要和算法实际运营主体保持一致。如果你的算法是子公司研发、母公司产品上线，或者A团队开发、B公司运营，建议把主体关系证明准备齐全，比如股权关系说明、授权运营协议、算法权属声明，否则审核时很容易被质疑权属不清。

注册账号之后，系统里会引导填写“算法主体信息”和“算法信息”。算法信息是整份备案材料的核心，后面几个小节说的都是这里面的内容。

3.2 第二步：算法信息填报，重点是原理描述和安全评估

算法信息填报里最考验功底的三个模块是：算法基本原理、训练数据情况、算法安全评估。

算法基本原理这一栏，常见两种极端。一种是写得太玄，什么“基于扩散模型的多模态语义表征与生成”，审核人员不是看不懂，而是没法从这段描述里判断出你的算法边界和风险点。另一种是写得太浅，比如“使用开源模型生成图片”，没有任何架构、流程、后处理信息，也过不了。我的建议是把算法链路拆成几个节点来描述：输入是什么、通过什么模型结构做处理、输出是什么、输出前有没有过滤或者标识环节。比如写“输入文本提示词，经过文本编码器转换为语义向量，送入基于潜在扩散结构的图像生成模型，生成图像后叠加隐形水印”，这样的描述清晰、可验证，也比较容易通过。

训练数据情况要写清楚来源、类型、规模、是否含个人信息。用过开源数据集、自己采集的数据、第三方授权数据，都列出来。尤其是有真实人脸或真实声音样本的数据，一定要说明是否获得授权、是否做过去标识化处理。这一块是合规审查的重点，也是很多申报材料被退回的高发区。

安全评估模块，很多人理解成“写保证书”，其实不是。你要写的是“我的算法具体通过什么措施来降低风险”。面向深度合成内容，比较常被认可的安全措施有五类：内容标识（生成内容打上显式或隐式水印）、输入输出双向过滤（敏感词、涉政、涉黄等方向的内容拦截）、真实身份核验（使用数字人形象或声音时验证用户授权）、内容溯源（可追溯到生成账号和时间）、用户举报通道（提供渠道并有人工处理机制）。每一项不要只写“有”，要写清楚落在产品哪个模块、技术方案是什么、由谁负责。比如“在服务端生成环节写入隐式水印，水印字段包含算法版本号和用户ID，通过内部工具可提取验证”，这样明显比“有防伪措施”有说服力得多。

3.3 第三步：算法安全自评估报告和配套材料

除了在线填表，一般还要提交一份算法安全自评估报告。这份报告的内容和在线填报的安全评估有重叠，但更展开，通常包含：算法基本情况、风险研判、安全措施、应急响应机制、测试情况、合规承诺等章节。报告没有全国统一的强制模板，但参考主管部门发布的安全评估指引来写是最稳妥的。具体章节可以按风险识别、风险等级判定、针对性措施的逻辑组织。

配套材料里常被忽略的是：产品上线情况说明、算法测试账号信息、备案系统里要求上传的承诺书。测试账号尤其关键，审核测试人员需要实际使用你的产品来验证算法，账号权限要够用，不要给人一个只能看不能用的游客账号。我见过不止一次因为测试账号失效或功能没开通而被驳回的案例，这种退回原因其实完全可以通过提前自测避免。

3.4 第四步：功能测试和技术验证环节

材料审核通过后，进入功能测试阶段。测试人员会根据你申报的算法类型，在测试环境里跑一遍生成、编辑功能，验证算法是否真实存在、功能是否正常、安全措施是否生效。测试通常包括正常操作和越权操作两种场景。比如你做的是图片生成，他们会生成一张图片看有没有标识；如果做的是声音复刻，他们会测试未授权人声是否被拦截。

这个阶段最能暴露问题的地方是“备案内容和实际产品不一致”。申报里写“通过手机号实名认证后可使用声音复刻功能”，但测试时发现游客也能用，这就是一致性缺陷。另一个常见问题是“内容标识时有时无”，水印在部分生成场景下没生效。所以递交备案前，建议自己在测试环境把申报材料里提到的每一条能力、每一条安全措施逐项验证一遍，录好操作视频留档，有问题先改产品再申报。

3.5 第五步：公示和常态化信息更新

测试通过后，算法会进入公示环节。公示通常包含算法名称、主体名称、主要用途等摘要信息。很多团队以为公示完就万事大吉，其实不是。备案通过后，如果算法出现重大变更，比如模型架构替换、训练数据来源发生根本性变化、应用场景大幅扩展，理论上需要履行变更备案程序。产品日常的小版本迭代、Prompt优化、数值调整，一般不需要重新备案，但建议保留每次变更的记录备查。

4. 被驳回最多的几个坑：实测经验和排查表

备案被驳回不可怕，可怕的是被驳回后找不到原因，反复提交反复退。我根据自己经验把最常见的驳回原因整理成了一张速查表，申报前对着过一遍，能省掉不少来回沟通的时间。

除了表格里的常见问题，还有三个经验性心得值得说一下。

第一个是“材料之间的证据链”非常重要。算法原理、训练数据、安全评估、测试账号这四块信息要能互相印证。比如你在安全评估里写“生成内容带有隐式标识”，那测试时就一定要能让检测工具提取到标识；你训练数据写了“含10万条人脸数据”，产品提供的隐私说明里也要有对应描述。材料之间一旦出现矛盾，审核人员有理由怀疑申报内容真实性，这种驳回比单项缺失难处理得多。

第二个是安全评估模块不要套模板。很多团队从网上找一份范本，换上自己产品名字就交了。审核人员看过大量材料，模板痕迹非常明显。比较容易被认可的做法是先把算法可能引发的风险点单独列出来，再针对每个风险点写对应措施。比如数字人产品，风险点包括虚拟形象被滥用制作虚假视频、声音被冒用等，措施就要对应到身份授权验证、生成内容标识、举报入口。这种“风险—措施”一一对应的写法，既有逻辑又体现你对产品合规真的做了思考。

第三个是时间规划要给足。第一次申报的团队，我建议预留至少一个半月到两个月。材料准备、内部审核、测试账号准备、可能出现的一轮补正，都需要时间。不少团队卡在“产品上线前一天才想起备案”，即使材料已经完美，公示周期摆在那里，临时抱佛脚没有任何意义。备案这件事，应该和产品设计、开发、测试并行推进，而不是放在上线前的checklist里。

5. 备案通过后，还有几件容易忽略的事

拿到备案公示不是终点，后面还有常态化的事情要做。我见过不少产品公示前一切顺利，公示后反而因为疏于维护在后续检查中出问题，这里挑几个容易被忽略的方面讲一讲。

第一，内容标识要有全程可追溯性。深度合成算法备案的要求里，内容标识不是生成一张图加个水印就完了，而是要贯穿生成、传播、举报反馈的整个链条。你的产品如果能做到解析自己生成过的内容，验证是否经过篡改，甚至在举报处理时能提供该条内容的生成账号、生成时间、算法版本，这套追溯体系才算完整。不要等出了纠纷再想办法补日志，生成端就该把元数据完整存下来。

第二，安全评估要和算法迭代同步更新。很多时候产品改了模型，安全措施也跟着变了，但备案材料还停留在上一版。比如你原来没有语音转写功能，新版本加了，这就涉及算法能力扩展，需要评估是否触发变更备案。又比如你原来生成图片没加水印，后来服务器端加了水印模块，虽然方向是更合规，但按照一致性原则，备案信息里的安全措施描述也应该对应更新。不要刻意回避变更，主动说明反而能建立信任。

第三，用户举报和反馈通道要真实可用。合规要求不是文件里写写就有用，实际运营中用户能不能找到举报入口、提交后有没有人处理、处理结果有没有记录，都是后续会被核验的点。我建议在后台单独建一个举报处理台账，记录每条举报的接收时间、处理过程、处理结果，既能满足合规留痕，产品上也更容易发现内容风险趋势。

第四，属地沟通渠道值得用心维护。备案申报过程中，遇到不确定的问题直接通过系统留言或电话渠道咨询，比自己在网上搜答案靠谱。通过之后，如果产品有重大版本规划，或者对某类功能是否合规拿不准，也可以主动找主管部门沟通，提前获得意见比事后整改成本低很多。合规这件事，本质上是在产品创新和外部要求之间找平衡，沟通越顺畅，平衡越容易达成。

6. 个人实操中的几点体会

备案流程跑多了之后，我最大的感受是：这件事真正难的不是填表，而是把一个产品从“技术实现”翻译成“可被理解、可被验证、可被追溯”的合规语言。同一个算法，在不同人嘴里描述出来，给审核人员的感觉完全不同。与其临时找模板，不如从一开始就建立一份持续更新的产品合规文档，把技术方案、数据来源、安全措施、变更记录都放一起维护，每次申报或变更时直接提取，效率高、也少出错。

另外一个小技巧：申报前找一位没参与备案材料编写的同事，把生成的产品说明和备案摘要给对方看一眼，让他描述理解到的是个什么产品。如果他能说清楚你的算法主要功能和安全措施，材料基本合格；如果他说得模棱两可，说明你的描述还有信息缺口。这个方法我用了很多次，比逐字检查管用得多，算是一个不太会写进官方指引但很实用的土办法。

深度合成算法这块，行业还在高速演进，备案要求和审核口径也会随实践不断细化。对做应用的人来说，保持对行业动态的关注、维护好自身的合规体系建设，比追求一次性通过某个具体批次更有价值。这次的779项入列，是行业合规意识整体抬升的一个截面，也意味着接下来新入场的团队要面对的是更加规范、更加成熟的市场环境。希望这份实操梳理，能帮你少走几步弯路。