欧盟《AI 法案》进入实施阶段：企业合规指南

一、实施阶段首先改变企业的责任边界

AI 法案在 2024 年 8 月 1 日生效，但义务按照风险和市场角色分阶段适用。2025 年 2 月 2 日起，禁止的人工智能实践和人工智能素养要求开始生效；2025 年 8 月 2 日起，通用人工智能模型的核心义务进入实施阶段；2026 年 8 月 2 日则是大多数系统义务和透明度要求的关键节点。与受监管产品安全规则相连的部分高风险系统拥有更长的过渡期，部分要求会延伸至 2027 年 8 月 2 日，因此企业仍需结合系统类型和过渡条款确认准确日期。^[1]

这些日期把原本分散的产品、采购和管理决定连到了一起，也标志着相应规则进入不同的适用阶段。产品经理需要在版本计划中预留重新分类和回归测试的时间，采购团队要在供应商续约前取得最新的技术文件，人力资源部门在启用招聘或员工分析工具前要完成基本权利审查，董事会也需要看到哪些系统仍存在没有关闭的高风险缺口。

如果企业只把日期记在法务日历里，其他部门仍按原来的方式上线系统，法规就不会真正进入经营流程。相反，当每个日期都与负责人、交付物和证据位置绑定时，企业才有可能在客户问询、监管抽查或事故发生后迅速还原当时的判断依据。欧盟委员会仍会持续发布实施材料，成员国也会完善本国的监督和处罚安排，因此法规版本、委员会说明、成员国通知和内部结论都应纳入同一份变更记录。^[2]

AI 法案的地域范围也决定了这不是欧盟总部企业才需要处理的问题。只要系统在欧盟市场提供，或者系统输出会在欧盟被使用，境外企业就可能进入法规范围。服务器位于美国或亚洲，模型由第三方托管，都不能单独证明企业与欧盟监管无关。对跨境业务而言，合规判断应从客户所在地、输出使用地和系统影响对象出发，而不能只看开发团队和数据中心在哪里。

进入法规范围后，企业还要按供应链角色确定义务。开发系统并以自己名义投放市场的一方属于提供者，在日常业务中使用系统的一方属于部署者，把第三国系统带入欧盟市场的是进口商，向市场供应系统的是分销商，非欧盟提供者还可能需要指定授权代表。不同角色承担的文件、监督和市场义务并不相同，所以角色判断决定后续全部控制措施。^[1]

同一家公司经常同时拥有多个角色。企业可能先以部署者身份采购一个通用模型，随后加入自有数据、工作流和决策规则，再把整套服务以自己的品牌卖给客户。如果企业改变了系统的预期用途，或者实施了足以影响合规状态的重大修改，原本由供应商承担的部分提供者责任就可能转移过来。

这解释了为什么合同中的“供应商负责合规”不能替代企业自己的判断。供应商可以负责模型层面的技术文件、版本说明和漏洞修复，但企业仍要对具体业务用途、输入数据、用户告知、人工复核和最终决定负责。责任不会因为合同中出现一句概括性承诺就自动消失，也不会因为底层模型由知名公司提供就变得清楚。

较为实用的做法是为每个系统建立一张角色卡，记录谁决定预期用途，谁选择模型版本，谁控制输入数据，谁批准上线，谁有权暂停服务，以及输出最终由谁使用。角色卡还应与系统版本和合同主体绑定，业务用途、品牌、模型或市场范围变化后重新确认。这样做能把抽象的法律角色变成可执行的内部责任，避免企业在年末审计时临时寻找负责人。

角色判断一旦清楚，企业才能进一步回答哪些义务由供应商完成，哪些证据必须自己保存，哪些事故需要双方共同处理。接下来要解决的就不再是“谁负责”这个问题，而是同一个系统在具体场景中究竟需要多强的控制。

二、实际用途和影响决定控制强度

AI 法案并不要求所有系统承担完全相同的义务，而是根据实际用途和可能造成的影响，区分禁止实践、高风险系统、需要履行透明度义务的系统以及最低风险系统。风险分类应以模型在具体业务流程中的实际作用为准。

第一道边界是禁止实践。法规禁止利用潜意识操纵或有目的的欺骗来改变人的行为，也禁止利用儿童、老年人和残障人士等群体的弱点造成重大伤害。社会评分、根据生物特征推断敏感属性、在工作场所或学校进行某些情绪识别，以及只依据画像预测个人犯罪风险，也处于禁止或严格限制范围。公共场所的实时远程生物识别只有非常狭窄的执法例外。^[1]

