如果你的模型仓库还挂在 Hugging Face 或者 GitHub Releases 上这篇内容大概率和你有关。2025年8月2日欧盟《人工智能法案》里针对“通用人工智能模型”的监管要求正式进入适用阶段。这大概是开源大模型生态第一次被一部专门针对AI的法规正面点名。跟过去几年各种“AI伦理倡议”不太一样这次有明确的义务清单、时间表甚至有按全球营业额计算的罚则。如果你参与过开源大模型的训练、微调、打包发布或者公司内部拿开源权重做二次开发都值得花十分钟把这篇读完。先声明一句我不是律师这篇也不是法律意见。我写它是因为我自己的团队也在做开源模型工程过去一年被内部法务和外部客户反复问同一类问题。我会把目前公开、已经相对确定的监管框架梳理出来翻译成工程上能听懂的话再给一份可以照着做的清单。具体到你的项目最终还是要结合官方正式文本和合规意见去判断。1. 时间线已到为什么开源圈这次躲不掉先说时间线。2024年8月1日《人工智能法案》正式生效。当时很多开源开发者没什么感觉因为大部分条款都留了过渡期尤其对AI系统本身的监管要等到2026年。大家普遍觉得“还早”。但法案里有一类东西被单拎出来提前监管了就是通用人工智能模型General-Purpose AI简称GPAI。按现在的安排GPAI模型提供者的义务从2025年8月2日起就开始适用。这意味着什么意味着如果你在2025年8月之后仍然以“提供者”身份把一个符合GPAI定义的模型放到欧盟市场就可能要面对技术文档、版权政策、训练数据摘要、透明度说明这一整套要求。先说清楚开源圈为什么紧张。GPAI的定义覆盖非常广凡是“能够在大量不同任务上表现出高泛化能力”的模型基本都算。文本大模型、多模态模型几乎全在内。开源社区里常见的 Llama、Mistral、Gemma、Qwen、DeepSeek 这一档没有哪个能说自己“不是通用模型”。换句话说这不是少数头部闭源模型的问题而是整个开源大模型生态的问题。更关键的是管辖逻辑。监管不是看你的服务器架在哪个国家而是看你的模型有没有“投放欧盟市场”或者“在欧盟投入使用”。只要你的权重挂在公开平台被欧盟境内的企业或个人下载、集成、商用在很多解读下就可能被算作面向欧盟市场的提供行为。开源项目没有国界贡献者遍布全球但义务的触发点完全可以落在欧盟境内。为什么开源项目特别容易踩线我的观察是开源团队普遍没有“法务部”这个概念。正常情况下一个商业公司要发布模型会有人提前审许可、审数据、审文档开源项目往往是维护者觉得“模型训完了发个权重完事”。可一旦下游企业把开源模型嵌进自己的产品里客户在采购尽调时一定会问这个模型按新法规的要求文档齐不齐版权政策有没有训练数据摘要是什么到时候你拿不出来客户就转头去用闭源API了。所以这不是“欧盟管不到我海外开发者”的问题而是一条供应链传导链监管直接约束欧盟境内的部署方和使用方他们会把压力传递给模型提供方。你在GitHub上开源一个模型和你在欧盟卖一个软件只隔着一层“有没有人下载使用”。这也是我把这篇定位成“工程团队需要知道的东西”而不是“法务才需要看的东西”的原因。2. 先分清三个概念GPAI、系统性风险、下游高风险系统很多开源开发者把“欧盟AI法规”想象成一个大口袋觉得什么都能往里装。真去看条文就会发现它把监管对象拆成了好几层每层义务不同。如果不先分清自己在哪一层后面所有讨论都是乱的。2.1 GPAI 和“生成式AI”不是一回事法案里对GPAI的描述关键词是“通用性”和“泛化能力”。一个模型能处理写文章、翻译、总结、代码、对话这类任务同时经过大规模预训练基本就落入GPAI范畴。它可以是生成式的也可以不是。比如某些做Embedding的通用向量模型不输出文本但也可能被认定为GPAI区别要个案判断。这和“大不大”没有直接关系。一个70亿参数的模型只要训练方式是大规模无监督预训练、能力足够通用照样算一个专门做心电图分类的医疗小模型无论训得多好都不算GPAI但它如果进入临床辅助决策就会落在“高风险AI系统”那一层那又是一套完全不同的义务。所以判断顺序应该是先看是不是GPAI再看是不是系统性风险GPAI最后看下游具体把模型用在什么场景。2.2 系统性风险 GAPAI 的“算力门槛”和等效能力条款GPAI内部又分两档普通GPAI和具有系统性风险的GPAI。后者要负担更重的义务包括风险评估、对抗性测试、事件报告、网络安全保护等。默认认定标准是一个硬数字用于训练的总计算量达到 (10^{25}) FLOPs浮点运算次数。这个量级在法案起草时基本只有少数头部闭源模型才够得着。但要注意两点第一FLOPs的估算方法非常不统一不同框架、不同集群实测结果可以差出几倍所以官方最终怎么确认还要等后续实施细则第二就算你的模型没到算力门槛如果监管机构认为“等效能力”已经达到类似水平也可以个案认定。也就是说“我的模型参数小所以绝对安全”这个想法是靠不住的。2.3 下游高风险系统是另一座山很多开源开发者以为“我只发模型不碰应用”就万事大吉。实际上如果你的开源模型被集成到欧盟境内的一个高风险AI系统里——比如用于医学诊断、招聘筛选、信贷评估、关键基础设施管理——那么下游系统提供商要承担非常重的合规义务。问题是他们凭什么叫供应商配合靠的就是你的技术文档和透明度说明。反过来看这对开源项目其实是个机会。一个能提供完整文档、明确说明能力边界和已知限制的上游模型会更容易被合规压力大的企业选中。闭源API在这个场景里反而不那么透明。开源模型的“可审计性”本来就是卖点新法规等于把这个卖点写进了法律语言。我用一张表把这几个概念和对应义务的粗略对应关系整理出来方便团队内部聊对口径对象判断重点主要义务方向适用时间普通 GPAI 模型提供者泛化能力、大规模预训练技术文档、版权、训练数据摘要、透明度2025年8月2日起系统性风险 GPAI 提供者算力阈值或等效能力在普通义务上叠加评估、缓解、事件报告、安全测试2025年8月2日起下游高风险AI系统使用场景是否属于受限清单风险管理、数据治理、日志、人为监督等2026年8月2日起对大多数开源项目来说最值得先关心的还是第一行我是不是普通GPAI提供者如果是我缺哪些文档和流程3. GPAI提供者的几类义务翻译成工程语言如果不去看法律原文只看工程动作GPAI提供者的义务可以浓缩成四件事写文档、查版权、出摘要、给下游信息。每一件都能对应到开源项目里一个具体产物。3.1 技术文档把 Model Card 升级成“可审计文档”很多开源项目现在已经有Model Card了记录一下模型架构、评估指标、训练方法。但按新监管框架的要求这份文档不能只是“宣传页”而要是能支撑监管回溯的工程文档。大致需要覆盖模型架构与参数量、训练数据和数据组织方式、训练过程与计算资源、评估结果与测试方法、已知限制和潜在误用、以及足够的信息让下游判断模型能不能用于特定高风险场景。我见过很多团队是模型发布之后才补文档那真是灾难。训练时用的数据版本、超参数配置、甚至随机种子都散落在个人终端里凑齐全靠聊天记录。正确做法是从训练第一天就把训练日志当代码一样纳入版本管理。比如训练配置、数据采样策略、评估脚本全部进Git每个权重包发布时记录好对应commit、数据版本、训练起止时间、最终评估指标。这样写技术文档只是“转录”不是“考古”。3.2 版权合规数据治理不是签个字就完这条是很多开源开发者最容易忽略、但监管最认真抓的点。新框架要求GPAI提供者制定版权政策核心是确保训练数据来源合法并且尊重权利人的“保留权利”机制。背后逻辑是欧盟版权体系里的文本与数据挖掘例外合法访问到的内容原则上可以用于AI训练但权利人可以通过技术手段声明“我不要被拿来训模型”最常见就是robots.txt里的声明。也就是说你的训练数据抓取流程要能证明自己尊重了这些信号并且保留记录。工程落地起来是几件具体的事数据采集脚本要记录抓取来源URL、抓取时间、当时robots.txt的响应内容如果使用Common Crawl这类公开数据集要能说清楚里面包含哪些站点、有没有做过滤、按什么规则过滤建立权利人请求通道比如公开邮箱允许数据权利人要求停止使用其内容把这些过程整理成一份书面版权政策发布在项目仓库里。现实是很多开源项目的训练数据来自“朋友给的一个parquet文件”来源是几个网络爬虫的合集授权情况一塌糊涂。以前大家能糊弄过去以后这就是结构性风险。因为版权合规义务不因开源许可而消失这点下面会展开。3.3 训练数据摘要公开“足够详细但不泄密”的摘要很多人一听“要公开训练数据摘要”第一反应是“难道要开放训练集”。不是。这个摘要不是让你把全部语料打包开源而是要求提供足够详细的模型和数据说明让监管机构和公众理解你用了什么数据、数据长什么样。大致要覆盖数据来源类型网页、书籍、代码、学术论文等、语言分布、数据规模量级、清洗和过滤策略、处理流程。目前摘要的具体模板还没有完全定稿欧盟AI办公室那边一直在推进行为准则和配套模板。我的建议是不要干等模板。你可以先按“数据卡片”Data Card的思路把信息结构做出来来源类别、各类别占比、语言分布、去重去毒流程、隐私处理方式。后面官方模板出来了只需要调整字段格式不需要重新发掘历史记录。3.4 向下游提供足够信息让用你的人能合规最后一项义务是面向下游的。如果你把模型给企业集成你必须提供足够多的信息让集成方知道模型适合做什么、不适合做什么、有什么已知偏见、有没有安全风险。这套信息在实际商务中通常体现为“模型说明书”或“下游合规说明文档”。工程上建议直接反应在Model Card的“Intended Use”和“Out-of-Scope Use”里并且措辞要更严谨。以前可以写一句“本模型仅供研究”现在不行因为“研究”不能抵消实际使用风险。你应该写清楚具体推荐场景明确边界比如“不建议用于医疗诊断”“不适合作为法律建议来源”“在涉及未成年人内容时需额外过滤”。这些话既是保护下游也是保护你自己。4. 开源豁免的成色许可证是入场券不是免死金牌听到这里很多人的第一反应是“法案里不是有开源豁免吗”确实有但这个词被严重误读了。开源豁免不是让所有GitHub项目自动免责它有非常明确的前提和边界。4.1 豁免前提真正的自由开源许可证法案语境里的“free and open-source licence”不是“免费下载”甚至不是“开放权重”。它指的是符合开源社区普遍理解的那些许可证比如Apache-2.0、MIT、BSD这类OSI认证许可。核心特征是没有使用限制、允许自由修改和再分发、不附带歧视性条款。问题来了开源圈大量“开放权重模型”用的并不是严格意义上的开源许可证。很多厂商发布模型用的是自定义社区许可有的规定“月活用户超过一定规模需要另行申请商业授权”有的限定“不能用于特定领域”。从开源定义看这几类都属于“源代码可见但有额外限制”和真正的自由开源许可证不是一回事。凡是这类自定义许可在监管框架下享受豁免的可能性都会大打折扣。所以第一步打开你模型仓库根目录里的LICENSE文件老老实实做一次审计这是什么许可证是不是OSI认证有没有额外限制如果你的模型挂着“开源”的牌子但许可条款比Apache-2.0严一截请立刻有心理准备你可能享受不到豁免。4.2 豁免范围有限版权义务始终在第二个误读是“我是开源的所以所有义务都不用管”。即便你的模型使用Apache-2.0也不代表所有GPAI义务整体豁免。从目前监管框架的讨论方向看豁免主要覆盖的是技术文档、训练数据摘要、透明度这类相对程序性的义务但版权合规这条硬底线几乎不可能豁免。想想也合理——抽掉版权政策等于允许开源项目用抓来的版权数据白嫖训练这在任何体系里都过不了关。另外一个使所有讨论失效的条件是一旦模型被认定为系统性风险GPAI开源身份就救不了你了。不管你是不是Apache-2.0只要被认为具备系统性风险该做的评估、测试、缓解、事件报告一个都不能少。以头部开源模型的体量这条不能当不存在。4.3 “提供”和“使用”是两回事托管服务更不是开源还有一层常见混淆开源豁免权属于“提供者”。你发布权重你是提供者你拿着别人的开源权重在云上开API给企业用这个动作叫“投入使用”甚至“提供AI服务”不因为你依赖的权重是开源的而豁免。换句话说把你的开源权重做成MaaS模型即服务卖出去你需要承担的合规责任和一般商业模型提供者没有本质区别。同样模型发布方和模型微调方的责任也不同。你在开源模型基础上做微调、再发布一个新版本你对新版本承担提供者责任同时你对基础模型使用得合不合法也要自行负责。以前开源生态里大家默认“上游用了什么数据与我无关”现在链条上每一环都要有自己的记录和声明。我把几个典型角色和豁免情况整理了一下角色动作能否享受开源豁免用Apache-2.0发布自训GPAI权重的开发者提供者可能豁免部分义务版权和系统性风险除外用自定义社区许可发布权重的厂商提供者通常不能部署开源模型对外提供API服务的企业投入服务/提供者不能把开源模型集成进自家产品的企业下游使用/高风险提供者看集成场景自身义务另算这张表不需要当作定论但方向是对的开源豁免最可能的受益者是“真正以自由许可证发布、非商业化运营、且没有系统性风险的模型提供者”而不是任何“用了开源两个字”的模式。5. 现在就可以动手的八步合规清单这部分是我自己团队过去几个月实际落地的事情。没有高深理论全是工程动作每一条都能从今天开始做。第一步给项目建立“来源档案”在项目仓库里建一个docs/compliance/目录把训练数据的来源清单、代码版本、训练配置、权重包的哈希值、发布日期全部记下来。不需要一次做到完美先把有的信息补上再逐步完善。哈希值尤其重要——同一个模型的多个版本合规状况可能完全不同监管和商业伙伴都只认具体版本。第二步重写Model Card把模糊结论改成明确边界老式Model Card里常写“适合NLP研究”“不要滥用”太含糊了。现在要改成“推荐用于摘要、翻译、初级代码生成不建议用于医疗建议、法律结论、未成年人内容生成已知在X语言上表现较弱可能输出性别或种族偏见下游需自行评估。”每条都要能拿得出手。第三步建立训练数据台账在训练工程里增加一个数据采集审计层。凡是主动抓取的数据记录来源域名、抓取日期、robots.txt快照使用第三方数据集记录版本号和下载时间对于可追溯的授权数据保留授权文件。技术上说这项工作就是把数据管道里的每个输入文件都打上一张“来路证明”标签。第四步发布书面版权政策写一页纸的COPYRIGHT_POLICY.md内容包括训练数据来源分类、对robots.txt等保留权利机制的处理方式、权利人如何提交请求、你如何处理已知侵权投诉。别写空话比如“我们将尊重所有版权”要写“所有网络抓取在入库前会检查robots.txt如果权利人通过声明或邮件提出异议会在48小时内从候选数据中移除相关来源”。第五步做一次许可证审计把仓库、权重包、训练代码所有依赖组件的许可证全部过一遍不只是最外层那一个文件。很多项目主许可证是Apache-2.0但内部依赖的数据集许可证五花八门。发现问题别慌记录下哪些数据集的许可证与新监管框架下的开源豁免冲突优先处理最核心的训练数据。第六步写一份“下游注意事项”说明独立于Model Card写一份给集成方的说明文档。内容可以包括模型能力边界、安全风险、偏见报告、推荐使用方式、禁止使用方式、以及建议下游做哪些检测。OpenAI和各大模型厂商都在发布类似的System Card开源项目可以做得更透明。第七步跟踪行为准则和模板进展GPAI的技术文档、训练数据摘要、安全评估都还没有绝对固定的模板欧盟AI办公室主导的行为准则仍在持续迭代。开源社区不要当旁观者去看草案、参加咨询、提意见。规则是被参与者塑造的如果开源生态集体沉默最后出来的模板很可能完全不适合社区协作的开发模式。第八步把合规检查插进CI/CD流程这是最重要的一步。在发版流水线里加一个检查发布模型权重之前必须通过“文档完整性检查”缺少Model Card、数据台账、版权政策就直接阻塞发布。强制不如自动化只有让合规成为发版流程的一部分它才会被真正执行。手动补合规永远是“下次一定”的结局。6. 时间表、罚则与容易踩的认知误区6.1 几个关键时间节点我见过不少团队把“还不知道具体怎么执行”和“现在不用管”混为一谈。实际上监管框架的时间线已经相当清楚了时间事件2024年8月1日法案生效各项准备性工作启动2025年8月2日GPAI模型提供者义务开始适用2025年进行中行为准则、文档模板、摘要模板持续定稿2026年8月2日下游高风险AI系统相关要求开始适用2027年预计人工智能责任指令等配套规则逐步落地对开源项目来说2025年8月是第一个真正需要面对义务的时间点。上游没准备好的下游就开始用“能不能合规”来筛选模型了。6.2 罚则和管辖风险监管框架对违规行为的罚则设计得很有层次违反GPAI义务的最高罚金达到1500万欧元或上一财年全球年营业额的3%取较高者提供错误、不完整或误导性信息存在另一档罚则。具体数字以正式文本和官方解释为准但量级已经能说明问题这不是一个倡议性文件是有牙齿的。对开源开发者来说最现实的通常是组织层面的责任。个人纯学术分享、非商业科研活动、纯粹的代码托管在解释空间上是存在争议的没有任何人可以给你一个“绝对安全”的保证。但一个公司、基金会、或者商业型开源项目只要构成“提供者”身份就很难用“我们只是社区贡献者”去开脱。我建议所有公司背景的开源团队都按最严格的预期准备合规材料。6.3 五个最容易踩的认知误区我最近跟开源社区的朋友聊这个话题发现误区高度集中这里统一列一下“开源等于全豁免”错。豁免有前提且版权和系统性风险义务通常在豁免之外。“我的模型参数才几十亿肯定不算系统性风险”不一定。等效能力认定是个案判断不能被参数规模麻痹。“我是个人开发者监管拿我没办法”在面临商业使用场景时个人开发者也可能被认定为提供者只是执行上会优先追组织实体。“训练数据摘要要公开全部语料”不是。摘要是结构化的元信息描述不是训练集本身。“我只发模型不管别人怎么用”模型提供者有义务在下游信息上做必要披露否则下游责任会反噬你的生态。最后说点我自己的实操体会过去一年我在开源项目里推动合规文档建设最大的阻力不是技术而是认知——团队总觉得“这些是法务要管的我们是工程师”。但事实是训练流水线里有没有记录数据来源、发布流程里有没有强制更新Model Card、许可证审计有没有纳入依赖管理这些全是工程基础设施。法务只能帮你审一份已经写出来的文档没法帮你拼凑从来没有记录过的训练历史。开源文化一直讲透明代码透明、社区透明、决策透明。现在监管要求模型来源也透明这本来就跟开源精神是同一条路。既然早晚要做就趁现在把数据台账、许可证审计、文档模板当作和单元测试一样平常的事情。等法务邮件来了再补那才是真正的加班地狱。希望这篇能让你少走点弯路。