热点关注

技术不是“免责牌”:《最高人民法院关于依法审理涉人工智能纠纷案件的意见》下AI企业该读懂的过错认定与企业合规转向

2026 年 10 月 26 日约 9 分钟阅读作者:苏维艳来源:最高人民法院

最高法涉AI纠纷意见明确技术复杂不是免责理由,企业必须按过错责任分级管理、完善处置并留存尽责证据。

技术不是“免责牌”:《最高人民法院关于依法审理涉人工智能纠纷案件的意见》下AI企业该读懂的过错认定与企业合规转向

2026年9月7日,最高人民法院发布《关于依法审理涉人工智能纠纷案件的意见》(法发〔2026〕10号,下称《意见》)。该文件共五部分二十四条,系最高审判机关首次就涉人工智能纠纷发布的系统性裁判规则文件,在人工智能专门立法尚未出台的背景下,以现行法律为依据,对归责原则、主体责任、证据规则等问题作出司法指导。需要首先明确的是,《意见》的法律位阶为司法政策文件而非司法解释,不能作为裁判依据直接援引,其功能在于指导各级法院准确适用《民法典》《个人信息保护法》《著作权法》等既有法律。以下围绕《意见》中与企业最为相关的过错认定规则与提供者责任条款,就条文的规范结构、适用条件及尚待明确之处进行分析。

一、《意见》的归责原则与过错考量因素

《意见》第3条确立了一般归责规则:法律没有明确规定适用无过错责任或者过错推定责任的,涉人工智能侵权依照《民法典》第1165条第1款的过错责任原则认定。这一安排的规范意义在于,在人工智能领域不以技术特殊性为由偏离侵权责任的一般体系——仅在既有法律(如产品责任、机动车交通事故责任)已有明确规定的情形下,方可适用无过错责任或过错推定。

第3条同时列举了过错判断的六项考量因素:应用场景、自主化程度、技术与信息透明度、潜在风险及影响范围,开发者与提供者为预防和减少侵权所采取的措施及技术上的可能性,以及使用者对损害后果的预见能力与控制能力。从规范结构观察,这六项因素既非独立的构成要件,也非免责事由,条文未设定权重或冲突时的取舍规则。其功能更接近于为法院提供过错判断的事实指引,而非划定明确的责任边界。

目前适用难点在于“技术上的可能性”的基准问题。若以行业内通行技术水平为参照,要考虑义务相对可预期;若以特定企业实际具备的技术能力为基准,则技术能力越强的企业反而面临更高的注意义务,这与《意见》“避免人工智能技术与产业在发展初期承担过重责任”的政策取向之间存在张力。在缺乏国家标准的领域,过错判断仍依赖个案权衡,事后判断受损害结果严重程度影响的风险并非不存在。从可操作性的角度看,较为现实的方向是将《生成式人工智能服务管理暂行办法》等既有规范设定的合规要求,作为判断注意义务是否履行的外部参照,使过错认定获得相对客观的尺度。

“技术中立”在这一框架下的地位需要准确界定。第3条并未将“技术中立”列为独立的抗辩事由,但六项因素中“技术与信息透明度”和“所采取的措施及技术上的可能性”的并列,实际上为一种有条件的抗辩留出了空间:当事人可以主张,依据纠纷发生时的技术水平,特定损害后果在客观上难以预见或控制。这一抗辩能否成立,取决于具体场景中的技术条件与控制能力,而非主张本身。

二、生成式人工智能服务提供者责任的规则构成

(一)第7条:通知后的必要措施义务

第7条就生成式人工智能侵害人格权益的情形,引入“通知—必要措施”机制。条文采取两段式结构:前段针对自动生成内容的情形,经权利人通知,服务提供者未及时采取停止生成侵权内容等必要措施的,对造成的损害承担侵权责任;后段针对用户诱导生成的情形,必要措施扩展至“停止生成、屏蔽相关生成指令”。通知的有效要件被明确为“构成侵权的初步证据及权利人的真实身份信息”。

与传统网络侵权“通知—删除”框架相比,规范上的实质变化在于必要措施的范围。提供者的处置义务不再限于移除已生成的内容,而要求对特定提示词或生成路径采取阻断,以防止同类内容的反复生成。这意味着第7条对提供者的技术处置能力提出了超出一般内容删除的要求:是否具备对生成指令的识别与屏蔽能力,以及处置是否“及时”,将在诉讼中成为事实认定的重点。

还有第7条与《民法典》第1197条的关系。前述“通知—必要措施”规则以服务提供者不知道且不应当知道侵权存在为前提;若提供者知道或应当知道用户利用其服务侵权而未采取必要措施,则适用第1197条的连带责任,不再经由通知程序免责。在人工智能场景下,“应当知道”的判断可结合同类投诉的累计情况、相关功能是否曾被监管提示、是否具备生成内容标识与追溯机制等因素。这一区分意味着,投诉数据的系统化留存与风险信号的内部响应,具有过错认定上的直接意义。

(二)第12条:开发者不侵权抗辩的举证协助义务

