AI企业法律风险地图(四):员工、外包和顾问写出来的代码,怎样才能归公司?一、AI企业真正要防的，不只是产品能不能跑起来
AI企业早期最容易形成一种错觉：只要代码在公司仓库里，产品在公司服务器上，客户也是以公司名义签的合同，那么这套系统当然就是公司的。这个判断在商业沟通中没有问题，但在法律审查、融资尽调、客户采购、并购交易和争议处理中，往往不够。AI企业最怕的不是没人写代码，而是代码、模型、插件、知识库、Agent工作流、评测集、提示词体系都做出来以后，公司说不清这些东西到底是不是自己的。（一）AI产品通常不是一个人、一个合同、一个仓库做出来的
创始人先写一版Demo，员工补核心模块，兼职开发接接口，外包团队做前端和后台，顾问给算法路线和行业规则，实习生做数据清洗和标注。产品跑起来以后，团队内部通常会默认“这是公司的产品”。真正判断成果是否稳定归属于公司，要看合同怎么写、岗位职责怎么约定、代码和模型怎么形成、交付文件是否完整、付款和验收是否闭环、相关人员是否已经确认权属。如果这些文件和记录缺失，问题不会在产品测试阶段暴露，往往会在关键节点集中出现。客户私有化部署时，客户会追问源代码、模型、接口、插件和第三方组件是否存在权利瑕疵。并购时，买方会要求公司说明核心资产形成过程、权利链条和第三方限制。员工离职、外包撤场、顾问合作终止时，对方也可能反过来主张自己对部分代码、算法方案、插件工具或知识库结构享有权利。AI企业一旦说不清楚，产品不是不能用，而是会从“公司资产”变成“带瑕疵的资产”。（二）AI成果归属比普通软件项目更复杂
普通软件公司做权属审查，重点通常是源代码、软件著作权、开发合同、员工职务成果、外包交付和开源合规。除源代码外，还要审模型权重、训练脚本、微调数据、提示词库、知识库结构、评测数据、Agent工作流、插件、部署环境、API配置、数据处理规则、行业业务逻辑和客户场景沉淀。普通软件成果相对容易界定：某个系统、某段代码、某个模块、某个版本。AI成果则经常混合代码、数据、算法路线、模型参数、业务规则、专家经验和客户场景。比如，一个企业智能客服系统，看起来是一个软件产品，但里面可能同时包含：底层大模型调用、客户文档知识库、问题分类标签、Prompt模板、RAG检索规则、质检评测集、客服业务流程、接口插件、部署脚本和日志分析工具。如果企业只用普通“软件开发协议”处理AI项目，很容易漏掉模型、数据、知识库、提示词、评测集和衍生成果。结果就是合同里写了“软件系统归甲方所有”，但真正产生商业价值的那部分能力，并没有被清楚纳入权属范围。（三）员工、外包和顾问参与开发时，要把核心成果稳定归集到公司
AI企业要解决的核心问题，不是把所有参与人员的成果都简单写成“公司所有”，而是把不同类型人员的贡献方式、交付内容、权利边界和证据链分别处理清楚。员工成果怎么约定，外包成果怎么交付，顾问成果怎么确认，兼职和实习人员怎么管理，离职和撤场时怎么交接，融资和并购时怎么拿出证据，这些问题必须在项目形成过程中同步解决。等产品已经上线、客户已经签约、融资已经启动、关键人员已经离职，再回头补文件，主动权通常已经不在公司手里。二、员工写的代码，也不能只靠“职务成果”兜底
很多企业认为，员工在公司上班，拿公司工资，写出来的代码当然归公司。这个判断有一定基础，但不能替代完整的合同和证据安排。在我国现行规则框架下，员工在履行本职工作任务、主要利用单位物质技术条件完成的成果，通常更容易被认定与单位存在紧密权属关系。对于计算机软件、技术成果、专利申请权、商业秘密等，不同法律规则下的判断口径并不完全相同，不能简单用一句“上班期间写的都归公司”概括。（一）员工职务成果更容易归公司，但文件不能缺位
如果员工在本职工作范围内，利用公司设备、数据、服务器、研发平台、代码仓库和项目资源完成研发成果，通常更容易认定为公司成果。员工可能使用个人电脑、个人GitHub仓库、个人开源项目、入职前已经形成的代码片段或模型工具，也可能在公司项目中复用自己过去写过的框架、脚本或插件。这时，如果公司只有劳动合同，没有保密协议、知识产权归属协议、个人项目披露文件、研发记录和离职交接清单，后续就可能发生争议。员工可能主张：某段代码是入职前完成的；某个工具是个人开源项目；某个Prompt框架是个人经验沉淀；某个插件只是授权公司使用，并未转让权利。公司则可能主张：这些内容已经进入公司核心系统，使用了公司资源，服务于公司产品，应当归公司或至少由公司享有完整使用权。双方争议的关键，往往不在于谁说得更合理，而在于合同和证据是否足够清楚。所以，AI企业至少应在劳动合同、保密协议、知识产权归属协议中明确：员工在任职期间因履行工作职责、接受公司任务、使用公司资源、参与公司项目形成的成果，其相关权益归属于公司或由公司依法享有；员工应配合公司办理权属登记、申请、备案、交付和确认手续；员工不得将公司成果擅自复制、留存、上传、开源、转让或提供给第三方。（二）员工成果归属不能只写“软件著作权归公司”
AI企业的员工成果归属文件，如果只写“软件著作权归公司”，覆盖范围明显不足。应当把成果类型写得更完整，至少包括：源代码、算法代码、模型训练脚本、模型权重和参数、提示词库、评测集、数据清洗脚本、知识库结构、Agent工作流、插件和工具链、部署文档、技术方案、产品文档、接口文档、测试报告、模型评估记录、业务规则整理文件等。原因很简单：AI产品的价值不一定都体现在“软件著作权”上。一个模型微调项目中，训练脚本、参数配置、评测集、数据处理流程、Prompt体系和部署方案，可能比界面代码更重要。一个行业Agent项目中，Agent工作流、工具调用规则、业务判断逻辑和知识库结构，可能是产品真正可复制的能力。一个企业知识库项目中，文档切分规则、标签体系、检索排序策略和问答评测方法，可能是后续服务客户的核心资产。如果合同只写“软件系统归公司”，一旦发生争议，对方可能主张模型文件、数据处理规则、提示词、业务规则、评测集不属于传统软件范围，未被明确转让或确认。这类争议不一定导致公司败诉，但会显著增加解释成本和交易风险。（三）员工个人项目和公司项目必须切开
AI研发人员维护个人GitHub项目、参与开源社区、私下做模型工具、用历史代码解决公司问题，都很常见。这种过度约定既可能引发劳动争议，也可能在执行中缺乏合理性。员工入职前已经形成的个人项目、与公司业务无关且未使用公司资源完成的个人成果，不宜被公司简单纳入权属范围。如果员工把个人项目直接嵌入公司核心产品，或用公司项目继续完善个人工具，边界就会变得非常模糊。后续员工离职时，公司可能发现核心模块依赖员工个人仓库；客户要求交付源代码时，公司无法确认是否有完整权利；投资人尽调时，公司无法解释个人开源项目和公司商业产品之间的关系。稳妥做法是建立“既有项目披露+公司项目确认+使用审批”的机制。员工入职时，应披露其既有个人项目、开源项目、历史代码库、可能与公司业务相关的工具或模型。公司项目启动时，应明确项目范围、参与人员、研发任务、仓库地址、成果类型和归属规则。员工拟将个人历史代码、个人工具或第三方开源项目用于公司项目时，应当提前披露并经公司确认，明确公司取得何种使用权、是否可商用、是否可二次开发、是否可交付客户、是否存在开源许可证限制。使用公司资源、公司数据、公司客户需求形成的成果，应明确归公司所有或由公司享有完整商业使用权。这一套机制不是为了限制员工正常技术积累，而是为了避免个人项目和公司产品混成一团。（四）员工离职时，不能只交电脑和账号
如果只收回电脑、工牌、邮箱和办公账号，技术资产可能已经断档。对于核心研发、算法、数据、产品和交付人员，离职交接至少应覆盖：代码仓库权限、分支和未合并代码、模型训练记录、训练脚本、模型文件、参数配置、部署文档、API密钥和配置说明、数据处理脚本、未提交代码、本地模型文件、客户项目资料、实验记录、评测结果、接口文档、第三方组件清单、开源使用说明、项目未决问题清单。第一，员工是否已将工作成果完整提交至公司指定仓库或系统。第二，员工是否仍在个人设备、个人网盘、个人邮箱、个人仓库中留存公司代码、模型、数据、客户资料或技术文档。第三，员工是否确认离职后继续承担保密义务、竞业或不招揽义务、资料返还义务、配合权属登记义务。不少模型文件、测试数据、训练脚本、临时插件、客户部署配置，可能长期存在于员工个人电脑或个人云盘中。如果离职时没有清点，后续即使发现问题，也很难完整追溯。三、外包开发不是“付了钱，成果就一定归我”
原因也很现实：内部团队要做模型和核心逻辑，前端界面、后台系统、爬虫工具、标注平台、小程序、APP、私有化部署工具、插件接口，往往会交给外包团队。（一）外包项目真正要看合同，而不是看付款事实
很多企业的直觉是：我付了钱，对方交了代码，系统也上线了，成果当然归我。外包开发真正要看合同约定和交付事实。合同是否明确著作权转让，源代码是否交付，企业是否可以二次开发，外包方能否复用底层框架，第三方组件责任由谁承担，开源代码是否合规，模型和数据相关文件是否纳入交付范围，这些问题都会影响成果归属和后续商业使用。在实务中，很多外包合同只写“完成某某系统开发”，没有写清楚权利转让，也没有写清楚源代码、部署文档、测试报告、数据库结构、接口文档和第三方组件清单的交付。但等企业要独立维护、迁移部署、交付客户、进行融资尽调或替换供应商时，问题就会集中暴露。外包方可能说：我只是交付可运行系统，没有转让全部源代码。也可能说：底层框架是我的通用框架，我可以继续给其他客户使用。还可能说：你只能在本项目内部使用，不能复制、二次开发、再许可或用于其他客户。如果合同没有提前写清楚，公司很难仅凭付款事实取得完整权利。（二）外包开发协议至少要写清六件事
不能只写“交付系统”或“完成开发”。应当列明源代码、可执行文件、前后端代码、数据库结构、接口文档、部署文档、测试报告、运维手册、配置文件、模型相关文件、训练脚本、插件文件、第三方组件清单、开源使用清单、账号权限、验收材料等是否全部交付。应明确为本项目定制开发形成的著作权、专利申请权、技术秘密、商业秘密、衍生成果、文档成果、接口成果、插件成果等归公司所有，或由公司享有永久、不可撤销、可复制、可修改、可二次开发、可商业使用、可向客户交付的权利。应要求外包方披露是否使用开源代码、第三方SDK、第三方模型、第三方API、第三方字体、图片、数据集或工具链，并提供清单。对于可能影响商用、闭源交付、私有化部署或再许可的组件，必须提前审查。如果外包方使用其自有通用框架，可以允许其保留底层工具权利，但必须限制其复用本项目定制成果、客户数据、业务逻辑、行业方案、接口配置和非公开需求。特别是不能把为公司或客户定制开发的核心能力，原样或实质相同地提供给竞争对手。如果代码侵权、开源许可证违规、第三方SDK未经授权、模型调用条款不允许商用、数据来源不合规，合同应明确由谁承担责任。不能只写“外包方保证合法”，还要写清赔偿、下架、替换、整改、协助应诉和第三方索赔承担机制。外包方应提供部署、培训、缺陷修复、运维交接、文档说明、账号交接和必要技术支持。项目终止、合同解除或外包方撤场时，也应继续履行交接义务，不能以费用争议或合作终止为由拒绝交付已有成果。（三）AI外包尤其要盯住模型和数据
如果外包方只是做一个普通网页，权属风险主要集中在代码、素材和第三方组件。如果外包方参与模型训练，要写清训练数据来源、数据授权情况、训练脚本归属、模型权重归属、参数配置归属、模型文件交付方式、外包方是否可以保留模型副本、是否可以继续使用训练结果。如果外包方参与数据标注和清洗，要写清数据保密义务、标注成果归属、清洗脚本归属、标注规则归属、不得留存和复用客户数据、不得将数据上传至未经授权的第三方平台。如果外包方调用第三方模型API，要写清API账户归属、调用记录归属、输入输出内容的使用限制、输出结果能否商用、上游平台条款是否允许客户交付、是否允许用于训练、是否允许私有化部署或再分发。这类问题不能事后靠一句“外包方负责合法合规”解决。企业应要求外包方提供第三方模型和API使用清单，说明调用场景、账户主体、数据输入类型、输出用途、上游条款限制和风险承担方式。特别是涉及客户数据、个人信息、商业秘密、未公开技术资料的项目，不能默认外包方可以随意调用公有云模型或境外API。（四）通用底层框架和项目成果要分层处理
企业不能简单要求外包方全部转让。否则外包方通常不会接受，或者报价显著提高。更可行的做法是区分“外包方既有底层工具”和“本项目定制成果”。对于外包方在合作前已经形成的通用框架、基础组件、开发工具、通用模块，可以约定仍归外包方所有。但对于为本项目定制开发的代码、接口、页面、业务逻辑、数据结构、插件、模型配置、知识库结构、客户场景适配和交付文档，应明确归公司所有或由公司享有完整商业使用权。同时，企业必须确保自己至少取得永久、不可撤销、可二次开发、可复制、可修改、可部署、可商业使用、可向客户交付的权利。外包方复用其底层框架时，不得泄露公司数据、客户资料、业务逻辑、行业方案、部署配置和非公开需求。第一，外包方拿相似系统服务公司竞争对手，客户认为公司泄露行业方案或专属配置。第二，公司无法独立维护产品，供应商一撤场，系统就无法升级。第三，客户要求源码或私有化部署时，公司无法完整交付。四、顾问不是员工，但顾问贡献也可能进入核心资产
有的是高校老师，有的是科研机构专家，有的是行业公司资深人员，有的是前大厂技术专家，有的是法律、医疗、金融、制造等垂直领域专家。顾问不一定写代码，但他们的贡献可能进入产品核心能力。（一）顾问贡献一旦产品化，就不能只靠口头信任
顾问可能提供算法路线建议、行业规则梳理、业务知识库搭建、评测标准设计、数据标注规则、提示词体系、产品方案、场景判断逻辑。这些内容在会议纪要里可能只是几段讨论，在产品系统里却可能变成分类标签、知识库结构、诊断逻辑、Agent决策规则、模型评测标准或行业解决方案。如果顾问贡献只是一般性讨论，通常不一定产生可独占的成果。但如果顾问已经交付具体方案、文档、规则库、流程图、评测集、Prompt模板、知识库结构，且这些内容进入产品核心能力，就必须有书面确认。否则后续顾问可能主张：该部分内容来自其专业经验，公司只能在特定项目使用；公司不能继续商用；公司不能用于其他客户；公司不得改写、训练或复制；公司应支付额外报酬或保留署名。这类主张未必当然成立，但会给公司融资、客户交付和商业复制带来不确定性。（二）顾问协议不能只写“提供咨询服务”
应明确顾问到底提供什么：一般建议、具体技术方案、可交付文档、知识库结构、业务规则、评测集、算法改进方案、数据标注规范、Prompt体系、产品设计方案，还是行业标准操作流程。具体交付成果可以约定归公司所有，或由公司享有永久、不可撤销、可复制、可修改、可商用、可用于客户项目的权利。涉及顾问既有知识、通用经验、专业方法论的，可以约定公司在产品和项目范围内享有使用权，同时明确顾问仍可保留其一般知识、经验和方法。因为顾问的专业经验不可能被公司整体买断，但顾问为公司项目形成的具体交付成果，必须能够被公司持续使用。（三）专家经验进入AI系统时，不能只当普通咨询处理
在传统咨询项目中，顾问给建议、出报告，企业内部参考即可。但在AI产品中，顾问经验可能被结构化、数据化、流程化，直接进入系统能力。比如医疗顾问提供的问诊路径，金融顾问提供的风险分类规则，法律顾问提供的审查清单，制造专家提供的设备故障判断逻辑，教育顾问提供的题目标签体系。这些内容如果被整理成行业规则库、诊断逻辑、问答知识库、分类标签体系、标准操作流程、Agent决策规则，就已经不只是“咨询意见”，而可能成为产品核心能力。企业必须提前明确：公司是否可以长期使用，是否可以商用，是否可以用于其他客户，是否可以继续训练、改写、抽象、迭代，是否可以与模型、知识库、插件、工作流结合，是否可以对外演示和交付。尤其是医疗、金融、法律、教育等领域顾问，还要注意专业资质、责任边界和输出误导风险。AI企业不能因为有专家参与，就对外宣称系统可以替代专业判断。顾问贡献进入系统后，仍应设置适用范围、风险提示、人工复核、专业责任边界和客户使用限制。（四）顾问所在单位的权利也要核查
顾问个人是否有权提供相关成果，不能只看顾问个人承诺。如果顾问来自高校、科研机构、医院、金融机构、互联网公司或制造企业，其与原单位、现单位之间可能存在保密义务、竞业限制、职务成果归属、科研项目成果管理、客户资料保密等限制。但如果顾问拿的是原单位内部资料、客户案例、未公开数据、项目文档、算法方案、业务规则、培训材料，公司接收并用于AI产品后，也可能被牵连。AI企业应在顾问协议中要求顾问确认：其提供的资料、方案和成果不侵犯第三方权利，不违反其对原单位或现单位的保密义务，不使用受限资料、个人信息、商业秘密或未经授权的客户数据。对于高风险行业顾问，必要时还应要求顾问提供资料来源说明，或者限定其只能提供抽象化、去标识化、非受限的专业经验。五、兼职、实习生和临时人员成果最容易被忽略
兼职算法工程师、高校学生、实习生、远程开发、短期项目人员、社区贡献者，都可能参与数据标注、模型测试、插件开发、Prompt优化、评测集整理、爬虫脚本编写。（一）越是临时人员，越要先签文件
很多企业觉得实习生、兼职人员贡献不大，所以不重视合同。一个实习生整理的评测集，可能成为模型能力评估标准。一个兼职开发写的插件，可能成为客户系统对接的关键工具。一个短期人员写的数据清洗脚本，可能决定训练数据质量。一个远程开发优化的Prompt体系，可能直接影响产品输出效果。至少要签署保密协议、成果归属确认、数据安全承诺、账号和资料返还条款。如果涉及个人信息、客户数据、商业秘密或未公开技术资料，还应设置最小必要访问权限、操作日志、下载限制、外发审批和离场清理机制。临时人员不能因为合作周期短，就绕开公司基本的权限管理和资料管理。（二）兼职人员不能既像员工一样干活，又没有任何权属安排
兼职人员的特殊之处在于：其不一定与公司建立劳动关系，工作时间、工作地点、使用设备和成果形成方式都可能更灵活。对于兼职开发、兼职算法、兼职产品、兼职数据人员，公司应在合作协议中明确具体任务、交付成果、交付时间、验收标准、权利归属、保密义务、第三方权利保证、禁止留存和复用、资料返还、违约责任。如果兼职人员使用个人设备、个人账号或个人仓库工作，公司应要求其将工作成果及时提交至公司指定系统，不得绕过公司仓库私下交付，不得把公司代码、数据、模型、客户资料留存在个人环境中。如果兼职人员同时服务其他企业，特别是竞争对手或同一行业客户，还要明确利益冲突披露和保密边界。（三）高校学生参与尤其要谨慎
但学生可能同时参与导师项目、实验室项目、科研课题、学校竞赛、公司实习项目，成果边界容易混乱。如果学生使用学校实验室资源、导师项目成果、科研经费支持形成的代码、模型、数据或论文成果，公司后续可能面临权属争议。至少应要求学生明确工作内容、工作成果、成果归属、是否使用学校资源、是否涉及导师或实验室项目、是否存在第三方权利限制。如果项目重要、成果核心、学校资源参与明显，必要时应取得相关单位确认，或者避免将存在权属不清的科研成果直接纳入商业产品。对于AI企业而言，早期节省一点合同成本，后期可能会付出融资受阻、客户无法交付、核心模块重写的代价。六、成果归属不只是“写归公司”，还要能证明归公司
在融资、并购和大客户采购中，别人不会只看一句“成果归公司所有”。（一）尽调看的是权利链条，不是单句承诺
投资人和买方通常会进一步看合同签署时间、人员身份、代码提交记录、仓库权限、交付文件、付款记录、验收记录、权利转让文件、离职交接文件、开源组件清单、第三方授权文件。如果外包方只交付了可执行文件，没有交源代码和部署文档，客户私有化部署可能无法完成。如果顾问只口头参与，没有书面确认，投资人会担心核心知识库和业务规则存在第三方权利。如果模型训练数据来源不清，客户会担心数据合规和知识产权风险。这就是为什么AI企业不能只在融资前“补合同”，而要在研发过程中建立证据链。（二）AI企业要建立成果形成证据链
代码层面，应保留Git提交记录、代码评审记录、版本发布记录、模块负责人记录、分支合并记录、缺陷修复记录。这些记录可以说明某段代码是谁写的、什么时候写的、在什么项目中写的、是否经过公司评审并纳入公司版本。模型层面，应保留训练任务记录、模型版本记录、训练脚本记录、参数配置记录、权重保存记录、模型评估记录、上线审批记录。这些记录可以说明模型如何形成、由谁训练、使用了哪些数据、使用了哪些脚本和配置、哪个版本进入生产环境。数据层面，应保留数据来源记录、授权记录、采集记录、标注记录、清洗记录、脱敏记录、使用范围说明。这些记录可以说明训练数据、测试数据、评测集、知识库内容是否具有合法来源和使用依据。项目层面，应保留需求文档、任务分配、会议纪要、交付清单、验收记录、付款凭证、变更记录、撤场交接记录。这些记录可以说明外包方、顾问、客户、兼职人员各自交付了什么，公司取得了什么权利。（三）没有证据链，权属条款会变弱
如果公司无法说明某个模块是谁写的、何时写的、依据什么合同归公司，后续尽调解释会很被动。如果公司只拿得出一个代码仓库，却拿不出任务记录、交付记录、验收记录、付款记录和权利确认文件，投资人和客户很难判断这套系统是否真正属于公司。如果公司说模型是自研的，却无法提供训练脚本、训练记录、模型版本和数据来源说明，所谓“自研”就容易被质疑。AI企业越早建立研发记录，后续越容易融资、签约大客户和推进并购。相反，产品越成熟、客户越多、估值越高，权属瑕疵的代价越大。七、客户项目中的定制开发成果，要提前分清归属
客户专属知识库、行业Prompt模板、Agent工作流、客户系统接口、数据清洗工具、行业评测集、模型微调结果，都可能在项目过程中形成。这些成果到底归客户，还是归AI企业，不能留到项目结束后再谈。（一）客户和AI企业对成果的期待并不完全一致
客户关心数据安全、行业经验保密、定制功能独占、不被用于竞争对手、系统可持续维护、供应商撤场后能否接管。AI企业则关心底层框架能否复用、通用工具能否复用、项目经验能否沉淀、行业解决方案能否复制、产品能力能否继续迭代。客户可能认为：既然我付费定制，项目中产生的一切都归我。AI企业可能认为：客户数据和专属配置归客户，但底层代码、通用框架、行业能力和抽象化经验应由我复用。（二）客户项目成果建议分为三类处理
包括客户数据、客户文档、客户业务流程、客户专属配置、客户接口信息、客户内部规则、客户专属知识库、客户特定场景下形成的非公开成果。这类成果原则上应归客户所有或由客户控制，AI企业应承担保密义务，不得擅自留存、复用、披露或用于其他客户。包括通用模型、底层代码、通用框架、通用工具、非客户专属算法、平台基础能力、通用插件、通用部署工具、已有产品模块。这类成果应明确归AI企业所有，客户取得项目范围内的使用权，而不是取得全部所有权。包括基于项目形成但可以抽象为通用能力的工具、方法、模板、评测方式、行业经验、功能优化、流程改进。这类成果最容易争议。可以约定在不包含客户数据、客户商业秘密、客户专属配置、可识别客户信息的前提下，经脱敏、去客户化、抽象化处理后，由AI企业用于产品迭代和其他客户项目。（三）不分层，最容易引发客户投诉和竞业争议
如果合同没有分层，后续AI企业把类似功能用于其他客户时，原客户可能认为其行业方案被复制。如果AI企业为了避免争议完全不复用项目经验，商业效率又会大幅下降。所以，客户项目合同的关键不是简单写“成果归客户”或“成果归乙方”，而是把客户专有成果、AI企业底层成果、可复用衍生成果分开写。对于客户特别敏感的行业规则、业务流程、数据结构和场景配置，还应约定更严格的保密、隔离和复用限制。对于AI企业必须复用的底层工具和平台能力，则应在合同中提前说明，避免客户误认为自己取得了全部底层技术。八、AI企业成果归属文件至少要覆盖的内容
AI企业要把成果归集到公司名下，不能只靠一份模板协议。不同人员、不同项目、不同成果类型，对应的文件可以不同，但核心内容应当相对完整。（一）成果范围要写全
成果范围至少应覆盖代码、模型、算法、训练脚本、提示词、知识库、评测集、插件、接口、部署文档、产品文档、行业方案。对于AI企业而言，尤其要把模型权重、参数配置、训练脚本、数据处理脚本、Prompt体系、Agent工作流、知识库结构、评测数据和部署环境写进去。这些内容未必都能简单归入传统“软件著作权”，但它们可能是产品能力的核心。（二）权利类型要写清
权利类型至少应包括著作权、专利申请权、技术秘密、商业秘密、数据处理成果使用权、模型权重和参数控制权、衍生成果使用权。如果涉及技术方案、算法改进、模型训练方法、数据处理方法，还要考虑是否涉及专利申请权或技术秘密保护。如果涉及客户资料、行业规则、知识库和标注成果，还要考虑保密义务、使用范围、复用限制和数据合规要求。（三）归属方式不能一刀切
归属方式可以分为直接归公司、转让给公司、授权公司永久使用、在特定范围内授权使用、由客户和公司分层共有或分别享有。员工职务成果、外包定制成果、顾问具体交付成果、兼职项目成果，通常可以根据具体情况约定归公司所有或转让给公司。顾问既有知识、外包方底层框架、第三方组件、开源项目，则未必能够转让，应通过授权、许可、使用范围和限制条件来处理。客户项目成果则更适合分层：客户专有成果归客户，AI企业底层成果归AI企业，去客户化后的通用衍生成果可由AI企业复用。（四）交付内容要能支撑后续维护
交付内容至少应包括源代码、可部署版本、训练脚本、模型文件、配置文件、账号权限、技术文档、第三方组件清单、开源使用清单、数据来源说明。外包和顾问项目尤其要注意：只交一个压缩包或演示版本，不等于完成交付。公司应要求交付物能够被内部团队接管、部署、维护、迭代和审查。对于私有化部署项目，还要明确部署环境、依赖组件、数据库结构、安装步骤、运维手册、故障处理方式和权限交接。（五）禁止事项要具体
禁止事项至少包括：不得留存客户数据，不得私自复用公司代码，不得向第三方披露模型和数据，不得将公司成果提交到个人开源仓库，不得绕过公司仓库私下交付，不得利用公司成果服务竞争对手。对于员工和兼职人员，还应禁止擅自复制、下载、外发、上传公司代码、模型、数据和客户资料。对于外包方，还应禁止未经许可复用项目定制成果、客户业务逻辑和非公开需求。对于顾问，还应禁止使用第三方受限资料、原单位内部资料、客户未公开信息。（六）违约责任要能落地
应明确返还资料、停止使用、删除副本、赔偿损失、协助权属登记、配合删除或下架、承担第三方索赔、继续履行保密义务和交接义务。对于可能造成重大损失的行为，可以约定违约金、损失赔偿范围、律师费和维权费用承担。对于第三方侵权、开源违规、数据来源不合规、模型API违规调用等问题，应明确责任主体、整改期限、替换方案、赔偿机制和协助处理义务。九、AI企业现在最该补的几份文件
AI企业不一定一开始就有完整合规体系，但至少要先补齐几份关键文件。（一）员工知识产权和保密协议
这份文件应覆盖职务成果、个人项目披露、公司项目范围、成果归属、保密义务、资料返还、离职交接、竞业或不招揽安排。重点不是把员工所有东西都写成公司所有，而是把公司项目形成的成果、使用公司资源形成的成果、进入公司产品的成果，清楚归集到公司名下。（二）外包开发协议
这份文件应覆盖源代码交付、交付清单、权利归属、开源组件、第三方侵权、模型和数据、外包方复用限制、维护支持和撤场交接。尤其要避免只写“开发某系统”，而不写源代码、模型文件、部署文档、第三方组件清单和权利转让。（三）顾问服务协议
这份文件应覆盖顾问服务内容、具体交付成果、成果归属、既有知识使用边界、第三方权利保证、保密义务、专业责任边界。对于行业专家参与AI产品建设的项目，还要明确专家经验被结构化为知识库、规则库、评测集、Prompt体系后，公司是否可以长期商用和复用。（四）实习和兼职人员协议
这份文件应覆盖数据保密、成果归属、账号权限、资料返还、第三方权利保证、个人设备和个人仓库管理。临时人员参与核心项目，不应低于正式员工的保密和交付要求。（五）客户项目成果分层条款
这类条款应区分客户专有成果、AI企业底层成果和可复用衍生成果。客户数据、客户文档、客户业务流程和客户专属配置，应受到严格保护。AI企业已有底层代码、通用模型、通用工具和平台能力，应保留自身权利。基于项目形成但可抽象为通用能力的成果，可以约定脱敏、去客户化后由AI企业复用。（六）离职和撤场交接清单
这份清单应覆盖代码、模型、脚本、文档、账号、配置、数据、客户资料、实验记录、评测结果、未提交成果和本地文件。员工离职、外包撤场、顾问服务终止、兼职合作结束，都应完成交接确认。十、AI企业要形成“权属文件+交付记录+研发证据”的闭环
AI企业成果归属的核心，不是写一句“归公司所有”，而是把谁参与、谁贡献、交付了什么、权利怎么转、证据怎么留讲清楚。员工、外包、顾问、兼职、客户项目团队，每一类人的贡献都不同，归属文件也不能完全一样。外包要处理交付物、权利转让、底层框架、第三方组件。顾问要处理专业经验、具体交付、既有知识、第三方限制。兼职和实习人员要处理临时参与、数据保密、成果确认、账号返还。客户项目要处理客户专有成果、AI企业底层成果和可复用衍生成果。AI企业如果想融资、签大客户、做并购，不能只证明产品能跑，还要证明产品确实属于公司。不能只拿出代码仓库，还要拿出合同、交付、付款、验收和研发记录。只有这样，公司才不是“有产品”，而是“有可融资、可交付、可并购的资产”。十一、真正可靠的AI资产，必须经得起别人追问
AI企业早期最常见的错觉，是“东西都是我们一起做出来的，当然属于公司”。投资人、客户和买方会问得很具体：谁写的，什么时候写的，依据什么合同归公司，有没有第三方权利，有没有外包方、顾问、员工保留权利，是否使用开源代码，是否调用第三方模型，是否用了客户数据，是否存在学校、原单位或其他机构的权利限制。AI企业的合规建设，不应只盯着算法备案、数据合规和内容安全。对很多早期AI公司来说，最基础、最容易被忽略、也最影响企业价值的，恰恰是研发成果到底是不是公司的。把员工、外包、顾问、兼职、客户项目中的成果归属处理清楚，把合同、交付、付款、验收、研发记录和交接文件留完整，企业后续才有底气对投资人、客户和买方说清楚：这套AI产品不仅能跑，而且权属清楚、来源可查、风险可控、可以融资、可以交付，也可以进入下一轮更大的交易。第一时间获取AI领域合规解读、政策动态与实操指南，助您更高效地识别风险、理解规则、推动合规落地。也欢迎您转发、转载本文，让更多有需要的朋友及时看到。
夜雨聆风