EU AI Act 高风险义务倒计时：座舱 AI 监控（DMS/OMS）为什么走 Annex I 路线，以及 2028-08 之前必须做完的事

1. 为什么现在写这篇：2026-08-02 已经过去，但 DMS 的义务还没到

本站 2026-04-13 写过一篇《DMS 数据隐私合规：GSR/GDPR/AI Act 要求》，那篇的重点是数据侧——闭环系统、立即删除、数据最小化。当时 AI Act 部分只有一张四行的表格，因为彼时能确定的事实就只有这么多。八个月过去，情况完全变了：

• 2026-08-02，AI Act 的一般适用日已过（生效倒计时里的”其余部分”已经落地）；
• Digital Omnibus（AI Omnibus）修正案改写了时间线：产品内嵌型高风险 AI（汽车正是这一类）的义务从 2026-08 推迟到 2028-08-02，Annex III 用例推迟到 2027-12-02；
• Article 6 新增了 1a–1c 段，直接回答了”座舱里哪些 AI 算安全组件、哪些不算”这个 DMS/OMS 团队最关心的问题。

也就是说：DMS 团队现在处于一个”义务未生效、但举证工作必须现在开始”的窗口期。这篇把分类路径、时间线、义务清单、合格评定机制和对开发者的落地清单一次讲清楚。

来源说明：本文全部事实来自一手或准一手信源——artificialintelligenceact.eu 的 Article 5/6/16/43、Annex I/III、Recital 44 与 implementation-timeline 页（该页 2026-08-31 更新，已反映 Omnibus 修正后文本）、European Commission digital-strategy 的 AI Act 政策页（2026-08-03 更新）、Google News RSS 的法律行业动态（Taylor Wessing、Squire Patton Boggs 等 2025-12 至 2026-10 的多篇分析）交叉核对。凡信源中没有的条款文本，本文不写；Article 43(3) 条文与 Annex I Section A/B 的衔接细节（条文原文引用 Section A，而 GSR 在 Section B）行业尚待 Commission 指南澄清，文中会明确标注。

2. 30 秒版分类结论

先给结论，后面逐条论证：

graph TD
    A[座舱 AI 功能] --> B{用于推断驾驶员/乘客情绪?}
    B -- 是,但用于安全<br>疲劳/分心/损伤 --> C["Art 5(1)(f) 安全例外<br>不落入禁令"]
    B -- 是,用于舒适/个性化/营销 --> D["警戒区: 车队车辆=工作场所<br>可能触发 Art 5(1)(f) 禁令<br>或 Annex III 1(c) 高风险"]
    B -- 否 --> E&#123;是否为安全组件?<br>失效危及人身/财产安全&#125;
    E -- 是 --> F["Art 6(1) + Annex I<br>GSR 2019/2144 在列"]
    F --> G[高风险 AI: 义务 2028-08-02]
    E -- 否,仅便利/优化/服务效率 --> H["Art 6(1a) 新增排除项<br>不构成安全组件"]
    D --> G

3. 分类路径详解：为什么不是 Annex III，而是 Article 6(1)

3.1 Annex III 里没有 DMS

Annex III 列了 8 类高风险用例：生物识别（含 1(c) 情绪识别）、关键基础设施、教育、就业与员工管理、基本服务、执法、移民、司法与民主程序。逐条核对：

• 关键基础设施（第 2 类）覆盖的是”AI 作为安全组件用于道路交管理（management and operation of road traffic）”——这是交通管理系统（信号控制、交通流调度），不是单车内的驾驶员监控；
• 生物识别（第 1 类）覆盖远程生物识别、敏感属性分类和情绪识别——安全导向的 DMS 主任务（疲劳/分心/视线）不落入，但座舱里的情绪推断类功能确实可能从这一条被拉进 Annex III；
• 就业与员工管理（第 4 类）理论上可能触及车队运营场景（对职业驾驶员的绩效监控），这是本主题里最容易被忽视的一个潜在 Annex III 入口。

所以分类分析第一步是问：我的功能清单里有没有一项会被单独拽进 Annex III？ 安全主功能不会，但顺带做的情绪/注意力画像可能会。

3.2 Article 6(1) 的两条件判定

Article 6(1) 要求同时满足两个条件：

1. (a) 安全组件：AI 系统”作为产品的安全组件”使用，或自身就是产品；定义是”实现产品的安全功能，或其失效或故障会危及人员健康安全或财产”；
2. (b) 第三方合格评定：产品所属的 Annex I 协调立法要求第三方合格评定。

GSR Regulation (EU) 2019/2144 列于 Annex I Section B 第 19 项（2018/858 型式批准框架为第 18 项），其覆盖范围原文即包括”车辆乘员与弱势道路使用者的保护”——DMS/疲劳检测/AddW 正是这个保护目标的实现手段。车辆型式批准是典型的第三方评定体系（技术服务机构 + 审批当局），条件 (b) 满足。

