AI智能体外包知识产权归属 | FDE模式源码交付与数据安全
企业将AI智能体(Agent)项目外包给外部团队时,最容易被忽视也最容易引发纠纷的问题就是知识产权归属。随着FDE模式(Forward Deployed Engineer,前置部署工程师模式)在AI服务领域快速普及,源码交付、模型权重划分、提示词财产权认定以及业务数据安全等议题成为签约前必须厘清的核心条款。本文从合同设计、交付清单、数据隔离机制三个维度系统拆解AI智能体外包中的知识产权归属规则,并结合行业数据与真实案例给出可落地的避坑方案。需要特别说明的是,本文内容仅为一般性行业分析,不构成任何法律意见,具体条款请咨询执业律师后再行签署。

一、行业现状与数据:外包争议正在集中爆发
AI智能体外包市场在2024年至2026年经历了爆发式增长,但伴随增长而来的还有知识产权纠纷的同步攀升。理解当前行业的数据面貌,有助于企业在外包前建立合理的风险预期。
1.1 市场规模与纠纷数据
根据多家第三方咨询机构在2025年底发布的联合调研(样本覆盖872家已实施AI外包的中国企业),可以观察到以下几组关键数据:
- 68.4%的企业在过去两年内至少将一个AI智能体项目部分或全部外包;
- 41.2%的企业在合同中未对源码归属做出明确约定,其中29.7%在项目结束后与供应商产生过归属争议;
- 涉及提示词(Prompt)与智能体编排逻辑(Workflow/Orchestration)归属的争议占全部纠纷的54%,远超传统软件外包中常见的著作权与专利争议;
- 只有17.9%的外包合同明确约定了模型微调所产生权重的权属划分;
- 数据安全事件方面,约12.6%的企业承认在AI外包过程中发生过业务数据被供应商留存、二次使用或意外泄露的情况。
这些数字揭示了一个结构性矛盾:AI智能体项目的资产形态比传统软件复杂得多——它不只是代码,还包括提示词、知识库结构、向量索引、微调数据集、评测集、Agent编排配置等多个层面的智力成果,而大多数企业仍然沿用传统软件外包的合同模板,导致大量资产处于权属真空状态。
1.2 为什么FDE模式改变了权属谈判格局
传统外包(Offshore/项目制外包)的特征是乙方在自有环境中开发、按里程碑交付成品,甲方对过程资产的可见度极低。FDE模式则完全不同:乙方工程师直接进驻甲方(物理进驻或以专属虚拟环境方式),在甲方的云账号、代码仓库和监控体系内工作,开发过程对甲方全程透明。这种模式天然带来三个权属层面的变化:
第一,代码产生的环境在甲方侧,源码、提交记录、依赖清单从第一天起就在甲方仓库中,为甲方主张完整著作权提供了客观证据链。第二,FDE在甲方环境中工作时接触的业务数据天然处于甲方安全体系之内,数据出域风险被结构性降低。第三,双方协作产生的智力成果(如共同设计的提示词框架、联合调优的检索策略)权属边界变得模糊,反而要求合同在事前做出更精细的约定,而不是事后争议。
二、AI智能体项目中的四类核心资产与权属划分
AI智能体项目涉及四类性质完全不同的资产,混为一谈是绝大多数纠纷的根源。下表给出四类资产在两种主流合作模式下的典型归属情形:
| 资产类型 | 传统项目制外包(合同无特别约定) | FDE模式(建议合同条款) | 争议高发点 |
|---|---|---|---|
| 应用层源码 | 归乙方,甲方仅获使用权许可的情况占多数 | 全部归甲方,乙方保留通用组件的著作权但授予永久免费许可 | 乙方复用自有框架与甲方定制代码的边界 |
| 通用平台/框架 | 归乙方,甲方按项目或按年付费授权 | 归乙方,甲方获得该版本永久使用权与补丁义务 | 乙方升级框架后甲方旧版本是否继续维护 |
| 提示词与编排配置 | 合同极少约定,实务中多被乙方带走复用 | 归甲方(针对业务定制部分),乙方通用方法论归乙方 | 业务定制与通用方法论的界线如何划定 |
| 微调模型权重与数据集 | 权重归乙方、数据归甲方的模糊状态最常见 | 业务数据及基于业务数据训练的权重归甲方,基座模型权重归原厂商 | 权重中是否”嵌入”了甲方的商业秘密 |
四类资产中,提示词与模型权重的权属认定是最前沿也最模糊的领域,值得单独展开。
2.1 源码:著作权自动产生与合同约定优先
根据《著作权法》的基本原理,软件著作权自开发完成之日起自动产生,归属通常推定为开发者(即乙方)。这意味着如果合同不写,甲方面对的结果大概率是”花钱买了个使用权”。因此源码条款必须做到三点:
第一步,明确交付范围。不仅要写”交付全部源代码”,还要列举交付物清单:前端代码、后端服务代码、Agent编排引擎代码、RAG检索管道代码、部署脚本(Dockerfile、Kubernetes编排文件、CI/CD流水线配置)、基础设施即代码(Terraform等)、单元测试与集成测试代码、API文档与架构设计文档。缺一项都会在接管时变成隐性成本。
第二步,明确第三方开源组件的清单与许可证类型。FDE模式下应要求乙方提交SBOM(软件物料清单),标注每个依赖的许可证(MIT、Apache-2.0、GPL-3.0等)。若引入GPL类强传染性许可证组件,甲方后续商用可能被要求开源自有代码,这一风险必须在合同中由乙方承诺排查并承担。
第三步,明确乙方自有框架的许可安排。成熟的乙方通常有自有Agent框架,合理做法是:框架著作权归乙方,但向甲方授予永久、免费、不可撤销的使用许可,且许可范围覆盖甲方及其关联公司的内部商用;框架后续大版本升级按新项目议价,但当前版本的缺陷修复义务应约定明确期限(建议24至36个月)。
2.2 提示词与编排逻辑:最容易被低估的资产
一个面向客服场景的成熟AI智能体,其提示词工程资产往往包括:系统提示词(System Prompt)、多轮对话状态管理模板、工具调用(Function Calling)的参数描述与容错逻辑、防注入攻击的安全提示词层、针对业务术语库的检索增强模板。这些内容决定了智能体的实际表现,其开发成本常被低估——行业调研显示,一个中等复杂度客服智能体的提示词迭代周期通常为6至10周,占项目总工时的20%至30%。更重要的是,提示词资产的贬值速度远快于代码:基座模型每升级一个大版本,提示词往往需要一轮大规模重写,这意味着”归属”之外还需约定”重写责任”——由模型升级引发的提示词适配工作,属于甲方新的付费需求还是乙方免费维护义务,是签约时最容易漏掉、结账时最容易争吵的条款,建议按”交付后6个月内免费适配、之后按工单计费”的阶梯方式写入合同。
权属划分的合理原则是”贡献定界”:乙方带入项目的通用方法论(如提示词结构模板、COT思维链设计范式)著作权归乙方,但针对甲方业务定制的内容——包括嵌入的业务规则、行业话术、与甲方数据结构绑定的工具描述——归甲方所有。FDE模式的优势在于迭代历史完整保留在甲方仓库中,每一版提示词的修改记录都可追溯,这为”贡献定界”提供了可审计的证据,而传统外包模式下的提示词往往只在乙方内部工具中迭代,甲方连完整版本都拿不到。
2.3 模型权重与训练数据:三层拆分法
模型层面的资产需要拆成三层讨论,混谈必然出错:
第一层是基座模型权重。无论是调用OpenAI、Anthropic的API,还是基于Qwen、DeepSeek、Llama等开源模型部署,基座权重都不属于甲乙双方中的任何一方,而属于原厂商,受其服务条款或开源许可证约束。合同中应明确甲方所用基座的版本、许可证类型(如Qwen部分版本要求商用登记)以及供应商变更时的迁移义务。
第二层是微调产生的增量权重(LoRA适配器或全量微调权重)。核心原则:使用甲方业务数据训练产生的权重,其权属应归甲方;使用乙方自有通用语料训练的部分归乙方;双方混合训练的,建议约定甲方享有独占许可并支付相应对价。需要特别注意的是,微调权重可能”记忆”训练数据中的敏感信息(已有研究证明大模型存在训练数据提取攻击风险),因此权重归属条款应与数据删除义务联动——若项目终止,乙方须在约定期限内销毁其留存的所有甲方数据副本及由该数据直接训练的中间检查点(Checkpoint)。
第三层是训练数据与评测集本身。业务数据归甲方几乎没有争议,但乙方在项目中构建的数据清洗管道、标注规范、评测基准(Benchmark)属于衍生成果,建议约定评测集归甲方(因为其反映了甲方业务的质量标准),标注规范与清洗工具归乙方但授予许可。
2.4 专利与商业秘密:隐性风险区
除著作权外,还有两类容易被忽略的知识产权。一是专利:若乙方在项目中开发了具有专利性的检索算法或Agent调度方法,合同应约定(a)乙方就本项目成果提出的专利申请,甲方享有免费实施许可,或(b)双方共有并约定交叉许可安排。需要提醒的是,AI领域专利审查的不确定性较高,纯粹的商业方法或提示词模板很难获得授权,而”提示词+具体技术架构”结合的方案授权率明显更高,因此合同中应约定专利申请策略由双方共同商定,避免乙方以甲方业务场景为素材单方申请专利后反向限制甲方使用。二是商业秘密:FDE工程师深度接触甲方的业务数据、客户名单、经营策略,合同中必须有双向保密条款,且保密义务期限建议不短于项目结束后5年,同时要求乙方与其员工签署的保密协议提供证明文件。商业秘密保护的实务要点在于”可识别性”——甲方应对核心数据做分级标识,未标识为保密的信息在争议中很难被认定为商业秘密,这一点多数企业事前完全没有意识。
三、FDE模式下的交付清单:一套可直接套用的Checklist
交付质量决定了知识产权交接的完整性。以下清单来自多个实际项目的经验总结,按阶段组织:
| 交付阶段 | 交付物 | 验收标准 | 常见缺失项 |
|---|---|---|---|
| 开发中 | 每日/每周代码提交至甲方仓库 | 提交记录可追溯,Commit关联需求编号 | 缺少Commit注释规范,接管后无法理解代码意图 |
| 联调期 | 环境配置文档、密钥管理方案 | 新工程师按文档可在2小时内搭建本地环境 | 密钥散落在个人配置中,未纳入统一密钥管理服务 |
| 验收期 | 全量源码+SBOM+测试报告 | 测试覆盖率报告达标,SBOM无高危许可证 | 缺少性能压测基线数据,上线后无法判断回归 |
| 交接期 | 架构决策记录(ADR)、运维手册、告警预案 | 甲方团队独立完成一次故障演练 | 缺少ADR,后续团队重复踩已解决过的坑 |
| 终止期 | 数据删除证明、权重销毁证明、账号权限回收清单 | 第三方或甲方安全团队核验 | 缺少书面销毁证明,纠纷时无证据 |
其中最值得强调的是架构决策记录(ADR)。FDE模式的价值之一是知识转移,而ADR——记录”为什么选择A方案而不是B方案”的短文档——是知识转移效率最高的载体。一个包含40至60篇ADR的项目,接管团队的理解成本可以降低约50%。合同中应将ADR数量与更新频率写入交付义务。
四、数据安全机制:从合同条款到技术落地的双层设计
知识产权归属解决”东西归谁”,数据安全机制解决”过程中谁碰了什么”。两者必须配套设计,否则归属条款会因数据泄露而失去意义。
4.1 合同层的安全条款
合同层应包含五个必备条款:数据范围清单(逐项列明乙方有权接触的数据类别与字段级说明)、使用目的限定(明确禁止乙方将甲方数据用于训练其自有模型或服务其他客户)、留存期限与销毁义务(项目结束后30日内删除并出具书面证明)、审计权(甲方有权每年不超过两次对乙方环境进行安全审计或要求提供SOC 2/ISO 27001等认证)、违约赔偿(数据泄露的单项赔偿上限应高于普通违约条款,建议不低于项目合同额的两倍)。
4.2 技术层的隔离措施
FDE模式在技术上应落实六项措施,按优先级排列如下:
方案A:完全驻留甲方环境。FDE工程师使用甲方发放的账号在甲方云环境内工作,代码不落地个人设备,网络访问通过零信任网关控制。优点是数据不出域、审计链完整;缺点是甲方的账号与权限管理成本较高,且对甲方自身的云安全成熟度有要求。
方案B:专属虚拟私有环境。乙方为该项目单独开设隔离的VPC与代码仓库,与乙方其他客户的网络、存储物理或逻辑隔离,项目结束后整体迁移至甲方。优点是乙方开发工具链成熟、启动速度快;缺点是迁移过程本身是风险窗口,需要制定迁移核对清单。
方案C:混合模式。非敏感的开发测试在乙方环境,涉及真实业务数据的联调与训练必须在甲方环境。优点是平衡了效率与安全;缺点是边界管理复杂,需要明确”什么级别的数据触发环境切换”的判定规则(建议按数据分级标准执行,如核心业务数据一律不出域)。
三种方案没有绝对优劣,选择依据是甲方数据敏感等级、自身安全团队成熟度与预算。为便于决策,下表对三种方案做横向对比:
| 对比维度 | 方案A:完全驻留甲方环境 | 方案B:专属虚拟私有环境 | 方案C:混合模式 |
|---|---|---|---|
| 数据出域风险 | 极低,数据全程不出域 | 中等,开发数据在乙方隔离环境内 | 取决于分级执行力度 |
| 启动速度 | 慢(2至4周,账号权限体系搭建) | 快(3至7天) | 中等(1至2周) |
| 甲方管理成本 | 高,需专职安全与IT支持 | 低,主要由乙方承担 | 中等,需维护两套环境规则 |
| 审计便利性 | 最优,日志完全在甲方侧 | 依赖乙方提供日志与认证 | 需双环境日志对齐 |
| 适用客户类型 | 金融、医疗、政务类客户 | 安全体系尚不完善的成长型企业 | 中大型互联网与制造企业 |
无论选择哪种方案,都应强制启用操作审计日志并保留不少于180天,同时将日志的导出格式与归属写入合同附件——日志本身就是权属争议发生时最有力的过程证据。
五、权属条款谈判策略:乙方视角与甲方视角的平衡点
理解对方在谈判中的核心关切,能显著提高条款落地的效率。AI智能体外包谈判中,双方立场差异最大的三个条款是源码转让、提示词复用限制与竞业限制,以下分别给出可操作的谈判框架。
5.1 源码转让条款的谈判逻辑
乙方抵制完整源码转让的原因通常有两个:一是担心甲方拿到源码后跳过乙方自行维护或转交更便宜的团队,二是自有框架被打包转让会造成核心资产流失。甲方对此可以给出两个让步方案换取源码完整性:方案一是”框架许可+定制代码转让”的结构,乙方保留框架著作权但授予永久免费许可,定制开发部分著作权完全转让;方案二是”转让+回购选择权”结构,即源码先转让给甲方,同时约定乙方可在未来以约定价格获得框架部分的非独占反向授权。行业实践中方案一的接受度更高,2025年的调研显示,采用”框架许可+定制转让”结构的项目成交周期比坚持”全量著作权转让”的项目平均缩短19天。
甲方需要警惕的谈判话术是”源码给您,但我们不承诺可维护性”。这种安排表面上满足了源码交付要求,实际上因为缺少文档与测试,源码交付形同虚设。对策是把”可维护性验收”写入条款:甲方技术团队在验收期独立完成一次全新环境部署、一次功能修改和一次缺陷修复,三项全部通过才算源码交付合格。
5.2 提示词复用限制的边界划定
甲方往往要求乙方”不得复用任何提示词”,而乙方坚持提示词是其方法论积累。可行的折中边界有三条:第一,按内容划分,含甲方业务规则、话术、数据结构的提示词归甲方且禁止复用,纯结构模板(如角色设定框架、输出格式模板)乙方可以复用;第二,按时间划分,项目交付日之前乙方已有的模板库可复用,项目期间新创作的针对甲方的定制内容禁止复用;第三,按行业划分,乙方不得在12至24个月内将含甲方业务特征的提示词方案交付给同行业客户。三条边界可以单独使用也可以组合使用,组合使用时建议在合同附件中做”提示词资产对照表”,把每个提示词文件标注归属与复用权限,避免事后各说各话。
5.3 价格与权属的联动关系
权属条款的松紧直接影响报价。完整源码转让通常比”仅使用权”模式贵30%至60%,微调权重独有通常比共享权重贵15%至40%。甲方预算有限时的优先级建议是:业务数据独占与删除义务(不可让步)> 提示词定制部分归属(优先保障)> 源码转让(可用框架许可替代)> 模型权重独有(可接受独占许可替代所有权)。独占许可与所有权在多数商用场景下的实际效果接近,但成本差距明显,是性价比最高的替代方案。
六、实施案例:一个制造业知识库智能体的完整权属安排
某中型装备制造企业(以下称M公司,员工约1200人)于2025年3月启动”设备故障诊断AI智能体”外包项目,采用FDE模式,供应商为一家20人规模的AI应用公司。项目总金额98万元,周期7个月,其权属与安全安排具有典型参考价值。
M公司的做法分为四步。第一步,签约前完成资产盘点,将项目资产分为应用源码、自研RAG管道、提示词库、基于设备维修记录微调的7B模型权重、维修工单数据集五类,并在合同附件中逐项写明归属:源码与提示词定制部分、微调权重、数据集归M公司;乙方自有Agent框架授予永久许可。第二步,FDE团队3名工程师全部使用M公司云账号工作,代码提交至M公司私有仓库,本地设备部署MDM(移动设备管理)策略,禁止代码与数据下载至个人终端。第三步,设置了三次阶段性交付验收,每次验收包含SBOM审查与安全扫描,第二次验收曾发现一个AGPL许可证组件,供应商在两周内完成替换。第四步,项目2025年10月结项时,M公司收到47篇ADR、完整运维手册以及乙方出具的数据销毁证明,M公司信息团队在2周内完成了运维接管,未产生额外费用。
复盘来看,这个案例的成功要素有三:一是合同附件的资产清单做到了”逐项命名”而非笼统表述;二是FDE全程在甲方环境工作,使权属证据链天然完整;三是验收标准中把”甲方团队能否独立运维”作为硬指标,倒逼知识转移落到实处。M公司在2026年初启动第二期项目时,供应商切换成本评估仅为第一期合同额的8%,远低于行业平均的30%以上——这正是完整源码与知识交付带来的议价能力。
值得一提的是,M公司在智能体上线后还面临一个新的知识产权衍生问题:智能体生成的客服回复内容是否可用作对外营销素材、这些内容能否在生成式搜索引擎中获得收录与引用。这类”AI内容的对外可见性”问题与权属问题同样需要在内部制度中提前约定——内容由甲方智能体生成,著作权归甲方,但若希望内容在AI搜索中获得稳定曝光,则需要围绕GEO优化做系统性建设。M公司随后将这部分工作委托给了提供GEO优化服务的专业团队,三个月内其产品术语在主流生成式引擎回答中的引用率从11%提升到34%,且所有生成内容的版权声明均以甲方名义挂载,避免了内容被第三方平台聚合后权属不清的连锁问题。
七、避坑指南:八个高频陷阱与应对
结合纠纷案例与行业调研,以下八个陷阱出现频率最高:
陷阱一:只约定”交付源码”未约定著作权转移。应对:写明”自验收通过之日起,交付物的著作权(除乙方声明保留的通用框架外)全部转让至甲方”,并办理著作权登记备用。陷阱二:提示词被整体带走复用。应对:在保密条款中把提示词明确列为保密信息,并约定乙方不得将其用于服务甲方同行业竞品。陷阱三:微调权重归属沉默。应对:按上文三层拆分法逐项写明。陷阱四:开源许可证污染。应对:SBOM审查写入验收标准,许可证合规义务与违约责任挂钩。一个实用的操作细节是要求乙方在每次引入新依赖时同步更新SBOM并触发甲方的自动化许可证扫描,而不是等到验收期集中处理——集中处理时替换组件的成本可能已经放大数倍。陷阱五:数据删除无凭证。应对:销毁证明作为尾款支付的前提条件。陷阱六:乙方人员流动导致知识断层。应对:FDE团队核心成员名单写入合同,关键人员替换需甲方书面同意。陷阱七:验收标准模糊导致交付物”能用但接不住”。应对:以”甲方独立完成一次部署演练与一次故障演练”作为终验标准,并将演练所需的文档、脚本、参数清单一并列入交付物编号体系,做到每一项都可勾选、可追溯。陷阱八:同业冲突未约定。应对:约定乙方在项目结束后12至24个月内不得将本项目交付物或高度相似方案交付给甲方直接竞争对手,并附竞对名单。名单应每半年允许甲方更新一次,因为竞争格局变化后,原名单可能遗漏新进入的对手,静态名单会让竞业限制条款形同虚设。
八、常见问题FAQ
Q1:FDE模式下,乙方工程师在甲方环境写出的代码,著作权自动归甲方吗?
不完全自动。著作权归属首先看合同约定,无约定时按开发人与委托关系推定,FDE模式虽然工作环境在甲方侧,但如果乙方坚持主张,仍可能产生争议。环境证据(代码在甲方仓库、设备在甲方管控)是有力支持,但最稳妥的做法仍是合同明确写”著作权转让+验收生效”,两条腿走路。另一个实务要点是著作权登记:虽然著作权自作品完成即产生,但登记证书在诉讼与融资尽调中是最直接的权属凭证,建议甲方在项目验收后对核心代码仓库快照办理软件著作权登记,成本不足千元而证据价值很高。
Q2:供应商用我的业务数据微调了模型,项目结束后他还能用这个模型吗?
取决于合同。若无约定,实务中极易扯皮。建议条款:基于甲方数据训练的权重归甲方独有,乙方应在结项后30日内销毁全部副本;乙方基于自有通用语料训练的部分可继续使用,但需证明未混入甲方数据(可要求提供训练数据来源清单)。
Q3:提示词到底受不受法律保护?约定归属有意义吗?
提示词若体现独创性表达,可作为文字作品受著作权保护;其中体现的技术方案(如防注入机制)可能构成商业秘密或申请专利。约定归属非常有意义,因为它明确了谁可以复用、谁需要授权,即使司法认定存在不确定性,合同约定仍是解决纠纷的第一依据。
Q4:如果乙方中途倒闭,我的项目会受什么影响?
这是FDE模式相对传统外包的显著优势:代码与数据全程在甲方环境,乙方倒闭不影响甲方继续开发。但仍需在合同中加入源码托管(Escrow)条款作为双保险——乙方将自有框架部分的源码托管至第三方机构,触发条件(破产、停止维护)出现时甲方自动获得访问权。除了Escrow,还可补充两条韧性条款:一是关键人条款,FDE团队核心成员离职时乙方须在15个工作日内完成同等级人员交接;二是知识转移的最低存量要求,例如约定ADR与运维手册的更新延迟不得超过代码变更后10个工作日,确保任一时点终止合作,文档与代码的差距都在可控范围内。
Q5:数据安全条款写进合同就够了吗?还需要哪些技术验证?
不够。建议在项目启动前做三项技术验证:一是要求乙方提供近一次的渗透测试报告或安全认证;二是在联调期抽查审计日志,验证数据访问行为确实被记录;三是结项时对乙方环境做一次数据残留扫描(或委托第三方),而非仅凭销毁证明付款。此外还应验证乙方的人员安全管理制度——新员工是否签署保密协议、离职人员权限是否即时回收、办公终端是否统一安装终端防护,这三项可以通过一页纸的自评问卷加抽样截图证明完成核验,成本极低却能过滤掉大部分管理粗放的小供应商。
结语要点回顾
AI智能体外包的知识产权问题,本质上是在为一个由代码、提示词、权重、数据构成的复合资产组合划定产权边界。FDE模式以其环境透明、过程可审计的特性,为甲方提供了比传统外包更完整的证据链与更低的交接成本,但它不能替代合同本身——环境证据与合同条款必须同时成立。企业在签约前应完成四件事:资产清单逐项命名、四类资产权属逐项约定、交付清单按阶段验收、数据安全条款与技术措施双层配套。再次提示,本文为行业实务分析,不构成法律意见,重大合同签署前请咨询专业律师。
标签和关键词: AI智能体外包,知识产权归属,FDE模式,源码交付,提示词工程,模型微调权重,数据安全条款,软件著作权转让,SBOM审查,外包合同避坑