欧盟AI法案下高风险系统识别及出海企业交易策略

2026-06-24 |欧盟《人工智能法案》|高风险AI系统|交易应对

摘要：高风险AI界定并非衡量模型先进性，而是由产品安全、自然人影响、合同角色及证据链共同决定的合规门槛。

引言

2026年5月19日，欧盟委员会公布了高风险人工智能系统分类指引草案，并就此启动利益相关方咨询。该咨询原定于2026年6月23日截止，后因行业组织及其他利益相关方要求延期，欧盟委员会将咨询截止日延至2026年7月23日。这个时间点看似仅是欧盟《人工智能法案》（AI Act）落实过程中的一项程序安排，但对于正面向欧洲输出软件、机器人、工业设备、SaaS、HR工具、金融科技产品、医疗相关系统及智能硬件的中国企业而言，其真正引发的疑问是：相关AI系统是否会被划定为“高风险AI系统”。

这一疑问不宜等到客户问卷、投标文件、尽调清单或监管调查出现后再被动应对。在AI Act框架下，“高风险”并非商业宣传用语，也不是合规部门在风险提示中单独列出的抽象定义，而是会实质影响产品设计、技术文档、数据治理、供应链协作、客户合同、上市节奏及后续监管应对的基础性划分。

换句话说，企业真正需要应对的疑问，并不是“欧盟是否又出台一项AI新规”，而是：当AI系统进入招聘、教育、信贷、关键基础设施、工业安全、医疗设备、客户画像或自动化决策等具体应用场景后，谁负责判定系统划分，谁提供技术文档，谁保存运行日志，谁配合监管问询，谁在系统用途、功能或部署方式变动后重新评价风险。

本文拟结合AI Act及欧盟委员会高风险AI系统分类指引草案的主要内容，从实务角度梳理中国企业在AI产品出海欧洲过程中需要关注的高风险划分规则、例外适用边界、交易结构影响及合同安排要点。

一、高风险划分的入口，不在于“模型是否先进”，而在于“系统如何被运用”

AI Act采用以风险为核心的分级监管方法。就高风险AI系统而言，其判断入口主要集中于第6条及附件III。

第一类，是作为欧盟特定产品安全法规所覆盖产品本身，或作为该等产品安全组件的AI系统。对于中国出海企业而言，这类场景通常可能出现在医疗器械、机械设备、机器人、玩具、升降设备、无线电设备、压力设备、个人防护设备、民航、车辆、海事设备等产品链条中。若某一AI模块影响产品的安全功能、故障识别、自动控制、人机交互或风险预警，即便其在商业宣传中仅被描述为“智能辅助”或“效率增强”功能，也不宜简单按普通软件模块对待。

第二类，是附件III列明的特定使用场景。该划分方法关注的并非模型参数规模、算法复杂程度或技术先进性，而是AI系统被用于何种社会功能，以及该输出是否可能影响自然人的机会、权利、安全或基本利益。附件III涉及的典型领域包括生物识别、关键基础设施、教育和职业培训、就业和劳动管理、基本公共和私人服务、执法、移民和边境管理、司法及民主进程等。

因此，一家中国企业向欧洲客户提供招聘筛选工具、员工绩效评分模块、信贷风险评估接口、学生测评系统、工业安全预警模块、机器人安全组件，或可以对自然人进行行为预测、风险分层、客户画像或自动化排序的系统时，不能仅停留在“我们是否属于通用人工智能模型提供者”这一问题上。更具体、更有操作意义的疑问应当是：该系统在欧洲客户处被嵌入了什么业务流程，其输出是否影响自然人，客户是否依赖该输出作出实质性判断，以及该判断是否进一步影响个人获得就业、教育、信贷、服务或安全保障的机会。

二、第6(3)条例外，不是企业“自我宣称低风险”的安全阀

AI Act第6(3)条确实为部分附件III场景下的AI系统设定了有限例外。概括而言，如果AI系统并未对自然人的健康、安全或基本权利造成重大风险，且不会实质性影响决策结果，则可能不被认定为高风险。该条同时列举了若干可能不构成高风险的情形，例如执行狭窄程序性任务、改进既有人类活动结果、识别决策模式或偏差但不替代人工审查，或仅为附件III场景中的评估准备材料。

