2026 EU AI Act Article 50：自托管开源模型标记验收清单
获胜者：先完成角色与输出范围判定，再做双层标记验收。 开源许可和自托管部署不等于豁免；只有符合条件、且在 2026 年 8 月 2 日前已投放市场的存量系统，才可能将 Article 50(2) 的标记与检测义务延至 2026 年 12 月 2 日。新系统、Article 50(1) 交互披露和 Article 50(4) 可见披露，不能一起顺延。(欧盟委员会 Article 50 官方 FAQ)
这篇文章适合三类人：向欧盟用户开放产品的自托管开源模型技术负责人，负责元数据、水印和内容发布链路的工程师，以及需要规划隔离测试环境的合规负责人。
如果团队只是在内部个人环境试用模型，且没有对外提供系统或内容，这份清单的适用性会明显降低。
先记住一条边界：“模型由谁训练”与“系统由谁以什么名义对外提供”不是同一个问题。Article 50 的角色判断，应回到产品链路和业务控制关系，而不是只看模型许可证。
最后更新于 2026 年 8 月 3 日，日期、宽限期、角色定义和罚则已根据欧盟委员会 Article 50 FAQ、2026 年 7 月 20 日发布的实施指南、Code of Practice 页面及 EUR-Lex 法规正文 核对。
先区分 provider、deployer 与系统使用者
自托管开源模型对外服务后，角色不能靠部署方式决定
欧盟委员会 FAQ 将 provider 定义为：开发 AI 系统，或委托他人开发 AI 系统，并以自身名称或商标将其投放欧盟市场或投入使用的自然人、法人、公共机关或其他机构。即使该主体位于欧盟之外，只要系统输出在欧盟被使用，也可能进入 AI Act 的适用范围。(欧盟委员会 Article 50 官方 FAQ)
deployer 则是根据自身权限使用 AI 系统、且不是个人非职业活动的主体。一个团队可能同时具有两种身份：
- ✅ 只调用第三方模型，并以自身产品名向客户提供完整 AI 应用：通常需要重点检查 provider 角色。
- ✅ 在企业内部使用模型生成营销、公共事务或客户服务内容：可能承担 deployer 侧披露责任。
- ⚠️ 下载开源模型、修改推理服务、接入品牌网站并控制上线版本：不能仅因“模型来自社区”就排除 provider 判断。
- ⚠️ 由外包商部署，但产品、域名、发布审批和客户合同均由平台方控制：外包商不一定是唯一责任主体。
可执行的判定路径如下：
- 先确认系统是否面向欧盟市场，或其输出是否会被欧盟自然人使用。
- 再记录模型、推理服务、前端交互和发布平台分别由谁开发或委托开发。
- 查看系统上线时使用的名称、商标、域名、应用商店主体和客户合同主体。
- 判断谁决定模型版本、提示词、输出过滤、标记方式和发布渠道。
- 将 provider、deployer、第三方基础设施提供方分别写入责任矩阵。
- 对无法单独归类的链路交给熟悉欧盟 AI Act 的法律人员复核。
开源模型是否自动获得 Article 50 豁免？
不是。官方 FAQ 只列出特定输出和特定使用情形的边界，例如源代码、短字符序列、纯机器间传输，以及封闭工业研发环境中的非最终输出。它没有把“开源许可”列为 Article 50 的普遍豁免。
这也是自托管团队最容易验收失败的地方：把模型权利、服务器归属和系统责任混成了一个概念。最终定性仍需结合实际产品链路，本文不构成法律意见。
12 月宽限期只覆盖有限的存量系统
Article 50 自 2026 年 8 月 2 日起适用。官方 FAQ 给出的有限过渡安排，只针对在该日期前已经投放市场的 AI 系统，并且只涉及 Article 50(2) 的生成内容机器可读标记与检测义务；符合条件的 provider 最迟可到 2026 年 12 月 2 日完成该部分义务。
不要把以下三组日期混在一起：
- 系统日期：版本何时首次投放市场或投入使用。
- 生成日期：某一段文本、图片、音频或视频何时生成。
- 公开日期：内容何时被发布、展示或提供给自然人。
2026 年 8 月 2 日前上线的系统，都能使用 12 月宽限期吗？
不能直接这样判断。团队至少要证明系统在该日期前已投放市场，并确认所延后的只是 Article 50(2) 标记和检测要求。Article 50(1) 的交互披露、Article 50(4) 的可见标签，以及 8 月 2 日后新上线的系统，不能因为使用旧模型或旧服务器而自动顺延。
建议保存以下时间证据：
- 版本仓库的首次发布记录。
- 生产环境上线审批单。
- 对外服务页面、客户合同或应用发布记录。
- 模型权重、推理镜像和标记组件的版本哈希。
- 生成日志中的时间戳与内容发布日志。
- 8 月 2 日后新增功能是否构成新系统或新版本的评估记录。
内容在 2026 年 8 月 2 日前生成的，官方 FAQ 表示无需追溯性补标；但这不等于 8 月 2 日后再次分发、编辑或重新生成的内容天然不需要处理。
先判定输出范围，再选择标记技术
自托管团队不应一上来就讨论“用水印还是元数据”。先按输出类型建立范围清单。
文本、图像、音频和视频分别过一遍
Article 50(2) 的核心对象是 AI 生成或实质性操纵的合成音频、图像、视频和文本，并要求采用有效、可靠、稳健、可互操作且在技术上可行的机器可读标记，使相关内容能够被检测。
建议按以下顺序验收：
- 文本：检查是否为最终向自然人展示的内容，是否经过后处理、翻译、摘要或人工编辑。
- 图像：检查导出格式、缩略图、裁剪和社交平台压缩是否保留标记。
- 音频：检查重新编码、响度处理和在线播放器转换后的检测结果。
- 视频：检查转码、字幕烧录、剪辑和多平台二次分发后的标记保留情况。
源代码输出也需要机器可读标记吗？
官方 FAQ 将 source code 列为通常不在该标记义务范围内的输出之一。同时，纯机器到机器传输、完全自动处理且不向人展示的输出，也可能落在范围之外。
但工程团队不能把“代码生成”扩大解释成所有开发场景都豁免。例如，模型生成的代码如果被包装成面向客户的教程、产品文档、公共安全说明或其他最终文本，就应重新判断其是否已经成为向自然人发布的内容。
B2B 或工业研发场景也不能只写一句“内部使用，所以豁免”。官方指南提到狭义的 B2B、工业和封闭研发边界，但是否满足条件取决于输出是否最终展示、是否离开封闭链路以及是否涉及自然人。
三种标记分别解决什么问题
- 机器可读标记：主要解决 provider 侧的识别与检测问题。可以是元数据、嵌入式水印或其他技术方案，但必须验证在实际分发链路中是否仍可检测。
- 用户可见标签：主要解决 deployer 侧的信息披露问题。深度伪造内容和特定公共利益文本，需要在自然人首次接触时清楚呈现。
- 交互提示：解决 Article 50(1) 的人机交互披露。用户需要知道自己正在与 AI 系统交互，不能用内容元数据替代界面层面的告知。
官方 Code of Practice 将 provider 侧的 Article 50(2) 标记与 deployer 侧的 Article 50(4) 标签分成不同章节。该 Code of Practice 属于自愿工具，不会替代法规，也不会因为使用某一个图标就自动建立合规结论。(欧盟委员会 Code of Practice 说明) 欧盟委员会对该 Code of Practice 的评估也明确指出，遵循代码本身并不构成最终合规的决定性证据。(欧盟委员会对 Code of Practice 的评估意见)
验收经验：可见标签能被人看到，不代表监管工具能检测；元数据能被检测，也不代表普通用户已经获得清楚披露。两条链路必须分别测试。
用条件分支决定验收路径
下面这组条件可以直接放进团队的评审单。满足条件时进入 A 路径，否则回退到 B 路径。
- 若系统在 2026 年 8 月 2 日前已经投放市场，且只是补齐 Article 50(2) 的标记与检测能力，则
→ 进入存量系统过渡路径，目标日期为 2026 年 12 月 2 日；同时继续执行不在宽限范围内的其他义务。 - 若系统在 2026 年 8 月 2 日后首次上线，或上线日期无法提供证据，则
→ 按现行 Article 50 要求立即验收，不把宽限期当作默认缓冲。 - 若团队以自身名称或商标提供完整 AI 应用，并控制上线、版本和客户交付，则
→ 按 provider 风险路径核对 Article 50(1)、(2) 及适用的其他要求。 - 若团队只是根据自身权限使用 AI 系统，并负责向公众发布深度伪造或公共利益文本，则
→ 进入 deployer 路径，重点检查首次曝光时的可见标签、人工复核和编辑责任。 - 若输出只在机器间传输，未向自然人展示，且最终产品不包含该输出，则
→ 保存范围判断和链路证据，不要直接把结论扩展到后续公开版本。 - 若输出经过转码、压缩、裁剪或第三方平台重新编码后仍能被检测，则
→ 保留测试样本、检测日志和工具版本；否则回退到补标、阻断发布或增加人工检查。
证据链比“已经加了水印”更重要
Article 50 合规验收至少要能回答五个问题：要求来自哪一条规则，哪个版本实现，测试了哪些内容，发布前谁批准，失败后如何处置。
建议按以下 6 步落地：
-
建立责任矩阵
为 provider、deployer、模型团队、前端团队和发布团队指定责任人。不要只写部门名称，要落到能够批准上线或暂停发布的具体岗位。 -
固定测试环境
锁定模型版本、推理框架、标记组件、导出工具和检测工具。生产环境不应直接试错。对多版本模型并行测试，应使用独立环境和固定样本集。 -
准备分层样本
至少覆盖文本、图像、音频和视频；同时覆盖原始输出、编辑后输出、压缩后输出、转码后输出和重新上传后的输出。每条样本记录输入、模型版本、生成时间和发布渠道。 -
记录检测结果
保存标记是否写入、是否能被检测、检测工具版本、失败原因和人工复核结论。任何“成功率”“保留率”或性能数字，都必须来自可复现测试记录，不能凭一次演示填写。 -
设置发布闸门
标记丢失、检测失败或标签缺失时，系统应阻止发布，或转入人工复核队列。第三方平台重新编码后无法保证标记保留时，需记录替代措施，而不是默认平台会保留元数据。 -
形成回滚与复测记录
标记组件升级、模型替换、导出格式变化和前端发布链路调整后，重新执行回归测试。保存旧版本配置、审批记录和回滚结果，证明团队能够在发现失败后恢复到已验证版本。
公共利益文本的人工复核怎样才算有效？
官方 FAQ 将实质性人工审查或编辑控制与拼写检查、语法修正等形式性操作区分开。人工复核应涉及内容实质、事实可靠性和来源判断，并由自然人或法人承担最终编辑责任；仅做排版或拼写修正，不能直接写成豁免依据。
对于生成新闻摘要、公共安全说明、政策解读或金融信息的系统，证据链中应额外保存复核人员、复核时间、修改内容、批准人和最终发布版本。
隔离环境决定改造能否稳定复现
合规改造通常同时涉及模型推理、导出、转码、检测、前端展示和发布审批。只有一台生产设备时，团队很容易出现三类隐性成本：
- ❌ 测试与线上版本互相覆盖，失败后无法复现。
- ❌ 不同模型版本抢占同一套依赖，导致检测结果漂移。
- ❌ 大批量样本、视频转码和回归检测挤占线上资源，迫使团队减少测试覆盖。
本地 Mac 更适合需要物理接口、固定开发工具链、长期稳定负载和低延迟调试的团队。云端 Mac 更适合短期并行测试、远程协作、隔离版本和项目周期内的弹性扩容。选择时应先确认：
- 若团队需要固定硬件、外接设备或长期持续运行，优先本地设备。
- 若团队需要同时验证多个模型版本、转码链路和检测工具，优先隔离的云端 Mac 环境。
- 若合规测试只持续数周，且测试人员分布在不同地点，按项目周期交付的远程环境通常更容易控制成本与权限。
- 若模型推理依赖 Linux、CUDA 或特定 GPU 栈，Mac 环境不能直接替代原有生产环境；它更适合作为 macOS 工具链、发布端、客户端和跨平台链路的补充测试环境。
在开始改造前，可先查看 ProxyMac 帮助中心，确认远程访问、权限和交付流程是否符合团队的隔离要求。若需要比较短期测试与长期设备持有成本，再结合 ProxyMac 方案说明核对项目周期，而不是只比较单小时价格。
当前方案与 Mac 方案的取舍
如果团队继续在单台本地设备上完成所有 Article 50 测试，真实缺点通常不是“速度慢”这么简单：测试环境与生产环境互相干扰，多版本模型难以并行，转码和检测回归容易被临时任务打断，远程成员也无法稳定复现同一套环境。
如果改用通用云主机，又可能遇到 macOS 工具链缺失、权限边界复杂、客户端发布验证不一致和临时环境无法保留的问题。对需要 macOS 端验证、远程协作和短期隔离实例的团队，租赁 ProxyMac 的 Mac 环境更适合作为合规改造阶段的测试层，而不是贸然替换全部生产基础设施。
更稳妥的做法是：先整理本文的角色、输出类型、日期证据和失败处置清单；如果现有设备无法稳定复现多版本模型、转码与检测流程，再按项目周期租赁 ProxyMac 的隔离环境，完成回归验证后才将标记链路推进到生产。