第12条在涉人工智能知识产权侵权的框架下,规定开发者提出不侵权抗辩的,应当提供训练数据来源、训练过程记录、模型运行模式以及科学理论依据等予以佐证。有解读将其规范效果概括为“对AI‘黑箱’的司法穿透”,即通过举证义务的配置,使掌握技术信息的开发者在诉讼中承担实质性的说明负担。

从规范性质上看,这并非举证责任的倒置——不侵权抗辩的提出者仍承担相应的证明必要,但法院在审查抗辩时有权要求开发者提供其控制范围内的技术资料,无正当理由未能提供可能影响抗辩的成立。其实际效果在于改变了“算法黑箱”在诉讼中的功能:技术不透明不再能作为回避实质说明的当然理由,而在一定程度上转化为要求开发者以可验证材料回应质疑的依据。训练台账、数据来源记录与模型版本信息,由此从内部管理资料转变为可能进入司法评价的证据材料。

(三)第13条:开源提供者责任的豁免条件

第13条为免费开源人工智能软件的开发者、提供者设置了责任豁免通道,其适用需同时满足三个条件:以免费开源方式提供代码模块;公开说明功能和安全风险;他人使用该代码模块导致侵权。判断是否属于“免费开源方式”,需综合考量该主体是否从代码提供行为中获利,以商业化方式提供开源代码的主体不能适用豁免。

规范的留白在于“获利”的边界。从代码提供行为中直接获利与通过开源生态在产业上下游间接获利之间,条文与官方解读尚未给出明确区分。对于使用开源组件构建人工智能产品的企业而言,这一豁免条款的意义是双向的:作为下游使用者,上游开源方的合规状态并不当然转移自身责任;作为可能的开源贡献者,豁免的可用性取决于能否在提供行为与商业化获利之间维持可辨识的界限。开源许可协议类型、信息披露程度与安全合规举措,构成法院综合考量的因素。

三、注意义务履行与证据留存的规范要求

上述条款在规范层面共同指向一个可观察的趋向:过错判断的重心,正从对主体身份的抽象归类,移向对具体行为与可证明事实的审查。《意见》第3条所列因素中,“为预防和减少侵权所采取的措施”与“技术上的可能性”并列,意味着企业实际的风险管理行为在过错评价中占据独立位置。第7条的“及时”与“必要”、第12条的举证协助、第13条的信息披露,均以可还原的行为记录为事实基础。

这一趋向对企业合规的规范含义可以归纳为三个层面。其一,场景分级具有规范依据。《意见》将“应用场景”列为首项考量因素,且第2条基本原则明确区分通用与专用、开源与闭源等不同类型在风险外溢与控制能力上的差异。对不同风险层级的业务采取差异化的管理措施,本身即构成“采取了与风险相匹配措施”的事实基础。其二,技术能力边界的说明与留痕具有证据功能。产品功能说明、适用限制与风险提示,在过错判断中可作为证明企业未作出超出技术可能性之承诺的材料;其对外披露的充分性,也与第13条开源豁免中的“公开说明功能和安全风险”要件直接相关。其三,证据治理应嵌入业务流程。训练数据来源记录、模型版本信息、投诉处置日志与人工复核记录,若在纠纷发生后补制,其证明力将受到质疑;持续生成与留存,是在“可证明的尽责过程”成为过错判断要素的规范环境下的合理应对。

四、企业合规应对的条文依据与操作要点

综合上述条文,企业在《意见》框架下的合规重点不在于寻求抽象的免责表述,而在于使自身的行为与记录能够对应条文所设定的过错判断要素。

(一)人工智能业务场景的梳理与风险分级。 依据第3条“应用场景”与“潜在风险及影响范围”两项因素,以及第2条关于分类治理的原则,对涉及人格权益合成、专业决策辅助等高风险场景与一般工具性使用作区分管理,并将分级依据与对应措施形成书面记录。

(二)通知处置机制的完善与记录可查。 依据第7条,投诉通道的有效性、对侵权初步证据的核验能力、停止生成与屏蔽指令的技术可行性,以及处置时间记录,均应纳入机制设计。同时,投诉数据的累计分析可作为判断是否触发第1197条“应当知道”标准的管理依据。

(三)人工智能证据台账的建立与日常管理。 依据第12条,训练数据来源、训练过程与模型运行模式的相关记录应在研发与运营流程中持续生成;依据第13条,开源组件的许可协议类型、风险说明与商业化使用情况应单独建档。上述材料的功能不限于应对诉讼,也构成企业主张已履行注意义务的事实基础。

《意见》以过错责任为基线,并未为人工智能技术设置独立的免责机制,也未将技术复杂性本身接纳为免除或减轻责任的当然理由。对开发者与提供者而言,条文所预留的责任空间,系于可证明的风险控制行为与信息留存,而非主体身份或技术属性的抽象主张。这一规范逻辑,是理解《意见》下企业合规义务的基点。

原文链接: https://www.court.gov.cn/zixun/xiangqing/511101.html

苏维艳律师

苏维艳

创始合伙人

查看律师主页 →

本文仅为一般性法律信息分享,不构成对任何具体事项的法律意见,亦不构成对任何案件处理结果的承诺。 如需法律帮助,请通过「联系我们」与我们取得联系。