国浩视点 | AI浪潮下，信息技术外包企业订立合同时的风险防范——从交付标准切入

来源：国浩律师事务所

发布日期：2025年09月02日

引言： 在信息技术外包业务中，企业签订合同时若对交付标准约定模糊，可能引发哪些风险？又应通过何种方式进行规范约定？本文以软件研发外包合同中三类典型的交付标准约定模式为切入点，结合AI技术广泛应用的时代背景，系统剖析了交付标准不明可能导致的法律风险，并针对性提出了风险规避策略。

目录

一、问题的提出

二、软件研发企业的常见做法

三、AI浪潮给上述约定方式带来的冲击

四、为什么软件行业的交付标准如此难以约定？

五、对软件研发企业的建议

Part 01 .

问题的提出

在涉及信息技术外包（ITO）、特别是软件研发外包的法律纠纷中，成果是否已经达到交付标准是最常见的争议焦点之一。

一般而言，信息技术外包企业（以下通称为软件研发企业）在合同签订过程中的议价能力较弱。因而，合同中关于交付标准的约定常常不够明确，委托方往往多次改变需求和设计，成果交付后往往也确实会存在瑕疵，双方会发生关于维修和改进的沟通。一旦发生纠纷，根据合同、往来文件和沟通记录，很难评价成果是否达到了交付标准，给裁判结果带来很大的不确定性。

在AI浪潮的影响下，虽然所谓的“氛围编程”（Vibe Coding）引发了很多的争议，但毫无疑问，软件开发的流程已经、即将被AI大幅度重塑。在这种背景下，软件研发企业在证明其工作量、工作成果时，将面临进一步的挑战。

Part 02 .

软件研发企业的常见做法

对于交付标准，软件研发企业在协议中大多采取以下三种约定方式：

第一种，约定概括性的成果， 例如“某某集团第几代财务管理系统”，而不约定交付标准的技术细节，有时候还会加入“以某几位专家审核通过”作为验收标准。

第二种，约定成果技术细节， 但由于委托方很少在项目启动时就能提供完善的需求文档，因此交付标准往往不断改变，合同约定很快形同虚设；另一方面，基于行业习惯和对于“商务工作”的漠视，技术人员在沟通过程中往往不遵守、不考虑合同约定，擅自认可委托研发企业对交付标准的任意变更。

第三种，约定提供研发人员， 往往进行驻场开发，以工时计算成果。这种方式存在法律上被认定为劳务派遣 [注1][注2] 、进而影响合同法律效力和裁判标准的风险，但本文主旨不在此，不再赘述。

有些有经验的商务人员、项目经理认为，不管合同约定采用哪种模式，验收还是要靠公关，靠沟通来获得一纸验收证明。且不说这种思维等于放弃了法律上维护权利的道路，值得注意的是，即使获得了一纸验收证明，也有可能被认定为未达到交付标准。在相关案例中 [注3] ，虽然软件研发企业最终得到了支持，但最高院并不是仅仅依据验收报告来确定交付合格，而是在有验收报告的情况下综合了双方在验收报告后的沟通，逐一核对验收项目才确认完成了交付的。

上述第一、第二种模式由于约定不明确，在实践中已经引发了很多争议。第三种模式在交付方面相对较为清晰（根据打卡等情况统计工时即可），但委托方仍可能主张项目未完成、合同目的未实现而拒绝付款，如果完全不约定要完成的项目内容，则更加可能被认定为劳务派遣 [注4] 。而且，第三种模式在AI浪潮的冲击下，反而会带来新的争议点。

Part 03 .

AI浪潮给上述约定方式带来的冲击

对于上述第一、第二种模式，AI的引入将极大提升委托开发方审核成果的能力。对于确实不合格的成果，委托方能够火眼金睛地识别出来固然是好事，但对于合格的成果，委托方“找茬”的能力也被大幅度提高了。对软件研发有所了解的人都知道，完美的代码并不存在。如果委托方故意不接受成果，让AI无限制地“找茬”，总是能从成果中挑出问题。

对于上述第三种模式，AI的引入虽然暂时不能完全代替程序员，但却能被用于反驳关于工时和工作量的主张。试想，假设某软件研发企业进行了数千工时的开发工作，但其中有不少的时间用在需求的明确、人员之间的沟通、代码的审核和测试上。而在发生纠纷时，需求已经固定，代码本身也已经存在，因而业务逻辑已经非常明确，有经验的技术人员完全可以针对其中的某些模块（特别是AI擅长的前端、测试、增删查改等部分），当庭表演“十分钟完成一个模块”的“魔术”，只要当庭完成的成果能够跑通、能够通过基本的测试用例，那么即使是对软件行业有所了解的裁判者，也极有可能形成心证：软件研发企业主张的工时是虚假的，是“磨洋工”。

这其中的一部分原因固然是AI带来的生产效率的真实提高，但另一部分原因是针对需求进行明确、沟通和设计的巨大工作量被掩盖了，还有一部分原因是AI批量快速生成的代码与人工参与的代码存在质量区别——但是，在不需要用于生产、只是证据来反驳工作量的主张的场景下，AI生成的代码就足够了。