实践中的难点往往不在于企业公开采购了一款名为“社会评分”的产品，而在于高风险功能被更温和的名称包装起来。把员工情绪识别称为“状态洞察”，把自动拒贷称为“客户分层”，不会改变系统对人的实际影响。审查时应使用普通语言说明系统读取了谁的数据，生成了什么判断，判断会触发什么动作，受影响者能否提出异议。只要其中一项无法说明，就不应继续自动化上线。

不属于禁止实践的系统仍可能因为用途和结果进入高风险范围。高风险系统主要来自两条路径。一类系统是受监管产品的安全部件，另一类来自附录三列出的关键领域，包括生物识别、教育、招聘和员工管理、重要基础设施、基本服务、执法、移民与边境管理以及司法和民主流程。招聘排序、信贷资格评估、保险定价和医疗资源分配之所以需要更严格的控制，是因为它们会直接改变个人获得工作、服务和机会的可能性。^[1]

同一底层模型放在不同流程中，风险结论可能完全不同。帮助招聘人员整理岗位描述的语言模型，与自动决定候选人是否进入面试的系统，不能归入同一风险档；客服机器人起草退款回复，与系统自动关闭账户，也不是同一种控制要求。分类文件必须写清预期用途、输入数据、受影响群体、人工决定点和可能产生的后果，才能为后续控制强度提供理由。

还有一些系统不属于高风险，却会影响用户对内容和互动对象的判断，因此需要通过透明度义务减少信息不对称。聊天机器人通常需要在互动开始时说明其机器身份，合成图像、音频和视频在适用场景下需要标注，深度伪造和公共利益信息尤其要谨慎。如果系统在工作场所进行情绪推断，或者根据生物特征分类，风险还可能迅速上升。^[1]

最低风险系统也需要基本治理。内部写作助手应禁止输入客户机密，代码助手要保护密钥和未发布代码，员工需要知道如何核实模型提供的事实和链接。风险分类的作用不是为某些系统提供免责标签，而是让企业把资源放到风险更高的地方，同时保留所有系统都应具备的最低控制。

三、合规的核心是一条贯穿供应链的证据链

当系统被认定为高风险后，企业需要证明的不只是自己制定过一份政策，而是风险管理、数据治理、技术测试、人工监督和运行监测之间确实形成了连续关系。如果每项材料单独存在，却不能说明某个风险如何被识别，由哪项控制降低，上线后又如何被监测，那么文件数量再多也无法形成可信的合规证据。

风险管理应从具体伤害开始。团队先识别系统可能造成的安全、歧视、隐私和基本权利影响，再估计发生的可能性和严重程度，设定能够接受的范围，实施缓解措施，并在上线后使用真实运行数据检查剩余风险。准确率只是其中一个指标，不同群体的错误率、分布漂移、可解释性、鲁棒性和网络安全都应进入测试。模型更新前后还要使用可比较的基准，以确认风险究竟改善了还是转移了。

数据治理则要解释测试结果为何可信。训练和验证数据从哪里来，是否拥有许可，是否包含重复样本和错误标签，是否代表实际用户，谁批准了清洗规则，都应留下记录。完全不收集敏感属性并不等于没有歧视风险，因为邮编、学校、语言和工作经历都可能成为代理变量。如果为了偏差检测确有必要处理敏感属性，应在受控环境中完成，并采用最小化、访问限制和到期删除措施。

技术文档和运行日志负责把设计决定与实际使用连接起来。文档应说明预期用途、系统架构、训练方法、性能限制、测试结果、人工监督设计和安全措施，日志则应记录输入、输出、人工干预、异常和版本变更。日志全部留在供应商后台并不够，部署者至少要能够导出与自身决定有关的记录，并把记录关联到具体模型版本和操作人。^[1]

人工监督也必须能够真正改变结果。监督人员不仅需要培训，还需要有权暂停、覆盖和撤销模型输出，并且拥有足够时间作出独立判断。招聘、信贷、医疗和公共服务场景不能把模型分数直接复制为最终决定，界面也不应把“接受模型建议”设计成唯一的默认选项。当人工不同意模型时，系统应保存理由，这既能支持申诉，也能帮助团队发现模型持续存在的缺陷。

安全与鲁棒性测试需要覆盖提示注入、数据投毒、模型反演、越权访问、对抗样本和服务降级。生成式功能还要检查幻觉、敏感信息复述和越狱提示。每个未通过的测试都应对应明确处置，例如暂缓上线、限制用途或修复后复测，而不能只留下一个没有负责人和期限的“已知问题”。

提供者还要根据适用情况完成质量管理、符合性评估、欧盟声明、CE 标识和注册，并建立上市后的监测与严重事件报告机制。CE 标识只对应特定版本和用途，并不意味着未来的所有更新都自动合规，因此部署者需要把供应商声明、系统版本和自己的用途记录关联起来。至此，风险识别、技术控制、上线决定和运行监测才构成一条完整的证据链。

