1. 三种义务扫盲备案、大模型备案、登记各自在管什么接触“AI产品合规”这件事最早是我接手一款面向公众的问答类应用时遇到的。当时团队里有两种声音一种觉得“这些流程就是走个形式提交材料等通过就行”另一种更极端觉得“只要沾上备案就麻烦干脆先上线再补”。两种想法都让我很头疼因为真把材料拆开看就会发现备案、大模型备案、登记这三件事管的东西完全不一样准备材料的方向和节奏也完全不同。如果一开始不把它们分开理解后面基本就是反复被打回、反复补材料的循环。1.1 算法备案管的是“算法做了什么”算法备案面向的是算法本身。只要你的产品用到了内容推荐、排序精选、检索过滤、生成合成这类技术并且直接向公众提供信息服务那就需要把算法的核心机制说清楚。注意这里说的“说清楚”不是写一句“我们用协同过滤”就完了而是要具体到模型形态、训练数据来源、特征工程逻辑、输出内容如何做安全校验甚至包括算法可能带来的负面影响的应对方案。我们当时做的是问答应用里面同时用了检索增强和生成式模型理论上一次请求会走“召回—重排—生成—过滤”四条链路。第一次写算法备案材料时我天真地以为把模型名字和版本填上去就够了结果受理侧给出的反馈是“未说明检索结果的排序策略对信息呈现的影响”。这句话让我意识到算法备案不是在报“我有什么技术”而是在回答“你的算法会怎样影响用户看到的信息”以及“这种影响会不会带来风险”。所以准备工作里最重要的一步不是写文档而是让研发把推理链路的每一个环节拆出来标出哪些地方涉及信息排序、哪些地方涉及内容合成、哪些地方涉及用户画像。1.2 大模型备案管的是“模型底座是否可控”大模型备案是另一回事。它的关注点从“算法机制”上升到了“模型底座”。什么样的模型需要备案一般来说只要你的产品把基座模型作为核心能力对外开放或者你的服务实际由一个大模型驱动并且面向公众基本就跑不掉。这里面的典型材料包括模型的基本情况、训练数据的来源与规模、数据清洗和过滤的方法、评测集和评测结果、内容安全压力测试的报告以及模型使用过程中的应急响应机制。在我们项目中大模型备案的材料比算法备案厚了不止一倍。原因在于受理侧更关心的是“这个模型会不会生成违法违规内容”“被恶意诱导时表现如何”“安全兜底是否有效”。这些不是靠写承诺书能糊弄过去的而是要真的拿出测试数据。比如我们做了上千条对抗性样本测试覆盖历史敏感事件、自残自杀引导、违法犯罪手段、虚假医疗信息等类型并把每一类样本的“拒答率”“安全改写率”“漏网率”都统计成表。这个工作相当枯燥但恰恰是备案评审中最有说服力的部分。如果你只是笼统写一句“我们做了内容过滤”而没有具体的数据和判定规则说明材料大概率会被打回补充。1.3 登记管的是“谁在提供这项服务”登记这件事经常被误解成“备案的另一个名字”其实它的颗粒度在主体层面。它要回答的是“什么主体、用什么产品、以什么方式向谁提供服务”。登记材料通常涉及产品的基本信息、服务提供者信息、服务形态、用户规模、是否具备跟帖评论等功能模块。它更像是一个“产品身份档案”把产品和运营主体绑定起来方便后续各项监管动作找到对应的责任方。在我们项目里登记环节出的幺蛾子是最无厘头的。最初提交的版本里产品名称和软件著作权证书上的名称不一致一个叫“XX智能问答”一个叫“XX问答助手Beta”结果被退回来要求统一。当时我还不理解为啥这么较真后来想想登记的目的就是建立明确的口径映射产品名称、服务形式、上线域名、运营主体的对应关系一旦混乱后续的投诉受理、内容下架通知、安全评估复查就全都没法精准落地。所以别看登记材料简单它却是整套合规链条里最需要“细心”而不是“技术含量”的一环。2. 为什么“算法、模型、登记”总被混为一谈说实话这三个概念在公开讨论里经常被当成同义词因为很多产品同时涉及三者提交材料的入口又都在同一个受理体系里导致大家觉得“反正都是填表”。但混在一起理解会带来一个很现实的问题你会不知道自己的项目到底处于哪个阶段也不知道被打回时反馈的是哪个环节的问题。2.1 最典型的三个错误认知第一个错误认知是“我们用了开源模型所以不用备案”。这个想法错得比较离谱。开源模型只解决了“模型从哪来”的问题没有解决“你拿它提供服务”的责任问题。只要你的产品面向公众开放并且确实使用了内容生成、推荐分发等能力那你就是服务提供者相关的备案义务不会因为模型是开源的就消失。第二个错误认知是“我们只是调用别人的API自己不做模型训练应该不用管”。调用API确实不等于训练模型但合规责任是从“服务提供”这一刻开始计算的。你的用户是在你的产品里看到内容的出了安全责任问题很难用“模型是别人家的”来撇清关系。比较稳妥的做法是要求上游服务方提供安全评估结论和调用说明自己这边保留完整的调用日志和内容记录。第三个错误认知是“备案通过之后就一劳永逸了”。这属于对流程性质的理解偏差。备案评审的是“当前版本、当前服务形式”下的合规状态产品一旦大版本迭代、核心模型更换、服务形态从问答变成内容社区原来的结论大概率就失效了。后面我会专门讲迭代时的重新申报问题这里先记住一个原则备案不是一次性的证照而是跟你的产品持续绑定的“动态档案”。2.2 一张表拆清三个流程的边界维度算法备案大模型备案登记管的对象算法机制与信息呈现逻辑模型底座与内容安全能力服务主体与产品信息触发点使用推荐、检索、生成合成等算法并提供公众服务面向公众的生成式服务使用了大模型基座产品上线并对外提供服务核心材料算法原理说明、安全自评估报告、数据与特征说明模型介绍、训练数据说明、评测报告、压力测试结果主体资质、产品名称、服务形式、功能模块说明典型审查点排序策略是否透明、算法是否有负面风险拒答率、安全覆盖率、对抗性样本表现名称一致性、责任主体清晰度版本更新时算法逻辑变化需重新说明模型版本迭代需重新评估产品名称/形态变化需更新2.3 判定自己要不要做的三条线索很多开发者的产品还处在早期阶段不确定自己到底要不要碰这些流程。我的经验是看三条线索。第一产品是否面向公众开放只要不设白名单、不限制特定人群基本就属于公众服务。第二产品是否具备内容生成或内容分发能力包括自动回复、信息流推荐、搜索结果排序这些都属于典型的算法服务场景。第三服务是否由大模型驱动哪怕你只是用API调用别人的模型只要最终呈现给用户的内容是由这个模型生成的就大概率需要安排模型侧的评估与报备。三条线索同时命中的产品基本就是“全程陪跑”从登记到算法备案再到大模型备案一个都跑不掉。三条线索只命中一两条的本身也应该把合规文档前置准备好因为产品形态随时可能变化等流量起来了再补流程一旦被要求暂停服务损失就不是几天时间能衡量的了。3. 我们项目上线前的合规流程是怎么跑通的这里分享一下我们实际操作中比较完整的流程。由于不涉及具体监管机构的内部细节我只能基于自己经历和同行交流的普遍做法来说不同行业、不同服务形态的受理要求和周期会有差异但整体的工作流大差不差。3.1 第一周材料盘点和内部联合评审拿到合规任务后我先没有急着填系统而是拉着研发、产品、运维开了一次材料盘点会。盘点会的目标是列出所有需要准备的文档并明确每一份文档的owner。我们当时列出的材料清单大概包括产品功能说明书、算法机制说明、数据来源说明、安全自评估报告、用户协议和隐私政策、模型评测报告、服务形式说明、主体资质材料。这一周的核心工作是确认范围而不是写文档。联合评审放在盘点的第二天。研发现场跑了一轮演示把“用户输入→检索→生成→安全过滤→展示”的完整链路走了一遍。产品经理在旁边补充了用户画像标签的使用逻辑运维给出了服务器部署和数据留存的说明。这样一轮评审下来法务和外部顾问才能判断材料里哪些地方容易出问题。我强烈建议AI产品团队不管规模多小都要做一次这样的内部评审因为写材料时暴露的问题远比受理侧反馈后再补要省时间。3.2 第二周安全评估与自评估报告第二周的工作量最大核心产出是自评估报告和模型评测数据。我们当时把自评估报告拆成六个章节算法基本情况、算法安全责任主体、算法机制机理、数据安全情况、算法潜在的负面影响、风险处置措施。每个章节都要求写实能配测试数据的配数据能画流程图的画流程图。模型评测是这周最吃人力的一环。我们从业务侧收集了几百条真实用户问题又让测试团队构造了两千多条对抗性样本分成十个大类每一类标注“正常答复”“安全改写”“直接拒答”“漏网”四种结果。评测跑完开始统计指标时我们发现了不少问题。比如医疗类问题中模型拒绝回答的比例很高但有一些被判定为“正常答复”的内容仔细看其实存在建议不够严谨的风险。这些问题最终都汇总成了整改项在真正提交备案前完成了第一轮修正。这一轮自查表面上是给备案准备材料实际上确确实实帮我们提前排掉了一批内容安全隐患。3.3 第三周系统填报与形式审查材料准备得差不多之后就进入系统填报阶段。这个阶段最容易被忽略的是格式和字段映射。同样的信息在不同表单里的字段名称、数据单位、措辞要求可能都不一样。我们第一次填报时因为把模型参数量写成了稀疏参数的计算口径和受理侧期望的稠密参数口径不一致被退回要求修正。这类问题不是技术问题纯粹是口径理解问题但很耽误时间。建议填报前先通读一遍表单里每一处解释说明尤其注意“模型规模”“训练数据规模”这类数字字段的单位。涉及百分比的地方要写清楚分母是什么。涉及“是/否”类字段时后面的补充说明不要空着哪怕写“否当前版本不涉及”也比留空让受理人员猜好。形式审查阶段虽然不评内容深度但因为格式问题被打回是最亏的。3.4 第四周整改、复核和回执填报完成后大概率会在数天内收到反馈反馈分为“通过”“退回补充”“整改后重报”几种情况。我们实际遇到的是“退回补充”反馈意见集中在两个点一是自评估报告里对“检索结果排序策略对信息呈现的影响”分析不够二是模型评测样本覆盖度说明不清晰。这两条我们花了三天补材料重点是针对反馈逐条回复说明在哪个文档哪个章节做了修改修改前后的内容是什么。这里有个经验补充反馈时不要只把新文档丢上去最好写一份修改说明清单列清楚每条反馈意见的响应位置和结论。这样既方便受理侧核对也能在内部留档后面再迭代时直接对照这份清单做增量更新。最后一轮复核通过拿到备案回执的时候团队才松了一口气。拉通算了一下整个流程包括国庆假期在内一共用了大约三周半中间真正导致返工的不是技术问题而是材料口径和细节描述。4. 团队协作里被忽视的四个关键交付物合规工作最怕临时抱佛脚因为很多材料在项目日常开发中根本不存在需要专项补做。如果团队里没人对“交付物”有清晰概念这些工作会全部压到某一个人头上最后写出来的材料质量也可想而知。我在这个项目里吃过的亏基本都集中在下面四个交付物上。4.1 研发侧必须写清楚的模型说明研发侧最容易交出一个“听不懂”的模型说明。比如写“本模型为大规模语言模型基于Transformer架构”这句话技术上没错但评审人员更想知道的是模型是怎么训练的训练数据从哪来怎么做清洗和去重有无使用强化学习推理时会不会动态调用外部工具这些内容决定了模型的风险画像。我们内部后来要求模型说明必须包含六个小节模型架构、训练数据、训练方法、评估结果、使用限制、已知问题。其中“使用限制”和“已知问题”是最提分但最容易被忽略的部分。主动写出“当前模型在复杂多轮对话中可能产生事实性错误须配合检索模块使用”远比评审人员在测试中发现这个问题要好。姿态上先承认边界材料可信度会高很多。4.2 安全侧必须交出的风险处置预案安全侧不能只交一份“我们做了安全过滤”的总结而是要交可执行的处置预案。预案里要包含三部分一是内容过滤策略包括关键词、分类器、模型安全工作这三层分别拦截什么二是应急响应流程从发现违规内容到下线处置再到上报每个环节谁负责、多久完成三是数据留存规则用户生成的文本内容在日志里保存多久、什么条件下提供给主管方。我们真实的预案写了三十多页最核心的其实是“响应时间”和“责任矩阵”。平时觉得这些问题很远但真正涉及投诉处置或上级复查时预案的颗粒度直接决定你能不能在规定时间内完成闭环。这里建议安全团队用表格把事件分级、触发条件、响应人、升级路径写清楚然后再输出成文档。4.3 产品侧必须落实的用户告知产品侧在合规里最容易敷衍的地方是用户协议和弹窗提示。恰恰这是用户能直接感知的合规触点。算法备案通过后理论上产品应在用户协议里说明算法服务的类型、机制和可能影响在涉及生成内容的位置保留可追溯的标识机制。我们的做法是在用户协议里新增了“算法说明”章节用比较通俗的话交代了哪些回复由算法生成、检索逻辑如何影响回答顺序、用户如何关闭个性化推荐。虽然问答类应用的个性化选项不多但这段说明在隐私合规和算法透明度上帮我们赢得了一些缓冲也避免用户出问题后抱怨“完全不知道信息是怎么被排序的”。4.4 项目侧必须建立的版本档案第4个交付物是软性的但长期价值最大。因为备案和登记跟版本强相关每次产品迭代都可能触发重新评估所以项目管理侧要建立一个“合规版本档案”字段包括产品版本号、模型版本号、算法逻辑变更点、对应内容安全测试结果、备案状态、登记状态、备注。这个表从项目启动第一天就建每次发版前由研发更新合规负责人定期检查。我们一开始没建这个表结果第一次被退回补充材料时想查两个月前某个版本用的模型是不是带安全微调竟然要翻三个人的沟通记录才弄清楚。后来花一晚上补建了档案再往后每次迭代前做增量评估就快多了。其实这就是一个简单的表格但多数AI团队忙起来完全顾不上等到合规复查时才发现历史版本的状态全是空白。5. 六个高频问题都是我们实际踩过的坑这一部分我单独列出来是因为这些问题在官方文档里往往不会写得太细又最容易在群里被反复追问。我用自己的项目经验逐一聊聊不敢说每个答案都放之四海皆准但至少能提供一个经历过一遍之后的操作基准。5.1 模型更新了要不要再来一遍答案是大概率要。但“再来一遍”的范围有讲究。如果只是换了prompt模板微调了输出风格没有更换基座模型也没有改变算法机制那一般不需要重新走大模型备案但建议保持记录。如果是把基座模型从一个版本换到另一个版本或者从开源模型换成了API调用那模型的评测结果、安全评估报告都需要对应更新备案材料也要同步修订。我们后来遇到过一种隐蔽的情形基建团队升级了部署框架导致推理量化精度变化模型输出质量出现了细微偏差。这种变化不涉及算法逻辑理论上不触发重新备案但如果不做记录未来复查时说不清楚版本差异就会很被动。所以我的原则是“做不做重新申报别拍脑袋先看版本档案里算法逻辑、基座模型、服务形式三项是否发生变化变了就主动联系受理侧确认”。5.2 用了开源模型责任边界在哪开源模型商用本身没有问题但责任边界在“谁向公众提供服务”这条线上。你基于某个开源模型微调后发布了对外产品那你就是最终责任主体。模型原作者的license只覆盖模型本身的使用权不覆盖你产品里生成内容的合规性。实操上建议保留三样东西开源模型的原版说明和许可证、你对模型做微调和安全对齐的完整记录、基于该模型的安全评测报告。这三样材料在备案评审时基本都要求提供越齐全越能证明你的安全能力。千万别觉得开源模型“别人都在用”就能省掉安全评估受理侧不关心多少人用过只关心你这个实例是否可控。5.3 企业内部工具到底算不算公众服务这个话题经常有争议。纯内部使用的效率工具比如内部知识库问答不面向公众开放一般来说不需要走面向公众服务那一套备案流程。但“内部”和“公众”的界限如果模糊就容易被认定成公众服务。比如团队成员把链接发给外部合作伙伴对方不用登录就能访问这在形式上就已经越界了。我们当时的做法是区分场景内部工具一律通过办公网络或企业账号体系访问不在公网开放匿名入口如果要给客户演示提前申请临时域名加白名单演示结束后立刻注销。这些动作在合规框架下看起来有点机械但确实能避免很多说不清的边界问题。5.4 只调API的“壳产品”要做多少只做壳的产品核心模型和技术都在上游自己只负责产品交互和用户体验。这种情况下备案义务并不会消失只是材料侧重点变了。你需要说明清楚调用了谁的API提供上游接洽时的合规承诺或安全评估摘要同时把自家产品的功能边界写明白比如“本产品不对模型输出做二次训练仅进行格式化和排版处理”。有一点要特别留意如果壳产品本身增加了用户输入信息的再加工逻辑比如聚合多个API结果重新排序那么新的“排序和聚合”逻辑本身也可能构成一种新的算法服务这时候算法备案的触发点就不只是上游API的问题了。我们合作过的一个聚合类产品就是这种场景最后不得不补了一份排序机制说明。5.5 材料被打回常见卡点集中在哪根据我和周围团队的交流被打回的高频原因集中在四类。一是关键信息模糊比如只写“采取内容过滤措施”不写具体的过滤策略和实现方式。二是自评估结论与实际测试数据矛盾比如报告里写“模型对违法违规内容拒绝率100%”但评测表里明明有漏网样本。三是主体信息不一致产品名称、备案主体、软著名称对不上。四是联系方式缺失或不是常驻联系人导致复审阶段找不到人。避免被打回的办法只有一个提交前做一轮“换位审查”。把自己想象成第一次看到这份材料的评审员只看文档本身不看任何背景信息能不能完全理解你的产品逻辑和风险控制措施。如果你自己都读得费劲那打回概率极高。5.6 涉及未成年人的产品有什么额外功课如果你的AI产品会面向未成年人或者在实际使用中没有有效的年龄隔离机制那就需要额外考虑内容分级的问题。我们当时在问答应用里接入了年龄判断对无法确认年龄的用户默认按未成年人标准做更严格的内容过滤并限制了一些涉及医疗、金融建议类问题的回答深度。材料准备上需要增加内容分级策略说明和未成年人保护专项评估报告。实测层面也建议专门跑一批“未成年人场景”测试样本比如带有校园暴力、自伤倾向的提问模型是否给出了安全且恰当的回应。这类测试数据在备案评审中很有说服力因为它覆盖的正是社会关注度最高的风险场景。6. 备案通过之后的持续义务清单不少团队拿到通过回执之后就彻底松了半年后收到内容安全巡检或用户投诉通知时才发现自己完全没有对应的响应机制。备案通过不是结束而是把产品放进了持续性监管视野里。这一部分我把备案之后的日常义务梳理一遍。6.1 日志留存、回溯与投诉响应最基础的工作是把用户反馈和系统日志留住。AI产品的投诉和普通软件不一样用户表达的细节往往很模糊比如“它刚才为什么给我推荐这个”如果你没有留存当时的对话上下文和推荐记录根本无从排查。我们的做法是对话日志保留一段时间用户可以主动查询自己账号下的内容记录客服也能凭记录回溯信息链路。投诉响应机制不能只停留在客服话术层面。至少要有两个角色一个负责接收和分拣内容安全相关投诉一个负责技术排查与处置。并明确从接收投诉到对违规内容做下线处理的时间目标。超过时限要有升级通道。这些内容在备案时的风险处置预案里写过但写完不算完每隔一段时间要演练一遍。6.2 迭代要带着“合规增量”一起走产品迭代时存在一个普遍现象需求评审会只讨论功能和性能合规完全不参与。结果是功能上线后才发现模型输出格式变了、新的prompt会诱导出风险内容、新增的联网搜索能力打破了原有安全边界。这些都是可以提前发现并规避的。我后来在团队里定了一个规矩每次版本评审会议增加一个五分钟环节叫“合规增量确认”。研发、产品各回答一个问题——“这次版本有没有改变算法机制”“有没有更换模型底座或新增内容来源”答案都为否的就直接过有一个为“是”就把合规负责人拉进来判断是否需要走补充评估或重新说明的流程。这五分钟帮我们拦住了好多次潜在麻烦。6.3 把合规日历排进版本计划备案通过后还需要把周期性工作排进日历。这个日历不一定要做得很重但至少要有几个节点模型例行评测的周期建议每个季度或每次基座版本升级时跑一次全量安全测试内容安全策略的更新周期尤其当产品新增了业务分类或内容源时要及时扩展对抗样本集合规档案的整理周期每个季度做一次版本档案状态核查把已经过时的文档标记为归档。我们的经验是不要想着一口气把合规体系做得完美无缺先跑起来再逐步迭代。最怕的是从来没有日历三个月后收到巡检通知一群人临时翻记录、导日志、补报告那种被动局面极其消耗团队精力。把合规日历当成跟版本发布日历一样平常的东西反而轻松。最后再分享一个小技巧在项目早期就把合规信息档案当一个正式交付物来维护每个版本的模型说明、安全测试结果、自评估结论都按统一命名规则归档。等你真正要提交算法备案或大模型备案材料时会发现需要的东西早就躺在文件夹里了不用靠回忆去补。合规这件事提前做和不提前做差的不是结果而是过程中的焦虑成本。希望这篇梳理能帮准备做AI产品合规的团队少走一点弯路。