哪些 EU AI 法案功能会悄然触发高风险合规——以及你必须在 2026 年 8 月前交付的内容

一项针对 106 个企业 AI 系统的 appliedAI 研究发现，40% 的系统风险分类不明确。这一数字并不反映监管的复杂性——它反映的是有多少工程团队在交付 AI 功能时，从未追问该功能是否改变了合规层级。欧盟 AI 法案对高风险系统的强制执法日期定为 2026 年 8 月 2 日。届时，处于那 40% 之列不再是管理问题，而是一个架构问题——你将在监管机构注视之下，以四倍于原始成本的代价、在截止日期的压力下修复它。

本文不是法律概述，而是面向工程师的深度解读：哪些产品决策会悄然触发高风险分类，这些分类对应哪些具体交付物，以及为什么事后改造的成本远高于一开始就内置合规的成本。

"高风险"在法案中究竟意味着什么

欧盟 AI 法案设立了四个风险层级：不可接受（禁止）、高风险、有限风险和极小风险。你的团队目前交付的大多数 AI 功能属于有限风险或极小风险，这两个层级的监管义务较轻——主要是透明度要求，例如披露用户正在与 AI 交互。

高风险则完全不同。它触发强制合规堆栈：质量管理体系、技术文档、自动日志记录、人类监督机制、符合性评估，以及在欧盟数据库中注册。这些不是勾选项，而是影响数据存储方式、工作流结构和可部署内容的架构特性。

触发高风险分类的不是技术，而是用例。用于推荐电影的嵌入模型属于极小风险；同一个模型若用于对招聘候选人进行排名，则属于高风险。上下文决定分类，这正是工程团队频频踩坑的地方。

静默触发器：八种翻转开关的产品模式

法案附件三（Annex III）定义了八类高风险用途。大多数显而易见——执法系统、关键基础设施管理、移民管控。但有四类会让产品团队猝不及防。

就业与劳动力管理。 若你的 AI 系统参与招聘、候选人筛选、晋升决策、基于行为特征的任务分配，或持续的员工绩效监控，则属于高风险。这比大多数团队预想的范围更广。一个聚合 Slack 活动、工单关闭率和代码提交模式来标注"高绩效者"以供季度奖金评审参考的仪表盘——如果该仪表盘使用模型对员工进行评分或排名，很可能符合高风险定义。法案明确涵盖"基于个人行为或个人特征分配任务"的系统。

教育与职业培训。 决定教育项目准入、评估学生或在考试期间监控行为的 AI 系统属于高风险。这对构建自适应评估、后果性自动评分或学术诚信检测工具的 EdTech 团队尤为值得关注。

基本私人服务——信贷与保险。 使用 AI 进行信用评估和保险风险评分属于高风险。一个在人工审核前将贷款申请通过模型路由的金融科技产品，或一个根据行为信号调整保费的保险科技功能，无论模型在产品描述中的决策权重显得多么微小，都在这一层级之列。

生物特征识别。 远程生物特征识别和生物特征分类属于高风险；某些模式（工作场所和学校中的情绪识别）自 2025 年 2 月起已被直接禁止。这一边界对构建门禁人脸识别、从视频推断压力的健康工具，或任何按推断敏感属性（如健康状况或政治取向）对人员分类的系统的团队至关重要。

这四类功能的共同点：它们都像是产品改进。"绩效洞察"功能、"自适应学习"模块、"智能核保"流水线。欧盟 AI 法案不在乎你如何命名它，它审视的是系统影响哪种决策，以及该决策是否实质性地影响一个人获得就业、教育、信贷或保险的机会。

高风险分类要求你构建什么

一旦你的系统属于高风险，你必须在其于欧盟投入使用前交付合规堆栈。这些要求是技术性的，而非文档性的。

风险管理体系（第 9 条）。 一份"活文档"远远不够。你需要一套贯穿系统全生命周期的系统性流程——用于识别、评估和缓解风险。这包括针对已知故障模式进行测试、记录残余风险，并保留在重大更新后审查系统的证据。该"体系"既是治理流程，也是版本控制和部署基础设施中的制品轨迹。

技术文档（第 11 条 + 附件四）。 文档必须详尽到足以让国家主管部门在不访问源代码的情况下验证合规性。内容包括：系统的预期目的和局限性、训练数据描述和质量措施、模型架构概述、准确性和鲁棒性测试结果，以及已知局限性列表。文档必须保持最新——在不更新文档的情况下更新模型即构成违规。

自动日志记录（第 12 条）。 系统必须在其运行全程自动记录事件。最低保留期为六个月，但实际要求是日志须捕获：输入、输出、置信度、调用系统的部署者身份、时间戳，以及人类监督行动和覆盖操作。仅记录错误和延迟的标准应用日志不合规。你需要以适合监管审计格式保存决策相关信号的 AI 专用日志。

加载中…