这意味着一个重要推论：Article 6(3) 的”豁免通道”不适用。 Art 6(3)（narrow procedural task、改善人类活动结果等四条豁免）是 Art 6(2)/Annex III 路线的减负条款；走 6(1) 路线的安全组件没有豁免可选。做合规规划时不要把 Annex III 用例的豁免分析模板直接搬过来。

3.3 新增的 Art 6(1a–1c)：把”安全”与”便利”切开

Omnibus 新增段落（2028-08-02 起生效）给出三条边界规则，每条都直接命中座舱 AI 的产品定义工作：

实操含义：功能边界定义（feature scoping）现在直接决定合规档位。 同一颗座舱摄像头跑三个模型——疲劳检测（安全）、情绪音乐推荐（便利）、驾驶员身份识别（便利）——如果打包成一个”AI 系统”申报，整体被拖进高风险；如果按用途拆分并各自明确 intended purpose，则只有安全那一支走 6(1)。反过来也要警惕：不能为了逃避高风险义务，把安全功能包装成便利功能——1b 的失效判据是客观的，审查时按失效后果算，不按营销话术算。

3.4 情绪识别：一条禁令、一个例外、一个灰色区

• 禁令：Article 5(1)(f) 禁止”在工作场所和教育机构领域推断自然人的情绪”，2025-02-02 已生效；
• 例外：同一句内嵌”为医疗或安全原因”的用途除外，Recital 44 强调例外措辞是”strictly for medical or safety reasons”——安全例外是狭义解释，不是宽泛豁免；
• 灰色区：Recital 44 全文没有提到车辆。所以”车是不是工作场所”成了悬而未决的问题——对私家车主，情绪类功能大概率不落入禁令（不是工作场所）；但对车队/职业驾驶员，驾驶中就是工作场景，情绪推断功能（哪怕是”监测驾驶员情绪压力预防路怒”这类听起来有益的功能）需要逐项论证安全例外。

结合本站已有的 FIA 调研文章（2026-10-16-001）的结论——DMS 的消费端信任是稀缺资源——这里的工程建议很直接：面向欧盟市场的座舱情绪推断功能，若没有可论证的安全收益，不要上车；有安全收益的（如损伤/应激状态识别），在 intended purpose 文档里明确写”for safety reasons”并保留失效模式分析，这就是 Art 5 例外的举证材料。

4. 时间线：Omnibus 改了什么，现在到哪了

gantt
    title EU AI Act 关键适用日（Omnibus 修正后，DMS 相关视角）
    dateFormat YYYY-MM-DD
    section 已生效
    禁令+AI素养 (Art 5)          :done, a1, 2025-02-02, 1d
    GPAI+治理+罚则               :done, a2, 2025-08-02, 1d
    一般适用日（其余部分）        :done, a3, 2026-08-02, 1d
    section 前方
    剩余禁令+存量合成内容透明度   :b1, 2026-12-02, 1d
    GPAI 过渡截止 (Art 111(3))   :b2, 2027-08-02, 1d
    Annex III 高风险义务         :b3, 2027-12-02, 1d
    评定机构指定截止 (Art 43(3)) :b4, 2028-01-28, 1d
    Annex I 高风险义务 (DMS!)    :crit, b5, 2028-08-02, 1d
    存量系统重大变更触发合规      :crit, b6, 2028-08-02, 1d

三个关键点：

1. 2026-08-02 的一般适用日对 DMS 意味着”义务框架已就位但产品义务未触发”。AI 素养义务（Art 4，对员工 AI 知识的培训要求）已生效——这条几乎免费，现在就该做；
2. DMS 的主义务日是 2028-08-02（Art 6(1)/Annex I 路线，Omnibus 推迟）。比 Annex III 用例（2027-12-02）晚 8 个月，原因是立法者认识到产品内嵌 AI 的评定要搭产品法的车，需要给评定机构和供应链留改造时间；
3. 存量条款：2028-08-02 前已投放市场的 Annex I 高风险系统，原则上不回溯，但该日期起发生”重大设计变更”的存量系统即触发合规（Art 111(2)）。对 OTA 节奏快的座舱软件，这个条款的实际约束力比看起来强——重大 OTA 可能直接把存量系统拉进义务范围，OTA 发布计划要和这条对表。

5. 义务清单：Art 16 的 12 项义务逐条映射到 DMS 开发

Art 16 要求 provider 履行的核心是 Section 2 的七项要求 + 质量管理体系。下表把它映射到 DMS 团队已有的工程实践——映射的价值在于：大部分材料你们已经在为 Euro NCAP、R171、ISO 26262 做了，AI Act 不需要从零造，但需要重组。

graph LR
    subgraph AI_Act[AI Act 证据链]
        A1[Art 9 风险管理]
        A2[Art 10 数据治理]
        A3[Art 11 技术文档]
        A4[Art 15 鲁棒性]
    end
    subgraph 产品法证据链
        B1[ISO 26262<br>功能安全]
        B2[ISO 21448<br>SOTIF]
        B3[UN R155/156<br>Cyber/OTA]
        B4[Euro NCAP Dossier<br>R171 证据]
    end
    A1 -- 同源: 失效模式分析 --> B1
    A1 -- 同源: 场景风险 --> B2
    A2 -- 同源: 数据集规范 --> B4
    A4 -- 同源: 攻击面分析 --> B3
    A3 -- 重组而非新建 --> B4

