【开源许可与版权工程】中国 AIGC 司法案例集：从春风画面到奥特曼案的工程启示

2023 年以后，中国是全球为数不多、在较短时间内连续输出多份实质性 AIGC（Artificial Intelligence Generated Content，生成式人工智能内容）司法判决的法域。北京互联网法院 2023 年 11 月宣判的”春风送来了温柔”案正面承认了 Stable Diffusion 生成图的可版权性；广州互联网法院 2024 年初判决的奥特曼（Ultraman）案在全球范围内第一次让 AIGC 服务提供者为其生成结果承担直接侵权责任；北京互联网法院同年审理的配音师殷某案，又让”声音权益”在 AIGC 时代获得一个可操作的裁判范本。

这些案件的工程意义远大于它们的赔偿金额：它们在法律侧固定下来的判断框架——独创性、平台注意义务、训练数据来源、生成物标识——几乎会原样映射到工程侧的每一个合规流程上。本文以工程师的视角逐一梳理这批判例，并与美国 Thaler v. Perlmutter、Andersen v. Stability AI、NYT v. OpenAI 及欧盟 EU AI Act 的相应规则进行横向比较，最后给出一份可落地的工程合规清单。

说明：本文涉及的判决书编号与赔偿金额均以公开报道与公开法律资料为准，部分 2025–2026 年的案件截至写作时仍处一审或二审程序中，结论可能变化。文末参考资料章节给出了每个案件可检索的公开来源；具体以中国裁判文书网、各互联网法院官网、最高人民法院公报及官方新闻发布为准。本文不构成法律意见。

一、中国 AIGC 司法的基础框架

讨论具体判例前，需要先看清中国法院在审理生成式 AI 案件时赖以适用的规范层级。与著作权法单兵作战的 GPL 案件不同，AIGC 案件往往在一个判决中同时援引著作权法、民法典人格权编、不正当竞争法、互联网信息服务相关行政法规、以及多部专门针对生成式 AI 的部门规章。

1.1 著作权法中的”独创性”标准

《中华人民共和国著作权法》（2020 年修订）第 3 条将作品定义为”文学、艺术和科学领域内具有独创性并能以一定形式表现的智力成果”。独创性（originality）在中国司法实践中长期坚持”独立创作 + 具有一定程度的智力创造”的双要件结构。对 AIGC 而言，问题聚焦在两端：一端是用户的提示词与参数选择是否构成”智力创造”；另一端是大模型的算法生成过程是否会让最终输出丧失独创性。

值得注意的是，中国著作权法明文只承认”自然人、法人或非法人组织”作为作者，因此”AI 作为作者”在现行法框架下是被排除的。这一点和美国版权局 2023 年的 Zarya of the Dawn 决定、2023 年 Thaler v. Perlmutter 一审判决的结论一致。

1.2 民法典中的人格权规则

《民法典》第四编”人格权”是 AIGC 案件的另一大规范来源。第 1018 条到第 1023 条分别规定肖像权、声音权益、姓名权的保护规则，其中第 1023 条第二款明确规定”对自然人声音的保护，参照适用肖像权保护的有关规定”。这一条在 2024 年殷某配音师案中第一次被大规模援引到 AIGC 语境。

人格权条款在 AIGC 场景中的独特价值在于：它不要求”作品”或”作者”，只要求”可识别性”——只要 AI 生成的声音或肖像能让公众联想到特定自然人，就落入保护范围，而不论其背后的训练数据是否合法获取。

值得特别提醒的是，民法典第 990 条还引入了”具体人格权 + 一般人格权”的二元结构，对于 AIGC 生成的新型人格利益损害（如”数字分身”、“语音外貌同时被克隆”等），即使不落入具体人格权的字面范围，也可以通过一般人格权兜底保护。这给未来几年围绕”数字孪生”、“数字遗产”、“AI 复活亲人”的争议留下了制度接口。

1.3 专门性部门规章

2022–2025 年，中国针对生成式 AI 集中出台了三部部门规章：

• 《互联网信息服务深度合成管理规定》（2022 年 11 月发布，2023 年 1 月 10 日施行）：首次对深度合成（deep synthesis）服务提供者课以显著标识义务；
• 《生成式人工智能服务管理暂行办法》（七部门联合发布，2023 年 8 月 15 日施行）：将预训练数据合法性、生成内容合规性、备案制一并纳入监管；
• 《人工智能生成合成内容标识办法》（国家网信办等，2025 年正式施行）：统一规定显式标识与隐式标识（metadata）两种形式，并对传播平台施加二次标识义务。

这些规章虽然是行政法层面的规则，但在民事诉讼中常常被法院作为认定”注意义务”的参考，这一点在奥特曼案 I 与 II 中表现得非常明显。

1.4 司法解释与典型案例机制

中国不是判例法国家，但最高人民法院通过”指导性案例”、“参考案例”、“年度十大知识产权案件”等机制实质形成类似判例的效果。北京互联网法院春风案、广州互联网法院奥特曼案均进入 2024 年最高法知识产权典型案件名单，其裁判思路事实上已经成为下级法院裁判 AIGC 案件的”软性先例”。

1.5 互联网法院的集中管辖

北京、广州、杭州三家互联网法院对涉网著作权、涉网人格权等类型案件享有集中管辖权。这使得大量 AIGC 案件集中在这三家法院，其法官也是中国接触 AIGC 争议最密集、最专业的群体。由于三家互联网法院内部建立了案例交流机制，判决思路往往高度一致，这也进一步强化了”软性先例”效应。

对工程团队的含义：一旦在一家互联网法院形成不利判决，另外两家复制的概率非常高，应急合规的优先级窗口很短。

1.6 行政监管与民事诉讼的双轨

中国 AIGC 合规的独特之处在于两条线平行推进：

• 行政监管线：网信办 + 国家标准化委员会 + 文旅部 + 公安部，体现为备案制、算法备案、深度合成备案、安全评估等事前审查
• 民事诉讼线：权利人通过互联网法院提起诉讼，主张停止侵权 + 赔偿损失

行政合规是准入门槛（不备案即不能对外服务），民事合规是持续义务（即使备案通过，一旦被诉仍会败诉）。工程团队不能把合规外包给”备案团队”了事，因为备案关心的是”是否有流程”，而民事诉讼关心的是”是否有实际效果”。

二、案例 1：AI 生成图可版权性案（春风送来了温柔）

2.1 案情事实

2023 年 2 月，原告李某使用开源模型 Stable Diffusion 在本地生成了一张年轻亚洲女性的写实风格肖像，配以标题”春风送来了温柔”并发布在小红书（RED）平台。被告刘某是百家号作者，随后在其百家号文章中使用了该图片，且未保留原作者署名与水印。李某以侵犯署名权与信息网络传播权为由诉至北京互联网法院。

李某在诉讼中提供了完整的证据链：Stable Diffusion 软件的本地界面截图、使用的正向提示词（positive prompt）、负向提示词（negative prompt）、使用的基础模型（checkpoint）与 LoRA 权重、CFG scale、采样器、随机种子（seed）、以及生成过程中多次调整参数后的中间版本。这份证据后来成为中国第一份被法院正式采信的”AIGC 创作过程日志”。

2.2 争议焦点

• 涉案图片是否构成《著作权法》第 3 条意义上的作品？
• 若构成作品，李某是否为作者，享有何种权利？
• 被告擅自使用是否构成侵权？

2.3 裁判要点

北京互联网法院于 2023 年 11 月 27 日作出一审判决，认定涉案图片构成”美术作品”，原告为该作品的作者，被告构成侵权，判令被告公开赔礼道歉并赔偿经济损失 500 元。该判决书编号为（2023）京 0491 民初 11279 号。判决在以下几点上具有方法论意义：

1. 独创性判断锚定在”人”的智力投入。法院并没有把”AI 生成”作为独立的考察维度，而是回到著作权法的本位——审查人类用户在生成过程中是否做出了与作品表达直接相关的创造性选择。本案中，提示词的反复调整、模型与参数的选取、多轮迭代择优等行为被认定为构成独创性的智力投入。
2. “机器辅助”而非”机器创作”。法院将 Stable Diffusion 定性为创作工具，类比照相机之于摄影作品；工具的自动化程度高并不必然让使用者失去作者身份。
3. 作者只能是自然人。法院明确否定了”模型开发者”或”AI 本身”作为作者的可能性，回到著作权法第 11 条的文义解释。

