一份24条的文件，AI创业者该读出什么

2026年9月7日，最高人民法院发布了《关于依法审理涉人工智能纠纷案件的意见》，全文24条，覆盖人格权益、模型训练、知识产权、技术合同和诉讼证据等多个领域。

这份文件最核心的信号是四个字：宽容失败。

《意见》明确提出，要尊重科技创新规律和AI行业发展实践，以包容审慎的态度平衡权益保护与产业发展，营造"鼓励探索、宽容失败"的环境。

对正在摸索中的AI创业者来说，这当然是个好消息。技术路线还没定型，产品还在迭代，很多事情在立项那天根本没法保证做成。司法愿意正视这种不确定性，企业才更有底气去试。

但问题也随之而来：宽容失败，不等于不需要解释失败。

从商事争议解决的角度看，真正关键的在于——这个信号怎么在具体案件里落地？项目没达到预期，企业怎么证明自己尽力了？生成内容被指控侵权，开发者怎么说明数据从哪来、模型怎么训的？双方各执一词时，法官凭什么还原事实？

《意见》给出的答案很明确：司法为创新留出空间，但企业必须把能掌握的关键过程说清楚、证明出来。 对创业公司来说，研发记录、数据台账和合规档案，从一开始就该当作核心经营资产来管理。

---

一、技术可以失败，但"合理努力"得拿事实说话

第15条说了什么

《意见》第15条要求，审理涉AI技术开发、转让、许可、咨询、服务合同纠纷时，应结合合同约定，充分考量研发特点、技术开发方是否尽到合理努力等情形，依法认定违约责任。

这句话里，"合理努力"值得关注，"根据合同约定"同样不能忽略。

一个典型场景

假设一家AI公司给工厂开发缺陷识别系统，投入几个月后识别效果仍不达标，客户要求退款赔偿。开发团队觉得委屈："我们一直在改，确实遇到了技术难题。"

这个解释有意义，但法院还需要知道更多：双方约定的是共同探索一项尚待验证的技术，还是交付满足明确标准的系统？测试样本、使用环境和验收方法有没有约定？技术风险怎么分担？

如果企业明确承诺了特定条件下的交付结果，就不能仅凭"研发很难""团队很努力"当然免除违约责任。是否担责、担多少，仍须结合约定、履行情况和法律规定来判断。

保护从签约那一刻就开始

  • 哪些功能已经成熟，哪些指标需要进一步验证——写清楚

  • 相对方应提供什么数据和配合——写清楚

  • 需求改变后如何调整进度与费用——写清楚

  • 未达到阶段目标时，费用怎么结算、已有成果怎么处理——写清楚


对不确定性高的项目，可以考虑先做小规模验证再决定是否进入下一阶段。把成本提前谈清楚，反而更有利于合作真正启动。

过程记录比加班时长更有说服力

合同划出了责任边界，过程记录则帮助判断企业实际做到了哪里。

客户增加了新的缺陷类别，双方有没有确认调整？某轮测试表现不佳，团队分析了什么原因、尝试了哪些改进？发现重大障碍后，是否及时告知客户、讨论替代方案？交付的具体版本，跟当时的测试结果能不能对应上？

Git等版本管理系统里的修改记录、测试原始数据、问题清单、需求确认和阶段性交付材料，都可能为这些问题提供依据。

但要注意：提交记录多、加班时间长，并不能直接证明"合理努力"。 更有说服力的是，这些投入确实围绕约定目标展开，技术选择有依据，发现问题后作出了与当时条件相适应的处理。复杂软件开发合同纠纷中，除了最初的约定，中间涉及的需求更改都应以约定方式确认，避免后续争议。

争取司法对技术失败的理解，需要让法官看见真实的研发过程。技术上的挫折能够被解释，合同中的风险安排才更有可能得到准确适用。

---

二、模型可以是黑匣子，公司不能是黑匣子

合同纠纷需要还原研发过程。在今年的多起侵权纠纷中，法院多次要求企业进一步说明：模型是怎么形成的，争议内容又是怎么产生的。

第12条的核心要求

《意见》第12条明确，在AI生成内容被诉侵犯著作权的纠纷中，开发者提出不侵权抗辩的，应按法院要求提供以下材料佐证：

1. 训练数据来源
2. 训练过程记录
3. 模型运行模式
4. 科学理论依据

