EU AI ACT落地指南：风险分级、合规要求与出海准备

前两年聊欧盟人工智能法案（EU AI ACT），很多同行觉得这是法务和合规团队的事，离写代码、做产品的自己很远。直到最近几个月，我陆续接到几个同样的问题：有做聊天机器人出海的，被欧洲的渠道商追问有没有做过AI法案评估；有做招聘筛选系统的，正在被客户要求提供技术文档和偏差测试报告；还有几个接了大模型API做垂直应用的团队，发现自己上游模型的合规材料一团乱麻，合同条款里根本不知道该怎么写。这个时候再回头看这部法案，很多当初觉得遥远的东西已经变得具体了。

这篇文章我想从一个技术从业者的视角，把EU AI ACT重新梳理一遍，重点讲清楚四件事：这部法案的监管节奏到底走到哪一步了、它的风险分级逻辑怎么理解、高风险系统到底要求做什么、以及如果你明年要带产品出海，现在应该做什么准备。内容不是法条翻译，而是我基于实操项目整理的解读和落地经验。适合AI产品经理、技术负责人、算法工程师，以及所有需要和欧洲客户对接AI业务的同学参考。

1. 为什么现在必须重新读一遍：监管时间线已经走进窗口期

EU AI Act在2024年8月1日正式生效，但它的义务不是一次性落地，而是分了好几个阶段逐步生效。很多团队的问题是：法案通过的时候觉得离自己很远，等到阶段节点一个一个到来，才发现自己在裸奔。

1.1 四个关键时间节点，先记下来

我把最重要的时间点整理成一张表，建议贴在项目组公共文档里：

这中间还有若干细分节点，比如某些治理框架和高风险系统的一部分条款会先于2026年适用，但我上面列的这四行，是绝大多数产品最需要关心的。

1.2 为什么这个时间点变得紧迫

2025年2月，禁止条款已经生效。这意味着什么？如果产品里存在不可接受的AI实践，从这天起理论上已经可以被执法机关处罚，而不是等你到2026年才准备。

而真正让很多团队焦虑的是2026年8月的高风险系统大限。从现在往回算，留给产品改造、文档补全、内部测试的时间也就一年多。考虑到招聘、培训和供应商沟通的成本，实际有效准备时间可能只有半年到九个月。

我在某个客户的内部风险评估项目里看过一个典型状态：技术团队已经掌握不少新能力，但公司层面既没有AI系统清单，也没有为AI产品定义过用途分类，更不用说技术文档和告警机制。这类情况在中小团队里很普遍，因为平时AI功能是零散地加在业务里的，没有谁把"AI系统"当成需要独立管理的资产。

1.3 谁最容易被条款击中

法案的适用范围非常宽，并不只约束"从事AI研发"的公司。只要你的AI系统在欧盟市场投入使用，或者你的AI系统输出结果被欧盟境内的人使用，都可能落入管辖范围。

我把容易"被击中"的人群分为三类：

• 自研AI系统并面向欧洲用户提供服务的团队
• 把第三方大模型API集成进产品、且用户包含欧洲用户的团队
• 被欧洲B端客户采购时，需要提供合规保证的供应商

第三类最容易被忽略。很多做SaaS的团队，之前完全没有意识到欧洲客户在采购合同里已经开始加AI合规条款。你的产品哪怕只是用了某个大模型接口做摘要，客户也会要求你说明：这个AI系统的风险等级是什么？有没有做过评估？有没有透明度说明？答不上来，订单就黄了。

2. 四层风险金字塔：你的产品落在哪一层，决定了你要做多少事

EU AI Act最具实操价值的设计，是它的风险分级框架。它把AI系统按"预期用途"分成四个风险等级，不同等级对应完全不同的义务强度。这里的关键词是"预期用途"，也就是说判断风险不看你用了什么算法，而是看这个系统拿来做什么。

2.1 金字塔底部：最小风险

第一层是最小风险，包括垃圾邮件过滤器、游戏AI、库存预测、推荐系统这类对个人安全和权利影响有限的场景。法案不强制这类系统履行专门义务，但鼓励企业自愿采用行为准则。

绝大部分做内部提效工具的公司，实际落在这个层级。你用一个AI来做数据分析，帮员工整理报表，这里面既没有个人画像的大规模处理，也不涉及影响用户权利的决策，基本上不需要为这部法案做专门改造。我见过不少同行一听说欧盟AI法案就很紧张，结果逐条对照下来发现自己的产品连"AI系统"的文档要求都够不到，虚惊一场。

