上周欧盟那边传出一个讨论了很久的消息AI法案的简化修订方向基本定了一边给低风险AI应用松绑另一边把“脱衣换脸”这类深度伪造工具明确列入禁止范畴。我朋友圈里做AI产品的人分成两派一派觉得终于不用被繁琐流程卡脖子另一派盯着“禁止”两个字反复确认想知道自己的业务有没有踩线。这期合规周报就围绕这件事展开重点聊两个问题监管到底简化了什么、又凭什么对“脱衣换脸”这么较真以及我们这些做模型、做产品、做部署的人接下来该怎么把合规动作落到开发流程里。如果你正在做生成式AI的创业项目、在公司里负责AI应用的安全审核或者只是好奇深度伪造监管会怎么影响AI工具这篇文章应该能给你一份可直接对照的检查思路。我不打算复述法案原文更多是站在一线实操角度把这次调整掰开来看顺便给一些能写进需求文档的合规条目。好开始。1. 这次AI法案调整到底在改什么一边松绑一边划线1.1 所谓“简化”简化的是低风险场景的行政负担很多朋友一听说欧洲要简化AI法案第一反应是“要放水了”。其实不是。这次调整更像是在风险分级框架下做了一次“程序瘦身”。从公开的立法协调动态看欧盟内部是把之前一些过于宽泛、重复性强的评估流程压了下来核心是减少低风险场景里不必要的第三方评估、统一国家标准并避免对普通软件形态的AI应用套用过高义务。用大白话说如果AI只是帮你做PPT摘要、写邮件草稿、给客服自动回复那就不再需要按高风险系统那样去做全套审计了。为什么会有这个调整因为之前的监管预期一度让大量欧洲本地创新创业团队觉得“做AI先合规成本把研发淹没了”。企业要活下去监管也要保护基本权利两边必须找到一个平衡点。简化行政环节就是一个信号监管开始意识到AI作为工具本身并不可怕可怕的是工具被用在特定危险场景。所以这次简化并没有触碰安全底线反而把力量集中到真正需要管的地方比如“脱衣换脸”这类直接伤害真实个人的生成行为。把这里想透后面的技术合规动作就不会做歪。我见过很多团队一听说监管收紧就着急给所有AI功能加审核、加水印、加一堆弹窗反而把正常用户体验搞得很差。方向不对工作量白费。正确做法是按风险等级做分类低风险功能保持轻量高风险功能投入重兵。1.2 “脱衣换脸”类AI被点名说明深度伪造从“内容问题”升级为“安全红线”“脱衣换脸”这个名字听起来像是某类工具的功能描述实际上指的是利用生成式AI对他人照片进行处理把服装移除或者把人脸合成到不适合的影像里。这种应用往往涉及未经同意的真实人物生成结果极具羞辱性和胁迫性已经被多地执法部门看作网络暴力甚至敲诈勒索的技术工具。监管单独把它拎出来禁止不是偶然。几年前深度伪造还主要是名人换脸视频现在开源模型和在线工具把技术门槛降到几乎为零。普通人只要手里有一张社交平台上的正面照就可能被批量生成成攻击性内容。这种从“明星玩梗”到“针对普通人的恶意工具”的变化让监管不得不在法案里直接写名字。不再用“深度伪造可能造成损害”这种模糊表述而是明确某种用途本身就是违禁项。这里有一个很多人忽略的点禁令不是针对“换脸”技术本身而是针对“非自愿的、性化的、以真实人物为对象的合成行为”。娱乐性质的影视换脸、特效合成仍然有合法空间。监管要抓的是那些不经过本人同意、把个人影像用于色情和羞辱场景的生成型AI。这就给产品团队留了一个非常关键的工作必须在产品定义阶段把“合法合成”和“禁止用途”分清楚而不是一刀切砍掉整个人脸生成方向。2. 禁令到底管到了谁从模型到部署的合规链路2.1 底层模型训练数据与拒答机制的合规要求先看模型层。如果你在训练或微调一个能生成人物图像的模型现在必须假设监管会追问三件事训练数据是什么、模型能不能拒绝危险请求、发布时有没有附使用限制。训练数据这关最基础但很多人过不了。原因是网上下载的大规模图文数据里往往混着大量未经授权的私人照片、成人内容样本。直接用这些数据训出来的模型哪怕你没有任何恶意意图也会在推理时“习惯性”生成带有性暗示的人体图像。合规的做法是在数据清洗阶段增加一道人物敏感度过滤对图像先做NSFW分类对人脸做去重与授权检查再进入训练管线。这一步会损失一部分数据但能明显降低模型本身的生成偏向。模型对齐是另一道关。我接触过的多模态模型大多数默认会对“naked person”这类直接词条做拒答但用户不会只输入直白词。他们会把“脱衣换脸”描述成“摄影风格”“艺术人体”“把某人的脸p到另一张照片”等变体。所以安全团队需要准备多语种、多风格的对抗样本反复测试模型的拒答率。我自己常用的提示词集里大概有几十类变体覆盖口语、缩写、梗文化实测下来能把危险生成率压到很低但不能归零。因此不能只靠模型还要靠下游部署层再加闸门。2.2 应用层生成服务商如何拦截“脱衣换脸”请求应用层是普通用户真正接触的一层也是被投诉、被执法时最容易被找上的一层。哪怕模型本身有拒答机制服务商在调用链路里还必须再补几道自己的拦截逻辑。我把它们归纳为“入口拦截、出口拦截、行为拦截”三层。入口拦截发生在用户提交请求时不只看Prompt文本还要看上传的参考图片。如果用户上传一张真实人脸照片同时输入类似“去衣”“换脸”的语义模型本身可能不知道这是犯罪但应用层可以提前识别组合风险一个真实人物的面容特征加上性化关键词直接触发拒绝。这一步在网关做规则匹配和轻量图像分类成本可控。出口拦截发生在模型返回结果之后。有些请求看似正常比如“生成一张海边美女图”但生成结果里恰好带着某个真实人物的特征。输出侧的人体合规分类器需要二次判断发现高风险的图像直接拦截不进入交付队列。行为拦截则看用户使用模式短时间内反复上传同一人脸、批量生成大量人像、尝试多种Prompt变体这些信号都指向滥用。服务商应该设置频率阈值和临时封禁机制让恶意使用者不能像筛密码一样不断试。2.3 部署方与开源社区让模型“能跑”是不是也要负责模型发布出去以后部署在别人手里发布者还能不能控制这是开源社区吵得最多的问题。我的看法是发布者和部署者的责任应当分开看但在监管预期里两边都需要做自己的功课。模型发布方至少要做到在模型卡里写清已知风险、在许可协议里加入禁止用途条款、对权重分发做基础的控制。比如明确规定不得用于非自愿亲密图像生成违反条款即失去使用授权。这听起来像是“君子协定”但它给了后续追责一个法律抓手。部署方则不能因为“模型是开源的”就认为风险与自己无关。你自己搭了一个生成服务对外开放出了问题第一个被查的是服务运营者而不是模型发布者。我建议企业把这两层责任落到两份文档一份是《模型来源与许可记录》证明你用的模型和训练数据来源合规另一份是《部署场景风险评估》写明你的产品或服务打算用什么功能、禁止哪些用途、有哪些拦截机制。这两份东西平时不起眼遇到监管问询或合作方尽调时就是最直接的合规证据。开源本身不是避风港负责任的分发才是。3. 对产品团队而言这波调整意味着哪些安全关卡要补3.1 产品立项阶段“禁止用途清单”成为必填项以前做AI产品立项很多PRD里只有功能描述、技术方案、市场分析现在必须增加“禁止用途清单”。不把它写清楚后面所有功能设计都会在“能做什么”和“该做什么”之间摇摆。举个例子你要做一个“老照片修复”工具核心功能是给模糊照片做清晰化。但因为模型具备很强的人物生成能力用户上传一张缺失的衣服部位照片可能被模型自动补全成完全不同的效果。如果在立项阶段明确了“严禁输出人体裸露或性化内容”技术选型时就会优先选择带安全对齐的模型而不是“生成能力强但什么都能画”的大模型。禁止用途清单不需要追求法律条款式的繁复但要具体到工程能理解的颗粒度。我常用的写法是不允许生成的内容类型、不允许处理的输入类型、不允许实现的高风险功能、对应的拒答和拦截策略。拿“脱衣换脸”来说清单里要写“不生成未经同意的真实人物性化合成内容”还要落到输入判定上涉及真人照片的人物编辑默认触发人工审核或直接拒绝。一旦定下来后续的模型选择、数据准备、测试用例都会有明确依据。3.2 训练与微调阶段数据清洗和模型对齐要留下测试报告进入训练阶段后最容易犯的错误是只看效果指标比如生成图像的美观度和用户点击率忽略安全指标的验证和记录。我建议在每个微调任务结束时都运行一次固定的安全回归测试并把结果归档。这个测试集可以按季度更新每次都加入新收集的恶意Prompt变体尤其是针对“真实人物去衣换脸”的各类描述方式。数据清洗不止是“过滤色情”四个字。实操上要把图像数据先过一遍多模态内容审核把带有明显性化特征、私人肖像特征、未成年人脸部特征的样本分离出来。该拒绝的别拖泥带水。我自己踩过坑有次从公开数据集抽样子来微调人像生成模型觉得大致过滤过就没事结果模型在长尾场景下生成了部分裸露效果。后来用安全测试集重新测才发现训练数据里某个子集没洗干净。所以我的习惯是清洗后还要在小样本上做一次生成验证而不是只看分类器给出的“安全”标签。模型对齐方面除了系统提示词还要考虑拒绝语气。我见过不少模型确实会拒答但拒绝信息写得很生硬用户一看就知道“关键词被屏蔽了”于是换一种说法继续试。有效的做法是让模型以常规方式回答“我无法处理这类涉及个人隐私的图像编辑请求”并给出替代建议比如建议使用卡通形象或授权图片。这很细节但能显著降低用户尝试绕过系统的意愿。3.3 上线与运营阶段水印、标识、审核与举报闭环一旦AI生成内容对外提供透明标识就不再是“可选项”。欧盟以及越来越多地区的监管方向都要求用户能明确分辨内容是否为AI生成。落地到产品上至少要做到两层一层是界面上的明确提示例如生成图片角落的水印或文案“AI生成内容”另一层是文件本身可追溯的元数据采用类似C2PA的内容凭证标准把生成时间、模型来源、操作链路写进文件信息里。哪怕用户截图平台也能通过后续比对识别来源。不要只在平台内加水印截图传播后水印就失效元数据才能留存一部分可验证信息。审核环节我强调四个动作先审后发、违规拦截、快速下架、反馈闭环。对高风险的生成服务必须在输出到用户之前完成自动审核不要依赖事后举报。同时要给用户一个顺畅的举报通道并明确承诺处置时间。我自己在运营AI图片工具时会把“举报处置时长”当成核心周报指标来追踪。这个数据不只反映客服质量还反映整个审核链条是否健康。如果平均处置时间超过24小时说明流程里有卡点需要立刻排查是人工队列积压还是自动分类器漏检。4. 落地实操从需求到上线怎么把合规动作做进流程4.1 输出一份“合规红线速查表”与其每次开会争论某个功能能不能做不如提前做一张合规红线速查表让产品和研发直接对照。下面是我在项目里常用的简化版维度不追求覆盖所有法律风险重点是把最高频的场景先管住。场景风险级别必选动作真实人物换脸到色情或羞辱性内容最高风险直接禁止入口拦真人脸加性化词组合输出再做分类对真实人物做去衣处理最高风险直接禁止图片输入检测拒绝包含疑似真实人脸的编辑请求生成虚拟人物但外观酷似真实个人高风险检测输出人脸相似度超过阈值拒绝或模糊化普通AI换脸用于搞笑视频中风险需要显著标识“AI合成”并提供被换脸方申诉通道常规照片修复与上色低风险保持基础审核无需高强度检测这张表的价值在于让团队在功能评审阶段就能对号入座。我一般在评审时直接用表里的“风险级别”来定资源投入最高风险的场景不做或做全面拦截低风险场景别浪费太多开发力量。合规不是让所有功能都套上同样的枷锁而是让每一档风险得到匹配它的控制强度。4.2 上线前的安全测试清单负面样例加对抗输入上线前测试是发现合规漏洞最关键的环节但很多团队只做功能测试不做安全测试。我习惯把安全测试分成两类一类是“已知违规样例”直接验证常见违规请求是否被拦截另一类是“对抗输入”模拟用户各种绕过手段。对抗输入特别重要因为真实的滥用者不会输“我要做脱衣换脸”而是会说“把衣服去掉”“换个造型”“生成私人写真”。具体执行上我建议准备一批由安全人员、产品和运营共同维护的Prompt变体库至少包含以下类型明确性化词、人体部位描述、特定人名加性化词、名人或素人照片上传加修改指令、非英语口语里常见的替代表达。现在也可以用AI Agent跑一轮自动变体生成先粗筛再人工评审效率会高很多。每个变体至少在灰度环境跑三次记录拦截或放行的结果并把连续失败的用例加入回归集。我见过一些团队把安全测试全交给开发自测结果开发用自己论文里的Prompt测了一遍看着全拦截实际上用户换个词就绕过。正确的做法是找不懂“内部规则”的成员来写绕道Prompt越贴近真实用户越好。测试结束后要生成一份可追溯的安全测试报告。这份报告不需要写得像论文那么长但要包含测试日期、测试用例集版本、通过率、失败用例修复记录。它不仅是给自己看的也是后期应对监管问询的重要证据。没有记录的合规动作等于没有做过。4.3 上线后监控什么指标从“有没有出事”到“是否形成风险趋势”上线只是合规工作的开始。我每周固定看几个指标不只是看有没有重大事故而是看风险趋势。第一是违规生成率也就是系统自动拦截的违规内容在所有生成请求中的占比。这个数字长期偏高说明模型或Prompt解析有漏洞突然飙升可能迎来了一波新的恶意攻击方式。第二是投诉率尤其是“我的照片被拿去生成内容”这类投诉。它比一般内容举报严重得多一旦出现就要立刻回溯同源用户和同源照片。第三是举报处置时长前面提过超过24小时就要查流程。还有两个容易被忽略的指标模型修改后安全回归是否通过、以及自动化拦截误伤率。模型升级时经常会顺手改变安全性不跑回归就会把旧漏洞带回来。误伤率高则说明拦截规则过于粗糙把正常的人像生成请求也拦了用户体验受损后产品团队往往会偷偷调低拦截力度这样做非常危险。正确思路是给误伤设置一个单独监控不超过5%或相应业务容忍线避免靠牺牲安全来换体验。5. 这周收到的高频问题与避坑经验5.1 “开源模型是不是不用负责”这周几乎每天都有朋友问我用的是开源模型权重公开发布那我基于它做产品还需要负责吗答案是肯定的。开源不等于无主更不等于部署方免责。你要区分两个角色模型发布者负责提供模型时附上使用限制和风险说明而你作为部署方负责在你把模型变成对外服务时的安全控制。就像一个工具发布者说“这个工具不能用于破坏”但你拿它去做破坏责任不会自动消失。实操上我会在项目启动时做三件事记录模型的来源和许可证确认许可里有没有禁止用途条款把部署场景写成一份简短说明包括功能列表、目标用户、拦截手段再往代码仓库里放一个SECURITY.md写明发现违规行为时的处理流程和联系方式。这些动作不复杂但在审计或合作方询问时能省下很多解释成本。5.2 “用户上传图片导致违规责任怎么分”这类问题背后是传统平台“避风港”思维的延续平台说只要用户协议写了禁止出事就与我无关。但生成式AI服务与传统UGC平台有一个本质区别输出内容不是用户上传的现成内容而是由你的模型在请求后生成的。平台在整个生成链路里是主动参与者因此监管往往会认为平台有更强的控制义务。所以不要指望一句“用户自行承担”能免责。更好的做法是把责任拆到技术环节里入口拦截不合格输入输出侧拦截违规结果再加上事后溯源。如果模型就是没能拦下一个边界样本平台要能提供完整的日志说明哪一步做了判断、为什么放行。这种“自证清白”的能力比任何用户协议都重要。我建议从第一天开始就把关键请求日志留着至少保存一定期限才算有底线。5.3 “内容标识到底怎么做才不算摆设”上周有人问了很具体的问题我们已经在生成图片上放了一行“AI生成”小字为什么审核还被挑战因为审核人员不只盯着画面上有没有水印更看重内容是否能在底层被验证。只放界面文字截图后便无法追踪等同于标识无效。我理解的最小可行方案有四层第一层生成图片右下角加肉眼可见的水印或角标第二层把“AI生成”信息写入EXIF等元数据第三层接入内容凭证标准把生成模型、操作记录等存到签名元数据里第四层在平台内做记录索引用户申诉时能快速查证。四层不必一次全部到位但至少要满足“可见加可溯源”。不然等被拿去虚假传播后你连证明它是AI生成的证据都拿不出来。6. 本周合规观察笔记这周的新闻让我重新想清楚了一件事简化流程和禁止滥用在监管设计里并不矛盾反而互为表里。把低风险应用从沉重的合规流程中释放出来监管资源才能集中在“脱衣换脸”这类真正危险的使用方式上。我身边很多AI从业者担心监管会扼杀创新但从实际产品反馈看安全风控做得好的团队反而更容易通过合作方审核、更容易在海外市场拿到入场资格。安全投入不能简单看成成本它也是某种意义上的市场准入能力。最后再分享一个这几天发现的真实细节不少团队的安全测试集还停留在“艺术家画作”层面缺少针对真实人物照片的攻击样例。我建议如果你的产品涉及人像生成请尽快补充“真人照片上传加编辑请求”的测试路径并让运营定期在网上收集新的滥用话术加入回归集。合规不会一步到位但只要每周坚持跟进、把问题记录成文档产品会越来越稳。这期周报先到这里我会在下次有新信息时直接做一轮对照更新。