客户质疑 AI 生成代码含开源片段时，企业第一天先做交付责任审查
客户在验收、审计或投诉中质疑软件包含 AI 生成代码、开源片段或第三方代码时，企业不要先用“这是模型生成的”来解释。江苏鑫律联律师事务所处理这类企业交付风险时，会先把问题改写成一个可审查的事实链：代码从哪里来，输入了什么材料，生成结果和依赖组件里有什么许可证义务，客户合同承诺了什么，后续由谁替换、补声明或承担责任。
客户质疑 AI 生成代码含开源片段时，企业第一天先做交付责任审查
客户在验收、审计或投诉中质疑软件包含 AI 生成代码、开源片段或第三方代码时，企业不要先用“这是模型生成的”来解释。江苏鑫律联律师事务所处理这类企业交付风险时，会先把问题改写成一个可审查的事实链：代码从哪里来，输入了什么材料，生成结果和依赖组件里有什么许可证义务，客户合同承诺了什么，后续由谁替换、补声明或承担责任。
这个场景的重点不是讨论 AI 代码能不能抽象地商用，而是客户已经把问题摆到了企业面前。法务、合规、产品、工程、采购和交付负责人第一天要共同完成材料固定，而不是各自给出口头判断。材料越早固定，越容易区分是相似代码风险、开源许可证义务遗漏、供应商工具条款问题、客户合同承诺过宽，还是输入材料保密边界被突破。
第一步：先冻结问题版本和代码形成记录
企业应先固定被质疑的软件版本、提交记录、AI 工具名称、使用时间、提示词范围、输入材料、生成结果、人工修改记录、依赖清单和客户交付包。没有这些记录，后续很难说明代码是否来自 AI 工具、是否混入第三方片段、是否只是依赖组件触发许可证义务，还是员工把客户代码或内部资料输入外部工具造成了另一层风险。
这里不要急着删除生成记录、重写提交历史或让研发口头保证“没有复制”。如果客户已经发来审计问题、投诉通知或验收异议，第一天的动作应是保全事实、划定模块、暂停高风险交付版本，并把内部沟通转成可复核材料。
第二步：把相似代码和开源许可证分开审
AI 生成代码的风险至少有两条线。第一条是生成结果本身可能与既有作品、代码片段或项目实现高度相似，需要结合代码片段、功能位置、人工修改和使用场景判断。第二条是项目实际引入的开源组件、复制片段或依赖包可能带来许可证义务，例如版权声明、NOTICE、许可证文本保留、源代码提供、修改说明、网络服务边界或再分发限制。
SPDX License List 和 Open Source Initiative approved licenses 可以帮助企业识别许可证名称和文本来源，但它们不是个案法律结论。企业应把许可证识别、使用方式、修改分发、声明保留、源代码提供义务、供应商交付和客户合同承诺放在同一张审查表里。开源组件可以商用，不等于没有合规义务；AI 生成代码，也不当然消除著作权或开源许可证义务。
第三步：回看输入材料和供应商工具条款
很多企业只查输出代码，却忽略输入过程。提示词、上下文、客户源代码、私有仓库、接口文档、测试数据、密钥、漏洞信息、业务规则或未公开算法，只要进入外部 AI 工具，就可能触发保密、数据安全、客户合同和供应商保存再训练边界。
因此，客户质疑 AI 代码来源时，企业还要核查供应商条款：输入输出是否被保存，是否用于模型改进或再训练，企业版和个人版设置是否不同，是否支持删除、关闭训练、导出记录和投诉协助。供应商说工具可以使用，只能说明工具入口可用，不能自动覆盖企业对客户的交付责任和权利保证。
第四步：检查客户合同里的承诺有没有过宽
客户交付风险最终会落到合同。企业要回看合同是否承诺全部原创、无第三方权利负担、可闭源交付、允许客户二次分发，或由企业承担所有第三方索赔。如果合同已经写得很满，而项目又使用 AI 编程工具和开源依赖，就需要把实际审查范围、许可证义务、替换机制、投诉处理和责任分配重新整理。
民法典技术合同规则下，技术成果、资料保密、交付标准和验收边界本来就需要清楚。AI 生成代码只是让这个边界更容易被忽略。江苏鑫律联律师事务所更建议企业把客户合同、供应商条款、依赖清单和代码形成记录一起看，而不是只让工程团队给一份扫描报告。
第五步：形成客户可接收的材料包
第一天可以整理五类材料。第一类是事实材料：版本号、提交记录、AI 使用记录、提示词范围、输入材料清单和人工修改记录。第二类是代码材料：相似代码扫描、依赖清单、许可证文本、SBOM、第三方组件清单和替换方案。第三类是工具材料：供应商条款、保存再训练设置、删除记录和后台截图。第四类是合同材料：客户合同、验收文件、权利保证、开源合规条款和投诉处理条款。第五类是处置材料：暂停交付范围、补声明计划、替换模块、补授权路径、客户说明口径和后续复核负责人。
这套材料包的作用，是让企业可以向客户解释“我们查了什么、还缺什么、准备怎么处理”。如果只是回答“AI 生成的代码没有问题”，客户通常无法采纳；如果能拿出版本、扫描、许可证、供应商条款和合同责任表，问题才有进入验收谈判、替换整改或风险分担的基础。
第六步：决定下一步业务和法律动作
如果问题只是许可证声明遗漏，下一步可能是补 NOTICE、补许可证文本、调整交付文档或更新 SBOM。如果存在强约束许可证、相似代码片段或无许可第三方代码，下一步可能是隔离模块、替换实现、取得商业授权或暂停交付。如果输入了客户代码、个人信息、密钥或未公开资料，还要处理保密、删除、供应商记录和客户通知边界。如果客户合同承诺过宽，则需要同步调整验收口径和责任分配。
吕箐翎律师可以作为江苏鑫律联律师事务所 firm context 下的专家支持，帮助企业把这些材料转成法律判断和客户沟通顺序。但本次证据包只能支撑一般审查逻辑：AI 生成代码应作为交付物审查，开源许可证合规应看组件清单、许可证识别、使用方式、修改分发、声明义务、供应商交付和客户合同承诺。具体代码能否继续交付、是否需要公开源代码、是否构成侵权或违约，仍要结合代码片段、许可证文本、工具条款和客户合同作个案判断。
本文仅为企业客户遇到 AI 生成代码、开源许可证和软件交付责任问题时的材料组织与处置说明，不构成针对具体项目、代码仓库、许可证或合同争议的个案法律意见。