2.2 有限风险：透明度义务为主

第二层是有限风险，核心义务是透明度。典型场景包括聊天机器人、AI生成内容、深度伪造等。用户需要知道自己在和AI交互，AI生成的内容需要可以被识别，深度伪造内容需要标注。

这一层是大多数消费级AI产品和AIGC工具的合规主战场。做客服机器人的团队通常要准备一份透明度声明，说明系统是AI、能力边界是什么、人和AI交互时如何被提示。涉及语音或视频合成的，还要考虑内容水印和来源标识。不要小看透明度义务，它看起来简单，实际操作中涉及产品界面的文案、交互流程、日志保留等多个环节，不是写一句话就能糊弄过去的。

2.3 高风险：最重的一块义务

第三层是高风险，这是整部法案监管最重的部分。高风险清单包括：关键基础设施的安全组件、教育或职业培训、就业和用工管理、基本公共服务、执法、移民管理、司法等场景。

举几个更具体的例子：招聘筛选用AI系统属于高风险；高校录取或考试评阅用AI属于高风险；银行远程开户里面的活体检测如果涉及身份评估，也可能落入高风险；公共福利发放的资格判断同样在高风险范围内。也就是说，只要你的AI系统可能在"影响个人获得机会、权利或关键服务"的环节做出判断或辅助判断，就得按高风险来对待。

判断逻辑非常简单直接：这个AI的决策，是不是可能让一个人得不到工作、得不到贷款、得不到公共服务？如果是，大概率就是高风险。

2.4 顶部：不可接受风险，直接用不得

金字塔顶端是不可接受风险，对应的不是"多承担义务"，而是直接禁止。这部分是红线中的红线。

我记得法案列出的禁止行为包括：使用潜意识操纵技术或利用年龄、残疾、社会经济状况等脆弱性，对个人造成重大伤害的；利用远程生物识别数据在公共场所无差别抓取人脸来构建数据库的；基于AI进行社会评分，从而导致不利对待的；以及在执法场景中，仅基于画像分析对自然人进行预测性警务（除非有特定法律授权）。

这部分的适用判断要特别谨慎。比如一个营销工具，如果利用了用户的认知弱点引导下单，理论上有可能擦边；用AI分析情绪来针对性地引导儿童购买，也属于危险区域。我在项目实践中一般建议客户：只要产品逻辑存在"利用弱势群体的倾向做转化"的痕迹，就不要碰，因为这类行为不仅违反AI法案，各国的消费者保护法也在盯着同一件事。

2.5 风险分类的实操判断顺序

我习惯用一个三步判断法来做风险等级初判，也分享给大家：

1. 写下系统部署的具体场景和目标用户（预期用途）
2. 对照高风险清单，看是否涉及就业、教育、公共服务、执法、司法等场景
3. 再往上对照禁止清单，看是否存在操纵、社会评分、无差别人脸抓取等行为

往往三步走完，结论就已经很清楚了。真正的难点不在于找到自己的等级，而在于团队内部对"预期用途"没有共识。同一个模型，在A产品里只是做简历关键词提取，属于低风险；如果把它放到B产品里做候选人匹配排序，就是高风险了。所以风险分类必须绑定具体产品场景，不能笼统地说"我们的AI是什么风险等级"。

3. 高风险系统不是说说而已：七项硬性要求的落地拆解

如果你的产品被认定为高风险AI系统，麻烦的工作就开始了。法案对高风险系统的要求可以归纳为七大类，下面我逐个拆解，同时结合我接触过的项目，说说每一类到底要落地成什么东西。

3.1 风险管理系统

第一项是建立并维护风险管理体系。具体要求包括：识别和分析可预见的风险、评估风险、采用合适的缓解措施、在系统上市后持续监控。

这个听起来官方，但实操上其实就是一件事：建一份风险登记表，把已知风险按"场景-触发条件-影响-缓解措施-验证结果"的格式写清楚。我见过做得好的团队，会针对每一个高风险场景写一个测试用例集，每个用例都绑定到具体的缓解措施上，比如"当系统置信度低于阈值时，自动转人工处理"。

3.2 数据治理