2.4 与域外判例的对比

• Thaler v. Perlmutter（美国哥伦比亚特区联邦地区法院，2023 年 8 月）：Thaler 试图以”Creativity Machine”为作者为一幅图像申请版权登记，被版权局驳回后起诉，法院维持驳回，理由是”人类作者身份（human authorship）是版权的基础”。与中国春风案的差异在于：Thaler 明确请求将 AI 登记为作者；而李某主张的是自己作为使用者的作者身份。事实上两国法院在”AI 不是作者”这一点上立场完全一致。
• Zarya of the Dawn（美国版权局，2023 年 2 月）：艺术家 Kris Kashtanova 为其漫画书申请版权，版权局最终登记了文字与排版部分，但拒绝登记由 Midjourney 生成的单幅图像，理由是”用户对模型输出的控制不足以构成作者身份”。这是春风案与美国实践出现分化的第一个切口：北京互联网法院在 Stable Diffusion 场景下承认了用户的作者身份，而美国版权局在 Midjourney 场景下否认了这一点。
• 分化的技术根源：Stable Diffusion 的本地部署允许用户精确控制 seed、checkpoint、LoRA 等底层参数，美国版权局认为 Midjourney 的 web 交互只暴露了文本提示这一薄弱接口，输出具有较强的”非控性”。这意味着，同样是扩散模型，暴露的参数面越宽、用户的可控性越强，作品认定的胜率就越高。

2.5 工程启示

• 保留创作过程日志是 AIGC 产品的法务底层需求。prompt、negative prompt、seed、采样器、steps、CFG、checkpoint、LoRA 名称与版本号、每一次迭代的中间产物与时间戳，都应作为可选元数据写入输出文件（如 PNG tEXt chunk）或后台数据库。
• 暴露可控参数面会增强用户的作者身份主张，但同时意味着平台对输出负有更强的可预期性审查义务——这是一把双刃剑。
• 水印与署名策略应作为产品默认行为。本案中用户的水印被被告裁切去除，法院在赔偿数额认定中将其作为主观恶意的证据。

一句话启示：把每一次生成当成一次”有版权的摄影”来记录。

2.6 工程落地：一个可借鉴的元数据结构

基于春风案对证据材料的采信标准，我们可以设计一份”最小可采信”的创作过程元数据结构。这份结构可以作为产品后端数据库的表设计参考，也可以作为输出文件中嵌入的旁路清单：

• generation_id：本次生成的全局唯一 ID
• user_id：创作者标识，需可追溯真实自然人
• created_at：生成时间（UTC，精确到毫秒）
• model_family：底模名称与版本，如 stable-diffusion-xl-1.0
• loras：使用的 LoRA 列表，含名称、版本、权重
• prompt_positive / prompt_negative：正向与反向提示词原文
• sampler / steps / cfg_scale / seed：采样器、步数、CFG 强度、随机种子
• iteration_chain：从初版到终版的所有中间生成的 ID 列表
• manual_selections：每一轮用户做出的选择性操作（如 inpaint 蒙版、局部重绘区域）
• signature：用平台密钥对以上字段做 HMAC 或数字签名，用于事后反篡改举证

这份清单在发生侵权纠纷时既可以用来证明用户自己是作者（对应春风案原告角色），也可以在被诉侵权时证明用户对输出结果存在实质性选择（对应奥特曼案被告的平台抗辩）。

2.7 对产品 UX 的反向影响

春风案判决之后，国内外多款 AIGC 产品悄悄调整了 UX：

• 默认暴露 seed 字段，允许用户复现与微调；
• 将 prompt 与参数作为”作品”的一等公民展示，鼓励用户像写代码一样写 prompt；
• 提供”创作过程回放”视图，把多轮迭代的缩略图串成时间线。

这些 UX 变化不仅提升了可玩性，也事实上把”独创性证据”自动沉淀了下来。这是一次”司法判决反向塑造产品设计”的典型样本。

2.8 对”模型即作者”理论的间接否定

春风案判决在论证过程中反复强调”人的智力活动”这一要素，与之形成对照的是”模型的算法活动”。法院事实上把生成分成两段：

• 前段：用户选择模型、编写 prompt、调整参数、迭代挑选——这是智力活动
• 后段：模型根据输入进行计算并输出像素——这是机械活动

作品性来自于前段对后段的”控制”与”筛选”，而不是后段本身的”生成”。这一分段认识与美国 Thaler v. Perlmutter 所依据的 “human authorship” 原理是相通的：机器的计算过程无论多复杂，都不构成作者身份的来源。

2.9 “自主性越强，版权越弱”的悖论

一个值得警惕的隐含推论：当模型的自主性越强（如 agent 自主地决定分镜、色彩、元素），用户主张作品权的空间越窄。从春风案（使用者暴露到 seed / LoRA 级别）到 Midjourney（使用者只输入一句话）再到”AI 导演 agent”（用户只说”给我来一部科幻片”），用户的智力投入曲线是下降的，作品权主张的强度也同步下降。

这意味着更”高级”的 AI 产品可能反而更难为用户创造版权，工程团队在设计 agent 类产品时应考虑如何在保持自动化的同时，为用户留下足够的”选择点”。

三、案例 2：Stable Diffusion 相关训练数据侵权争议

3.1 案情事实

根据公开报道，2023–2024 年间国内有若干案件涉及 Stable Diffusion 与其衍生模型的训练数据合法性。因为 Stable Diffusion 基础权重由 Stability AI 在海外发布，国内诉讼多围绕”国内微调服务商”是否对其使用的训练数据尽到了审查义务展开，原告多为 UGC 平台上的独立画师或中小权利人。由于大量案件以撤诉、和解或调解结案，能作为公开裁判文书引用的不多，但争议焦点已相当清晰。

3.2 争议焦点

• 训练数据是否构成对原始图像的复制行为？若构成，是否符合著作权法第 24 条”合理使用”的十三种法定情形之一？
• 模型权重本身是否构成对训练数据的”实质性再现”？
• 微调服务商（通常基于 LAION-5B 下载或爬虫采集数据）是否能援引”非表达性使用”（non-expressive use）抗辩？

3.3 裁判趋势

截至写作时，中国法院尚未在公开判决中系统回答这些问题，但从已公布的判决理由可以观察到三点倾向：

1. 合理使用的十三项法定情形不宜扩张解释。著作权法第 24 条采用封闭式列举，“模型训练”不在其中；希望在中国通过判例打开日本第 30 条之 4 式的”非享受目的利用”窗口，短期内难度较大。
2. 训练数据的合法来源举证责任在被告。一旦原告初步证明自己的作品可能出现在训练集（如 LAION URL 列表命中），被告需要证明自己获取这些数据有合法依据；空白举证通常被不利推定。
3. “模型是否再现训练数据”采取结果导向。如果用户能轻易让模型吐出与训练数据近乎一致的输出（memorization），法院倾向于认定模型本身承载了复制件。

3.4 与域外判例的对比

• Andersen v. Stability AI（美国加州北区联邦地区法院，2023 起诉，2024 年裁定部分主张可继续）：原告画师群体主张 Stable Diffusion 训练侵犯复制权与演绎权。法院在 2024 年裁定允许诱导侵权等部分诉请继续审理，但驳回了关于每个输出都是侵权复制件的宽泛主张。与中国法院的路径相比，美国法院更依赖事实发现（discovery）阶段来确认训练集命中率。
• Getty Images v. Stability AI（英国高等法院 + 美国特拉华州联邦地区法院）：Getty 主张 Stability AI 擅自使用其图库进行训练。英国案件已进入庭审，美国案件在 discovery 阶段僵持。与中国案件相比，英美法院愿意在 discovery 阶段强制被告披露训练数据清单，这是一个中国法院目前较少采用的工具。
• 日本著作权法第 30 条之 4：允许以”非享受目的”使用作品进行模型训练，被视为全球对模型训练最友好的法域。中国法院不具备这一制度基础。

3.5 工程启示