Part 04 .

为什么软件行业的交付标准如此难以约定？

软件工程和建设工程相关的法律事务都属于笔者的专业范围，为什么同样作为“工程”，软件行业的交付标准就如此难以确定，以至于经常发生纠纷呢？我们不妨在这方面将两个行业对比一下：

1.建筑行业交付的成果是物理上的，软件行业交付的成果难以被形象地感知。 因而，在建设工程合同纠纷中，裁判者很容易以形象进度来判断成果本身是否存在，接下来只需要判断是否符合质量标准即可；在软件开发合同纠纷中，一旦合同约定不够具体，裁判者甚至很难对照合同来判断成果是否“基本上能用”，更遑论区分“不符合交付条件的缺陷”和“不影响交付的BUG”了。

2.建筑行业拒绝验收有解决方案，软件行业的成果容易被“窃取”从而被拒绝付款。 在建设工程合同纠纷中，对于发包方拒不进行验收的情况，也可以通过是否实际使用了建筑物来推断发包方是否认可验收。在软件开发合同纠纷中，如果委托方宣称项目取消，拒绝支付后续款项，也仍然可能获得有用的成果。虽然科技部《技术合同示范文本》 [注5] 中约定了研发失败的风险承担，但软件开发合同和技术合同还是有所区别 [注6] ，现在的软件行业更是很少进行类似的约定。虽然现在的软件开发合同往往会约定在验收完成、支付尾款时才提供源代码，但有些情况下，委托方在研发过程中还是能够通过种种手段获取源代码；另一些情况下，委托方并不需要源代码，只需要封装好的二进制库，即使软件研发企业能够使用一些技术手段进行限制，但仍有被突破的可能性。对于不公开使用的软件而言，委托方只要主张自己已经取消了相关项目，从而主张不付或少付开发费用，软件研发企业将很难证明其成果已经得到使用。

3. 建筑行业的成果几乎均与安全息息相关，法律争议数量也远远多于软件行业，相关法律法规、标准和规范都较为成熟； 软件行业则缺乏广泛适用的质量标准。 因而，在建设工程合同纠纷中，即使合同中有大量约定不明之处，裁判者也能依据强制性的质量标准来判断是否符合交付标准；在软件开发合同纠纷中，只有一些比较简单的推荐标准，鲜有合同约定适用它们，裁判者也就更不太可能主动参考这些标准。

4.软件行业工艺、效率的发展速度远胜于建筑行业。 在建设工程合同纠纷中，工程量和单价约定不明确，可以通过当地信息价来参考确定；在软件开发合同纠纷中，不仅没有信息价这类概念，也很少有商业主体愿意在合同中约定适用外部标准来计算工程量和单价。

Part 05 .

对软件研发企业的建议

如上文所述，软件研发企业的上述困境是行业特性等多种因素综合导致的，难以完美地解决，但从律师的角度，还是可以对相关企业提出一些建议：

重视合同的价值。 合同和程序其实颇有类似之处，它们的效果都取决于他者的解读而不是编写者的理解。不重视合同而只深耕于软件代码，可能难以在软件行业长久地发展。建议软件研发企业加强商务人员和技术人员的沟通，一方面，在订立合同时尽量详尽地约定交付的具体技术标准，另一方面，在研发过程中要将与委托方达成的修改意愿以补充协议的方式固化下来，以便交付时与成果进行比对。

参考建筑设计企业的做法，分段收取研发费用。 设计行业与软件行业有类似之处——成果容易被“窃取”。设计企业往往会约定，完成某一阶段的工作后，委托方需要进行中间验收、确认其工作量并支付部分价款，才会开始下一阶段的工作；即使委托方中途取消项目或解除合同，也需要按已经完成的进度支付相应费用。有些议价能力较高的软件研发企业已经采用了类似的方法，但中间验收环节往往约定不够具体，或实际验收时缺乏书面证据，在简单获得验收报告后、甚至没有获得中间验收报告就进行了下一步开发，甚至有的企业在未收到前一阶段款项、已经进入诉讼后，技术人员还在兢兢业业地进行下一阶段的研发工作。软件研发企业可以参考建筑设计企业的方法，细化流程，尽量增加中间验收、部分验收的约定，并严格进行中间验收、阶段性收款，以减少风险。

对于以工时计价的合同， 一方面， 要注意在派出程序员的同时，也要派出相应的管理人员，并形成一定的项目管理记录，而且要能证明这些管理记录形成于研发过程中。这既有助于防止软件开发合同被认定为劳务派遣合同，也有助于在发生纠纷时证明与沟通、设计、管理等相关的工作量。 另一方面， 即使以工时计价，也应当在合同中明确一些成果的基本验收标准，比如代码规范、测试标准等，特别是AI不能轻易达到的标准，并约定开发过程中AI的使用范围和使用方法限制，以避免上文所述的用AI来反驳工时的“魔术”。