某公司为了赶进度，允许研发人员使用AI编码助手完成新产品。代码审查时，法务发现部分辅助函数由开发人员逐行接受自动补全，一个核心模块则由编码智能体读取需求文档后整体生成。部分代码带有与公开仓库相同的函数名称和注释，工具还提示其中一段代码可能与公共代码匹配，并显示了相关许可证信息。 开发人员修改了变量名和部分逻辑后，将代码提交到主分支。另一些代码没有出现任何匹配提示。企业账号协议中写着输出归客户或者用户所有，销售合同却承诺全部软件均由企业独立开发，不包含受限制的第三方代码。项目组也没有保存主要提示词、生成会话和被接受的原始建议。 企业内部很容易形成四种判断：平台已经把输出权利转让给企业，可以直接使用；没有收到代码匹配提示，就代表不存在第三方风险；代码经过开发人员修改，就已经成为企业原创代码；AI生成代码无法取得著作权，因此一律不能进入核心产品。 企业至少需要分别判断：平台合同授予了什么；最终代码是否体现了足够的人类智力投入和独创性表达；是否存在第三方代码或者开源许可证风险；代码是否满足企业的安全、质量和权属要求；企业能否还原其形成和修改过程。 AI编码助手可以进入企业研发流程，但不能成为代码来源审查、人工设计、开源合规和安全测试的替代品。在企业研发管理中，可以将AI生成代码按照“来源需要特别核验的外部输入”进行管理。这种分类是为了启动来源、许可证和安全审查，并不代表相关代码已经被认定为第三方作品或者侵权代码。
一、平台约定“输出归用户”，不等于企业取得完整、排他的著作权 编码工具服务协议中常见的表述包括：平台不主张输出所有权；平台将其可能享有的输出权利转让给客户；用户可以将输出用于商业目的；输出可能并不唯一；用户应自行判断输出是否适合具体用途。 以现行OpenAI企业服务协议为例，在客户与OpenAI之间，在法律允许范围内，客户拥有输出，OpenAI将其对输出可能享有的权利转让给客户。但协议同时明确，客户应对输入拥有必要权利，并自行负责输出的使用、准确性和适用性评估，其他用户也可能获得相同或者相似内容。其代码生成服务条款还提示，包括Codex在内的代码生成功能输出，可能受到第三方许可证，包括开源许可证的约束。 GitHub现行生成式AI服务条款则规定，GitHub不拥有客户输入或者输出，同时要求客户自行承担利用相关服务开发应用和智能体时的法律、监管及许可证合规责任。不同采购渠道、个人订阅、历史企业客户和通过Microsoft采购的客户，可能适用不同合同文件。 这些条款首先处理的是平台与账户客户之间的合同关系。 “平台不主张权利”与“用户是否依法取得著作权”不是同一个判断。平台只能处分自身可能享有的权利，不能替第三方转让源代码著作权，也不能通过合同创造法律本身不承认的著作权客体。 第一是合同使用层面：平台是否允许企业将输出用于商业软件。 第二是作品成立与权利归属层面：最终代码是否体现了足够的人类智力投入和独创性表达；在此基础上，相应软件著作权依法应当归属于员工、组织开发的软件企业、委托方或者其他主体。 第三是第三方清权层面：最终代码是否复制了他人受保护的程序表达，或者受到开源许可证及其他权利限制。 其中任何一层成立，都不能自动推出另外两层成立。平台允许商用，不代表代码必然具有独创性；代码具有独创性，也不代表没有使用第三方代码；企业对人工修改部分享有权利，也不代表能够排除其他人使用相同的机器生成部分。 平台合同还不能解决企业与员工、外包方和合作方之间的权属关系。研发人员使用个人账号生成代码时，平台条款中的客户可能首先是个人；外包人员使用编码助手形成代码，也不意味着其已经将全部可转让权利交付给委托企业。 企业仍需通过职务开发制度、委托开发合同和合作协议，明确工具账号、输入材料、生成结果、人工修改部分及最终软件成果的归属。平台合同只能解决平台一侧的权利安排，不能替代企业内部的权利链。 二、AI生成代码能否获得著作权，关键在人类控制和贡献了什么 我国《著作权法》保护具有独创性并能以一定形式表现的智力成果，并将计算机软件列为作品类型。《计算机软件保护条例》规定，软件开发者可以是实际组织开发、直接进行开发并对软件承担责任的法人或者其他组织，也可以是独立完成开发并承担责任的自然人。 但作品是否成立与权利最终归谁，是两个不同问题。企业组织开发、支付费用或者承担产品责任，不能替代对代码是否包含足够人类智力投入和独创性表达的判断。 现行规则没有设置AI自动成为作者，也没有规定用户只要输入提示词，就当然取得全部输出的著作权。但这也不意味着所有AI参与生成的代码都无法受到保护。 判断重点不是开发人员使用了多少次提示词，也不是人工修改了多少行代码，而是人类是否对最终程序表达进行了实质性的设计、选择、控制和修改。 简单接受自动补全，与开发人员已经确定完整技术方案后借助工具实现代码，并不是同一种开发过程。 开发人员只输入函数名称或者少量上下文，工具自动补全一段常见循环、数据转换或者标准接口调用，人员没有作出实质性选择和修改时，人类对具体表达的控制较弱。其中还可能包含编程语言固定语法、通用模板和有限表达，企业能够主张的排他保护空间通常较小。 如果开发人员事先确定了模块结构、数据流、类和函数关系、异常处理、接口方式、性能和安全要求，工具只是按照这些安排生成初始代码，人类对程序结构和实现方向的贡献会更加明确。但仍需区分开发人员预先设计的内容与工具自行决定的具体表达。 在多轮生成、选择和重构场景中，开发人员可能比较多个方案，重新安排代码结构，改变算法实现、异常处理和性能逻辑，并将不同结果重新组合。最终代码能够体现人员个性化选择和实质性修改的，对相应人工贡献部分主张软件著作权的基础会更充分。 编码智能体自主读取仓库、分解任务、修改多个文件、运行测试并提交合并请求时，判断会更加复杂。人工点击最终批准，不应当然等同于创作了全部代码。企业需要说明，人员事先设定了哪些架构、约束和验收标准，智能体自主决定了哪些内容，人员是否逐项审核、修改和重构，以及最终代码中哪些表达能够归因于人的智力投入。 最高人民法院知识产权法庭刊载的相关司法研究提出，人类对生成过程的控制是判断人类贡献的重要因素，但还需要考察人的智力投入是否真正影响了个性化表达的形成。该观点主要基于人机共生成果展开分析，并非司法解释、指导性案例，也不是专门针对AI生成代码的生效裁判。 截至目前，国内尚未形成专门针对AI编码助手输出代码著作权成立标准的统一裁判规则。企业可以参考人类控制、选择、修改和重构程度进行证据管理，但不能将相关研究观点直接作为确权结论。 企业也不应制定“人工修改30%即可确权”之类的比例标准。修改变量名、统一格式、删除注释或者机械调整文件位置，通常不足以证明开发人员形成了新的独创性表达。更有价值的是代码架构、程序组织、实现路径和关键逻辑如何由人员作出选择，以及这些选择能否通过记录还原。 即使部分自动补全代码本身缺乏独创性，企业仍可能对人工设计的软件整体架构、自行完成的核心模块、人工选择和编排形成的代码组合、修改重构部分以及相关文档享有权利。 企业真正需要保护的是最终软件中的人类贡献和整体成果，而不是强行证明每一段自动补全都由企业独占。 三、AI输出与既有代码相似，不代表必然侵权，也不能因为“不知道来源”就免责 AI生成代码与公开代码相同或者近似，可能有多种原因。 编程语言固定语法、标准接口、通用算法、官方SDK示例、技术文档模板和相同功能下的有限表达，本来就可能导致不同开发者写出接近的代码。开发人员在提示词中输入既有代码，编码工具读取企业仓库上下文，也可能直接影响输出。 另一种可能是，生成结果复现或者高度接近开源项目、公开论坛答案，甚至第三方专有软件中的程序表达。 因此，发现代码相似不能直接证明模型记住并复制了某项训练材料；但企业无法解释模型内部原理，也不能成为忽略最终代码权利风险的理由。 企业把生成代码复制到产品、交付客户或者向公众发布时，实际实施的是软件复制、修改、发行或者传播行为。如果相关代码确实构成第三方受保护的表达，企业不能仅以“代码由AI生成”“平台没有显示来源”“研发人员不知道原作者”“代码经过少量修改”或者“所占比例很低”当然免责。 这类案件最终仍需判断第三方代码是否具有可保护性，相似部分是否属于通用或者有限表达，双方代码是否相同或者实质性相似，以及AI工具、人员输入、代码仓库上下文和公开来源能否对相似作出合理解释。具体侵权证明规则仍应按照第二篇的软件著作权分析处理。 部分编码工具提供公共代码匹配和引用功能，但这类功能只能作为风险提示，不能替代完整清权。 GitHub现行代码引用功能会将潜在建议及约150个字符的周边代码，与GitHub公开仓库索引进行比对；匹配时可以记录相关文件和许可证信息。但私有仓库、GitHub以外的代码不在该检索范围内，索引也可能存在更新间隔。对于开发人员自行编写的代码以及已经修改的内联建议，代码引用功能不会按照相同方式进行匹配检查。 公共代码匹配功能核查的是与GitHub公开仓库代码的技术对应关系，不是对著作权有效性、许可证适用范围和侵权成立的法律鉴定。 因此，出现匹配提示时必须进一步核查；没有出现提示，也不能视为已经完成第三方权利清查。研发人员更不能先接受匹配代码，再通过改名或者让AI重新改写来绕过内部审查。 短小、通用代码与具有明显个性化表达的代码也应区别处理。常见循环、简单配置、标准接口和普通异常处理模板的保护范围可能较窄；如果输出包含较长连续代码、特殊函数组织、非必要的变量和注释、项目名称、版权信息、共同错误或者独特实现方式，第三方复制风险会明显上升。 四、AI输出不能切断已经实际附着于相关代码的许可证条件 如果编码助手输出中包含可以识别的开源项目受保护程序表达，或者是在该代码基础上形成的修改版本，企业不能仅因代码经AI工具输出，就否定原有许可证条件。 企业是否需要履行许可证义务，仍然取决于原代码适用的许可证、相似范围、企业的修改方式、代码组合关系以及最终如何发布和交付。代码不是由研发人员直接从公开仓库复制，而是经AI工具重新输出，并不会当然切断已经实际附着于相关代码的许可证条件。 发现公共代码匹配后，企业不能只问许可证是否“允许商用”。还要核查匹配的具体仓库、文件和版本，代码是否来自多个项目，权利主体是否清晰，是否需要保留版权和许可证信息，是否可能触发对应源代码或者同许可证发布义务，是否存在NOTICE、专利和商标要求，以及该段代码能否替换或者独立重写。 删除版权声明、项目名称和许可证文本，修改函数及变量名称，将代码拆分到多个文件，或者再次要求AI“换一种方式重写”，都不一定改变程序表达的实质对应关系，也不会当然消除许可证义务。 Doe v. GitHub案围绕Copilot输出与公开仓库代码的对应关系、开源许可证以及版权管理信息等问题展开。该案中的多项请求已经在地区法院阶段被驳回或者限缩。目前进入第九巡回中间上诉的核心问题，是美国《数字千年版权法》第1202条关于版权管理信息的责任，是否要求涉案输出与原作品构成完全相同的复制。截至2026年8月6日，该案已经完成口头辩论，但尚未见上诉判决。 该案一方面涉及输出代码与公开仓库代码之间的对应关系，另一方面涉及版权管理信息被删除或者变更的法定责任。至于开源许可证条件是否继续适用于具体输出，还需要结合原代码、许可证条款、输出相似程度和实际发布行为分别判断。 因此，该案既不能被写成法院已经认定Copilot侵权，也不能被写成法院已经确认AI生成代码完全合法。它反映的是，代码复现、开源许可证、版权管理信息和损害证明仍处于规则持续形成过程中。 AI生成代码进入产品后，应与人工复制、外包交付和第三方组件一样纳入软件物料清单、代码片段扫描、许可证审查、发布审批和历史版本追踪。第三篇建立的开源合规体系，不能因为代码经过AI生成而停止适用。 五、平台提供知识产权索赔抗辩或者赔偿安排，不等于企业可以省略代码审查 部分平台会为特定企业客户提供第三方知识产权索赔抗辩或者赔偿安排，但其适用通常受到客户类型、采购渠道、产品版本和使用条件限制。 现行OpenAI服务条款分别为符合条件的API客户，以及ChatGPT Enterprise、Edu、Healthcare和Business客户设置了输出知识产权索赔赔偿安排。但具体客户是否享有赔偿，还需结合其主协议、订单、采购渠道和产品类型判断。 相关条款同时设置了多项除外情形。例如，客户知道或者应当知道输出可能侵权，关闭或者忽略相关引用、过滤和安全措施，对输出进行修改或者转换，将输出与非OpenAI产品组合，客户对输入没有合法权利，或者输出来自第三方产品时，相关赔偿可能不适用。测试和预览功能通常也适用不同的责任安排。 GitHub现行生成式AI服务条款则规定，只有客户基础协议本身包含第三方索赔抗辩承诺时，该承诺才扩展至生成式AI服务和输出。客户还需要遵守可接受使用政策、AI行为准则和必要缓解措施，并对最终应用的法律、监管和许可证合规负责。 “不侵权保证”与“第三方索赔抗辩或者赔偿承诺”不是同一概念。平台可能不承诺所有输出均不侵权，却在符合特定条件时承担部分抗辩或者赔偿责任。 即使平台承担责任，也未必覆盖产品延期、紧急重构、客户合同违约金、商誉损失、禁令导致的停服以及企业向下游作出的扩大承诺。企业修改、组合代码或者未及时通知平台，也可能影响合同保护。 知识产权索赔抗辩或者赔偿只是风险分配机制，不能替代研发合规。 平台条款还会更新。企业采购编码助手时，应保存签约时适用的主协议、产品专项条款、订单、数据处理协议、功能设置和赔偿条件，不能等争议发生后只访问平台当前网页。 六、AI编码助手还会引入输入泄密、权限过宽和代码安全风险 企业使用编码助手，不仅要审查输出，还要确认研发人员有权向工具提供输入内容。 输入材料可能包含企业源代码、客户委托开发代码、第三方商业软件、开源组件、未公开漏洞、密钥、配置文件、个人信息、生产日志和客户数据库结构。平台允许用户输入内容，不代表企业已经取得向外部服务提供这些资料的权利。 对属于《生成式人工智能服务管理暂行办法》适用范围的编码助手服务，提供者和用户还应遵守知识产权、商业秘密及服务协议等要求。即使某项企业内部工具不直接适用该办法，企业向外部工具输入第三方代码、客户代码和商业秘密的权限问题，仍需根据著作权、合同和保密义务独立判断。 企业版承诺“不用于模型训练”，也不等于不存在数据处理风险。 部分平台原则上不使用企业客户输入和输出训练模型，但仍可能为了提供服务而保留会话或者相关数据。编码工具还可能调用第三方模型、插件、外部工具或者MCP服务器，具体数据流和保留期限取决于产品设置、服务条款和数据处理协议。 编码智能体可能获得仓库读取、文件修改、终端执行、工具调用和自动提交权限。企业需要审查的不只是平台是否训练模型，还包括智能体能够访问哪些仓库，能否读取密钥和生产配置，是否会调用第三方服务，以及日志和会话保留多久。 即使不存在任何知识产权问题，AI生成代码仍可能包含不安全函数、硬编码密钥、注入漏洞、权限绕过、虚构依赖、过期接口、性能问题和错误业务逻辑。 “平台允许商用”与“代码能够安全上线”是两个完全不同的结论。AI生成代码仍需经过人工评审、单元和集成测试、依赖及漏洞扫描、密钥检查和架构审查。 七、不同代码场景需要不同强度的审查 企业既没有必要一律禁止AI编码助手，也不宜把是否使用、如何使用完全交给研发人员自行决定。 测试数据、临时脚本、代码解释、格式转换和不进入生产系统的原型，可以采用较低强度审查，但仍应禁止输入密钥、客户代码和其他敏感信息。 页面组件、一般业务逻辑、API封装和普通后台服务进入正式产品前，应完成正常人工审核、代码来源扫描、许可证检查、安全测试和代码仓库评审。 核心算法、模型调度、身份认证、权限控制、支付、密钥管理、安全防护、高风险决策逻辑以及企业计划作为核心知识产权保护的模块，应采用更严格的控制。企业可以限制智能体自主生成完整实现，要求双人复核、人工重构和专项权属确认。 未经授权的第三方专有代码、客户明确禁止外部处理的代码、涉密项目、真实生产密钥、未公开重大漏洞以及受特殊行业限制的技术，不应输入未经批准的编码工具。 提高核心代码审查强度，并不是因为AI生成代码当然低质量或者不能获得保护，而是因为这些模块一旦出现来源、权属或者安全问题，造成的业务损失更大，企业也更需要证明其形成过程。 八、企业需要形成一条可以审计的AI代码生成链 企业首先应建立工具、账号、模型和插件白名单，明确允许使用哪些编码助手，必须使用企业账号还是可以使用个人账号，能否连接代码仓库、调用第三方模型、启用智能体、使用测试功能和自动提交代码。 对于核心和高风险模块，还应保留足以还原代码形成过程的记录，包括使用工具及模型版本、操作人员、主要提示词和需求、原始输出、公共代码匹配提示、人工选择和修改、代码评审、扫描测试结果、最终提交记录以及上线版本。 企业不必永久保存每一次普通自动补全。记录范围应与代码风险相匹配。测试脚本可以只保留正常提交历史，核心算法、权限和安全模块则需要更完整的生成及复核记录。 AI代码来源还应进入代码仓库，而不能只存在于员工记忆中。企业可以在提交记录或者合并请求中标明AI辅助程度、使用工具、是否出现公共代码匹配、许可证审查编号、风险等级及人工复核人员。 权利来源门禁：检查公共代码匹配、第三方代码和许可证； 人工审核与责任门禁：由开发人员理解、审核和必要修改代码，对最终实现及其进入产品承担责任；核心知识产权模块另行记录人类设计和创造性贡献； 收到公共代码匹配提示或者权利人投诉后，企业不宜立即覆盖所有记录。应先固定原始生成会话、工具引用、代码提交历史、人工修改、扫描结果、上线版本、适用平台条款和供应商沟通记录，再决定删除替换、补充署名和许可证、取得商业授权、暂停版本或者启动平台索赔抗辩及赔偿程序。 企业使用AI编码助手的真正风险，不是机器参与了写代码，而是企业失去了对代码来源、形成过程和最终责任的控制。 AI可以提高开发效率，但纳入企业产品和交付物的代码，最终仍应由具体人员审核，由企业承担相应责任，并能够经受权属、许可证、安全和独立开发四方面的追溯。 第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。 也欢迎您转发、转载本文，让更多有需要的朋友及时看到。
夜雨聆风