但在实务中，第6(3)条例外很容易被误解。

首先，例外并非营销口径，而是需要在投放市场或投入使用前形成文件化判断。也就是说，企业不能仅在客户沟通中笼统表述“本系统不属于高风险AI系统”，而应当能够说明其判断依据、适用场景、功能边界、输出性质、人工复核机制以及未实质影响决策结果的理由。未来一旦主管机关要求说明，企业需要能够倒推出当时为何作出该划分判断。

其次，例外受到画像规则的明显限制。若系统涉及对自然人进行画像，即基于个人数据评估或预测其工作表现、经济状况、健康状况、偏好、行为、位置、可靠性或其他个人特征，则相关系统更容易落入高风险评价范围。对于HR、金融、保险、教育、广告投放、客户管理及风控场景中的“评分”“排序”“推荐”“风险分层”“优先级判断”等功能，企业尤其不宜轻率适用低风险例外。

再次，例外判断关注的是具体用途，而不是产品名称或供应商自我定义。同一AI模块，用于内部文件归档、资料检索或客服知识库辅助，可能仅属于低风险工具；但若同一模块被用于筛选求职者、评估员工绩效、影响贷款定价、识别高风险客户、触发工业安全停机或决定个体服务条件，则可能进入完全不同的法律评价框架。

因此，第6(3)条例外的实务意义，不在于为企业提供一条简单的“非高风险”通道，而在于要求企业将低风险判断本身证据化、场景化和可审查化。

三、划分判断错误，风险往往先表现为商业交付和合同责任

高风险AI系统的法律后果并不只体现在行政罚款条款。对于出海企业而言，更早、更现实的风险，往往发生在销售、采购、集成、验收及客户合同履行阶段。

对提供者而言，高风险AI系统需要围绕风险管理、数据治理、技术文档、日志记录、透明度和用户信息、人类监督、准确性、稳健性以及网络安全形成完整合规体系。欧洲客户在采购过程中，也可能要求供应商提供系统划分说明、测试材料、技术文档、合规声明、日志接口、人工监督说明以及监管协助承诺。若供应商前期未对系统作出划分判断，后续很可能无法满足客户尽调或招标文件要求，从而影响成交或交付。

对部署者而言，义务也并非空白。部署者通常需要按照说明使用高风险AI系统，安排具备相应能力的人员进行人工监督，监控系统运行状态，保存自动生成的日志，并在发现风险时采取适当措施。对于部分特定部署场景，部署者在使用前还可能需要开展基本权利影响评估。

更关键的是，AI Act第25条将责任沿价值链重新分配。如果分销商、进口商、部署者或其他第三方以自己的名称或商标投放高风险AI系统，对系统作出重大修改，或者改变系统预期用途，使其成为高风险AI系统，则相关主体可能被视为提供者并承担相应义务。

这对于中国企业尤为重要。许多中国企业在欧洲市场的商业模式，并非简单销售标准化软件，而是与当地经销商、系统集成商、客户IT团队或行业解决方案伙伴共同完成配置、训练、微调、嵌入、白标、二次开发或本地化部署。在这种交易结构下，若合同没有明确约定谁控制系统用途、谁批准功能修改、谁负责技术文档、谁保存运行日志、谁配合监管问询、谁承担用途变更后的重新评价义务，后续责任边界将很难清晰切分。

因此，高风险划分不应被视为“上线后补一份说明”的合规动作，而应前置进入交易文件的定义条款、用途限制、交付清单、验收标准、变更控制、日志保存、监管协助、责任分配和终止条款。

四、中国企业出海欧洲最容易忽略的四类场景

（一）AI模块嵌入硬件、机器人或工业系统

不少企业认为自己销售的是设备、机器人、控制系统或工业解决方案，而非AI服务。但从AI Act角度看，如果AI模块影响产品安全功能、故障预警、自动控制、人机交互或异常处置，就需要同时评估产品安全法规和AI Act下的高风险规则。

在这类交易中，合同至少应写明AI模块版本、预期用途、可配置范围、测试场景、异常处置机制、安全边界、更新机制以及客户不得擅自修改安全相关参数的义务。对于涉及工业安全、机械设备或医疗相关用途的场景，企业还应特别关注AI系统是否作为产品安全组件被纳入第三方合格评定范围。