• 训练数据清单要能出证。每一批训练数据的来源 URL、license、抓取时间、robots.txt 快照、是否经过 CC BY-SA 等许可标注，都应在数据管道中作为元数据持久化。
• 输出端防记忆化（memorization）。使用 membership inference 测试、去重训练、差分隐私等手段降低 verbatim 输出概率。
• 国内发布模型前做 opt-out 审查。对国内主流图库、漫画平台、UGC 画师社区建立白名单/黑名单清单，避免默认全网抓取。

一句话启示：训练数据合法性的举证责任在你，不在原告。

3.6 一个实务化的”训练数据合规清单”

以下清单是综合多起训练数据相关案件的争议焦点整理出的工程落地要点，可作为数据团队交付模型前的最终 checklist：

• 每一个训练样本绑定到一个来源 URL 或数据合作方 ID
• 对每个来源记录 crawl_time / robots_snapshot_hash / license_tag
• license 标签至少区分 PD（公有领域）/ CC-BY / CC-BY-SA / CC-BY-NC / ARR（保留全部权利）/ UNKNOWN
• 对 UNKNOWN 来源做二次审查或移除
• 建立中文互联网 UGC 高权重站点黑名单（如涉及美术师、摄影师集中社区的原创内容）
• 记录每次训练任务使用的数据子集哈希，便于纠纷发生后精准定位
• 为权利人提供自助查询接口：输入 URL 或作品哈希，返回”是否被用于训练”的查询结果
• 为权利人提供 opt-out 机制与响应 SLA（如 30 个自然日内完成剔除或重训练排期）

这一清单的精神与欧盟 AI Act 第 53 条的”训练数据摘要披露”要求方向一致，可以同时满足中国、欧盟两套监管框架的基本要求。

3.7 Memorization 与”实质再现”的工程判断

法院在评估”模型是否再现训练数据”时，通常依赖原告提交的”输出 vs. 训练集样本”的 side-by-side 对比。工程团队可以用如下方法提前自查：

1. 构造一批典型提示词（作品名、画师昵称、作品关键描述）；
2. 用当前模型生成若干轮输出；
3. 对输出与训练集做 pHash、CLIP、LPIPS 三类相似度比对；
4. 对相似度超阈值的样本判定为”高记忆化”；
5. 对高记忆化样本进行去重训练、引入差分隐私、或对 prompt 做软约束。

这一 pipeline 应作为模型上线前的标准评估项，并把评估结果固化到 Model Card 中。

四、案例 3：奥特曼案 I（广州互联网法院）

4.1 案情事实

原告上海新创华文化发展有限公司系日本圆谷制作株式会社（Tsuburaya Productions）在中国大陆的独占被授权人，享有”奥特曼”系列美术形象的著作权独占许可权。被告运营一款名为 Tab 的生成式 AI 网页服务，用户通过接入第三方大模型的 API 在平台上生成图像。原告以普通用户身份输入”生成一张奥特曼”、“生成一个戴着头盔的奥特曼”等提示词，平台均输出与奥特曼高度相似的图像。原告随后起诉，要求被告停止侵权并赔偿损失。

根据公开报道，本案一审判决于 2024 年 2 月由广州互联网法院作出，被广泛称为”全球首例生成式 AI 服务提供者侵犯著作权民事判决”。

4.2 争议焦点

• 平台输出的图像是否与原告享有著作权的奥特曼美术形象构成实质性相似？
• 平台作为生成式 AI 服务提供者，应承担何种性质的侵权责任：直接侵权、帮助侵权、还是注意义务违反？
• 平台是否享有”避风港”（notice-and-takedown）抗辩？

4.3 裁判要点

广州互联网法院在判决中明确：

1. 生成结果构成实质性相似。法院采取整体比对方法，认定输出图像再现了奥特曼系列形象的独创性表达元素。
2. 平台为生成式 AI 服务提供者，承担相应侵权责任。法院引用《生成式人工智能服务管理暂行办法》第 9 条、第 14 条关于服务提供者责任的规定，认定平台负有”生成内容合规”的注意义务。
3. 平台不能简单援引”技术中立”或”避风港”。与传统 UGC 平台不同，AIGC 平台通过提供训练、推理与生成能力直接参与了内容生产过程，这使其角色更接近”内容提供者”。
4. 要求平台采取措施防止再次生成。判决要求被告采取包括但不限于关键词过滤、输出图像识别、对用户投诉的快速响应等”合理且必要”的措施。根据公开报道，本案判赔金额在人民币一万元数量级，金额不大，但确立的行为义务影响深远。

4.4 与域外对比

• 美国：截至写作时，美国尚无生效判决要求 AIGC 平台承担直接侵权责任，Andersen v. Stability AI 与 NYT v. OpenAI 均还在早期阶段。美国版权法的 DMCA Safe Harbor 原本是为 UGC 平台设计的，其在 AIGC 场景的适用尚未获得法院明确背书。
• 欧盟：EU AI Act（2024 年正式通过）第 53 条要求通用人工智能（GPAI）模型提供者公开训练数据的”足够详细摘要”，并建立著作权合规政策。这是事前规则，侧重预防；而中国奥特曼案是事后规则，侧重救济。
• 日本：文化厅 2024 年《关于 AI 与著作权的考察》指出，生成阶段输出侵权作品时，以”是否与既有作品具有类似性和依据性”为标准，与中国奥特曼案的实质性相似判断接近。

4.5 工程启示

• 关键词黑名单不是可选项。在文本到图像服务中，知名 IP（奥特曼、米老鼠、皮卡丘、蜘蛛侠等）应进入前置关键词过滤与同义词扩展表。
• 输出端需要二次识别。可以使用 CLIP 相似度、pHash 近似、以及 IP 持有人的参考图比对，对输出图像做再次风险分级。
• 建立”AIGC 版侵权通知”流程。参考 DMCA/《信息网络传播权保护条例》通知-删除制度，为权利人提供可机读的投诉渠道，并在内部把”停止继续生成”作为处置措施之一。
• 不要依赖避风港抗辩。在 AIGC 场景，法院很可能不承认平台的”单纯管道”身份。

一句话启示：AIGC 平台不是 UGC 平台，“避风港”只是一层薄冰。

4.6 关键词过滤系统的工程分层

奥特曼案判决中的”合理必要措施”在实务中最常被翻译成一套关键词过滤系统。一个具备多层防御的过滤系统通常包含：

1. 字面层：直接匹配 IP 名称的中英日文写法（奥特曼、ウルトラマン、Ultraman、Ultra Seven）
2. 同义层：常见别名、昵称、社区梗（如”打小怪兽的”）
3. 拼音层：全拼（aotieman）、首字母（atm）、谐音（奥特慢）
4. 视觉特征描述层：不含 IP 名称但指向该形象的描述（“红白配色的巨大外星英雄、头部有晶体、胸口有计时器”）
5. 图文联动层：用户上传参考图时做 CLIP 相似度匹配
6. 输出层兜底：生成后对图像做 IP 相似度识别，命中即不返回

实际部署中，1–4 层部署在 prompt 预处理阶段，5–6 层部署在推理前与推理后两个节点。这套”深度防御”架构是应对奥特曼类案件的事实标准。

4.7 赔偿金额小，行为义务大

奥特曼案的经济赔偿只有数万元量级，远远覆盖不了被告的实际开发成本，但它确立的”关键词过滤 + 输出识别 + 投诉响应”三件套行为义务，事实上把整个行业的合规基线抬高了一大截。这一特征和中国 GPL 第一案的”数额不大、规则价值大”非常相似（参见 第 15 篇）。

4.8 从奥特曼到其他 IP：判决外溢效应

奥特曼案的一套裁判规则几乎可以无差别地套用到其他知名美术形象上。可预期的后续潜在诉讼标的包括：

• 迪士尼系列形象（米老鼠、唐老鸭、皮克斯角色群）
• 宝可梦系列形象（皮卡丘、伊布等）
• 国内头部动漫 IP（喜羊羊、熊出没、大圣归来、哪吒等）
• 知名体育形象与吉祥物（冰墩墩、雪容融等）
• 知名游戏形象（王者荣耀、原神、崩坏系列角色群）

对于做 UGC + AIGC 混合产品的团队，应把这一名单上的 IP 进行前置打标，并在模型训练阶段做去重与过滤。国内部分主流图像生成平台已经在 2024–2025 年间陆续补齐了这套黑名单。

