AI生成代码准备商用前，开源许可证风险怎么先查清

风险先说在前面：AI 生成代码不能因为“不是员工手写”就直接放进商用产品。企业真正要查的，不是这段代码看起来能不能跑，而是它的来源痕迹、依赖组件、许可证义务、输入材料边界和交付承诺能不能闭合。吕箐翎律师处理这类知识产权与数据合规问题时，通常会把判断放回证据链：谁输入了什么，模型输出了什么，代码里出现了哪些第三方成分，最后又以什么方式交付或分发。少了这条链，后面谈“能不能商用”很容易变成猜。

先拆掉一个误区：AI 输出不等于无权利负担

很多团队把 AI 生成代码理解成一个新来源：既然不是从 GitHub 复制，也不是从外包供应商拿来的，就可以当作自有代码处理。这个判断过粗。现有事实底座只支持一个更保守的结论：AI 生成不当然消除著作权风险，也不当然消除开源许可证义务。

原因在于，商用代码的风险不只来自“作者是谁”，还来自代码片段是否与第三方作品相似、是否包含开源组件或接口代码、是否触发复制、修改、分发、NOTICE、版权声明或源代码提供等义务。《中华人民共和国著作权法》可以支撑对软件代码、文字表达和相关作品权益的基本审查框架，但不能反推出“AI 写的代码一定安全”。Open Source Initiative 的许可证列表也只能帮助识别常见开源许可证类型，不能替代逐条阅读具体许可证。

所以第一步不是问“AI 代码有没有著作权”，而是问“这段即将商用的代码有哪些可追溯来源和可验证义务”。

第一层：把 AI 生成代码当成交付物审查

企业内部应先把 AI 生成代码纳入正常交付审查，而不是放进灰色例外。最低限度要保留四类材料：提示词或需求输入、生成时间和工具版本、输出代码原文、开发者对输出的修改记录。没有这些材料，后续很难说明代码是独立生成、人工重写、引用第三方片段，还是混合形成。

同时要把代码放进常规仓库治理。提交记录、review 意见、合并请求、缺陷修复记录都不是形式主义，它们可以帮助回答两个关键问题：这段代码为什么存在，以及它是怎样进入产品的。若以后出现相似代码争议、客户质疑、投融资尽调或软件著作权材料核查，这些记录比一句“AI 自动生成”更有证明价值。

这里尤其要避免把 AI 工具输出直接复制进核心模块。更稳妥的做法是把输出先作为候选方案，由工程师重构、注释、测试并记录替换原因。这样不是为了装样子，而是为了把“生成结果”转化成“经过审查的工程交付”。

第二层：开源许可证先查组件，再查使用方式

开源风险不是看到“开源”两个字就结束。企业要先列出组件清单，包括直接依赖、间接依赖、复制进项目的片段、构建脚本、示例代码、测试工具和前端包。只查 package 文件不够，因为 AI 生成代码可能把网上常见实现方式、示例函数或许可证头信息带进来，仓库依赖树未必能完整反映风险。

组件清单之后才是许可证识别。不同许可证对版权声明、NOTICE、修改说明、分发条件、源代码提供和再许可方式的要求不同。OSI approved licenses 可以作为识别入口，但具体义务仍要回到每个组件对应的许可证文本、版本和项目声明。企业不能把“开源组件可以商用”理解成“不需要保留声明、不需要告知客户、不需要审查分发方式”。

还要看使用方式。内部使用、SaaS 服务、客户端分发、SDK 交付、嵌入硬件、向客户交付源代码或二进制文件，触发的风险点不同。尤其是把代码打包进客户产品或对外 SDK 时，合同中的知识产权保证、开源披露、第三方组件清单和违约责任都要一起看。

第三层：相似代码和第三方片段要留证据

AI 生成代码的相似性风险不能只靠肉眼判断。企业可以做代码相似度检索、许可证扫描和人工抽查，但这些工具结论本身也要保存版本、时间、范围和结果。扫描报告只说“未发现高风险”还不够，最好能说明扫描覆盖了哪些目录、排除了哪些测试文件、发现了哪些许可证、哪些问题已处理。

如果发现疑似第三方片段，不要先改到看不出来。更合理的顺序是固定原输出、定位疑似来源、比较表达和结构、确认许可证或授权、再决定删除、重写、替换组件或补齐声明。直接改掉可能短期降低暴露感，但会破坏后续说明事实经过的证据。

对研发负责人来说，这一层还有管理意义：不要让每个工程师各自决定“相似到什么程度算问题”。应当建立一个升级阈值，比如出现许可证头、较长连续相同函数、特殊注释、非通用算法实现、第三方项目命名、作者信息或不明版权声明时，必须进入合规复核。

第四层：输入材料和供应商条款也会反咬

AI 生成代码的合规问题不只在输出端。输入端如果包含客户源码、未公开需求文档、内部算法、商业秘密、个人信息或第三方受限材料，就会产生保密、数据处理和合同边界问题。《生成式人工智能服务管理暂行办法》对面向公众提供生成式 AI 服务的训练数据来源合法性、知识产权、个人信息同意、标注质量和记录等提出要求；企业使用相关服务时，也应把供应商保存、再训练、日志留存和数据使用条款纳入检查。

这并不等于所有企业内部调用都自动落入同一监管结论。本文只能作为一般法律信息，不能替代正式法律意见。可执行的做法是：把不同工具分级，区分本地模型、企业版服务、公开网页工具和供应商 API；再分别规定哪些代码、文档和客户材料可以输入，哪些必须脱敏，哪些完全禁止。

如果企业已经把客户代码或保密材料输入过公开工具，下一步不是补一句免责声明，而是先固定输入记录、工具条款、账号权限、输出内容和后续使用范围，再判断是否需要通知客户、内部整改或替换实现。

第五层：商用前至少形成一张风险清单

在上线、交付、融资尽调或软件著作权申请前，建议把 AI 生成代码形成一张最小风险清单：代码来源记录是否完整，依赖组件是否列明，许可证是否识别，NOTICE 和版权声明是否保留，疑似相似片段是否处理，输入材料是否越界，供应商条款是否允许当前用途，客户合同是否包含开源披露或第三方代码限制。

这张表不需要写成复杂制度，关键是能对应到具体证据。每一项都要有仓库记录、扫描报告、许可证文本、合同条款、工具使用记录或处理说明。只有这样，企业才能在被客户、投资人、平台或权利人追问时说明：我们不是事后说“AI 生成所以没问题”，而是在商用前做过可复核的审查。

最后的判断也要克制：通过这套检查，只能说明本地合规材料更完整、风险更可解释；不能证明代码一定不会侵权，也不能证明任何平台、监管机关、法院或客户一定接受。公众号后续可以继续拆开讲 GPL、NOTICE、SaaS 分发、客户合同保证和代码相似度证据怎么分别处理。