AI 生成的代码能不能直接商用，真的还要查开源许可证吗？

不能直接按“AI 写的，所以没人有权利”来处理。企业把 AI 生成代码用于产品、外包交付或客户项目时，最稳妥的做法是先把它当成一份需要审查的代码交付物：查相似片段、查第三方代码、查开源许可证、查输入材料和供应商条款，再决定能不能并入主仓。

很多团队的误区是：只要没有人工复制，就不会有著作权或开源问题。这个判断太粗。AI 输出可能夹带与已有代码高度相似的片段，也可能受输入材料、插件、模型服务条款、供应商保存和再训练规则影响。问题不在于“是不是 AI 生成”，而在于企业能否说清楚这段代码从哪里来、用了什么材料、有没有许可证义务、交付给客户时谁承担责任。

先看使用场景，不要只看生成方式

如果只是内部临时脚本，风险重点通常是数据、账号和内部安全；如果要进入商业产品，风险重点就变成权利链和许可证；如果是外包公司交付给客户，还要看合同里是否承诺“原创”“无第三方权利负担”“不含传染性开源许可证”。同一段 AI 代码，在不同场景下的审查强度不一样。

举个常见场景：研发用 AI 生成了一段图像处理模块，测试通过后准备放进 SaaS 产品。法务不能只问“是不是 Copilot 或某个大模型写的”，还要问这段代码是否与公开仓库片段相似，是否依赖 GPL、AGPL、LGPL、Apache、MIT 等许可证，是否调用了第三方 SDK，提示词里是否放入客户代码或保密资料。

三件事先查清楚

第一，查代码来源痕迹。保留提示词、生成时间、模型或工具名称、人工修改记录、合并记录和评审记录。没有这些记录，后面很难说明企业已经做过合理审查。

第二，查相似代码和许可证。可以用代码扫描工具、依赖清单、SBOM、SPDX 或 OSI 许可证目录做初筛。重点不是背许可证名称，而是确认有没有必须保留版权声明、公开修改源码、开放衍生作品、限制商用或要求披露网络服务源码的义务。

第三，查合同责任。外包交付、客户定制开发、SaaS 上线前，要把 AI 辅助生成、第三方组件、开源许可证、供应商留存和再训练条款写进内部审查或客户交付文件。否则出问题时，业务会把“AI 自动生成”误当成免责理由。

行动建议

建议做一张交付前检查表，至少列五列：代码模块、生成工具或模型、相似代码扫描结果、涉及许可证、客户交付责任。每个模块都要有人签字确认，不要只在聊天记录里说“看起来没问题”。

对高风险模块，补三类材料：一是生成记录和人工修改记录；二是依赖包、第三方 SDK、开源许可证清单；三是客户合同或供应商条款中关于权利保证、开源使用、保密输入和再训练的条款。吕箐翎律师处理知识产权和数据合规问题14年，接触过11,000+件咨询和案件线索，实务上更关注企业能不能拿出这套材料，而不是口头解释“代码是 AI 写的”。

如果发现疑似 GPL、AGPL 或来源不明的关键片段，不要急着上线。先隔离模块、替换实现、补版权声明或取得授权，再决定是否交付。已经交付给客户的，要同步检查合同里的通知、修复、赔偿和开源组件披露义务。

常见问题

问：AI 生成代码没有作者，是不是就不受著作权约束？

不应这样理解。即使某段输出本身的权利归属存在争议，企业仍要审查它是否复制或近似已有作品、是否混入第三方代码、是否触发许可证或合同义务。

问：只要扫描工具没有报错，就能放心商用吗？

不能。扫描工具只能降低遗漏概率，不能替代人工判断。尤其是少量相似片段、改写后的代码、模型服务条款、客户保密代码输入，这些都需要结合项目材料判断。

问：客户要求“完全原创代码”，AI 辅助生成算违约吗？

要看合同怎么写。如果合同把“原创”理解为不含第三方权利负担，企业至少要证明生成过程、人工修改、许可证排查和第三方组件披露已经完成。没有记录时，争议会非常被动。

以上是一般信息参考，不构成针对具体项目的法律意见，也不能替代正式咨询。如需个案分析，可通过知乎私信联系吕箐翎律师。