4.9 服务提供者的内部组织设计

奥特曼案对 AIGC 服务提供者提出的”合理注意义务”并非一个单点技术问题，而是一个组织问题。一个合格的 AIGC 平台往往需要以下岗位或职能：

• 内容审核工程师：负责关键词库、相似度阈值的持续运营
• 法务接口：处理权利人投诉、准备诉讼应诉材料
• 模型安全研究员：研究 memorization 评估、越狱攻击防御
• 数据治理专员：管理训练数据清单、opt-out 处理、许可证审核
• 合规运营：对接监管部门备案、年度报送、监管约谈

岗位齐备与否，直接决定了平台能否在真实诉讼中出具令法院认可的”合理必要措施”证据。

五、案例 4：奥特曼案 II（上海浦东新区人民法院）

5.1 案情事实

广州奥特曼案之后，同一权利方新创华公司在 2024 年相继在上海浦东新区人民法院提起多起类似诉讼，被告是不同的 AIGC 服务提供者或图像生成产品。截至写作时公开可查的判决不多，媒体报道多集中在案件受理阶段，部分案件据公开资料已判决权利人胜诉并支付赔偿。

5.2 争议焦点的细化

与广州案相比，浦东案把焦点向更上游延伸：

• 被告是自建模型还是调用第三方模型？如果调用第三方，责任是否应向模型提供者追溯？
• 被告训练数据集中是否包含奥特曼系列图像？若包含，是否可类推适用合理使用？
• 用户作为 prompt 提供者是否也应承担部分责任？

5.3 裁判趋势（基于公开资料）

• 浦东法院在公开信息中倾向区分”基础模型（foundation model）“与”应用服务”两层主体：如果应用服务方只是”商业化套壳”基础模型，应用服务方依然要对生成结果负责，但可以在平台间建立追偿关系。
• 对”用户在提示词中主动提及 IP 名称”的情形，法院尚未认定用户构成共同侵权，但已在部分判决中将其作为减轻被告责任或降低赔偿的考量因素。

5.4 工程启示

• 模型调用链路要留证据。每一次调用的上游模型名称、版本、API 厂商、调用时间戳都要可回溯，这是上下游追偿的前提。
• 上游合同应约定生成侵权的责任分担。在采购第三方大模型 API 时，ToS 与 MSA 必须明确：若因模型输出造成侵权，上游模型方是否承担首位或连带责任。
• 把 IP 名称硬过滤前置到用户输入层。在用户提交 prompt 的一刻就进行过滤，而不是等到输出再兜底，可以显著降低赔偿风险。

一句话启示：AIGC 责任链条是”上游模型方 — 应用方 — 用户”三位一体，合同与过滤缺一不可。

5.5 开源模型带来的举证复杂度

当应用方使用的是开源模型（如 Llama、Qwen、DeepSeek 等）时，责任链条会发生微妙变化：开源模型的许可证（参见 第 24 篇 模型许可证深度解析）通常不含”侵权保证（warranty against infringement）“条款，这意味着应用方几乎无法向上游追偿。应用方需要：

• 主动做训练数据审计：通过公开的模型卡片与技术报告还原训练数据大类
• 主动做侵权风险评估：对高风险领域（IP 形象、名人声纹、敏感词）做额外过滤
• 在用户协议中承担”对开源模型输出的终端责任”
• 购买适当的专业责任险（部分保险公司已开始承保 AIGC 侵权风险）

一句话补充：用开源模型不是减轻责任，而是把合规责任 all-in 到自己身上。

六、案例 5：AI 声音侵权案（配音师殷某案）

6.1 案情事实

原告殷某是国内某知名配音演员，长期为多个有声书平台提供配音服务。2023 年，她发现网络上有一款 AI 语音合成产品可以用”她的声音”朗读任意文本；经技术比对，产品使用的模型是以她过往在一家文化公司录制的声音作品为训练数据训练得到的。殷某以侵犯声音权益为由，将录音版权方、AI 软件开发者、模型训练方等多主体一并诉至北京互联网法院。

本案一审判决于 2024 年 4 月作出。根据公开报道，法院判令相关被告赔偿原告经济损失约 25 万元人民币并承担赔礼道歉责任。该案被业界广泛称为”中国 AI 声音侵权第一案”。

6.2 争议焦点

• 声音权益在《民法典》下能否脱离著作权独立主张？
• 录音作品的著作权人是否有权单方面将录音用于训练 AI？
• 训练 AI 后输出”可识别的人声”是否落入声音权益保护范围？

6.3 裁判要点

• 法院援引《民法典》第 1023 条第二款，确认”自然人声音”作为独立于肖像权的人格权益受保护。
• 录音制品的著作权人对录音享有许可使用权，但声音所承载的”可识别的人格利益”不随录音著作权转移；将他人声音用于 AI 训练并对外输出与原声相似的合成语音，属于对声音权益的侵害。
• 本案关键技术事实是”可识别性”——即普通听众能否通过合成音识别出原配音者。法院要求原告提供声纹比对材料，并采纳专家意见确认相似度。

6.4 与域外对比

• 美国 Midler v. Ford Motor Co.（第九巡回上诉法院，1988）：法院支持 Bette Midler 禁止福特广告使用模仿其嗓音的歌手。这一早期判例是”声音可识别性”规则的起点，但美国联邦层面没有统一的声音人格权法典。
• ELVIS Act（Tennessee，2024）：田纳西州在 2024 年通过法律，将声音明确作为可受保护的人格权利并延伸到 AI 场景。中国殷某案的裁判路径与 ELVIS Act 的立法思路异曲同工。
• 欧盟 GDPR：声音属于生物识别数据，加工需有法定依据或同意。训练语音合成模型在欧盟场景下同时承担数据保护与人格权双重合规成本。

6.5 工程启示

• 声纹授权链要完整。从录音原始合同 → 录音制品 → 训练数据清单 → 合成模型 → 输出服务，每一步都要有”使用该声音训练 AI”的明示授权。录音版权的”放心录吧”不能覆盖 AI 训练。
• 可识别性是主要风险锚点。如果输出音色与已知配音者、歌手、演员高度接近，即使训练数据来自公开网络，也应启动复核。
• 模型级与用户级双重防线。平台可以提供”禁用名人声音”黑名单，并在用户上传自定义声音样本时要求授权承诺。

一句话启示：你买了音轨不等于你买了人——AI 训练要单独授权。

6.6 声纹授权链的合同模板要点

结合殷某案判决对”声音权益”的独立保护立场，配音、有声书、语音助手等产业链需要在合同中新增以下条款：

• 用途明示：声明”本次录音是否可用于训练 AI 语音合成模型”；沉默不等于同意
• 可识别性约束：即便授权训练，是否允许输出”可被识别为原声的合成语音”需要单独约定
• 撤回机制：声音人格权不能”永久转让”，配音员保留撤回训练授权的权利，平台需对应地支持样本下架与重训练
• 分发范围：合成语音是否可以分发给第三方客户、是否可用于广告、是否可用于涉政治人物与公众人物的内容
• 安全义务：录音原始文件的加密、访问审计、留存期限
• 违约责任：如果平台未经授权进行 AI 训练，约定高额违约金（而不是仅赔偿”市场价”，因为声音的人格属性决定了损害难以用市场价衡量）

6.7 用户上传声音的产品侧防线

面向 C 端的 AI 语音产品（“克隆自己的声音”）往往是声音侵权的高发地。产品上要注意：

• 活体验证 + 朗读指定文本：确保上传者确实对被克隆的声音拥有人格权
• 禁用名人声纹：对已知公众人物建立声纹黑名单；命中则拒绝克隆
• 水印强制：输出音频强制嵌入可检测水印（参考 AudioSeal、Perth 等开源方案）
• 合成音标注：在 UI 与元数据上显式标注”AI 合成”

6.8 语音克隆的”声音指纹”反查

类似图像 pHash，语音领域也有成熟的声纹嵌入（speaker embedding）技术。产品侧可以建立：

• 名人声纹指纹库：对公众人物的声音样本提取 embedding 并持久化
• 上传时比对：用户上传自定义声音时，与指纹库做相似度比对
• 高相似度拒绝 + 人工复核：超阈值直接拒绝克隆请求，可疑样本进入人工复核队列
• 输出端二次比对：对合成语音再次做声纹识别，确保不会误伤或绕过