（二）向欧洲客户提供HR、教育、金融或客户评分工具

HR、教育、金融和客户管理系统是高风险判断中的高敏感区域。企业往往将相关产品描述为“辅助推荐”“效率工具”或“决策支持模块”，但监管关注的重点并非产品宣传语，而是客户是否实际依据AI输出进行筛选、排序、评分、定价、分层或采取差别化措施。

因此，合同中不宜仅写明“客户自行负责使用结果”。更稳妥的安排是同时设置禁止用途、人工复核、日志保留、用途变化通知、客户部署责任、输出解释边界及监管配合机制。对于可能涉及画像或自动化决策的系统，还应结合数据保护规则同步评估个人数据处理基础、告知义务及数据主体权利响应机制。

（三）使用第三方大模型或开源模型开发行业应用

上游模型供应商的合规声明，并不当然覆盖下游应用。应用提供者仍需结合自己的产品功能、目标客户、部署场景和输出效果，判断该系统是否落入附件III，是否构成画像，是否改变了模型原有预期用途，以及是否需要额外测试、技术文档和风险管理措施。

尤其是在金融风控、医疗辅助、招聘筛选、工业安全、教育测评等场景中，即便底层模型来自第三方，行业应用层的提供者仍可能因其对系统功能、用途和交付方式具有控制力，而承担相应合规义务。

（四）欧洲经销、白标销售和系统集成

中国企业出海欧洲时，经销、代理、白标和系统集成模式较为常见。本地合作方可能要求使用其品牌对外销售，也可能根据终端客户需求进行大量配置和二次开发。此时，谁是AI Act下的提供者，不能仅按照商业合同标题判断，而应结合品牌使用、系统修改、用途控制和交付责任进行实质审查。

若本地合作方以其自身名称或商标投放系统，或对系统进行重大修改，或改变系统预期用途，则其可能被视为提供者。反之，若中国企业仍控制核心功能、版本更新、技术文档和系统用途，则其也难以完全通过经销结构隔离监管责任。因此，相关合同应明确品牌使用、修改权限、用途限制、合规材料提供、监管问询协助及责任回溯机制。

五、建议将高风险判断做成“四步证据闭环”

第一步：立项阶段建立AI系统划分表

产品、业务、法务、数据安全和技术团队应在立项阶段共同完成划分判断，至少记录以下事项：系统是否进入附件III场景，是否作为产品安全组件，是否影响自然人权益，是否涉及画像，是否使用第三方模型或通用人工智能模型，系统输出是建议、排序、评分、预警还是自动决定，是否存在人工复核以及客户是否可能改变系统用途。

该划分表不应只是内部合规留痕，而应成为后续产品设计、技术文档、客户沟通、合同谈判和监管应对的基础文件。

第二步：签约阶段写入AI Act协助条款

在供应商合同、集成合同、经销合同和客户合同中，应结合具体交易结构设置AI Act协助条款。相关条款至少应覆盖技术文档提供、训练和验证数据说明、测试记录、日志接口、版本更新、重大修改通知、禁止用途、再许可限制、监管问询协助、客户用途变化通知以及责任分配。

对于白标、经销和系统集成场景，还应特别约定：任何一方不得未经授权改变系统预期用途，不得擅自进行可能影响系统划分或风险水平的重大修改；如确需修改，应事先完成重新划分和风险评估。

第三步：上线前保存可审查材料

企业不应只保存供应商宣传册、客户验收邮件或商务报价文件，而应系统保存风险评估、测试报告、人工监督安排、用户说明、数据治理记录、例外判断文件、合规声明、关键会议纪要以及版本发布记录。未来真正有用的材料，是能够证明“当时为何这样划分、为何这样部署、谁批准了用途、谁知悉相关风险”的证据链。

对于主张不属于高风险的系统，企业尤其应保留第6(3)条例外适用的分析文件，避免未来在客户争议或监管问询中陷入“只有结论、没有过程”的被动局面。

第四步：运行后持续复核系统风险

AI系统的风险划分并非一次性判断。模型版本更新、客户行业变化、功能开关变化、数据