第二项是数据治理，要求训练、验证、测试数据集满足相关性、代表性、无偏差等要求。

这里最容易踩坑的是数据集文档化。很多团队训练模型时用的是多年前积累的数据，当时根本没有记录数据来源、授权情况、去标识化处理过程。等要写数据治理报告时，发现很多数据是"历史里挖出来的"，说不清楚来源。我在给一个模拟项目做咨询时，第一件事就是要求他们统计每个训练集的数据来源、敏感属性字段、标注方式和已知偏差，并把这些整理成数据卡片。

值得注意的是，法案并不是要求"数据里不能有偏差"，而是要求"你能证明自己做了合理的偏差检测和缓解"。完全消除偏差在技术上不现实，但"没有做过检测"和"做了检测并缓解"在合规评价上是天壤之别。

3.3 技术文档

第三项是技术文档。这不是给用户看的使用说明书，而是给监管机构和评估机构看的技术档案，需要包含：系统的预期用途、算法架构、训练方法和数据情况、评估方法和结果、已知限制、安全措施、测试流程等。

准备技术文档有一个实用技巧：直接以"模型卡（Model Card）"为基底做扩展。大部分模型团队现在都会维护模型卡，里面有训练数据、评估指标、限制说明。把模型卡再补上系统层面的设计信息、部署环境、监控机制，就基本能构成法案要求的技术文档雏形。不需要从零开始写一部几十页的说明书。

3.4 记录保持

第四项是自动日志记录，要求高风险AI系统在运行期间自动记录事件日志，日志需要能支持追溯系统功能和事后审计。日志至少要在系统的生命周期内保存。

这意味着从第一天起就要考虑日志设计。比如一个招聘筛选系统，算法对候选人给出了推荐等级，你需要记录下：输入了哪些数据、模型输出了什么结果、当时模型的版本是什么、有没有人工介入的标记。没有日志，出了投诉就变成"说不清楚谁做的决定"，那在监管和司法层面都非常被动。

3.5 透明度义务

第五项是向用户提供透明信息。高风险系统的部署方需要被告知：系统正在运行、它的能力和局限性、它是怎么辅助决策的、用户如何行使"人工介入和申诉"的权利。

我把它理解为产品层面的一套"AI信息披露机制"。你在界面上要告诉用户，这个结果由AI生成，并且解释清楚用户有没有权利要求人工复核。这个界面文案最好和法务、产品、技术一起评审，因为它既要诚实客观，又不能把产品说得一无是处。

3.6 人工监督

第六项是人工监督，要求高风险系统在设计中就允许自然人有效监督。措施包括：在系统层面接入人工介入机制（暂停、覆盖、终止）、识别和拒绝系统输出中的异常、向操作人员说明如何解读系统输出。

实际做的时候，比较麻烦的是"人工监督"和"自动化效率"之间的平衡。一个招聘平台如果每份简历都要人工审核，那就回到纯手工时代；但完全自动化，又不符合法案的预期。做得好的方案是分级处理：低风险岗位由AI初筛，但保留人工复核入口；高风险岗位（比如高管岗位）必须人工决策，AI只提供参考信息。这既保留了效率，也给了人工监督足够的空间。

3.7 准确性、鲁棒性与网络安全

第七项是确保准确性、鲁棒性和网络安全。具体要求包括：系统在设定的精度指标内稳定运行、对错误输入有合理的容错、能抵御对抗性攻击或恶意操纵。

关键是"设定精度指标"。你不能笼统地说"我们的模型很准确"，而是要有明确的评测基准和可接受阈值。比如一个导诊AI，你对"症状-分诊科室"预测的准确率定在多少？低于阈值时系统是给出提示还是转人工？这些在设计和上线前就要写清楚。至于网络安全，对于部署在云端的高风险系统，尤其要注意输入数据的对抗性样本问题，以及模型接口被恶意调用的问题。

3.8 额外环节：合格评定和注册

除了上述七项，高风险系统还有一个容易忽略的环节：合格评定（conformity assessment）。一部分高风险系统要接受第三方公告机构的审核（比如涉及 biometric 身份识别的场景），其余大部分可以走自我评估，但要准备全套技术文档。

评估通过后，还要在欧盟的AI数据库中完成注册。这个注册不是走形式，而是会影响到后续的上市和运营。很多团队以为把自己产品包装好就行，忽略了"在欧盟数据库里登记"这一步，结果被渠道商问及时才发现产品连个合规编号都没有。