这一套声纹反查系统的定位，等同于文生图产品中的 CLIP / pHash 相似度系统，在殷某案的裁判逻辑下属于”合理必要措施”的基本配置。

七、案例 6：深度伪造与 AI 换脸案

7.1 事实类型

2023 年以来，全国多地出现涉”AI 换脸”（face swap）、“AI 脱衣”、“AI 复活亲人”的民事与刑事案件。典型类型包括：

• 民事肖像权侵权：博主未经当事人同意，使用 AI 换脸技术将知名艺人的面部合成到短视频中用于带货，被判赔偿与删除。
• 侵犯公民个人信息罪：行为人批量爬取社交媒体公开照片，运营换脸服务供他人付费使用，构成刑法第 253 条之一规定的侵犯公民个人信息罪。
• 强制侮辱罪、诽谤罪：以 AI 合成色情图像散布他人，在部分案件中被追究刑事责任。典型如 2023 年浙江、江苏、广东等地的若干已公开判决。
• 诈骗罪：以 AI 换脸实时视频通话实施电信诈骗，2023 年包头警方公开的”10 分钟被骗 430 万”案件在全国引起高度关注。

7.2 裁判要点

• 深度合成服务提供者负有显著标识义务。《深度合成管理规定》第 17 条要求对合成内容添加显著标识，未履行可作为平台过错认定的重要依据。
• 肖像权保护不以主观恶意为要件。在未经许可进行 AI 换脸用于商业用途的情形下，即使行为人称”仅供娱乐”，仍会被认定侵权。
• 刑事风险集中在三类罪名：侵犯公民个人信息罪、制作传播淫秽物品牟利罪、诈骗罪。

7.3 工程启示

• 人脸换脸能力是高危能力。任何产品在接入人脸融合、视频换脸、图像去衣等功能前，应进行专门的合规与风控评估，默认禁用，仅在授权场景开启。
• 输入人脸需要活体 + 授权双重校验。把”你要把自己的脸放进去”和”你要把别人的脸放进去”在 UI 与权限上彻底分离。
• 合成内容必须打水印。按 2025 年《人工智能生成合成内容标识办法》的要求，同时实现显式标识（可视水印、角标）与隐式标识（文件 metadata、C2PA Content Credentials）。
• 日志保存时长对齐刑事办案周期。建议至少保存六个月以上的输入输出日志，以便配合警方追溯。

一句话启示：换脸能力的默认状态应当是关闭。

7.4 《深度合成管理规定》的工程落地要点

把 2023 年 1 月施行的《互联网信息服务深度合成管理规定》翻译成工程任务：

• 第 16 条显著标识：合成的文字、语音、图像、视频需要”不影响使用的显著标识”。落地方案：文字末尾加”（本文由 AI 生成）“、图像加角标、视频添加片头说明、语音在开头拼接提示音。
• 第 17 条可能导致公众混淆的深度合成信息（如人脸生成、人脸替换、人脸操控、人物姿态操控、声音生成、对话生成等）：需要在生成内容的合理位置作显著标识。这是”深伪高危名单”，对应的产品能力必须默认关闭 + 特别审批。
• 第 14 条真实身份信息认证：提供深度合成服务的应对用户进行真实身份信息认证。接入手机号 + 实名核验是最低标准。
• 第 10 条内容审核：提供服务的主体应加强管理，对输入数据与生成结果使用技术手段进行审核。

一句话：把法条逐条对照到你的代码仓库，每一条都应该能指到一个具体模块。

7.5 刑事风险的技术预防

AI 换脸相关刑事案件提示工程团队需要建立”反滥用能力”：

• 对批量请求、异常 IP、黄金时段外的 API 调用建立异常检测
• 对生成的疑似色情、未成年人相关内容做强制二次机审 + 人工复核
• 与公安机关建立协作机制，保存不少于 6 个月的可供调取的日志
• 对”复活亲人”等伦理敏感但并非违法的场景，要求用户上传亲属关系证明并签署伦理承诺书

7.6 “AI 复活亲人”场景的单独说明

2024 年以来，借助开源语音合成与面部驱动模型，“AI 复活已故亲人”成为短视频平台上的热门场景。其合规维度独特：

• 人格权延续性：民法典第 994 条规定自然人死亡后，其近亲属可请求侵权人承担民事责任。未经近亲属同意擅自”复活”可能构成侵权
• 数据敏感性：所需素材（人脸、声音）往往来自家庭相册、未公开录像，存在个人信息与隐私双重问题
• 伦理审查：产品应设置年龄门槛、心理健康提示、禁止涉及未成年人家属
• 用途限制：禁止商业化营销用途；禁止用于生成与死者生前形象严重不符的内容

这一场景是 AIGC 合规与伦理合规的交叉点，单靠法律合规清单不足以覆盖，需要产品层面的伦理设计介入。

八、案例 7：训练数据与代码托管平台相关争议

8.1 GitHub 代码训练的中国回响

GitHub Copilot 2022 年在美国被集体诉讼（Doe v. GitHub）后，中国开发者社区对”公共代码被用于训练”是否构成侵权产生广泛讨论。截至写作时，国内尚无公开的以”代码训练侵权”为主要争议的生效判决，但已有若干以不正当竞争法为切入点的案件立案。

8.2 相关案件走向

• 数据抓取类不正当竞争：2024–2025 年，部分大模型厂商被指控通过爬虫大规模抓取特定平台内容用于训练，被原平台方以违反反不正当竞争法第 12 条（互联网专条）为由起诉。裁判趋势倾向于”违反平台 robots.txt + 明显商业获益”即可认定不正当竞争。
• 开源许可证与模型训练：若训练数据中包含 GPL、AGPL 代码，生成输出是否受传染条款影响，目前中国法院尚无判决表态；学术界与产业界的主流观点是”模型权重本身不是衍生作品”，但这一观点尚未获得司法背书。

8.3 工程启示

• 爬虫合规仍是第一道防线。即使未来”模型训练构成合理使用”被确立，违反 robots.txt、违反平台 ToS 的抓取依然可能触发不正当竞争责任。
• 代码训练需考虑许可证隔离。对 GPL/AGPL/SSPL/BSL 等强传染或商业限制许可证的代码，应在训练前打标隔离，在生成端屏蔽整段 verbatim 输出。
• 建立开发者 opt-out 通道。参考 GitHub Copilot 提供的 opt-out 选项，为数据来源方提供退出机制。

一句话启示：训练合法，不代表抓取合法。

8.4 中国法下的训练数据合规四支柱

综合现有案件与部门规章，训练数据合规可以归纳为四个支柱：

1. 来源合法：robots.txt 合规 + 平台 ToS 合规 + 人格权合规
2. 许可清晰：每批数据有可追溯的 license / 合同 / 授权书
3. 权利可救济：提供 opt-out、自助查询、样本下架通道
4. 过程可审计：数据清单可出证，训练任务与数据子集有一一映射

这四支柱既是案件防御策略，也是 EU AI Act 第 53 条、中国《生成式人工智能服务管理暂行办法》第 7 条的共同要求。

8.5 中国 AI 不正当竞争诉讼的新战场

2024–2026 年间，“搜索 AI 回答的内容是否应付费给被引用站点”、“大模型训练爬取社区内容是否构成搭便车”等争议升温。参照百度 vs 搜狗、大众点评 vs 百度等经典互联网专条案件，未来可能形成”AI 搜索 / 训练数据抓取不正当竞争”的独立判例簇。工程上应提前做好：

• 公开声明是否允许 AI 训练（在 robots.txt / AI.txt / llms.txt 中声明）
• 对外输出时按原网站规则标注来源
• 大模型输出答案时提供引用跳转，并设计点击回流机制
• 与主流内容平台建立数据采购合作，把非结构化内容抓取升级为结构化数据授权

8.6 杭州互联网法院的相关典型案件

除北京、广州两家互联网法院外，杭州互联网法院也贡献了若干与 AIGC 相关的典型判决。公开可查的案件类型包括：

