企业用AI生成代码交付客户前先核对开源许可证四张记录

风险先看代码能不能交付给客户，而不是先问 AI 工具能不能生成。

企业用 AI 辅助写代码、补模块、改脚本或生成测试用例时，最容易把风险说轻：既然代码是模型输出，就以为没有第三方权利和开源义务；既然能在本机运行，就以为可以直接进客户交付。真正要先核对的是代码来源、许可证、使用方式和合同承诺。交付前留下四张记录，能把“AI 生成”从一句技术描述，变成研发、法务、采购和交付团队都能复核的材料。

吕箐翎律师处理软件著作权、开源许可证和企业交付争议时，通常会把生成代码先当成交付物审查，而不是当成天然无风险的新作品。下面四张记录不要求一开始做成厚报告，但要能回答：代码从哪里来，像不像已有片段，许可证义务是什么，客户合同怎么承接。

第一张记录：生成代码和人工代码的来源清单

第一张记录解决代码从哪里来。AI 生成代码、人工编写代码、历史项目复用代码、开源组件、供应商 SDK、外包交付模块和客户提供材料，不能混在一个仓库里只写“自研”。建议按目录、文件、组件、版本、贡献人、生成工具和输入来源列清楚，至少标明哪些是模型生成，哪些来自已有代码库，哪些由第三方交付。

这张清单不是为了否定 AI 工具，而是为了防止交付责任失焦。客户问某个模块是否可商用、是否含第三方代码、能不能再分发时，企业不能只回答“由 AI 生成”。如果提示词里放入了客户代码、供应商样例、竞品片段或内部商业秘密，还要记录输入材料是否允许这样使用，模型服务是否保存输入，是否存在再训练或外部人员接触。

清单字段可以很实用：仓库路径、文件或组件名、来源类型、生成工具、输入材料、人工改动、外部依赖、责任人和对应合同。先把来源说清，后面的许可证、相似代码和客户承诺才有基础。

第二张记录：开源许可证和组件义务

第二张记录解决许可证。开源组件可以商用，不等于没有合规义务。企业应识别具体许可证名称、版本、组件版本、依赖关系、是否修改、是否分发、是否与闭源代码链接、是否需要保留 NOTICE、版权声明、许可证文本，是否触发源代码提供义务。SPDX 和 OSI 的许可证资料可以作为识别和索引参考，但不能替代具体许可证条款判断。

尤其是 GPL 类许可证，不能只问“是不是商用”。更应看使用方式、链接或分发形态、源代码提供义务、第三方组件清单和替换方案。一个模型生成的函数如果高度接近某个开源项目片段，也不宜因为没有直接复制仓库就直接忽略许可证问题。相似性和来源不清时，应先隔离、替换或补充审查。

这张记录建议输出组件清单、许可证清单、义务清单和处置清单。绿色是许可证、使用方式和交付形态匹配；黄色是义务可以补足，比如补 NOTICE、补许可证文本、补清单或替换组件；红色是许可证与商业闭源交付、客户保密承诺或再分发安排明显冲突。

第三张记录：相似代码和第三方片段核查

第三张记录解决生成内容是不是贴近已有表达。著作权法保护的是具体表达，不保护抽象思想、功能和通用算法；但软件代码里的模块结构、注释、变量命名、异常处理、配置项、废弃代码和特定写法，可能成为比对时的重要线索。企业至少要对核心模块、客户可见交付代码和高风险生成片段做相似代码核查。

核查不必一上来追求全库 forensic 报告。第一步可以锁定高风险范围：提示词中引用过外部代码的文件，模型一次性生成的大段代码，核心算法和接口封装，供应商交付却没有清单的模块，客户要求可再分发或上架的组件。对这些范围做相似搜索、人工复核和替换记录，比事后解释“模型自己写的”更有说服力。

如果发现相似片段，要记录处理动作。能替换的就替换，能补许可证义务的就补，不能说明来源的就从交付版本剔除。不要把“相似不等于侵权”当作上线口径；这只是法律判断的起点，不是免检结论。

第四张记录：客户交付和供应商责任边界

第四张记录解决合同承诺。技术合同通常要明确标的、范围、履行方式、技术资料保密、成果归属和验收边界。企业把 AI 生成代码交给客户时，应核查合同里是否承诺原创、无第三方权利负担、可再分发、可开源、可嵌入客户产品、可用于境外部署，以及是否承诺承担开源许可证或第三方投诉责任。

如果企业还调用外部模型、代码助手或供应商开发服务，要同步核查服务条款和供应商交付义务：输入是否保存，输出是否可能被用于服务改进，供应商是否提供组件清单，是否承诺没有未披露开源义务，出现第三方投诉时谁负责替换、赔偿、协助说明。采购合同、开发合同和客户交付合同不能各说各话。

这张记录最好形成一页交付说明：交付范围、第三方组件、许可证义务、客户可使用范围、禁止用途、保密边界、替换机制和责任人。它不是营销材料，而是让项目经理知道哪些代码可以交付、哪些还要补材料、哪些不能进入客户版本。

另一个容易被忽略的细节是验收材料。交付包里如果只有代码压缩包和部署说明，客户后续很难判断哪些文件来自开源组件、哪些文件由 AI 辅助生成、哪些文件受供应商条款限制。建议把组件清单、许可证文本、NOTICE、替换记录和供应商声明作为交付附件，和验收单一起保存。这样即使后续出现第三方询问，也能先从材料链判断问题范围，而不是直接进入争议口径。

四张记录要一起看

来源清单、许可证义务、相似代码和合同承诺不能分开判断。代码来源说不清，许可证清单就可能漏项；许可证看似宽松，但客户合同承诺“完全自有、无第三方负担”，仍可能产生违约风险；相似代码已经提示第三方片段，供应商却没有交付清单，不能靠“AI 生成”把问题推给模型。

建议用红黄绿分层。绿色是来源、许可证、相似核查和合同承诺都能闭合；黄色是义务可补、片段可替换、合同可解释或可补充说明；红色是来源不明、许可证冲突、相似片段不能解释、供应商拒绝提供清单，或客户合同已经承诺超出企业可控制范围。

第一周先做可复核材料包

第一周先留下四份材料：代码来源清单、开源许可证清单、相似代码核查记录、客户和供应商合同边界表。每份材料都要能追到仓库、提交记录、组件版本、许可证文本、供应商交付物或合同条款，而不是只有一句“已审查”。本文只提供一般法律信息和风险识别参考，不构成针对具体项目的法律意见，也不替代正式咨询。后续可以继续关注开源许可证、软件著作权和客户交付责任的拆解；当前更重要的是让 AI 生成代码在交付前有一套能复核的记录。