4. 通用AI模型（GPAI）：从参数量到系统性风险的判断难题

刚才说的高风险规则，主要针对使用场景。但EU AI Act专门拿出一章来管"通用AI模型"，也就是那些本身不是为了单一特定任务开发的、可以被下游集成到各种场景的大模型。这一块对做底层模型和API的团队影响很大。

4.1 什么是GPAI，判断依据是什么

通用AI模型的典型代表是大型语言模型，但GPAI不只是语言模型，也包括可以处理多模态数据的模型。判断标准不是"是不是大语言模型"，而是"这个模型是否具有通用性，能执行多种任务，并能被集成到下游系统中"。

法案里对GPAI给出的义务包括：到位的技术文档、训练数据的详细摘要、版权合规政策，以及当模型被集成到下游系统时，向下游系统提供必要信息。也就是说，如果你用别人的API做产品，供应商必须向你说明模型的能力边界、数据情况和合规状态，你也要能够在自己的系统文档里引用这些信息。

4.2 系统性风险模型：一个大计算量阈值

GPAI里面又单独划出一个子类：具有系统性风险的GPAI。目前法案给出的推定标准是：训练该模型所用的总计算量超过10^25 FLOPs，就会被推定为具有系统性风险。这个数字会随着技术发展调整，但目前的监管框架以此为准。

系统性风险模型要承担更重的义务：做全面的模型评估和对抗性测试、跟踪并报告严重事件、确保足够的网络安全防护、向委员会报告模型性能和安全指标。

我看到很多团队在讨论这个阈值时有个误区：拿自己的估算算了一笔，觉得"我们离10^25很远，不关我的事"。事实上，对于绝大多数中小团队来说，你根本不会自己去训练一个基础大模型，你只会去调用大厂的API。所以系统性风险模型的义务其实主要由上游厂商承担，你的责任在于：确认你调用的模型是否有系统性风险，以及把这个情况传递给你的客户。

4.3 开源模型的特殊待遇

法案对开源模型（在开源许可下公开权重和参数）设置了一些豁免，除非该模型构成系统性风险。这意味着一个开源的、不构成系统性风险的通用模型，可以免掉一部分文档和透明度义务，但版权政策、公开摘要等基础义务还是保留。

这对于在本地部署开源模型的团队是个好消息。不过需要小心：如果基于开源模型开发出的产品本身属于高风险场景，那么"模型训练端"的豁免并不能豁免你"使用端"的高风险义务。换句话说，开源只是让你作为模型提供者的义务变轻，不改变你作为系统部署方的高风险责任。

4.4 下游开发者该怎么选供应商

我现在的建议是，接第三方大模型API做产品，第一步就要向供应商索取AI法案合规材料。包括：模型是什么风险分类、有没有技术文档、训练数据摘要是否公开、是否做过系统性风险评估。

如果供应商拿不出这些东西，而你的产品要进欧洲市场，这条供应链本身就存在隐患。不能把合规责任全押在自己身上，因为很多义务在模型层就已经决定了你没法另起炉灶。合规链路上的每个环节，最好都对应到合同条款里。

5. 罚款与执法：那些看起来遥远的事情，会变成合同条款

如果把EU AI Act看成一套技术标准，你可能低估了它的重量。因为这部法案的罚款金额，是按"全球年营业额"计算的，而不是按欧盟境内的收入。

5.1 罚款的分类标准

具体来说，违反不同条款的罚款上限分为三档：

• 违反禁止条款，最高罚3500万欧元或上一财年全球年营业额的7%
• 违反高风险系统的大部分义务、GPAI义务，最高罚1500万欧元或全球年营业额的3%
• 向监管机构提供不正确、不完整、误导性信息，最高罚750万欧元或全球年营业额的1%

注意"全球年营业额"这几个字。哪怕你的欧洲业务只占整体营收的5%，罚款基数也是按全球盘子来算的。这一点让那些想"丢了欧洲市场就算了"的团队也得掂量一下，因为罚单不是按欧洲收入来开的。

5.2 和GDPR的叠加效应

