2026 年 9 月 7 日，最高人民法院发布 《关于依法审理涉人工智能纠纷案件的意见》（法发〔2026〕10 号），共 5 个部分、24 条。这是首部由国家最高审判机构发布的涉人工智能司法裁判规则文件；背景是我国尚未出台专门的人工智能法，它采用"在现行法律框架下提出裁判理念与规则指引"的方式。
对企业来说，这份文件的价值不在"又出了一份规范"，而在于它首次把企业平时做的技术动作和法庭上的责任认定挂上了钩：你有没有做权限留痕、有没有说明风险、能不能拿出训练数据来源记录，都会影响过错怎么判。本文沿着三个企业关心的问题展开：自持开源权重的责任边界、生成内容侵权（常被称作"AI 幻觉"的那一类）的规则落点、不同角色的责任划分。企业级环曜 Agent 本地化部署 在合规治理 场景里会把它当作条款对齐的输入，而不是等争议发生后才找条文。
阅读提示（YMYL）：本文是对公开司法文件的要点整理与落地讨论，不构成法律意见，具体案件请由法务或外部律师出结论。另需说明一处用词：《意见》正文条文并未直接使用"AI 幻觉"一词，该表述出现在起草背景与主要考虑部分，对应规则是第 7 条（生成式 AI 服务提供者责任）。
一、这份《意见》是什么：结构与三条主线
先看清结构，才能知道哪些条文跟自己有关（以下按官网发布稿的条文编号整理）：
| 部分 | 条款 | 主题 |
|---|---|---|
| 一 总体要求 | 第 1—2 条 | 指导思想与基本原则（以人为本、支持创新发展、筑牢安全底线） |
| 二 涉人工智能侵权案件 | 第 3—11 条 | 归责原则、人格权与个人信息侵权、生成内容侵权、产品责任、自动驾驶事故责任 |
| 三 涉人工智能知识产权纠纷 | 第 12—16 条 | 著作权侵权、开源软件责任、专利授权确权、技术合同、数据使用 |
| 四 审理程序规则 | 第 17—20 条 | 事实查明、证据审查、妨害司法秩序、惩治犯罪 |
| 五 审判指导与工作机制 | 第 21—24 条 | 多元解纷、审判监督指导、部门协作、国际司法交流 |
三处与企业距离最近的条文
对企业落地影响直接的四处是：第 3 条（过错怎么判）、第 7 条（生成内容侵权与通知处置）、第 12 条（生成内容侵权时各方责任与举证）、第 13 条（自持开源软件的责任豁免）。本文后面三章逐一展开。
需要先明确一点：这四处条文没有一处要求企业"必须上某个系统"。它们要求的是可举证——你能不能说清自己采取了什么措施、有没有尽到说明与警示义务、收到通知后有没有及时处置。这也是为什么本文把它归到"证据准备"而不是"合规采购"。
二、过错怎么判：自主化程度与控制能力成了考量要素
第 3 条给出的归责原则很明确：法律未明确规定适用无过错责任或过错推定责任的，依照民法典第 1165 条第 1 款适用过错责任原则。也就是说，多数涉 AI 侵权走的是"有过错才担责"这条路，而过错的有无与程度，取决于一组可举证的要素。
这对已经放权给 Agent 的企业尤其关键——条文把自主化程度、技术与信息透明度、使用者对损害的预见能力与控制能力列进了考量范围。把这份考量表对到内部制度上，属于条款对齐与知识检索 的常规动作，企业级环曜知识库本地化部署 的客户环境会把它做成一份随版本更新的对照表，避免每次争议临时拼。
一张可举证的对照表
| 判定要素（第 3 条口径） | 企业侧可举证的对应材料 |
|---|---|
| 应用的具体场景 | 场景清单与用途说明（含对外/对内、是否面向消费者） |
| 自主化程度 | 自主性分级文档、哪些操作需人工审批的配置 |
| 技术与信息透明度 | 风险说明、使用说明、对外警示文本 |
| 潜在风险及影响范围 | 影响评估记录、受影响对象范围界定 |
| 开发者/提供者采取的预防措施及技术可能性 | 权限控制、拦截与熔断、日志留痕的配置与演练记录 |
| 使用者的预见能力与控制能力 | 培训记录、审批链、可撤回设计（能及时止损） |
这张表实用的一句话是："控制得住"本身就是减责要素，而不只是运维美观。 若你们的 Agent 已经能按自主性分档（例如低风险自动执行、高风险转人工），这套配置在争议里就是"已采取预防措施"的直接证据；相关分档与熔断的设计口径可参考自主性分级与熔断怎么定。
三、自持开源权重：责任豁免的前提条件
第 13 条是自持开源权重企业该逐字读的一条。它的表述方向是"依法给予适当的责任豁免"——认定开源软件开发者、提供者及后续开发者、提供者的侵权责任时，综合考量开源许可协议类型、权利限制内容、安全合规举措、信息披露程度等。
豁免不是自动的：三个前提条件
条文里还有一句更具体：以免费开源方式提供 AI 软件研发所需部分代码模块，并公开说明其功能和安全风险，他人使用该代码模块导致侵权的，可认定开源软件开发者、提供者不承担侵权责任。把这两处合起来看，"豁免"至少挂钩三件事：
- 许可协议类型与权利限制要看得懂——它不是背景资料，而是责任判定的考量项；
- 安全合规举措是考量项——"我直接拿权重上线、什么都没做"与"我做了校验、隔离与审计"不在同一档；
- 信息披露程度是考量项——公开说明功能与安全风险这四个字，正是把"共享"与"责任转移"区分开的关键。
把豁免前提记成台账
翻译成企业动作：自持开源权重时，把"用了哪一版权重、许可是什么、做了哪些安全措施、向谁说明了什么风险"记成一份可查的台账，这件事在选型阶段看起来像流程负担，在争议阶段就是责任边界的凭据。许可与安全说明的版本核对适合脚本化：用命令行 逐份比对，企业级环曜 CLI 本地化部署 的客户环境把这一步放进年度检查。我们在开源权重追平前沿 4.4 个月：私有化选型与隐性成本里讲过选型与追赶节奏，这里补的是同一件事的另一半：责任侧要留什么。
另外，开源协议本身对商业使用与再分发有不同限制，这类"隐形绑定"的核查清单可参考私有化 Agent 的隐形绑定与开源协议合规。
还有一层容易被忽略：调用边界。若自持权重跑在同一套执行层上，工具与插件能碰什么、不能碰什么建议一并收口，这样事后才能定位是哪一次调用产生了争议输出，环曜Claw 的业务系统集成 能力可以把调用收在一层，定位时不必逐系统翻日志。
四、幻觉侵权的规则落点：第 7 条与"通知—停止生成"
企业常问的一句话是"AI 说错了谁负责"。从《意见》看，与生成内容侵权直接对应的是第 7 条：AI 自动生成内容侵害他人名誉权、隐私权等人格权益，经权利人通知，服务提供者未及时采取停止生成侵权内容等必要措施的，就造成的损害依法承担侵权责任；通知应当包含构成侵权的初步证据与权利人真实身份信息。
第 7 条的另一半：用户责任
同一条还划了另一半责任：网络用户通过输入侵权提示词等方式恶意诱导生成侵权内容并造成他人损害的，该用户承担侵权责任；服务提供者经通知后未及时采取停止生成、屏蔽相关生成指令等必要措施，权利人可以依照民法典第 1195 条请求用户与服务提供者承担民事责任。
这条规则对企业提出了一个非常工程化的要求：你得有一条"收到通知 → 定位内容 → 停止生成/屏蔽指令 → 留档"的通道，并且要有可证明的时限。 它和内部质量管理不是一回事——内部弃权与复核解决"尽量别错"，这条通道解决的是"错了之后能不能及时止损"。处置时引用的依据（哪一版内部规则、哪一份风险说明）要能当场调出，把处置依据收进知识检索 入口是常见做法，企业级环曜知识库本地化部署 覆盖的正是这一段。若生成链路横跨多个业务系统，建议把停止生成与屏蔽指令的入口收在同一层，环曜Claw 的任务自动化 能力可以在不改业务系统的前提下统一执行处置动作，处置记录也只需在一处留档。
生成内容的责任分配与举证：第 12 条要什么材料
第 12 条针对 AI 生成内容侵害著作权的情形，给出两条对企业的硬提示：
其一，责任分配看六个因素：AI 服务类型、行业特点、训练数据来源、各方参与度、采取的必要措施、获利情况。也就是说，"我只是使用者"不足以免责，参与度与获利会被一并考量。
其二，举证方向被写明了：开发者提出不侵权抗辩的，应责令其提供训练数据来源、训练过程记录、模型运行模式及科学理论依据等佐证；而使用者明知或应知在先作品存在，利用 AI 生成与在先作品实质相似的作品且无合理抗辩理由的，应承担侵权责任。
这里要划清与站内既有两篇的边界——在私有环境 里交付的项目会把训练数据来源与版本记录纳入交付材料，企业级环曜 Agent 本地化部署 的验收清单里对应"数据类"一栏，不属于临时补件。讲企业用 Agent 产出的内容著作权归谁的那一篇，解决的是内部归属与署名口径。
而讲大模型幻觉在严肃业务里怎么解决、出了错谁负责的那一篇，解决的是内部流程与定责。本文补的是第三层——真的进入争议程序时，训练数据来源与过程记录这类材料你手上有没有。三者的关系是：内部约定让责任可分配，内部流程让错误可发现，而证据留存让责任可举证。
五、合规落位四步：从条文到交付物
把上面几条收拢成一套可执行动作，建议按四步走：识别角色 → 对标条文 → 备齐证据 → 写进合同。
| 步骤 | 做什么 | 产出物 |
|---|---|---|
| 识别角色 | 在每一类 AI 使用中确认自己是使用者、后续开发者、提供者还是兼有多重角色 | 角色清单（按场景逐一标注） |
| 对标条文 | 把第 3、7、12、13 条逐条对到自己的场景上，标出"有要求但没做"的项 | 条文对照表（差异项可排期） |
| 备齐证据 | 证据按"能证明措施存在"组织，而不是按部门存放 | 四类材料：权限与拦截配置、风险说明与警示文本、训练数据与版本记录、通知处置留痕 |
| 写进合同 | 与供应商、客户、外包方的责任边界用条款固定下来 | 合同附件（含开源许可与安全说明、处置时限） |
四步都落在纸面上，不需要先采购系统。其中第 2 步的条文对照表适合做成可复跑的对照动作：把条文要点与内部措施列成两栏，用命令行 导出一次即可看出差异，企业级环曜 CLI 本地化部署 的客户环境把它并进年度合规检查，改一次留一次记录。
一份可对照的四类证据清单
第 2 步之后，多数团队会卡在"证据怎么组织"：按部门存放，遇到争议时凑不齐；按案件临时拼，平时又没人维护。更稳的做法是按"能证明措施存在"来组织，分四类各建一份——同一类材料既能支撑内部审计，也能在争议时直接引出。
四类证据分别对应哪一条
其一，控制类（对应第 3 条"预防措施"）：权限表、审批链配置、拦截与熔断记录、撤回设计说明。这类材料的工程化程度最高，通常就是权限表与交互日志 的归档动作，在私有环境 里交付的项目会把它们列为上线验收项，企业级环曜 Agent 本地化部署 的客户环境通常把这一套与业务系统分开维护，避免与业务数据混在一起。
其二，说明类（对应第 9 条"真实说明和明确警示"、第 13 条"公开说明功能和安全风险"）：产品说明、适用场景与固有局限说明、对外警示文本。这一类的常见缺口是"只写了功能、没写局限"——而条文恰恰点名要说明固有局限与可预见风险。说明文本的版本管理建议与产品说明书同步迭代，用命令行 出一次差异对照即可，企业级环曜 CLI 本地化部署 的环境便于把说明文本纳入发布流程，避免对外文档与系统实际能力脱节。
数据类与处置类为什么容易缺
其三，数据类（对应第 6 条、第 12 条）：训练与语料的来源证明、版本记录、标注与复核记录；涉及个人信息时，是否属于"已合法公开且个人未明确拒绝"，以及对个人权益有重大影响的情形是否取得同意。这类材料的收集属于文档检索 与版本管理问题，企业级环曜知识库本地化部署 承接的正是把依据与版本收进统一入口这一段，争议时按版本调取而不是翻共享盘。
其四，处置类（对应第 7 条）：通知接收渠道、定位与停止生成的记录、屏蔽指令的操作留档、时限证据。这类要求建议在流程里写死：谁在几个工作小时内响应、由谁确认、留哪几项记录。处置动作建议由执行网关统一执行并留档，环曜Claw 的任务自动化 能力可以在不改业务系统的前提下完成停止生成与屏蔽，记录集中在一处，事后核对时不必逐系统抓取。
两组边界，别把条文读大或读小
别读大：第 9 条对"产品责任"的表述限定在以实物为载体的人工智能产品，并不是所有 AI 服务都自动套用产品责任；第 6 条对已合法公开个人信息的处理也给了"合理范围内、个人未明确拒绝"的空间，并非一律需要单独同意。
别读小：第 16 条把数据使用与对抗样本攻击等损害 AI 运行安全的行为一并纳入，第 17—20 条还专门讲证据认定与规制利用 AI 伪造证据。也就是说，"用 AI 攻击"和"用 AI 造假证据"这两类行为同样在这份文件的视野里，对应的防护（对抗样本测试、内容留样与来源说明）建议一并纳入。
一组可核对的材料留存数据
数据来源与口径：以环曜 2025 年 3 月至 2026 年 8 月完成验收的 41 个本地化部署项目为样本（口径：完成验收；时间窗：2025 年 3 月 1 日至 2026 年 8 月 31 日；样本量：41 个），其中 8 个在交付材料里包含"训练数据来源与版本记录"，6 个包含"开源许可与安全风险说明"；未纳入这两类材料的 33 个里，有 5 个在事后需要说明输出依据时只能提供部分材料。差距不在技术，而在交付清单里有没有这一栏。
结语：把条文变成三张纸
这份《意见》对企业的实操含义，可以压缩成三张纸：一张角色清单（我是谁）、一张条文对照表（哪条要求我没做到）、一份证据目录（我能拿出什么）。三张纸不涉及任何采购决策，今天就能开始写。
如果只做一件事，建议做"证据目录"：把控制、说明、数据、处置四类材料各列一行，逐个标注"已有 / 部分有 / 没有"。若要把这份目录变成可移交的交付物，企业级环曜 Agent 本地化部署 在私有环境 里交付时会把目录与权限表、审计留痕 一起移交，而不是只交一套系统。这份目录在争议里就是责任边界的地图。你们的 Agent 项目里，这四类材料现在能拿出几类？欢迎在评论区说说卡在哪一类。
常见问题 FAQ
Q：Q1 这份《意见》是法律法规吗，有强制力吗？
它不是法律，而是最高人民法院发布的审判指导性文件（法发〔2026〕10 号），依据民法典、个人信息保护法、著作权法等现行法律提出裁判理念与规则指引。它的强制力体现在法院审理涉 AI 纠纷时按此把握裁判尺度，因此对企业的影响是"进入争议后按这套规则认定责任"。
Q：Q2 "AI 幻觉"侵权在《意见》里对应哪一条？
《意见》正文并未使用"AI 幻觉"一词，该表述出现在起草背景与主要考虑部分。对应规则是第 7 条：AI 自动生成内容侵害他人名誉权、隐私权等人格权益，经权利人通知，服务提供者未及时采取停止生成等必要措施的，就此承担侵权责任；恶意输入侵权提示词的用户承担相应责任。这一条的关键不是"别生成错内容"，而是"收到通知后有没有及时处置"。
Q：Q3 我们只是"使用者"、又自持了开源权重，责任怎么算？
先看使用者一侧：第 12 条列出的责任分配因素包含行业特点、各方参与度、采取的必要措施与获利情况，同时明确使用者明知或应知在先作品存在、利用 AI 生成与在先作品实质相似的作品且无合理抗辩理由的，应承担侵权责任——"我是使用者"不是豁免理由。 再看自持开源权重一侧：按第 13 条的考量项至少做三件事——看懂许可协议类型与权利限制、留下安全合规举措的记录（校验、隔离、审计等）、做到信息披露（公开说明功能与安全风险）。豁免是"适当豁免"，不是自动豁免。
Q：Q4 培训数据与版本记录要留到什么粒度？
按第 12 条的举证方向，开发者主张不侵权时需提供训练数据来源、训练过程记录、模型运行模式及科学理论依据。落到日常，建议至少留存三层：语料来源与授权依据、版本与更新记录、评测与复核记录。这些材料统一收口后按版本调取省事，把制度文件与数据来源收进统一的文档检索入口是常见做法，企业级环曜知识库本地化部署 的交付里通常就包含这一段。
Q：Q5 我们对外卖的硬件里嵌了 AI 能力，要注意什么？
第 9 条针对以实物为载体的人工智能产品适用产品责任，认定不合理危险时会综合考量产品性质与用途、自主学习能力、升级更新情况、用户控制程度、是否符合国家标准或行业标准，并重点审查是否就适用场景、固有局限及可预见风险作了真实说明和明确警示。因此说明书与警示文本要写全"局限"，不能只写功能。
Q：Q6 选服务商时哪些条款值得写进合同？本地化部署会让责任更清楚吗？
合同建议写三类：① 责任与角色划分（谁对生成内容负责、谁负责处置通知）；② 处置时限与配合义务（收到通知后多久定位与停止、留哪些记录）；③ 材料交付义务（开源许可与安全说明、训练数据来源与版本记录的提供范围）。 至于本地化部署：会更清楚，前提是留痕做到位。数据与运行环境在自有边界内，权限、处置记录与版本台账更容易收口和调取，第 3 条要的"预防措施"与第 7 条要的"及时处置"都更容易举证；但如果日志只存不查、材料散在各团队手里，本地化不会自动带来举证优势。若同环境里还跑垂类定制模型，企业级大模型微调本地化部署 的样本与权重 版本也要并入同一份材料目录，否则庭上说不清是哪一版产生的输出。这三类条款可以作为附件逐项对齐，我们的本地化部署服务页里有现成的材料清单可参照。
