算法备案前3张材料清单

很多企业一听到“算法备案”，第一反应是找一套模板、问技术要几个截图、再把材料交给法务补文字。这个做法的风险在于：备案不是单纯填表，关键是先判断企业到底用了什么算法能力、面向谁提供服务、数据从哪里来、用户权益如何保障。材料没有拆清，后面即使临时补齐表格，也容易在产品说明、数据来源、风险处置和用户权益口径上互相打架。

吕箐翎律师处理知识产权和数据合规问题14年，接触过11,000+件咨询和案件线索。我的实务判断是，算法备案前不要先问“要不要备案”，而要先做三张清单：算法能力清单、数据来源清单、用户权益和风险处置清单。三张表做完，才知道后续是备案准备、合规整改、合同补强，还是先暂停某个功能。

误区：把算法备案当成行政表格

很多团队会把算法备案理解成一个外部申报动作，等产品已经上线、客户已经接入、模型调用已经形成固定流程后，才开始回头补材料。这样做最容易出现三类问题。第一，产品经理说这是推荐或检索，技术说只是排序，法务无法判断是否触发规则。第二，数据来源既有用户行为、客户上传、公开内容、第三方接口，又有内部标签，没人能说清哪些数据进入了哪一个算法环节。第三，用户权益保护只停留在隐私政策文字，没有对应的关闭入口、投诉记录、人工干预和日志留存。

第一张表：算法能力清单

这张表要回答“系统到底在做什么”。建议把推荐排序、检索过滤、个性化推送、生成合成、深度合成、调度决策、风控评分、内容审核、客服应答等能力拆开。每一项都要写明功能名称、触发场景、输入数据、输出结果、是否面向公众、是否影响交易机会、是否影响信息展示顺序、是否涉及生成内容或人像声音等敏感表达。不要只写“使用 AI 技术”或“智能推荐”，这种表述对合规判断帮助很小。

如果企业有多个产品线，还要区分内部管理工具和面向公众的互联网信息服务。内部客服质检、员工排班和销售线索排序，与面向用户的信息流推荐、生成式问答、图片视频合成、直播间排序不是同一类风险。算法能力清单越具体，后续才越能判断材料边界。

第二张表：数据来源清单

算法备案和算法治理离不开数据来源。企业至少要列出训练数据、规则数据、用户行为数据、标签数据、客户上传数据、第三方接口数据、公开网页数据、人工标注数据和历史业务数据。每类数据都要写明来源主体、取得方式、合同依据、个人信息字段、敏感信息、作品或数据库权益、保存期限、访问权限和删除机制。

这里的关键不是把所有数据都写成“合法合规取得”，而是能拿出证据。合同、数据处理协议、授权链、隐私政策、告知同意记录、后台权限截图、数据字典、导入日志、标注工单、删除记录、供应商承诺和客户审计问题，都应当能和清单逐项对应。涉及生成式 AI、深度合成或公开服务时，还要特别核查语料来源、训练目的、内容安全过滤、标识提示和投诉处置。

第三张表：用户权益和风险处置清单

很多企业材料最薄的部分不是技术说明，而是用户权益。清单里至少要写明：用户是否知道算法在影响展示、推荐、排序或生成结果；是否提供关闭、选择、删除、投诉、人工干预或解释路径；是否有未成年人、老年人、消费者、劳动者或平台商家等特定群体；是否可能产生歧视、沉迷诱导、虚假信息、价格差异、交易限制或内容误导。

风险处置也要写成可执行动作。谁监测异常输出，谁处理投诉，谁保存日志，谁决定下线，谁联系供应商，谁向客户解释，谁复核模型版本，谁负责整改报告，都要有责任人。否则一旦出现投诉或问询，企业只能临时拉群找人，材料很难形成闭环。

场景一：推荐排序功能上线前

假设一家企业要上线“智能推荐商品”功能，技术说明里写的是排序模型，业务说明里写的是千人千面，运营又准备把推荐结果用于促销位和流量分配。此时不能只看代码是否调用模型接口，而要看该功能是否面向公众提供互联网信息服务，是否影响用户看到的信息顺序，是否影响商家曝光和交易机会，是否有关闭或解释机制。若这些材料没有提前准备，后面很难说明算法机制和权益保障。

场景二：生成式客服接入客户系统

再看生成式客服。企业可能认为客服只是在回答问题，不涉及推荐排序。但如果客服调用客户知识库、历史对话、用户订单和第三方模型，就要拆清数据来源、提示词边界、输出审核、敏感内容过滤、人工接管、错误纠正和日志留存。客户要求合规证明时，企业不能只给一份模型介绍，还要说明数据从哪里来、输出怎么管、投诉怎么处理、供应商责任怎么分。

行动建议

第一，先由产品、技术、法务、数据和运营共同完成三张表，不要让某一个部门单独填。第二，把每一项算法能力对应到具体页面、接口、日志、数据表和责任人，避免只写抽象功能。第三，把数据来源和合同、授权、隐私政策、供应商协议逐项对齐，缺口先补协议或缩小使用范围。第四，把用户权益做成实际入口和记录，不要只停留在制度文本。第五，备案或整改前先跑一次内部问答：如果监管、客户或用户问“这个结果为什么出现”，企业能否在一天内拿出解释材料。

材料归档方式

建议建立一个固定文件夹或合规台账，至少包括产品说明、算法能力表、数据来源表、模型版本记录、供应商合同、数据处理协议、用户告知和权益入口截图、投诉处理记录、日志留存规则、内容安全策略、下线预案和整改记录。每次功能改版、模型替换、数据源新增、供应商变更或服务对象变化，都要更新版本号和责任人。

内部复核节奏

企业可以把复核分成三个时间点。上线前，确认功能、数据、权益入口和供应商责任是否闭合；上线后一个月，抽查日志、投诉、关闭入口和异常输出；重大版本更新前，重新核对数据源、模型能力、服务对象和对外说明。这样做的好处是，算法治理不会只停在一次性材料包里，而是能随着产品变化持续更新。尤其是客户项目型企业，建议把客户审计问题、供应商回复和内部整改记录一起归档，避免每次项目交付都重新解释同一套事实，也避免临时改口影响客户长期信任。

常见问题

是不是所有用了算法的企业都要备案？不一定，要结合服务对象、功能类型、是否面向公众、是否属于推荐排序、生成合成、深度合成等具体能力判断。是不是做了备案就没有风险？也不是。备案只是一层治理动作，数据来源、用户权益、内容安全、合同责任和知识产权边界仍然要持续维护。

结尾提醒

算法备案前最有价值的工作，不是把材料写得漂亮，而是让产品事实、数据事实和用户权益事实可以被核验。三张表如果做扎实，后续无论是备案、客户审计、融资尽调、供应商谈判还是投诉处理，都会少很多临时补证的成本。以上内容是一般法律信息参考，不构成针对具体案件的法律意见，也不替代正式咨询。

关注本号，后续继续拆解知识产权和数据合规中的证据、期限和处理顺序。