这条证据链不能止于企业内部。通用人工智能模型的提供者需要准备模型技术文件，向下游提供者说明能力和限制，制定符合版权法的训练数据政策，并公开足够详细的训练内容摘要。被认定具有系统性风险的模型还要进行模型评估，识别和缓解系统性风险，报告严重事件，并维持足够的网络安全和模型安全能力。^[3]

这些义务并不意味着购买方可以把全部责任交给模型提供者。企业先要确认自己取得的是 API、可下载权重、微调服务还是嵌入式办公功能，因为不同交付方式决定了企业能够看到多少日志、控制哪些版本、如何退出服务，以及输入数据是否可能被供应商用于训练。采购问卷应要求供应商说明模型名称和版本、数据留存规则、再训练政策、处理地点、版权投诉渠道、事故通知时限、日志导出方式和回滚安排。

合同需要沿着实际责任分工展开。供应商负责模型层面的技术文件、漏洞修复和重大版本通知，企业负责业务用途、用户告知、人工监督和最终决定，双方共同处理事件分级、监管问询和退出演练。供应商拒绝提供必要证据时，企业可以限制输入数据、关闭自动执行或降低使用场景风险，却不能用内部口头承诺填补一个外部黑盒。

当企业对模型进行大规模微调、改变预期用途，或者将模型嵌入高风险系统时，还要重新判断自己是否已经承担提供者责任。模型卡和供应商白皮书可以作为参考，却不能代替企业针对实际应用完成的独立测试。由此可见，GPAI 合规要求把供应链透明度纳入企业自己的责任链。

证据链也不能停在后台文档中，它最终还要落实到用户可以感知的界面和业务流程。用户第一次与聊天机器人互动时就应知道对方是机器，提示可以简短，但不能隐藏在很难找到的条款中。合成视频、声音和图片还应在生产流程里记录生成工具、模型版本、人工编辑和发布渠道，可见标签与可验证的来源信息最好同时存在，因为内容在平台间传播时可能丢失元数据。

告知对象也不只是消费者。员工需要知道哪些内容由模型生成，哪些字段来自外部数据，哪些决定必须由人作出。一个没有解释的灰色图标无法帮助用户判断可靠程度。对客户自带模型或嵌入式功能，合同中还要明确谁负责标记，谁回应投诉，谁保存相关记录。

更重要的是，透明度必须与基本权利保护连接起来。招聘、信贷、保险、教育和公共服务会影响个人的机会和尊严，某些高风险部署者需要在首次使用前完成基本权利影响评估，说明受影响群体、可能后果、风险缓解措施和监督安排。评估如果只由开发团队在内部完成，很容易遗漏真实使用者遇到的问题，因此应在适当范围内听取用户、员工代表或其他受影响群体的意见。^[1]

这项工作还要与 GDPR 一起进行。企业仍需证明个人数据处理具有合法性基础，明确目的和保留期限，响应数据主体请求，并在适用时完成数据保护影响评估。对于产生法律效力或类似重大影响的自动化决定，还要检查 GDPR 第 22 条、人工干预和申诉要求，同时考虑劳动法、反歧视法、消费者法和行业监管。

几个常见场景能够说明这种衔接。招聘筛选系统需要检查群体差异，提供人工复核并允许候选人申诉；客服机器人必须明确机器身份，并在涉及账户关闭或合同变更时转交人工；信用和保险系统除了保存模型解释，还要证明最终决定没有把营销分群直接升级为资格拒绝。产品体验中的告知、复核和申诉，正是责任链面向用户的一端。

四、持续经营能力必须进入日常流程

一条完整的责任链不能依赖某个合规人员长期手工维护。企业可以设立跨部门 AI 治理委员会，但委员会必须拥有批准和暂停的权限，产品负责人说明用途和用户影响，工程负责人说明测试与安全，数据保护官负责个人数据，采购和法务负责供应商与合同，信息安全负责人负责事件响应。每个系统还要有一个在事故发生时真正能够作出决定的负责人，而不是只有一个挂在组织架构图上的名字。

现有流程也需要加入相应控制。立项阶段确认用途和角色，采购阶段审查供应商证据，发布阶段检查风险分类和测试结果，运行阶段监测漂移、申诉和人工推翻率，退役阶段完成数据删除和访问关闭。应把 AI 法案要求嵌入企业已经使用的产品开发、采购、安全和审计流程。