• 数据爬虫与反不正当竞争：2024 年前后，杭州互联网法院审理过多起短视频平台、内容社区诉爬虫方的反不正当竞争案件，其中部分爬取行为被指向大模型训练。判决延续了互联网专条的既有立场：破坏平台技术措施、违背诚信原则的抓取被认定为不正当竞争。
• 电商平台涉 AIGC 商品图争议：商家使用 AIGC 生成的商品图片（模特、商品实拍效果）是否存在虚假宣传风险，是 2025 年杭州法院受理的新类型纠纷。
• 直播数字人形象权属：数字人形象的著作权、肖像权、声音权益如何在 MCN、主播、平台之间分配，也是杭州互联网法院正在探索的议题。

这些案件提示工程团队：AIGC 合规不只是模型方的事，也是电商、直播、教育等垂直领域的事。任何使用 AIGC 生成内容的业务都应把合规清单做一遍本地化。

8.7 一个被忽视的 AIGC 案件类型：文本生成的著作权争议

相比文生图、AI 语音的高曝光度，“AI 生成文本（article、代码、摘要）”的争议在中国判决数量较少。原因有二：

1. 独创性判断更难：文本的表达空间更大，侵权比对更依赖具体字词与结构
2. 权利人举证难度高：作者难以证明 AI 输出与自己的作品存在必然关联

但这一领域不应被忽视。截至写作时已经出现若干典型苗头：

• 新闻稿件训练争议：国内媒体集团对多家大模型公司发出律师函，质疑未经许可的新闻训练
• 学术文章训练争议：出版社针对 AIGC 撰写”二创”式学术文章的行为发起维权
• AI 生成文本的独创性：北京等地法院在部分判决中已在附带论述中提及”AI 生成的新闻稿件是否构成作品”

这些苗头的走向将深刻影响文本类 AIGC 产品的合规成本。建议做文生文产品的团队定期跟踪。

8.8 案例延伸：AI 生成代码的许可证传染

如果 AI 助手（如 Copilot 类产品）输出了与训练集中 GPL 代码高度相似的片段，开发者在将其合入商业闭源项目后，是否构成对 GPL 的违反？这是未来几年有潜在诉讼风险的场景。一种谨慎的合规路径是：

• 对代码建议做字面相似度检测，高相似度片段标注其可能来源与许可证
• 提供 “exclude GPL / AGPL” 的模型训练子集或过滤开关
• 在 IDE 插件中暴露”是否使用开源相似代码”的可视化标识
• 企业用户合同中约定对 AI 助手输出的代码使用负最终责任

这与 GitHub Copilot 在美国 Doe v. GitHub 案件后提供的 “Code Referencing” 特性方向一致，可以视作行业事实标准。

九、跨案横向总结

在进入逐项总结之前，下面用一张 SVG 把”平台责任 × 合规动作”的矩阵画出来，作为记忆抓手：

9.1 平台责任的三级梯度

综合奥特曼案 I/II、殷某案、深伪案，中国法院事实上在 AIGC 场景下形成了如下三级责任梯度：

1. 明知 / 应知即承担直接侵权责任：当侵权 IP 是广为人知的（奥特曼、著名演员、知名歌手），平台不能以”不知道”抗辩。
2. 未明知但未采取必要措施时承担帮助侵权责任：权利人发出通知后未及时处置；或用户投诉渠道缺失导致再次生成。
3. 采取了合理必要措施时减轻或免除责任：包括关键词过滤、输出识别、用户承诺、水印标识、快速处置。

9.2 训练数据合法性的举证责任

春风案、奥特曼案 II、殷某案共同传递一个信号：只要原告能证明其作品/声音/形象具有被训练的客观可能性，被告就需要对训练数据的合法来源承担举证责任。这在诉讼实务中意味着模型厂商必须能够在合理时间内出具一份可核验的”训练数据清单与许可证状态”。

9.3 输出物版权归属

• 用户是默认作者（春风案）：当用户作出实质性创作选择时，作者身份归用户。
• 平台与模型方通过合同分配权利：多数 ToC 平台在 ToS 中声明用户拥有输出版权，平台保留非独占使用许可；ToB 合同则更复杂。
• AI 本身不是作者：这是全球共识，也是中国司法坚持的底线。

9.4 生成内容标识义务的工程化

2025 年《人工智能生成合成内容标识办法》把显式与隐式标识变成了强制性合规义务，这是工程团队最直接可落地的”写代码项”：

• 显式标识：在可视区域添加角标、水印、或文本声明”AI 生成”；
• 隐式标识：在文件元数据中写入生成信息（如 Content Credentials/C2PA、PNG tEXt、EXIF、MP3 ID3v2）；
• 传播环节二次标识：分发平台对检测到的 AIGC 内容进行再次标注。

9.5 赔偿数额的”小额化”趋势

春风案 500 元、奥特曼案一万元量级、殷某案 25 万元，这一系列判决的赔偿数额与美国集体诉讼动辄数十亿美元的喊价截然不同。原因有二：一是中国法定赔偿上限（著作权法第 54 条法定赔偿上限 500 万元）相对保守；二是绝大多数原告难以精确证明侵权获利。这一”小额赔偿”特征导致单个案件的经济威慑力有限，但行为义务（行为保全、停止生成、强制整改）的威慑力正在逐步超过赔偿本身。对工程团队来说，这意味着合规的驱动力主要来自”被强制下架整改的业务风险”，而不是”被赔到倾家荡产的财务风险”。

9.6 举证责任的实务分配

综合上述案件，AIGC 诉讼中的举证责任分配大致如下：

• 原告：初步证明自己享有权利 + 初步证明输出结果与自己的作品/人格利益存在关联
• 被告平台：证明训练数据来源合法 + 证明已采取合理必要措施 + 证明输出结果与原告作品的差异足以排除实质性相似
• 被告用户：对自己的 prompt 构造合理性承担说明义务

这套分配规则与传统版权诉讼基本一致，但重心明显向”被告平台承担数据合规举证”倾斜。

9.7 诉讼周期与工程侧的应急节奏

以目前已公开的 AIGC 案件走向看，从立案到一审判决大约 4–10 个月，一审到二审再走 6–12 个月。对工程团队的意义：

• 收到律师函或投诉后的 前 30 天 是”关键窗口”：此时整改还能避免被诉
• 被起诉后的 前 90 天 是”证据准备期”：需要整理训练数据清单、处置日志、关键词库快照
• 一审败诉后的 上诉期 一般 15 日（民事案件）：内部上诉决策要快
• 二审败诉后会涉及是否履行”停止侵权”裁定，停止生成特定 IP 的能力 要在 7–14 日内完成

这一时间表提示工程团队：“合规事件响应”应作为一级 incident 类型，建立专门的 Runbook，而不是走通用 IT 工单流程。

十、与他国规则的横向对比

10.1 美国

• Thaler v. Perlmutter、Zarya of the Dawn：AI 不是作者；机器产出部分不可登记。
• Andersen v. Stability AI（N.D. Cal.）：训练是否构成侵权仍在审理，但诱导侵权等部分主张获允继续。
• NYT v. OpenAI（S.D.N.Y., 2023 起诉）：围绕新闻内容训练与输出记忆化问题；OpenAI 主张合理使用，双方在 2024–2025 年围绕 discovery 激烈交锋。
• Doe v. GitHub（N.D. Cal.）：代码训练案，部分 DMCA 1202 主张被驳回，部分合同违约主张继续。
• 特征：以合理使用（fair use）为主战场，依赖 discovery 确认事实；对平台直接侵权责任保守。

10.2 欧盟

• EU AI Act（2024 年通过，分阶段实施）：对 GPAI 提供者要求公开训练数据摘要并建立著作权合规政策。
• DSM Directive 第 4 条：文本与数据挖掘（TDM）例外，允许商业主体在无 opt-out 声明时进行 TDM；但艺术家可通过 robots.txt、meta 标签等实施 opt-out。
• 特征：事前合规（ex ante）为主，信息披露与 opt-out 机制并行。

10.3 日本

• 著作权法第 30 条之 4：允许”非享受目的”的利用，文化厅 2024 年文件进一步细化训练阶段与生成阶段的区分。
• 特征：训练阶段最友好，生成阶段仍按传统侵权规则处理。

10.4 中国

