AI企业法律风险地图(一):模型、代码和数据到底归谁?一、AI创业公司最早要讲清的，不是股权比例，而是核心资产归属
（一）很多AI项目一开始跑得很快，但资产边界往往没有同步跟上
AI创业公司早期最常见的场景，是几个创始人先把产品跑起来。谁有技术能力，谁先写第一版代码；谁懂模型，谁先调第一版参数；谁有行业资源，谁先找第一批数据；谁认识客户，谁先把项目拿下来。这个阶段大家的注意力都在产品、融资、客户和交付上，很少有人一开始就把代码、模型、数据、插件、知识库、提示词库、客户资料的归属逐项写清楚。创业早期这样做可以理解。问题在于，AI公司的资产不是到了融资、签大客户或者并购退出时才开始形成，而是在第一行代码、第一批数据、第一版模型、第一份客户材料进入系统时就已经开始形成。早期没有说清楚，后面并不会自然变清楚。等到融资尽调、客户合规审查或者并购谈判时，问题会集中爆发：代码是不是公司的，模型是不是公司的，训练数据能不能合法使用，员工和外包人员有没有签署成果归属文件，开源模型和第三方API是否允许商用，客户项目中沉淀下来的能力能不能用于其他客户。这些问题一旦被投资人、客户或买方问出来，往往不是临时补一份承诺就能解决。更现实的是，有些问题拖到后期已经补不回来。例如，公司早期核心代码由兼职人员写成，但没有约定著作权归属；模型微调大量使用客户资料，但合同没有约定可用于训练；底层模型依赖某个第三方API，但供应商条款限制转售和再训练；核心算法人员离职后主张部分成果属于个人项目。这些都会直接影响融资估值、客户信任和并购交割。（二）AI企业不能只按普通软件公司看资产
普通软件公司当然也要看代码权属、员工成果、外包开发、开源组件和软件著作权。但AI企业的资产边界更复杂。普通软件公司重点看“代码是不是自己写的”。AI企业除了代码，还要看模型、训练数据、参数、权重、提示词库、知识库、评测数据、插件、工作流、API调用链和客户场景沉淀。很多时候，AI产品的价值不是某个单独软件模块，而是一套持续运行能力。普通软件公司担心代码侵权。AI企业还要担心训练出来的能力能不能合法商用。即使代码是公司写的，如果训练数据没有授权，模型来源说不清，开源模型许可不允许商用，客户知识库不能复用，产品仍然存在根基不稳的问题。普通软件公司交割的通常是软件、客户合同和技术团队。AI企业交割的则是一套动态系统：模型能不能部署，数据能不能继续用，算力环境能不能延续，核心工程团队是否留下，供应商许可是否有效，客户系统是否允许继续接入。任何一环断掉，交易价值都会受到影响。因此，AI企业刚起步时，法务和创始团队最该先拆清六类资产：代码归属，模型归属，数据归属，开源和第三方依赖，员工、外包、合作方成果，客户数据和业务场景沉淀。只有先把这些底层资产说清楚，后面的融资、交付、出海和并购才有基础。二、代码能跑，不代表代码当然属于公司
（一）早期“混写代码”很常见，但后期一定会被追问
创始人在公司设立前已经写了一部分代码。技术合伙人用个人电脑、个人Git仓库开发。兼职人员、实习生、外包团队参与了部分模块。朋友帮忙写过插件、脚本、爬虫、接口。部分代码来自开源项目，部分代码来自创始人过去项目中的复用内容。这些情况在创业早期看起来都很自然。大家先把Demo跑起来，先把客户演示做出来，先把产品交付出去。但从法律上看，代码能跑，不等于权利清楚；公司能使用，不等于公司拥有完整处分权。融资尽调时，投资人通常会追问：核心代码是谁写的，什么时候写的，是否在公司成立前形成，是否有个人仓库记录，是否存在前单位职务成果，是否有外包参与，外包是否转让著作权，是否存在开源协议限制。并购时，买方会问得更细，因为买方最终买的不是“能跑的系统”，而是可交割、可处分、可继续商业化的资产。（二）公司成立前形成的代码，要有明确转入安排
如果创始人在设立公司之前已经写了一部分核心代码，后续将其带入公司使用，应当通过书面文件明确转让或许可给公司。文件里至少要写清：代码范围、形成时间、是否为创始人独立完成、是否使用原单位资源、是否存在第三方权利、是否允许公司复制、修改、商业化、再许可、转让。如果创始人曾在原单位从事相近业务，还要特别审查是否涉及原单位职务成果、保密义务、竞业限制或知识产权争议。很多AI创业项目的技术路线和创始人过去经历高度相关，这本身不违法，但必须提前划清边界。不能等投资人或买方问到时，才临时解释“这些都是我自己写的”。如果没有书面确认，后续融资或并购时通常会被要求补签。补签并不一定不能解决问题，但越晚补，解释成本越高；如果中间已经有员工离职、股东矛盾、前单位争议或外部客户交付，补文件的效果会明显下降。（三）员工写的代码，也要把职务成果边界讲清楚
员工在职期间为完成本职工作写的代码，通常更容易归入公司成果。但对AI企业来说，仍然建议通过劳动合同、保密协议、知识产权归属协议把规则写清楚。原因在于，AI研发人员常常同时维护个人开源仓库、个人插件、模型工具、训练脚本或副项目。有些代码是在公司项目里写的，有些是在个人时间写的，有些是个人工具后来被引入公司项目。边界如果不清，后续很容易出现争议。公司应当明确：员工在履职过程中形成的代码、模型、算法、文档、数据处理方案、提示词库、工作流、插件、测试工具等成果归公司所有；员工个人项目如与公司业务相同或相近，应当事先披露；使用公司设备、账号、数据、算力、客户资料或业务需求形成的成果，不得被员工主张为个人成果。这不是不信任研发人员，而是避免双方以后说不清。对员工来说，边界清楚也有好处。哪些属于个人开源项目，哪些属于公司项目，提前说清楚，比等到离职或融资时争执更稳。（四）外包开发不能只写“完成系统开发”
外包开发是AI创业公司早期常见做法。企业最容易有一个误区：钱付了，代码就归我。这个判断不一定成立。外包开发合同如果只写“完成系统开发”“交付软件系统”“按需求完成模块”，未必意味着企业拿到了完整著作权和后续处分权。企业可能只是取得使用权，甚至只是取得某个项目范围内的交付物使用权。外包开发协议至少要写清六件事：源代码是否交付，著作权是否转让，是否允许企业二次开发和商业化，是否包含开源组件，外包方是否可以复用底层框架，是否排除第三方权利。如果外包方使用了自己的通用框架，也要明确哪些是外包方保留的通用能力，哪些是专门为企业开发并归企业所有的成果。对AI企业尤其要注意，外包方可能不仅写代码，还可能参与爬虫、数据清洗、模型微调、插件开发、提示词工程、Agent工作流搭建。这些都不应只归入“软件开发”四个字里，而要按成果类型逐项写清。三、模型能力不能一句“自研”带过
（一）“自己的模型”这个说法，最容易说得太满
很多AI团队对外介绍时会说“这是我们自己的模型”。这句话在商业表达上很常见，但从法律和尽调角度看，必须继续追问：所谓“自己的”，到底是哪一层是自己的？有的模型是底层架构自研，训练代码自研，训练数据自有或合法授权。有的是基于开源大模型微调。有的是基于第三方API包装成产品。有的是基于客户知识库做RAG。有的是基于外部模型输出做蒸馏。有的是多个模型、插件和工作流编排起来形成的Agent能力。这些路径在产品展示中都可能被称为“模型能力”，但对应的权属和合规风险完全不同。不能统一包装成“自研模型”。（二）自研、微调、蒸馏、API调用，要分开审查
1、自研模型
自研模型要看底层架构、训练代码、数据来源、算力环境和团队贡献。所谓自研，不应只看最终模型名称，而要看训练过程是否由公司控制，权重是否由公司持有，训练脚本是否完整，数据来源是否合规，核心团队成果是否归属公司。2、开源模型微调
基于开源模型微调，要看开源协议是否允许商用，是否要求署名，是否限制特定用途，是否要求开放衍生成果，是否限制模型输出用于再训练。如果企业把开源模型微调后包装成完全自研模型，后续一旦被投资人、客户或买方追问，解释成本会很高。3、第三方API调用
如果产品核心能力来自第三方API，就要看供应商条款是否允许转售、嵌入客户产品、保存输出、再训练、批量调用以及用于高风险场景。企业拥有一个产品界面，不等于拥有底层模型能力。如果供应商涨价、限流、停服或禁止某类使用，企业产品可能立即受影响。4、模型蒸馏
模型蒸馏要看训练来源、教师模型许可、输出结果可否用于再训练、是否违反第三方服务条款。技术上能蒸馏，不等于合同上允许蒸馏。蒸馏效果越接近原模型能力，越要说明来源和授权边界。5、RAG和Agent编排
RAG和Agent编排要看知识库、插件、工作流、工具调用链是否属于公司可交割资产。很多企业真正的壁垒不是底层模型，而是行业知识库、工作流编排、工具调用能力和客户场景经验。它们能不能复用、能不能交割、能不能用于其他客户，必须提前说清。（三）权重、脚本、数据和推理服务要拆开看
公司拥有模型服务，不等于拥有模型权重。如果只是调用第三方API，企业可能没有底层模型资产。融资时这会影响估值逻辑，并购时这会影响交割范围。公司拥有训练脚本，不等于拥有训练数据。训练脚本可以是公司写的，但如果数据授权不足，模型后续商用仍然会受到影响。公司拥有推理接口，不等于可以迁移部署。如果模型运行依赖特定云厂商、特定GPU环境、特定第三方模型、特定私有接口，后续交割、出海或并购都会受影响。投资人和买方会追问模型到底独立到什么程度。如果公司只是把多个第三方API包装成产品，估值逻辑就和真正拥有核心模型能力不同。如果核心能力依赖单一供应商，投资人会关心涨价、停服、限流、模型下线、服务条款变化等风险。如果模型来源说不清，后续商用、客户交付和并购退出都会存在隐患。四、数据拿得到，不等于能训练、能商用、能交割
（一）早期为了跑Demo而“先把数据找来”，最容易埋雷
AI企业早期有很强的数据冲动。为了把Demo跑出来，团队经常会先找公开网页、行业报告、客户文档、历史项目资料、用户问答记录、内部员工经验、外部数据集。这个动作在业务上很自然，但法律上风险很高。数据拿得到，不代表可以训练；可以内部测试，不代表可以商用；可以用于一个客户项目，不代表可以沉淀成通用模型能力；可以保存在系统里，不代表可以出境、共享或交割。数据问题的麻烦在于，它通常不是一开始就爆发。早期Demo跑通了，客户觉得效果不错，融资材料也很好看。但等到尽调时，投资人会问数据来源、授权范围、使用目的、个人信息处理、客户数据复用、第三方版权内容、数据出境风险。那个时候再回头整理，往往已经说不清。（二）公开可见，不等于可以训练
很多AI企业会把“公开可见”误认为“可以训练”。这个误区非常常见。公开可见只说明数据能够访问，不当然说明可以复制、加工、训练、商用。网页、文章、图片、音频、视频、数据库、论坛内容背后可能涉及著作权、数据库权益、平台规则、用户协议、个人信息和反爬限制。融资或并购时，投资人不会只问“数据从哪里来”，还会问“你凭什么可以长期使用”。如果企业回答只是“网上公开的”，这个答案通常不够。企业至少要说明数据抓取方式、来源网站规则、是否包含个人信息、是否有版权内容、是否经过授权、是否仅用于测试还是用于商业模型训练。（三）客户数据不能自然沉淀为公司资产
很多AI企业会在客户项目中接触客户资料、业务流程、行业知识库、历史问答、合同文档、客服记录、产品手册、内部制度。企业为了提高交付效果，会用这些资料调模型、搭知识库、优化提示词、设计Agent工作流。交付完成后，团队自然会想把这些能力沉淀为通用产品，用于其他客户。这里必须区分五件事：为该客户项目使用，用于模型优化，用于其他客户，用于通用产品，用于商业化训练。这五件事不是一回事。客户提供资料用于项目交付，不等于授权AI企业拿去训练通用模型。客户没有明确反对，也不等于公司可以默认复用。客户通常关心两点：客户资料不能被拿去服务竞争对手，客户业务经验不能被通用化后反向提供给同行。AI企业则希望项目经验能够沉淀，通用能力能够复用。两边诉求并不天然一致，所以必须在合同里写清。（四）数据归属和数据使用权不是一个问题
有些数据不属于公司，但公司可能有有限使用权。有些数据来源合法，但用途受限制。有些数据可以用于内部测试，但不能用于商业化模型训练。有些数据可以留存，但不能出境、不能共享、不能交割。有些数据可以用于特定客户项目，但不能用于其他客户。AI企业必须建立数据使用台账。台账至少要记录数据来源、数据类型、是否含个人信息、是否含客户资料、是否含第三方版权内容、授权范围、可否训练、可否商用、可否出境、可否用于其他客户、保留期限和删除要求。没有台账，企业后续很难证明数据来源和用途合规。尤其在融资、并购和大客户采购中，数据台账不是加分项，而是基本功。五、开源模型和开源代码不是免费资产
（一）开源能降低研发成本，但不能消除法律边界
AI创业公司早期大量使用开源组件非常正常。开源代码、开源模型、开源数据集可以大幅降低研发成本，加快产品验证。但开源不是无主资源，也不是免费资产。真正要看的，是协议。开源协议要回答的问题包括：能不能商用，要不要署名，能不能闭源，能不能修改，能不能再分发，有没有用途限制，有没有披露源代码义务，有没有限制模型输出再训练。如果企业只知道用了某个开源项目，却不知道它的协议类型、版本、修改情况和使用位置，后面融资和并购时会非常被动。（二）开源协议不查清，会直接影响融资和并购
投资人或买方通常会要求企业提供开源软件清单，包括名称、版本、协议、使用位置、是否修改、是否分发、是否进入商业产品。如果存在强传染性协议或用途限制，可能影响产品闭源商业化。如果企业没有开源合规记录，后续补查成本很高。尤其是核心代码已经与开源组件深度融合时，想要拆分或替换并不容易。开源合规不是要求企业不用开源，而是要求企业知道自己用了什么、怎么用、有什么义务、是否影响商业化。（三）开源模型还要额外看模型许可
有的模型限制规模化商用，有的限制特定用途，有的要求保留署名和声明，有的限制使用模型输出训练竞争模型，有的对服务提供、再分发、微调模型发布作出约束。AI企业如果基于开源模型微调后，对外包装成“自研模型”，后续很容易被追问：底层模型是什么，许可条件是什么，是否满足署名或披露义务，是否允许商用，是否允许再分发，是否允许用于当前客户场景。六、高校、科研机构、顾问和合作方贡献，不能靠口头默契处理
（一）AI创业早期经常带有半科研、半商业特征
很多AI创业公司来自高校、科研机构或大厂实验室。常见情况包括：创始人来自高校或科研机构；导师、实验室、同学参与早期技术讨论；使用过学校服务器、实验室数据或科研成果；顾问参与模型设计或技术路线判断；合作方提供行业数据和业务场景。这些在早期很容易被忽视。大家可能觉得只是帮忙讨论、借用资源、合作验证、共同探索。但到了融资、客户审查或并购阶段，这些都可能变成成果权属问题。（二）高校和科研背景要特别谨慎
如果技术成果形成于原单位工作期间，要判断是否属于职务成果。如果使用原单位设备、经费、数据、项目资源，要判断原单位是否享有权利。如果论文、专利、模型代码和商业产品之间存在延续关系，要提前做权属切割。不要等融资尽调时才解释。那时解释成本会非常高。投资人通常不会只听创始人口头说明，而会要求看职务成果界定、成果转让文件、单位放弃权利证明、技术许可文件或其他书面材料。（三）顾问和合作方贡献也要文件化
顾问提供的是一般建议，还是参与核心技术方案？合作方提供的是场景验证，还是提供训练数据？行业专家贡献的是业务规则，还是可固化为模型能力的知识库？这些差别很重要。一般建议通常风险较低，但如果顾问参与核心模型设计、算法路线、行业知识库构建，或者合作方提供了关键训练数据和业务规则，就必须通过合同写清成果归属、使用范围、保密义务、收益分配和后续复用规则。不写清楚，后续可能产生权利主张、使用限制或收益分配争议。七、客户项目中沉淀出的能力，最容易说不清
（一）AI企业在客户项目中经常形成新能力
AI企业做客户项目时，往往会形成一些新的能力。例如，根据客户资料搭建行业知识库，根据客户业务流程优化Agent工作流，根据客户反馈改进模型输出，根据客户场景形成新的提示词模板，根据客户数据训练分类器或评测体系。这些能力对AI企业很有价值。问题是，它们后续能不能复用，必须看客户合同怎么写。如果客户合同没有区分客户专有成果和AI企业通用能力，双方后续很容易产生争议。客户可能认为，所有基于其资料、流程、场景形成的成果都应属于客户或至少不得用于竞争对手。AI企业则可能认为，底层模型、通用工具、通用方法和项目经验应当可以沉淀复用。（二）最稳妥的做法，是把成果分成三类
1、客户专有成果
基于客户专有数据、流程、制度、文档、业务规则形成的成果，原则上只能用于该客户。尤其是客户资料、客户流程、客户内部知识库、客户业务经验，不应未经允许用于服务竞争对手。2、AI企业通用能力
底层模型、通用代码、通用工具、通用框架、通用工作流能力，仍应归AI企业所有。否则AI企业每做一个客户项目，都会被客户锁住一部分底层能力，商业模式很难持续。3、项目改进成果
介于两者之间的项目改进成果，应在合同中明确是否可复用、是否需要脱敏、是否限制行业范围、是否限制服务竞争对手、是否需要客户同意。不做区分，后续最容易发生争议。客户担心自己的经验被通用化，AI企业担心自己的能力被客户锁死。合同越早讲清，后续越容易合作。八、AI企业刚成立时，至少先拉四张清单
（一）代码和软件资产清单
企业至少要记录：每个模块是谁写的，是否在公司成立前形成，是否使用开源代码，是否有外包参与，是否有第三方授权限制，是否已经进入公司仓库并完成权属确认。这张表解决的是“产品代码到底是不是公司的”。没有这张表，后续很难证明核心代码归属。（二）模型和技术路径清单
企业要记录：自研、微调、蒸馏、API调用、RAG、Agent编排分别占比多少；底层模型来自哪里；训练脚本和权重是否由公司控制；供应商条款是否允许商用；是否依赖单一第三方模型或云平台。这张表解决的是“模型能力到底独立到什么程度”。融资和并购时，这会直接影响估值。（三）数据来源和使用范围清单
企业要记录：数据从哪里来，是否包含个人信息，是否包含客户资料，是否包含第三方版权内容，能不能训练，能不能商用，能不能出境，能不能用于其他客户。这张表解决的是“数据凭什么能用”。AI企业没有数据台账，后续商业化和客户交付都会不稳。（四）人员和合作方贡献清单
企业要记录：创始人贡献、员工贡献、外包贡献、顾问贡献、高校或科研机构贡献、客户或合作方贡献，以及是否签署知识产权归属和保密文件。这张表解决的是“成果是谁贡献的、权利归谁”。AI企业早期关系复杂，越早记录越省事。九、AI企业最早该补的，不是复杂制度，而是几份基础文件
（一）创始人协议或股东协议
创始人协议不能只写股权比例，还要写技术投入、数据资源、知识产权归属、退出机制和竞业限制。如果某个创始人贡献了成立前代码、算法方案、客户资源或数据资源，应当明确这些资源如何进入公司，是否转让，是否许可，退出后如何处理。否则，创始人一旦发生矛盾，公司核心资产很容易被撕裂。（二）知识产权归属协议
知识产权归属协议要覆盖代码、模型、算法、技术文档、数据处理方案、提示词库、工作流、插件、评测体系等，不要只写“软件著作权归公司”。AI企业的资产形态很多，不能只用传统软件著作权条款覆盖。模型文件、训练脚本、提示词库、Agent工作流、数据处理流程都应纳入成果归属范围。（三）员工保密与成果归属协议
研发人员、产品人员、数据标注人员、算法工程师都要覆盖。协议中应明确职务成果、个人项目、离职交接、保密义务、竞业限制和开源贡献规则。尤其要处理个人项目和公司项目边界。员工可不可以继续维护个人开源工具，能不能把公司代码用于个人项目，能不能把个人插件引入公司系统，都应有规则。（四）外包开发协议
外包开发协议要明确源代码交付、著作权归属、第三方组件、开源披露、保密义务、成果验收和违约责任。如果外包方参与模型训练、数据清洗、爬虫、插件开发、工作流搭建，也要明确这些成果的归属和使用范围，不能只写“完成开发服务”。（五）数据来源与使用台账
数据来源与使用台账不是合同，但非常重要。以后融资、客户交付、并购时都要用。台账要持续更新，而不是临时补。很多数据风险不是因为企业恶意使用，而是因为时间长了以后没人记得数据从哪里来、谁授权、能不能商用。（六）客户数据使用条款
如果已经开始做客户项目，要尽早写清客户数据是否可用于训练、优化、沉淀和复用。这类条款不能写得太粗。至少要区分客户专有数据、项目交付成果、AI企业通用能力、脱敏后的改进成果。否则，AI企业后续想复用能力，客户可能认为侵犯其数据和商业秘密；客户想锁定成果，AI企业可能认为自己的通用能力被限制。十、AI创业公司越早讲清资产归属，后面越容易融资、签客户和谈并购
（一）先问公司到底拥有什么，再问公司值多少钱
AI创业公司刚成立时，真正该先问的不是“公司值多少钱”，而是“公司到底拥有什么”。企业早期可以没有完整法务体系，但不能没有核心资产意识。资产归属一开始混着用、混着训、混着交付，后面一定会在融资、客户审查和并购时集中暴露。（二）越早补文件，成本越低
早期补文件，成本最低。大家关系还简单，项目边界还清楚，贡献人员还在，数据来源还能回忆。融资前补文件，成本变高。投资人会提出要求，创始人和员工可能重新谈条件，历史问题需要解释。并购时补文件，往往已经影响估值和付款安排。买方可能要求价格扣减、专项赔偿、分期付款、托管价款或延迟交割。出了争议再补，很多时候已经补不回来。权属争议、客户数据争议、开源合规问题、第三方许可限制，一旦进入纠纷阶段，补文件的效果会非常有限。（三）这也是AI企业法律风险地图第一篇要讲“归属”的原因
AI企业法律风险地图的第一站，不是监管审批，也不是融资条款，而是资产到底是不是你的。只有先回答这个问题，后面的融资、交付、出海、并购才有基础。否则，企业看起来像是拥有一个AI产品，实际上可能只是临时拼接了代码、第三方模型、客户数据、开源工具和个人贡献。十一、AI企业的地基，不是产品演示，而是资产归属
初创企业不可能一开始什么都完美。早期产品在试错，团队在变化，客户在验证，法务体系也不可能一步到位。真正危险的，不是早期没有一套厚厚的制度，而是核心资产一路混着用、混着训、混着交付，最后没人说得清谁有权继续使用。代码是谁写的，模型从哪里来，数据凭什么用，开源协议是否允许，客户资料能否沉淀，员工和外包成果归谁，这些问题都不是形式问题，而是AI企业的资产地基。地基不清，产品跑得越快，后面的风险越大。企业越早把模型、代码和数据的归属讲清楚，越容易融资，越容易签大客户，也越容易在未来并购退出时把价值真正交割出去。第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。也欢迎您转发、转载本文，让更多有需要的朋友及时看到。
夜雨聆风