员工政策应说明哪些数据不能输入外部工具，哪些输出必须人工核实，如何报告错误以及什么情况下停止使用，并针对真实岗位提供案例。客服人员需要学习识别幻觉和转人工，开发人员要防止密钥泄露，招聘人员要理解模型偏差与申诉流程，管理层则要学会阅读风险报告。人工智能素养要求不同岗位具备与其职责相匹配的判断能力，不能停留在看完一次视频。^[2]

事故演练能够检验这些安排是否真的有效。团队可以从一次错误输出或数据泄露开始，检查谁负责判断影响，谁保存证据，谁暂停系统，谁通知客户和监管机构。如果演练中仍需要临时寻找联系人或讨论哪份合同有效，就说明责任链尚未建立。

为了让证据可持续使用，每个系统应拥有独立证据包，并以系统 ID、版本和日期命名。角色卡、分类备忘录、数据流图、供应商尽调、合同与变更记录、风险管理报告、测试结果、人工监督方案、告知文本、日志策略、事件记录、培训记录和退出计划都应纳入其中。证据包应回答系统为何获批、发生了哪些变化、谁作出了决定以及问题如何被处理。

一张控制台账可以把这些材料串起来。每一项控制都写清目标、证据、负责人、检查频率和异常处理，例如“重大模型更新前完成回归测试”，对应证据是带版本号的测试报告，异常处理是阻断发布并提交治理委员会。只有当控制目标与证据一一对应，企业才能在监管问询之外，也把合规结果用于客户尽调、内部审计和后续模型比较。

对尚未形成系统治理的企业来说，九十天可以用来启动第一版责任链，但不能把九十天当成合规终点。前三十天的重点是看清现状，任命负责人，冻结未经登记的新 AI 采购，盘点正式系统和员工自行订阅的工具，并完成初步的角色与风险分类。疑似禁止实践、自动作出重大权利决定以及无法说明数据来源的系统，应优先暂停或限制使用。

第 31 天至第 60 天用于补齐关键控制。高风险系统开始建立基线测试、人工监督和日志方案，采购团队向供应商索取模型版本、数据政策和事故机制，法务更新通知、审计、退出和重大变更条款。此阶段的目标是确保每一个高风险缺口都有负责人、期限和可验证的关闭条件，不要求所有文件一次性完美。

第 61 天至第 90 天用于形成证据包并进行演练。团队从一次错误输出出发，完整走过发现、暂停、通知、修复和复盘流程，治理委员会据此关闭红色缺口，董事会则审阅尚未解决的风险、预算和业务取舍。对暂时无法关闭的问题，应记录接受风险的理由、有效期和重新评估日期，避免临时例外变成永久状态。

九十天之后，企业仍要按版本、用途和监管变化持续复核。供应商更新模型，业务将草稿工具接入正式决策，用户群体发生变化，都可能触发新的风险分类。九十天计划的价值在于启动一套可以循环运行的机制；完成一轮集中行动后，企业仍需按这套机制运行。

这套机制最终需要由管理层持续负责。AI 法案按照违法类型规定了高额行政罚款。违反禁止实践的企业，最高可达 3500 万欧元或上一财政年度全球营业额的 7%，取较高者；违反其他义务的最高档通常为 1500 万欧元或全球营业额的 3%，向监管机构提供不正确、不完整或误导性信息也有单独的罚款上限。具体处罚还会考虑企业规模、持续时间、主观过错和配合程度。^[1]

但管理层如果只盯着罚款，会低估法规的经营影响。系统可能被要求停止使用、撤回或修改，客户合同可能触发赔偿和审计，员工与消费者也可能依据数据保护、劳动或消费者规则提出申诉。更直接的影响是产品上线变慢、供应商更换困难、客户尽调无法通过。企业即使拥有可用模型，也可能因为缺少证据而无法在欧洲继续扩大业务。

董事会不需要阅读模型代码，却应该定期看到系统数量和风险分布、未关闭缺口、重大版本变化、供应商事件、用户申诉、人工推翻率、培训覆盖率和治理预算。这些指标共同说明企业是否具备持续经营 AI 的能力，不能只看法务部门完成了多少份表格。

归根结底，欧盟《AI 法案》进入实施阶段后，合规已经成为企业在欧洲市场部署和经营 AI 的基础能力。有效的合规体系不会停留在一份风险问卷或一套技术文档里；它应让角色判断决定责任，让风险分类决定控制强度，让技术和组织措施产生可以持续验证的证据，并确保用户在受到影响时能够获得说明、人工复核和纠正。

企业不需要等待所有实施细节完全稳定后才开始行动，更不能把合规理解成可以一次完成的项目。需要建立的是一套随着模型版本、业务用途和监管要求共同更新的治理机制。能够持续证明责任清楚、风险可控和处置有效的企业，才有条件在欧洲市场长期使用 AI、推出新产品并赢得客户信任。