• 事后救济 + 部门规章事前监管并行：既有奥特曼案、殷某案这样的民事判决，也有深度合成规定、生成式 AI 管理办法、标识办法这样的行政法规。
• 特征：独创性与人格权并重；平台责任较欧美更重；合理使用制度偏封闭。

10.5 韩国、新加坡、印度

• 韩国：2023 年《著作权法》修订讨论引入 TDM 例外，截至写作时尚未通过；法院在肖像权纠纷中已多次处理 AI 换脸案件，保护强度接近中国。
• 新加坡：2021 年修订版《著作权法》第 244 条引入”计算数据分析”例外，类似日本 30-4 但略窄；新加坡个人资料保护法（PDPA）对训练数据中的个人信息施加独立约束。
• 印度：德里高等法院 2024 年就 Asian News International v. OpenAI 开庭，诉点类似 NYT 案；印度无专门 TDM 例外，合理使用解释相对狭窄。

一份对比矩阵：

10.6 “出海”与”引进”的工程策略

中国 AIGC 产品出海、或海外模型落地中国，都面临跨法域合规拼图：

• 中国产品出海欧盟：需要准备 GPAI 训练数据摘要、署名 EU Representative、接入 CE 合规机制，额外承担对艺术家 opt-out 的尊重义务
• 中国产品出海美国：重点在 discovery 阶段的数据披露准备、DMCA 1202 下的水印信息保护
• 海外模型落地中国：必须通过生成式 AI 备案、算法备案、安全评估；训练数据中如含大量中文 UGC 社区内容，需专门审计
• 跨境模型调用：API 层面的数据出境、个人信息跨境传输，需同步履行《个人信息保护法》的合规手续

出海与引进的共同底线：每一法域都单独过一遍合规清单，不存在”全球一版 ToS 通吃”的解法。

十一、工程团队合规检查清单

11.1 训练数据阶段

• 数据来源 URL 与抓取时间戳全量持久化
• robots.txt 快照留档
• 许可证识别（CC BY、CC BY-SA、CC BY-NC、Public Domain、All Rights Reserved）
• 对已知 IP 形象、知名艺人声纹、个人隐私照片做黑名单过滤
• 对 GPL/AGPL/SSPL/BSL 代码做隔离训练或屏蔽 verbatim 输出
• 提供数据来源方 opt-out 渠道（邮件 + 自助表单）
• 生成数据清单摘要，供监管部门备案或诉讼举证

11.2 模型与输出阶段

• prompt 前置过滤：IP 关键词、名人姓名、色情/暴力/政治敏感词
• prompt 扩展防绕过：同义词、拼音、繁体、谐音、emoji 替换
• 输出端 pHash/CLIP/声纹相似度二次识别
• memorization 检测：定期用训练集样本探测 verbatim 输出
• 显式水印（可视）+ 隐式水印（C2PA / PNG tEXt / EXIF / ID3）
• 可控参数（seed、checkpoint、LoRA）暴露给高级用户并记录

11.3 用户协议与商业合同

• ToS 明确输出版权归属（默认归用户 + 平台非独占使用许可）
• ToS 要求用户承诺 prompt 合法性、不涉及他人 IP / 肖像 / 声音
• ToB 合同划分上游模型方、应用方、用户三方责任
• Model Card 披露训练数据来源大类、已知偏差、禁用场景
• 侵权通知渠道：邮箱、表单、在产品中可见入口

11.4 运维与应急

• 侵权通知 SLA（例如 24 小时内响应、72 小时内处置）
• 处置措施梯度：提示词拦截、账号限制、历史输出下架、模型补丁
• 证据留存：提示词、输出、时间戳、IP、账号、处置日志保存 6 个月以上
• 合规年度审计：训练集审计、模型审计、用户投诉复盘
• 与 OSPO、法务、安全团队的联席工作机制（参见 第 17 篇 OSPO）

11.5 三类典型产品的差异化合规要点

一刀切的合规清单在实际工程中往往低效，不同产品类型的风险面差异很大。下面给出三类典型产品的重点差异：

文生图 / 图生图产品

• 重点防御 IP 形象、明星肖像、色情内容
• 提供 seed / 参数可控性，以利用户主张作品权
• Content Credentials 水印嵌入必做
• 对 LoRA / Embedding 社区上传内容做二次审查（IP 风险密集）

文生文 / 对话式产品

• 重点防御记忆化输出（新闻、小说、代码原样吐出）
• 提供引用来源链接
• 对敏感话题做可追溯的拒答策略
• 对代码生成结果做 GPL/AGPL 传染输出检测

语音克隆 / 语音合成产品

• 重点防御名人声纹、未成年人声音
• 活体 + 授权书双要件
• 可检测水印（AudioSeal 类）强制嵌入
• 生成语音的使用范围限制（禁用广告、禁用政治人物）

11.6 一个可执行的 CI/CD 合规门禁示例

把上述合规要求落到 CI/CD，可以设计如下门禁（伪配置，语义清晰为主）：

• 代码侧：每次 PR 合并前，跑 aigc-compliance-lint：检查 prompt 过滤黑名单更新情况、检查水印嵌入代码是否被误删、检查 ToS 版本是否与后端声明一致
• 数据侧：数据集变更需要提交 dataset-change-request，并附 license 汇总与变更前后差异
• 模型侧：每次模型发布前，跑 memorization-eval + ip-leakage-eval，生成报告作为发布审批必需材料
• 运行时侧：灰度发布期间，通过告警监控侵权通知数量、用户投诉率、输出疑似 IP 命中率

这套门禁的目标是：让合规不再依赖个别法务同事的记忆，而是固化到代码仓库与 CI 配置里。

11.7 与 OSPO / 法务 / 安全的协同模型

AIGC 合规本质上是跨职能的，不可能由单一团队闭环。一种可参考的协同模型是：

• OSPO（Open Source Program Office）：统筹开源许可证、模型许可证、训练数据许可证，对外与开源社区保持对话；参见 第 17 篇 OSPO
• 法务团队：跟踪判例、撰写 ToS、起草上下游合同、应对律师函与诉讼
• 安全与内容风控：运营关键词库、审核队列、输出过滤模型
• 研发与算法：实施技术方案、做 memorization 评估、维护水印 pipeline
• 产品与运营：对 C 端用户做合规教育、在 UI 上体现标识与权属

四方会议（OSPO + 法务 + 安全 + 研发）每月一次，统一输入判例动态与业务需求，输出下月合规改进点。缺任何一方，都会出现”各自以为对方在做”的合规盲区。

十二、与本系列其他文章的交叉引用

• AIGC 训练数据的合规基础：第 23 篇 AI 训练数据与开源许可
• 模型权重许可证的工程分析：第 24 篇 模型许可证深度解析
• 中国著作权法基础：第 02 篇 中国著作权法下的开源工程视角
• 中国 GPL 诉讼第一案系列：第 15 篇 中国 GPL 诉讼第一案系列
• 中国开源数据库协议选择：第 14 篇 OceanBase / TiDB / Doris
• 开源许可证全景：第 01 篇 开源许可与版权工程全景
• Copyleft 工程边界：第 04 篇 Copyleft 的工程边界
• 知识产权综合：第 05 篇 专利与商标在开源中的工程影响
• OSPO 与合规治理：第 17 篇 OSPO 建设
• CLA / DCO 与贡献者权利：第 18 篇 CLA 与 DCO
• 出口管制与合规：第 19 篇 开源与出口管制
• 开源战略：第 20 篇 开源战略
• 许可证选择实务：第 21 篇 许可证 Cookbook

十三、写在最后

从春风案的一张图到奥特曼案的一个 IP，再到殷某案的一段声音，中国 AIGC 司法在两年内把一个几乎空白的规则图景补齐到”可操作”的程度。对工程团队来说，最关键的转变不在于去记住判决书编号，而在于接受这样一组默认设定：

• 训练数据合法性的举证责任在你；
• 平台即内容提供者，避风港是薄冰；
• 用户是默认作者，工具是你的，不代表作品是你的；
• 人格权（肖像、声音）不依赖著作权，单独保护，优先级甚至更高；
• 显式 + 隐式标识是强制合规，不是可选项。

把这五条装进 Model Card、写进 ToS、编成 CI/CD 的检查脚本、塞进每一次灰度发布的审查表，远比等到被起诉之后再补救要便宜得多。

13.1 给不同角色的行动项

