AI代码交付先看风险

AI代码交付先看风险

风险先说清楚：企业把 AI 生成代码直接放进产品、外包交付或客户项目里，最容易犯的误区不是“AI 写的就没人有权利”，而是没有把这段代码当成一个需要审查的交付物。真正要先看的，是代码里有没有相似片段、第三方组件、开源许可证义务、输入材料保密边界，以及供应商是否保存、复用或再训练相关材料。

这类审查不等于否定 AI 工具。相反，企业越是想把 AI 用进研发流程，越需要把“生成效率”后面那一串责任链条拆开。吕箐翎律师在处理知识产权和企业交付争议时，通常不会先问“是不是 AI 写的”，而会先问：这段代码从哪里来、用了什么材料、交给谁、按什么合同交、出了问题谁负责。

第一层：先把代码当交付物，而不是灵感草稿

AI 生成代码如果只是内部试验，风险边界相对窄；一旦进入客户交付、商业软件、SaaS 产品、外包成果或平台上线，就不能只停留在“模型生成”四个字。著作权、开源许可证、合同交付责任和客户验收都会同时出现，企业需要证明自己交付的不是来源不明、许可证不明、权属不明的代码。

建议先建立一份交付物登记表：代码版本、生成时间、使用工具、输入提示词的大类、人工修改记录、第三方组件清单、开源许可证识别结果、客户项目编号、交付节点、验收记录。这里不需要把商业秘密全部写进公开表格，但内部至少要能还原形成过程。以后发生相似代码争议、客户验收争议或供应商追责时，提交记录、测试记录、开发文档和交付记录比一句“这是 AI 生成”更有证明价值。

登记证书、软件著作权材料或仓库记录都有价值，但不能替代代码形成过程和权利链证据。企业如果只保留最终压缩包，缺少提交日志、需求变更、员工或外包权属文件、开源组件清单，后续很难说清楚自己到底审过什么、改过什么、交过什么。

第二层：开源许可证不能只问能不能商用

很多团队审查开源风险时只问一句：“这个许可证能不能商用？”这个问法太粗。GPL 相关风险尤其不能只按是否商用判断，还要看具体许可证版本、使用方式、链接或分发形态、源代码提供义务、第三方组件清单和替换方案。SPDX License List 和 Open Source Initiative approved licenses 可以帮助识别许可证名称和文本来源，但它们不能替代具体条款审查。

AI 生成代码里如果混入类似开源项目的代码片段，或者研发人员把开源组件、示例代码、插件代码和模型输出一起提交，企业就要把组件层和生成层分开。第一，列出第三方组件和许可证；第二，标记哪些代码是模型生成后人工修改，哪些来自已有库；第三，确认是否触发源代码提供、版权声明保留、许可证文本附带或分发条件；第四，准备替换方案，避免上线前才发现不能按客户合同交付。

这里的重点不是把所有开源都当成危险，而是别把许可证问题留到交付后。客户要求源代码交付、私有化部署、二次开发或嵌入其产品时，许可证义务可能直接影响合同履行。研发效率提高了，法务和交付侧的清单也要同步变细。

第三层：输入材料和供应商条款要单独看

AI 生成代码的另一个风险，是企业把客户需求、内部接口、业务规则、日志、账号信息、未公开算法思路或第三方材料输入工具，却没有看供应商条款。生成式人工智能服务的治理规则中，面向公众提供服务时会涉及训练数据来源合法性、知识产权、个人信息和数据处理记录等要求。企业作为使用方，也应把输入材料的合法来源和保密边界放进内部流程。

如果工具由外部供应商提供，合同至少要问四件事。第一，输入内容是否会被供应商保存、用于改进模型或再训练。第二，企业能否关闭相关使用或留存。第三，供应商对输出内容、第三方权利投诉、开源片段相似性有没有承诺或免责。第四，发生客户投诉、代码相似性争议或安全事件时，供应商能否提供记录、日志和协助。

这些问题不要只留在采购聊天记录里。建议把供应商条款、版本说明、后台设置截图、账号权限、日志导出、付款和订单记录归档。将来如果要判断责任链，合同、截图、后台记录和邮件比口头说明更可靠。

第四层：客户交付合同要写清责任边界

对外交付时，合同里最好不要只写“交付源代码”或“交付系统”。如果项目使用 AI 辅助生成、第三方组件或开源组件，应当在交付范围、权属、第三方材料、开源许可证、验收标准、缺陷修复、侵权投诉处理、供应商追偿等条款里留出边界。否则，客户发现相似代码、许可证标识或第三方组件问题时，争议会直接落到交付方身上。

企业内部也要区分三类材料：自己员工形成的代码，外包或供应商交付的代码，AI 工具辅助生成并经人工修改的代码。每一类都要有对应的权属文件、开发记录和验收记录。外包交付尤其要保留人员安排、需求文档、提交记录、测试记录、源代码交接记录和发票付款记录，不能只拿一个压缩包就入库。

如果合同已经签完，也可以补一个交付审查附件：组件清单、许可证清单、AI 辅助使用说明、已排除材料、待客户确认事项、上线前复核责任人。这个附件不一定能消除全部风险，但能让争议焦点从“谁也说不清”变成“哪些材料已审、哪些事项待确认”。

第五层：证据清单要跟研发流程连在一起

真正有用的证据不是事后临时拼出来的。建议研发、法务、采购和交付侧共用一套最小清单：需求文档、代码提交记录、版本标签、测试记录、第三方组件清单、许可证文本、供应商合同、工具后台设置、账号权限、日志导出、客户交付记录、验收邮件、发票和付款记录。每一项都对应一个问题：来源是否合法，权属是否清楚，许可证义务是否识别，客户是否知道交付边界。

电子证据还要注意连续性。截图要能看到时间、账号、页面来源和关键内容；聊天记录要能和合同、订单、付款或交付节点互相印证；后台日志要能说明谁在什么时间做了什么操作。知识产权争议里，单个截图往往不够，证据之间能不能闭环更重要。

吕箐翎律师处理这类企业知识产权问题时，更看重“第一天能不能把材料摆成链条”。链条越清楚，后续选择谈判、补充合同、替换组件、暂停上线、客户说明或诉讼保全时，判断空间越大。链条越散，企业越容易在客户、供应商、员工和工具提供方之间反复扯皮。

第六层：上线前做一次红黄绿判断

可以把 AI 代码交付审查做成红黄绿三档。绿色，是来源、权属、许可证、供应商条款、客户合同和交付记录都能对应上，可以按原计划交付或上线。黄色，是发现缺少记录、许可证不明、供应商条款不清或客户合同没覆盖，需要补材料、换组件或补充确认。红色，是存在高相似代码、许可证义务无法承受、客户材料输入越界、供应商拒绝提供记录，或者交付责任已经明显说不清，应暂停上线或交付。

这个判断要避免两个极端：一是把所有 AI 代码都挡在门外，研发无法推进；二是把所有输出都当成普通人工代码，等客户投诉再补救。更务实的做法，是把 AI 生成代码放进现有研发合规流程，要求它留下可审查的来源、修改、组件、许可证和交付证据。

本文只提供一般法律信息和风险识别参考，不构成针对具体案件或具体项目的法律意见，也不替代正式咨询。后续本号会继续拆解知识产权项目中的证据、期限和交付责任问题，企业可以先从一份组件清单和一份交付证据清单开始，把 AI 代码风险放回可管理的流程里。