夜雨聆风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系统的风险分类并非一次性判断。模型版本更新、客户行业变化、功能开关变化、数据来源变化、输出用途变化、部署地区变化，都可能使原本低风险的工具转向高风险场景。企业应指定产品负责人和合规负责人定期复核，并在客户变更用途、系统重大修改或新增高敏感场景时触发重新评估。
从实务角度看，分类复核机制不仅是合规要求，也是一种交易风险控制工具。它可以帮助企业在客户扩大使用范围、经销商擅自包装销售或系统集成商修改功能时，及时识别责任外溢风险。
结语：先分类，后出海
欧盟高风险AI系统分类指南目前仍处于草案及咨询阶段，相关时间表也受到AI Omnibus政治协议及后续制度安排的影响。但这并不改变一个基本判断：企业不能等到规则完全“尘埃落定”后，才开始建立分类、文档和证据机制。
对中国出海企业而言，最稳妥的做法不是急于给系统贴上“非高风险”标签，而是把判断过程做实：系统进入什么场景，输出影响谁，是否涉及画像，谁部署系统，谁修改系统，谁保存日志，谁向监管机关解释，谁承担用途变化后的重新评估责任。
AI Act最终考验的，并不只是企业的模型能力，而是企业能否将技术、合同和证据连接起来。对于已经或计划进入欧洲市场的AI产品而言，高风险分类不是合规工作的终点，而是出海交易结构设计的起点。
法源索引
1. 欧盟：Regulation (EU) 2024/1689，2024-07-12
https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. 欧盟委员会：AI regulatory framework / AI Act implementation materials
https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
3. ITPro：European Commission opens public consultation on long-awaited draft for high-risk AI guidelines，2026-05-20
https://www.itpro.com/business/policy-and-legislation/european-commission-opens-public-consultation-on-long-awaited-draft-for-high-risk-ai-guidelines
────────────────────────────────────────────
作者简介/ About the Author
秦国梁（Frank）在国际头部律所、红圈所、高盛拥有丰富从业经验，专注于争议解决、知识产权、数据合规、商业谈判与企业出海。本文仅为一般性法律与商业信息分享，不构成针对具体事项的法律意见。