最高法在答记者问中说明，权利人仍需就争议内容由相关AI生成、与其作品构成实质相似等初步事实举证。与此同时，掌握内部技术资料的开发者，也需要为自己的抗辩提供依据。

对企业来说，这意味着"我们没有抄"必须有事实支撑：

  • 数据由谁提供，通过什么渠道取得，使用依据是什么？

  • 取得的许可是否覆盖实际用途？

  • 数据经过哪些处理，用于哪个训练版本？

  • 针对可能出现的侵权内容，采取了什么预防和处理措施？


这些问题未必能靠一份采购合同回答。供应商声称"数据合规"，还需要结合授权文件、实际交付内容和具体使用方式来判断。

一个重要的边界

最高法明确表示，对未经许可使用他人作品训练大模型如何定性，《意见》暂未作出规定。企业不能据此推导出"训练使用已经获得普遍许可"，具体项目仍需结合现行法律和使用事实分析。

记录的意义，就在于为这种分析保留事实基础。

黑匣子的比喻

我愿意把它比作飞机的黑匣子：它无法保证飞行永远不出问题，但在问题发生后，能够帮助人们知道当时发生了什么。AI企业保存关键过程，也是为了让争议有可以核查的依据。

不必把目标设成完整解释每一次模型输出。企业可以先把能控制的环节管好：

  • 数据如何进入

  • 版本如何变化

  • 风险如何评估

  • 投诉如何处理


使用外部模型接口开发应用的团队，可以从供应商条款、模型版本、自行接入的知识库来源和调用记录做起；自行训练、微调模型的团队，则应保存相应的数据处理和训练记录。具体范围应与企业角色、业务风险和实际控制能力相匹配。

技术虽复杂，企业对自身行为的说明应当尽可能清楚。

---

三、合规与证据工程：把日常记录变成法律防线

前面两个问题，最终都会落到同一件事上：记录存在，并不意味着它已经足以证明企业的主张。

第18条的审查标准

《意见》第18条要求重点审查电子数据在生成、收集、存储、传输过程中的真实性和完整性。对区块链存证，还要审查上链前数据的真实性以及平台的可靠性。

因此，文件做了存证，不等于文件记载的事情就当然真实。

在司法实务中，面对项目纠纷，法院通常要求提供原始结果、测试条件，并与交付记录相互印证，才更容易判断它是否符合合同约定。记录也应如实呈现相关的失败测试、异常和修正——它们能解释问题怎样被发现、方案为何调整，有时正是判断企业是否尽到合理努力的重要依据。

什么是"证据工程"

研发管理、数据合规和诉讼准备，其实可以在同一套日常工作中完成：

  • 研发记录可以证明履约情况

  • 数据来源材料可以支撑侵权抗辩

  • 运行日志也可能帮助查明异常原因和责任范围


这就是"证据工程"的核心思路：围绕将来可能发生争议的关键事实，让日常记录形成可以核查、相互印证的联系。

小团队也能落地的四个节点

1. 立项时——把技术目标和风险分担落实到合同
2. 接入数据时——保存来源、许可和处理依据
3. 交付时——把需求、版本、测试和客户反馈对应起来
4. 发现异常或收到投诉后——及时记录处置过程，固定相关材料

同时要明确由谁保存、存在哪里、谁能修改，以及怎样备份，避免人员离职或系统更新后关键资料无法找回。留存范围、期限和访问权限，也应兼顾个人信息保护与商业秘密。

专家提前参与的价值，就在于与业务、技术团队一起判断：哪些事实会影响责任，合同怎样表达这些事实，现有系统能否留下相应依据。企业不必等到收到起诉状，才第一次把技术过程翻译成法律能够判断的问题。

好的合规，应当帮助企业顺畅推进业务，也让关键经营行为在需要时有据可查。

---

写在最后

这份《意见》体现了司法支持创新的态度，也围绕合同履行、侵权责任和证据审查等具体问题，为企业依法维护自身权益提供了指引。

这种保护会惠及认真投入的创业者：项目遇到困难时，研发记录能帮助澄清履行情况；遭遇侵权指控时，数据和技术资料能为抗辩提供基础；开展新合作时，清楚的责任安排也有助于双方建立信任。

AI创业仍然值得大胆尝试。 企业可以在探索未来的同时，把已经走过的路记录清楚，让真实的投入、审慎的判断和负责任的行动，成为继续向前的底气。