AI创业卷入诉讼，法院会审查什么?
文章作者：赵暄律师
文章来源：曼昆区块链法律服务
2026年9月7日，最高人民法院发布《关于依法审理涉人工智能纠纷案件的意见》。这份共24条的文件，涉及人格权益、模型训练、知识产权、技术合同和诉讼证据等多个方面。
最近读到这份文件，我最关注的是其中对创新的态度：《意见》明确提出，尊重科技创新规律和人工智能行业发展实践，以包容审慎的态度平衡权益保护与产业发展，营造“鼓励探索、宽容失败”的环境。
这对AI创业者是一个积极信号。技术尚在探索，产品不断迭代，许多事情本来就无法在立项时保证成功。司法愿意认真对待这种不确定性，有助于让企业更有信心地尝试。
不过，从商事争议解决的角度看，我更关心这个信号怎样在具体案件里提供指引。
项目没有达到预期，企业怎样证明自己尽到了合理努力？生成内容被指控侵权，开发者怎样说明数据来源与训练过程？双方各执一词时，法官依据什么还原事实？这些问题的应对，在此次的意见里得到了指引——
司法为创新保留空间，也要求企业把能够掌握的关键过程说清楚、证明出来。对创业公司而言，研发、数据和合规记录，值得从一开始就作为重要的经营资产来管理。
允许技术失败，但“合理努力”需要事实支撑
《意见》第15条要求，审理涉人工智能技术开发、转让、许可、咨询、服务合同纠纷时，应根据合同约定，充分考量研发特点、技术开发方是否尽到合理努力等情形，依法认定违约责任。
这句话里，“合理努力”值得关注，“根据合同约定”同样不能忽略。
设想一家AI公司为工厂开发缺陷识别系统。投入数月后，识别效果仍未达到预期，客户要求退款、赔偿。开发团队觉得委屈：“我们一直在改，确实遇到了技术难题。”
这样的解释有意义，但法院还需要知道：双方约定的是共同探索一项尚待验证的技术，还是交付满足明确标准的系统？测试样本、使用环境和验收方法有没有约定？技术风险如何分担？
如果企业明确承诺了特定条件下的交付结果，不能仅凭“研发很难”“团队很努力”，就当然免除违约责任。是否承担责任、承担多少，仍须结合约定、履行情况及法律规定判断。
因此，保护应当从签约时开始。哪些功能已经成熟，哪些指标需要进一步验证，相对方应提供什么数据和配合，需求改变后如何调整进度与费用，都应尽可能说清楚。
对不确定性较高的项目，还可以考虑先做小规模验证，再决定是否进入下一阶段；同时约定未达到阶段目标时，费用如何结算、已有成果如何处理。把成本提前谈清楚，往往更有利于合作真正开始。
合同划出了责任边界，过程记录则帮助判断企业实际做到了哪里。
再如，客户增加了新的缺陷类别，双方有没有确认调整？某轮测试表现不佳，团队分析过什么原因，尝试了哪些改进？发现重大障碍后，是否及时告知客户、讨论替代方案？交付的具体版本，与当时的测试结果能不能对应起来？
Git等版本管理系统里的修改记录、测试原始数据、问题清单、需求确认和阶段性交付材料，都可能为这些问题提供依据。
但提交记录多、加班时间长，并不能直接证明“合理努力”。更有说服力的是，这些投入确实围绕约定目标展开，技术选择有依据，发现问题后作出了与当时条件相适应的处理。此外，就我代理的一些复杂软件开发合同纠纷案的经验来看，除了最开始的约定外，中间可能涉及的需求更改，都应以约定的方式予以确认，避免后续可能的纠纷。
对创业者而言，争取司法对技术失败的理解，需要让法官看见真实的研发过程。技术上的挫折能够被解释，合同中的风险安排才更有可能得到准确适用。
模型可以是黑匣子，公司不能是黑匣子
合同纠纷需要还原研发过程。在今年的多起侵权纠纷中，法院多次要求企业进一步说明：模型是怎样形成的，争议内容又是怎样产生的。
《意见》第12条明确，在人工智能生成内容被诉侵犯著作权的纠纷中，开发者提出不侵权抗辩的，应按法院要求提供训练数据来源、训练过程记录、模型运行模式及科学理论依据等材料佐证。
最高法在答记者问中说明，权利人仍需就争议内容由相关AI生成、与其作品构成实质相似等初步事实举证。与此同时，掌握内部技术资料的开发者，也需要为自己的抗辩提供依据。
对于企业，这意味着“我们没有抄”需要有事实支撑。
数据由谁提供，通过什么渠道取得，使用依据是什么？取得的许可是否覆盖实际用途？数据经过哪些处理，用于哪个训练版本？针对可能出现的侵权内容，采取了什么预防和处理措施？
这些问题未必能靠一份采购合同回答。供应商声称“数据合规”，还需要结合授权文件、实际交付内容和具体使用方式判断。
这里尤其需要注意一个边界：最高法明确表示，对未经许可使用他人作品训练大模型如何定性，《意见》暂未作出规定。企业不能据此推导出“训练使用已经获得普遍许可”；具体项目仍需结合现行法律和使用事实分析。
记录的意义，就在于为这种分析保留事实基础。
我愿意把它比作飞机的黑匣子：它无法保证飞行永远不出问题，但在问题发生后，能够帮助人们知道当时发生了什么。AI企业保存关键过程，也是为了让争议有可以核查的依据。
这里不必把目标设成完整解释每一次模型输出。企业可以先把能够控制的环节管好：数据如何进入，版本如何变化，风险如何评估，投诉如何处理。
使用外部模型接口开发应用的团队，可以从供应商条款、模型版本、自行接入的知识库来源和调用记录做起；自行训练、微调模型的团队，则应保存相应的数据处理和训练记录。具体范围应与企业角色、业务风险和实际控制能力相匹配。
技术虽复杂，企业对自身行为的说明应当尽可能清楚。
合规与证据工程
前面两个问题，最终都会落到同一件事上：记录存在，并不意味着它已经足以证明企业的主张。
《意见》第18条要求重点审查电子数据在生成、收集、存储、传输过程中的真实性和完整性。对区块链存证，还要审查上链前数据的真实性以及平台的可靠性。
因此，文件做了存证，不等于文件记载的事情就当然真实。
在司法实务中，面对项目纠纷，法院通常要求提供原始结果、测试条件，并与交付记录相互印证，才更容易判断它是否符合合同约定。因此，记录也应如实呈现相关的失败测试、异常和修正。它们能解释问题怎样被发现、方案为何调整，有时正是判断企业是否尽到合理努力的重要依据。
从这个角度看，研发管理、数据合规和诉讼准备，其实可以在同一套日常工作中完成。研发记录可以证明履约情况，数据来源材料可以支撑侵权抗辩，运行日志也可能帮助查明异常原因和责任范围。
这就是我所理解的“证据工程”：围绕将来可能发生争议的关键事实，让日常记录形成可以核查、相互印证的联系。
小团队也可以从几个节点做起。立项时，把技术目标和风险分担落实到合同；接入数据时，保存来源、许可和处理依据；交付时，把需求、版本、测试和客户反馈对应起来；发现异常或收到投诉后，及时记录处置过程，固定相关材料。
同时，要明确由谁保存、存在哪里、谁能修改，以及怎样备份，避免人员离职或者系统更新后，关键资料无法找回。留存范围、期限和访问权限，也应兼顾个人信息保护与商业秘密。
专家提前参与的价值，就在于与业务、技术团队一起判断：哪些事实会影响责任，合同怎样表达这些事实，现有系统能否留下相应依据。企业不必等到收到起诉状，才第一次把技术过程翻译成法律能够判断的问题。
好的合规，应当帮助企业顺畅地推进业务，也让关键的经营行为在需要时有据可查。
这份《意见》体现了司法支持创新的态度，也围绕合同履行、侵权责任和证据审查等具体问题，为企业依法维护自身权益提供了指引。
这种保护会惠及认真投入的创业者：项目遇到困难时，研发记录能帮助澄清履行情况；遭遇侵权指控时，数据和技术资料能为抗辩提供基础；开展新的合作时，清楚的责任安排也有助于双方建立信任。
AI创业仍然值得大胆尝试。企业可以在探索未来的同时，把已经走过的路记录清楚，让真实的投入、审慎的判断和负责任的行动，成为继续向前的底气。