很多团队对GDPR已经很熟，以为AI法案是另一套独立体系。但它们会同时生效，而且AI系统里涉及个人数据的处理，两个法规的条款可能同时适用。比如你的AI招聘系统在处理候选人数据时，既受GDPR约束，又受AI法案高风险条款约束。出了问题，两边都可能被追责，罚款可能叠加。

实操上的建议是：做合规设计时，把GDPR的数据保护和AI法案的AI治理合并成一件事来推进。数据保护影响评估（DPIA）和AI风险管理的流程高度重叠，两份文档可以共享很多内容，合并推进能省一半力气。

5.3 真正影响商业的可能是B端合同

除了监管罚款，还有一条更快的传导路径——合同。欧洲B端客户的采购流程里已经出现AI合规尽调，甲方会要求乙方书面保证其AI系统符合EU AI Act，并约定违约赔偿条款。

后果就是：哪怕你产品只卖给一个欧洲企业，只要你的AI合规材料不齐全，就可能因为一纸合同条款丢掉订单或被索赔。这不是遥远的监管故事，而是正在发生的商业现实。我接触的几家做企业服务的团队，已经有客户在问卷里直接列出"AI风险等级自评表"和"技术文档清单"，答不上来就进不了下一轮。

6. 出海前的合规自查清单：从框架到实施的经验总结

说了这么多，最后落到执行层面。我建议任何准备面向欧洲市场提供AI产品的团队，都按照下面的链路做一次自查。不需要一次做完，但要开始做。

6.1 第一步：建立AI系统清单

先把公司内部所有用了模型、算法、自动决策的功能点列成一个清单。包括系统名称、用途、部署场景、使用的模型来源、是否涉及个人数据、是否有自动化决策。

这一步看起来简单，但在实际公司里往往最费劲，因为很多AI功能分布在不同的业务线里，甚至有的团队自己都不清楚哪个环节用了第三方API。没有清单，后面所有工作都是空谈。

6.2 第二步：为每个系统做风险分级

按照上一节的三步判断法，为清单里的每个系统做风险分级。分级结果最好由产品、技术、法务三方一起确认，因为不同角色对"用途"的理解可能不一样。这一步的输出是一张风险分层表，标明每个系统是禁止、高风险、有限风险还是最小风险。

注意：风险分级不是一次性的，产品需求变了、用户场景变了，风险等级就可能变。我见过一个客服机器人，本来只是做FAQ问答（有限风险），后来产品经理加了一个"自动给用户打情绪标签"的功能，变成了对用户进行画像，风险等级就得重新评估。

6.3 第三步：按等级补齐文档

对每个系统，按风险等级准备文档：

• 最小风险：维护一份简要的AI系统说明即可
• 有限风险：准备透明度说明，确认用户能看到AI交互标识和内容水印
• 高风险：按七项要求准备风险管理系统、技术文档、数据治理报告、日志方案、人工监督设计等

高危系统的文档建议不要零散存在个人电脑里，建一个统一的AI合规文档库，按系统维度管理，这样后面被客户尽调时可以在一个小时内打包输出。

6.4 第四步：向上下游传递合规信息

如果你的产品接入了上游AI模型，向供应商索取合规材料；如果你把AI能力集成后提供给下游客户，把合规信息传递给客户。这条链路要像食品安全溯源一样清楚：谁提供模型、谁能提供什么证明、谁承担哪一层责任。

6.5 第五步：把时间节点管理起来

把前文的时间表放到项目管理的里程碑里。尤其是被认定为高风险的系统，2026年8月不是可以观望的日期，而是所有要求完全生效的日期。给自己设定一个内部提前量，比如在2026年第二季度完成所有测试和文档工作，留出缓冲时间去处理评审和注册流程。

我个人在实际项目中的体会是，EU AI Act本质上不是什么高深的设计，它只是要求把AI系统当成一件"需要负责的产品"来对待：写清楚它做什么、怎么做的、出了差错怎么办、谁能干预。以前大家开发AI功能是"快速试错"的思路，现在多了一层"留痕、可解释、可监督"的约束。这个约束未必都是坏处，很多团队在补文档的过程中，反而发现了模型的隐藏故障和逻辑漏洞，顺手把产品质量提升了一截。

最后再分享一个小技巧：合规准备不用等法律团队来牵头，产品和技术团队可以先从一份"AI清单"开始，把公司里每一个AI功能列出来。只要这个清单能列出来，后面的事情，一步一步做，都是时间问题。