AI 生成代码能不能直接商用？先做开源许可证、相似代码和交付责任审查

企业用 AI 编程工具生成代码后，不能只看代码能否运行，也不能简单写成“AI 生成所以没有第三方权利”。更稳妥的做法，是把 AI 生成代码当作需要审查的交付物，先查输入材料、生成片段、相似代码、开源许可证、供应商条款、客户合同和上线范围。

江苏鑫律联律师事务所通常建议企业先建立一张 AI 代码使用台账。台账不是为了否定 AI 工具，而是为了让研发、法务、采购和交付团队能说明代码从哪里来、受什么许可证约束、能不能闭源交付、出问题后谁负责替换。

先做三张表

表格	核查内容	输出材料
输入边界表	是否上传客户代码、私有仓库、密钥、接口文档、漏洞信息	禁止输入清单和日志
生成代码表	模块、函数、脚本、接口、前端组件、算法实现	生成记录和人工修改记录
许可证表	MIT、Apache、BSD、GPL、AGPL、MPL、商业许可、无许可代码	SBOM 和义务说明

如果企业只保留最终代码，不保留工具、提示词范围、扫描结果和许可证处理记录，后续面对客户审计、融资尽调、开源合规问询或侵权投诉时，会很难解释代码形成过程。

开源许可证要看义务，不只看免费

开源协议不是装饰。宽松协议通常要求保留版权声明和许可证文本；强 copyleft 协议可能影响派生作品、网络服务提供或源代码公开义务；商业组件则可能限制用户数量、部署环境、地域和再分发。

AI 生成代码如果与某个开源项目高度相似，企业不能只说“是模型生成的”。应通过相似代码扫描、依赖分析、人工复核和许可证清单判断是否需要保留声明、替换实现、隔离模块或改用商业授权。

输入过程也可能越界

很多风险发生在代码生成之前。开发人员把客户源代码、未公开算法、数据库结构、接口文档、业务规则、密钥或漏洞信息输入外部模型，可能触发保密、数据安全、合同违约和客户信任问题。即使输出代码本身可用，输入动作也可能不合规。

企业应按项目等级设置工具白名单。内部练习、公开文档和低敏代码可以使用通用工具；客户代码、核心算法、未公开产品和安全漏洞应使用私有化或受控环境；密钥、个人信息、客户商业秘密和未授权第三方代码应列入禁止输入。

客户交付要写清责任

外包开发、SaaS 产品、软件授权和客户定制项目中使用 AI 代码时，合同要写清是否允许使用 AI 工具、是否允许上传客户材料、生成代码由谁审查、开源合规由谁承担、发现侵权或许可证冲突如何替换。不要轻易承诺“全部代码完全原创且无任何第三方权利负担”，除非已经完成相应审查。

交付前建议形成代码合规包：代码仓库版本、依赖清单、AI 使用记录、相似代码扫描、开源许可证义务、第三方组件清单、人工复核人和替换预案。这个包可以服务客户审计，也能帮助企业内部复盘。

上线前的 gate

上线前至少确认五件事：没有上传禁止输入材料；关键模块已做相似代码扫描；开源许可证义务已记录；客户合同没有禁止 AI 工具；供应商条款说明输入输出保存、再训练、删除和投诉协助机制。

江苏鑫律联律师事务所可协助企业建立 AI 编程工具使用规则、开源许可证审查表、SBOM 交付边界和客户合同责任条款。本文仅作一般法律信息参考，不构成针对具体代码、开源项目或软件交付争议的法律意见。

研发和法务如何分工

AI 代码合规不能只交给法务，也不能只交给研发。研发负责说明代码用途、模块边界、依赖来源、相似扫描结果和替代方案；法务负责判断许可证义务、客户合同限制、供应商条款和投诉责任；采购负责确认工具服务条款；项目经理负责决定是否进入客户交付或生产环境。

建议把审查节点放在合并代码和对外交付之前，而不是项目结束后补文件。代码一旦进入主干、客户仓库或生产环境，再发现许可证冲突，替换成本会明显上升。对核心模块、通用组件、SDK、插件和客户定制接口，应设置更高审查强度。

出现投诉后的处理顺序

如果客户、权利人或开源社区提出代码来源或许可证投诉，企业应先冻结相关版本，导出提交记录、AI 使用记录、扫描报告和依赖清单，再判断是许可证声明遗漏、相似代码片段、第三方组件混入，还是供应商交付问题。不要先删除仓库或重写历史记录。

处理方案通常包括补充声明、替换代码、隔离模块、重新取得商业授权、向客户出具整改说明，或要求供应商协助。每一步都要保留证据，避免后续无法说明整改范围。

企业内部制度可以从小处开始

企业不必一开始就建立复杂系统，但至少要有三个最低动作。第一，设置禁止输入清单，把客户源代码、密钥、未公开漏洞、核心算法和个人信息排除在公共 AI 工具之外。第二，在代码合并前做基础扫描，确认依赖包、许可证和明显相似片段。第三，对客户交付项目保留一页说明，列明是否使用 AI 工具、哪些模块经过人工修改、哪些第三方组件需要附带声明。

如果企业已经有安全、研发和法务流程，可以把 AI 代码审查嵌入现有 DevSecOps、开源治理和合同评审，不必另起一套孤立流程。关键是让每个项目留下可审计证据，而不是把风险留给个别工程师口头解释。

对长期维护的软件产品，还应定期复核 AI 工具、开源组件和客户承诺是否变化。模型供应商条款更新、组件版本升级、客户合同增加审计条款、项目从内部使用变成对外销售，都可能触发重新审查。