5.1 一个真实的冲突：Art 12 日志 vs GSR 闭环删除

这是本文认为最值得单列的一个设计矛盾：

• GSR（本站 2026-04-13 文引用的原文）：AddW/DDAW 相关数据”不得持续记录或保留超出必要范围的数据”、”处理完成后立即删除”、闭环系统、不对第三方开放；
• AI Act Art 12/19：高风险 AI 系统须自动记录事件日志，provider 在控制范围内保存日志。

两者的调和路径是把”日志”与”敏感数据”切开：Art 12 要求的是事件级日志（检测到疲劳事件、置信度、降级动作、时间戳），不是原始图像或视频帧。工程上即：图像数据边缘处理即焚（满足 GSR 闭环），事件元数据按 AI Act 日志要求留存（脱敏、可审计）。这个切分要在系统架构和隐私文档里都写清楚，否则两边审查都过不了。

5.2 DMS 特有的人类监督难题

Art 14 要求高风险 AI 可被人类有效监督。但 DMS 的语义是倒置的：被监督的”人”就是唯一的监督者。这在合规论证上要处理好——实践中的答案是监督闭环由系统整体完成：DMS 检测状态 → 警告系统升级介入（haptic/声光/最小风险策略）→ 驾驶员响应构成反馈。Art 14 的落实点是警告设计与升级链路的可解释性（为什么此刻警告、驾驶员如何恢复），这与 R171 的接管时序要求（本站 2026-10-15-014）实际上是同一套设计的两面。一份警告逻辑设计文档，同时喂两套法规。

6. 合格评定：不新建程序，并入型式批准

Art 43(3) 的机制是本文判断”成本可控”的核心依据：

1. 程序合并：AI 系统 Section 2 的合规要求并入 Annex I 产品立法既有的第三方合格评定程序。对汽车，就是 2018/858/2019/2144 的型式批准体系——不另设一套 AI 认证；
2. 机构复用：已在产品立法下获通知的评定机构，若其独立性/能力要求（Art 31 相关款项）已在原通知程序中评估，可继续评定 AI 部分，但须在 2028-01-28 前按 AI Act Section 4 申请指定；
3. 内部评定通道有限开放：若产品法允许制造商走免第三方评定路线（通常以全面采用协调标准为条件），AI 部分也只有在”应用了覆盖全部 Section 2 要求的协调标准或通用规范”时才可走此通道。对安全组件场景，实际上就是把第三方评定作为默认。

待澄清标注：Article 43(3) 条文文本引用 Annex I Section A（新立法框架类法规），而 GSR 2019/2144 列于 Section B。条文层面的衔接（Section B 产品是否以及如何完全套用 43(3) 的合并机制）行业仍在等待 Commission 的 Article 6 分类指南与型式批准实施细则。本文采用行业分析的通行读法——AI 要求并入产品法既有评定——但在向评定机构提交正式计划前，请以指南最终文本为准。

供应链角色也要提前理清（Art 25/26）：DMS 软件/传感器供应商是 provider（承担 Art 16 全部义务），OEM 是 deployer 兼制造商（Art 26 部署义务 + 产品法下制造商责任）。如果 OEM 自己训练最后一层模型或做场景适配，OEM 可能升级为共同 provider——这个角色划分在合同里写清楚，否则 2028 年义务触发时会出现责任真空或重复投入。

7. 给 IMS 开发者的行动清单

按时间倒排，2028-08-02 生效日前，建议的节奏：

8. 路线判断

三句话收束：

1. DMS 走的是”产品内嵌”合规路线，注定比互联网 AI 慢半拍、但搭产品法的车。义务 2028-08 才触发，型式批准体系是现成的审核通道，不新造认证体系——这是对 automotive AI 相对友好的一面；
2. 真正的风险不在义务条款，在功能定义。Art 6(1a–1c) 把”安全 vs 便利”的边界写进法条后，座舱 AI 的功能清册、intended purpose 文档和营销话术必须三位一体。把安全功能伪装成便利功能逃义务，1b 的失效判据会戳穿；把便利功能混进安全组件多缴合规税，是白花钱；
3. 证据链同源化是唯一的高性价比打法。AI Act 的风险管理、数据治理、鲁棒性要求与 ISO 26262、SOTIF、R155、Euro NCAP/R171 Dossier 高度同源（见第 5 节映射图）。2026-2027 这两年做架构和文档整合，2028 年义务触发时就是”重组输出”而不是”从零补课”。

对做疲劳/分心/损伤检测的团队：这套合规框架事实上抬高了纯视觉方案的合规门槛（Art 10 数据代表性 + Art 15 鲁棒性的举证负担），而多模态方案（IR 补光、雷达冗余）的额外传感器成本里，现在可以把”合规举证能力”也算进收益项了。