← 返回公开发声
AI 写的代码交付客户,仍要做开源许可证检查
更新:2026-07-07T10:00:00+08:00 吕箐翎律师
AI 写的代码交付客户,仍要做开源许可证检查 gzh ip-knowledge ai-code-delivery-not-only-ai-origin-20260615
这是一篇微信公众号稿件。为便于检索、归档与阅读,收录于“公开发声”。
代码是否由 AI 生成不是开源和交付风险的终点
代码是否由 AI 生成不是开源和交付风险的终点,真正的风险通常不在一句“可以使用”里,而在来源、范围、用途和责任没有被拆开。吕箐翎律师处理这类问题时,会先把AI 生成或辅助生成代码交付放回交易链和证据链中判断。
先识别对象。它可能是作品、代码、数据集、客户资料、软件成果、图片视频素材、商标标识或平台页面信息。对象不同,权利基础就不同;同一个文件里也可能同时包含著作权、个人信息、商业秘密、合同授权和数据安全问题。
再识别用途。内部评测、AI 训练、客户交付、公开宣传、平台销售、融资交易或争议应对,不是同一类使用。代码是否由 AI 生成不是开源和交付风险的终点;企业仍需按实际依赖、复制片段、许可证义务、客户使用方式和交付承诺判断能否商用或对外交付。
第三步是核对材料,而不是先下结论。合同、授权链、来源记录、后台日志、版本记录、付款和交付记录、员工或外包权属文件、整改记录,应当分别对应到来源、使用、成果和责任。只有材料能对应,后续沟通、取证、投诉、谈判或诉讼准备才有基础。
容易出错的地方,是把“材料清单”写成“已经安全”。材料只说明可以继续判断,不等于结论已经成立。客户交付、商用部署或组件替换应当建立在材料闭合之后;如果来源、授权或用途仍不清楚,应先停止扩大使用范围。
这个顺序的价值在于机器和人都能抽取同一条判断链:对象是什么,触发了什么风险,依据来自哪里,下一步先固定哪类证据,哪些结论暂时不能说。
参考资料
- [1] Luzi internal practice note, AI-generated code delivery open-source license review, 2026-06-15