算法工程师 / 研究员

• 训练前检查数据来源许可，别把 “能下就能用” 当默认
• 在模型卡片里写清训练数据来源大类、已知偏差、memorization 评估结果
• 对强传染许可证代码（GPL / AGPL）做训练前隔离与输出过滤

产品经理

• 在功能立项阶段就要求法务参与高危能力评审（换脸、声音克隆、名人模仿）
• 把”生成内容标识”作为需求默认勾选项，而不是可裁剪的体验优化项
• 用户协议中对输出版权归属、prompt 责任、合规义务做清晰表述

前端 / 客户端工程师

• 水印、角标、EXIF 标识不要只在服务端做，客户端二次验证能提高可信度
• 在用户分享功能中保留 AIGC 标识，不允许一键去水印
• 提供用户举报入口，24 小时内可达人工审核通道

后端 / 平台工程师

• 日志保存至少 6 个月，包含 prompt、参数、输出、用户、时间、IP
• 关键词黑名单的更新纳入配置中心，支持秒级热更新
• 侵权通知处置走独立工单系统，打通法务、内容审核、开发三端

法务 / 合规

• 建立判决跟踪与影响评估机制，每季度发布内部”AIGC 司法周报”
• 与业务团队共建合规红线清单，并固化到 CI/CD 中
• 对上下游合同（模型采购、数据采购、代理经销）更新 AIGC 责任条款

13.2 未来的三个看点

展望 2026–2027 年的中国 AIGC 司法，以下三个方向值得持续关注：

1. 训练数据合理使用边界：中国是否会通过司法解释或立法为”非表达性利用”开一扇窗？若开，其条件（来源合法性、opt-out、商业用途限制）将如何组合？
2. 大模型基础方的责任：在奥特曼案 II 的延长线上，上游基础模型提供者是否会被直接拉入被告席？一旦发生，将会重塑中国基础模型产业的竞争格局。
3. AIGC 内容标识的事实标准：2025 年标识办法实施后，显式与隐式标识的技术路线（C2PA vs. 自建方案）、跨平台互认、二次标识的执行细节，都会在实务中沉淀出事实标准。

以上三个方向一旦落地，现有合规清单可能需要大幅重写。持续关注并迭代，是 AIGC 合规区别于传统开源合规的最大特点。

13.3 从案件到流程的迁移

合规知识之所以容易停留在文档里，是因为它往往以”判决摘要”、“法条原文”的形式存在，而研发流程消费的是”PR 模板”、“CI 脚本”、“告警阈值”。把本文梳理的案件规则迁移到流程，典型路径是：

1. 把每一条裁判要点翻译成一条可执行的”if-then”规则
2. 把”if-then”规则落到代码仓库的 lint、CI 检查、服务端配置
3. 把规则的变更通过 PR 管理，让法务、合规、安全能以 reviewer 身份介入
4. 为关键规则设置告警监控，让违规数据在运行时可见
5. 每季度做一次”规则-案件”复盘，让更新的判例能触达代码

这一路径本质上是把合规当成”另一个系统”来做，与可观测性、SRE、安全工程是同一方法论。

13.4 写给创业团队的精简版

如果你的团队规模很小，无法立刻建立上面那些庞大的体系，下面这组”最小可行合规”可以先做：

• 训练数据：只用已有明确许可的数据集 + 自采购数据；不去做灰色抓取
• IP 黑名单：维护一个不少于 200 项的中文互联网知名 IP / 公众人物黑名单，前置过滤
• 水印：所有输出默认加可视水印 + EXIF / PNG tEXt 元数据
• 用户协议：明确输出归属 + 用户对 prompt 负责 + 平台有权下架
• 投诉邮箱：在产品页脚放一个随时可达的邮箱并承诺 72 小时响应
• 日志：prompt + 输出 + 用户 + 时间 + IP 至少保存 6 个月

这套”最小可行合规”覆盖了 90% 以上的常见诉讼场景，成本可控，可以先上线再逐步深化。

本文为工程参考，不构成法律意见。涉及具体法律风险请咨询专业法律顾问。

参考资料

1. 北京互联网法院（2023）京 0491 民初 11279 号李某诉刘某侵害作品署名权及信息网络传播权案（“春风送来了温柔”案）：判决全文与案情说明可通过北京互联网法院官网及中国裁判文书网检索：bjinternetcourt.gov.cn、wenshu.court.gov.cn
2. 广州互联网法院奥特曼 AIGC 著作权侵权案：2024 年 2 月判决，被最高人民法院列入 2024 年知识产权司法保护典型案例。官方新闻通稿：gzinternetcourt.gov.cn；中国法院网报道：chinacourt.org
3. 北京互联网法院殷某诉某智能科技公司等声音权益纠纷案（“AI 声音第一案”），2024 年 4 月一审判决：北京互联网法院官方公众号通稿；新京报、澎湃新闻、The Paper 报道：thepaper.cn
4. 《中华人民共和国著作权法》（2020 年修订）：全国人大官网公开文本 npc.gov.cn
5. 《中华人民共和国民法典》（2021 年施行）人格权编第 1018–1023 条：全国人大官网公开文本
6. 《互联网信息服务深度合成管理规定》（国家网信办等，2022 年 11 月发布）：cac.gov.cn
7. 《生成式人工智能服务管理暂行办法》（2023 年 8 月 15 日施行）：cac.gov.cn
8. 《人工智能生成合成内容标识办法》（2025 年施行）：国家网信办官方发布稿
9. Thaler v. Perlmutter, No. 22-cv-01564 (D.D.C. Aug. 18, 2023)：美国哥伦比亚特区联邦地区法院判决书公开版本
10. U.S. Copyright Office, “Zarya of the Dawn”（Registration # VAu001480196）Letter, Feb. 21, 2023：copyright.gov
11. Andersen et al. v. Stability AI Ltd. et al., No. 3:23-cv-00201 (N.D. Cal.)：PACER 公开文书
12. The New York Times Co. v. Microsoft Corp. & OpenAI, No. 1:23-cv-11195 (S.D.N.Y.)：起诉状与后续动议公开版本
13. Doe v. GitHub, Inc., No. 4:22-cv-06823 (N.D. Cal.)：GitHub Copilot 代表性诉讼文书
14. Getty Images (US), Inc. v. Stability AI, Inc., No. 1:23-cv-00135 (D. Del.)：PACER 公开文书
15. Regulation (EU) 2024/1689 (EU AI Act)：欧盟官方公报：eur-lex.europa.eu
16. Directive (EU) 2019/790 (DSM Directive) Art. 3–4 TDM 例外：欧盟官方公报
17. 日本文化厅《AI と著作権に関する考え方について》2024 年 3 月版：bunka.go.jp
18. 日本著作权法第 30 条之 4：elaws.e-gov.go.jp
19. Tennessee ELVIS Act (Ensuring Likeness Voice and Image Security Act), 2024：capitol.tn.gov
20. Midler v. Ford Motor Co., 849 F.2d 460 (9th Cir. 1988)
21. 中国裁判文书网：wenshu.court.gov.cn
22. 最高人民法院：court.gov.cn
23. 北京互联网法院：bjinternetcourt.gov.cn
24. 广州互联网法院：gzinternetcourt.gov.cn
25. 杭州互联网法院：netcourt.gov.cn
26. C2PA Content Credentials 技术规范：c2pa.org
27. Coalition for Content Provenance and Authenticity 白皮书：c2pa.org/specifications
28. LAION-5B 数据集公开文档：laion.ai
29. Stability AI Stable Diffusion 模型卡：huggingface.co/stabilityai
30. 36kr、澎湃新闻、南方都市报、中国新闻网对上述案件的持续报道

延伸阅读

• 模型许可证深度解析：本文涉及的许可与判决，对照模型侧的许可条款一起读更清楚。
• AI 训练数据与开源许可：训练侧合规的许可基础。
• LLM 网关与多模型路由：模型许可与合规约束在网关层如何落到访问控制与审计。
• 国产芯片与 DeepSeek 部署：中国栈落地时的硬件与许可边界。
• 开源之道系列目录：许可、治理与合规的完整阅读路径。

上一篇：模型许可证深度解析

下一篇：AI 训练数据与开源许可（回顾训练侧） · 开源之道系列目录