AI 生成的代码交付客户前，要先查开源许可证吗？

结论先说：客户问“AI 写的代码能不能直接交付”，不能只回答“能不能用”。更稳的做法，是把它当成一份需要交付审查的源代码成果，先过一遍开源许可证、相似代码、输入材料和合同责任。

为什么 AI 生成不等于风险清零

AI 生成只是代码形成方式的一部分，不会自动消除著作权、开源许可证和技术合同义务。真正会出问题的，通常不是“用了 AI”四个字，而是交付物里混进了第三方代码片段、训练或提示输入里带了客户保密材料，或者合同里没有说清楚谁负责后续开源披露、源代码提供和侵权赔偿。

所以第一步不是让工程师承诺“模型没抄”，而是把交付物拆成可核查对象。

先查 4 类材料

第一类是组件清单。至少要列出项目依赖、间接依赖、复制进仓库的代码片段、生成代码所在模块和对应版本。没有清单，就很难判断哪些许可证可能要求保留声明、提供源代码，或者限制再分发方式。

第二类是许可证识别。可以用 SPDX License List、OSI approved licenses 这类索引做名称和文本识别，但不能只停在“开源等于免费”。同一个组件，在内部使用、SaaS 部署、源码交付、嵌入式交付、二次分发里的义务可能不同。

第三类是输入和供应商边界。要看提示词、需求文档、客户数据、接口文档、日志和历史代码有没有被放进 AI 工具；还要看供应商是否保存输入、是否用于再训练、是否允许企业删除或导出记录。这里既关系到保密，也关系到客户合同承诺。

第四类是代码形成过程证据。提交记录、版本标签、测试记录、代码评审、外包或员工权属文件、交付验收记录都要留。软件著作权登记证书有证明价值，但不能替代形成过程和权利链。

合同里要问清楚什么

如果企业是供应商，交付合同里至少要把三件事说清楚：交付物是否包含开源组件或第三方材料；客户能否复制、修改、再分发、接入模型或继续训练；出现开源许可证、第三方权利或数据输入争议时，由谁提供说明、替换方案、源代码、NOTICE、赔偿或抗辩材料。

如果企业是客户，验收时不要只收一个压缩包。更实用的验收包应包括组件清单、许可证说明、AI 工具使用说明、关键模块相似性核查记录、第三方素材清单、权属承诺和问题整改记录。

一个常见误区

很多团队把“AI 生成代码”理解成“没有作者，所以没有版权或许可证问题”。这个说法太粗。企业真正要管的是交付物能否合法使用、能否继续交付、能否在客户系统里稳定运行，以及发生争议时能不能拿出来源、授权和修改过程。

换句话说，风险控制对象不是模型，而是交付成果和证据链。

可以用一张交付前检查表

我会建议项目经理、法务和技术负责人共用一张表，至少列 6 列：模块名称、来源类型、许可证或权属文件、使用方式、需要保留或交付的材料、责任人。对高风险模块，再加一列整改动作，例如替换组件、补 NOTICE、补授权、隔离输入材料、要求供应商删除记录，或把交付范围写窄。

这张表的价值不是增加流程，而是在客户验收、投资尽调、软件著作权争议或侵权投诉出现时，让企业能快速说明“这段代码从哪里来、谁有权交付、出了问题谁处理”。

什么时候需要进一步审查

如果交付物包含核心算法、客户历史代码、外包团队提交的大段代码、GPL/AGPL 等强义务许可证、模型供应商不承诺删除输入，或者客户合同要求“无第三方权利负担”，就不适合只做口头确认。至少要把代码、合同、许可证、AI 工具条款和交付记录放在一起审。

以上只是通用信息，不替代个案法律意见。知乎上如果你已经遇到 AI 代码交付、开源组件、客户验收或源码权属争议，可以把合同角色和交付范围说清楚，再联系或私信吕箐翎律师做个案分析。