# Eu Data Act Compliance

> 评估欧盟《数据法》（Regulation (EU) 2023/2854）下互联产品、物联网设备、数据共享、云服务切换、B2B 公平性、B2G 数据获取、争议解决和国际数据传输的合规义务。涵盖范围评估（制造商、数据持有者、数据接收者角色）、用户数据访问权、售前透明度、不公平合同条款、公共机构数据请求、云可移植性、争议解决机制、国际传输限制、设计即获取义务、商业秘密保护，以及与 GDPR、AI 法案和 CRA 的跨法规映射。在评估《数据法》义务、设计互联产品、起草数据共享合同、回应 B2G 请求、规划云切换能力或评估争议解决选项时使用。

- Skill: `cslawyer1985/eu-data-act-compliance` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add cslawyer1985/eu-data-act-compliance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cslawyer1985/eu-data-act-compliance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cslawyer1985 (https://skillmd.com/u/cslawyer1985)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cslawyer1985/eu-data-act-compliance

---


# 欧盟《数据法》合规评估

评估您的组织在欧盟《数据法》（Regulation (EU) 2023/2854）下对互联产品、数据共享、云服务和 B2G 数据请求的义务。

**重要提示：** 本技能支持结构化的法律合规工作流。它**不**替代法律判断。《数据法》义务依背景而定，并与 GDPR、行业法规和国家实施措施相互作用。始终明确识别假设、待解决问题和存在争议的解释。

**关键日期：**
- **生效：** 2024 年 1 月 11 日
- **主要要求适用：** 2025 年 9 月 12 日
- **设计即获取义务适用：** 2026 年 9 月 12 日
- **云切换费用逐步取消：** 2027 年 1 月 12 日

## 《数据法》合规工作流

按此顺序进行。不要跳过范围评估。

### 第 1 步——范围评估：您的组织承担哪些《数据法》角色？

《数据法》根据您在数据生态系统中的角色施加不同义务。

评估您的组织是否属于：

1. **互联产品制造商**——依据条例的产品相关定义，以自身名义或商标将互联产品投放市场的实体。对相关服务提供者单独评估，而非并入制造商角色。
2. **相关服务提供者**——在数字服务与产品相结合或相互连接从而影响《数据法》获取义务的情况下，单独评估。
3. **数据持有者**——有权或有义务提供数据的法人或自然人（第 2 条第 6 款）
4. **用户**——拥有、租赁或租用互联产品或接受相关服务的自然人或者法人（第 2 条第 7 款）
5. **数据接收者**——数据持有者向其提供数据的法人或自然人（第 2 条第 8 款）
6. **数据处理服务提供者**——提供商业数据处理服务（云、边缘计算）的提供者（第 2 条第 11 款）
7. **公共机构**——可依据紧急情况或公共利益理由请求数据的机构（第五章）

**关键排除：**
- **《数字市场法》下的守门人平台**具有单独的义务
- **中小企业**（员工 < 50 人，营业额 < 1000 万欧元）作为制造商可受益于简化义务

**边界说明：** 进口商和分销商并不自动等同于制造商，但取决于谁将产品投放市场、以谁的名义投放，以及存在何种合同/技术控制，他们可能具有相关性。

询问：
- 您是否制造或进口物联网设备、智能产品或互联设备？
- 您是否运营从产品使用中生成数据的服务？
- 您是否持有非您制造的产品生成的数据？
- 您是否以商业化方式提供云计算、数据存储或处理服务？
- 您是否是可能因应急响应或公共利益任务而需要数据的公共机构？

→ 关于详细角色定义和边界情形，阅读 references/scope-assessment.md。

### 第 1b 步——数据范围分诊

在继续之前，对相关数据进行分诊，以避免错误适用：

**询问：**
- **数据性质：** 个人数据 / 非个人数据 / 混合？
- **可获得性：** 数据持有者随时可得，还是需要新的处理？
- **数据类型：** 原始 / 观测 / 派生 / 推断？
- **敏感性：** 商业秘密 / 商业敏感 / 非敏感？
- **行业约束：** 是否受行业特定的保密（如银行、医疗）或安全限制？

大多数《数据法》错误适用源于未能在开始时正确界定数据范围。派生分析、推断洞察和专有增值层并不自动与原始产品遥测数据受相同的获取义务约束。

### 第 2 步——互联产品数据获取权（第二至三章）

如果您的组织是互联产品数据的**数据持有者**，您必须应用户请求实现**用户获取**和**第三方共享**。

**用户获取权（第 4 条）：**
- 用户对因使用互联产品或相关服务而产生、且依据条例**数据持有者随时可得**的数据享有获取权。**不要**假设这自动包括制造商或服务提供者创建的**推断、派生或专有分析**。
- 获取必须**无不当延迟**地提供。在相关且技术上可行的情况下，数据应**持续且实时**地提供。
- 数据必须以**结构化、常用、机器可读的格式**提供
- 获取必须**免费、简便且安全**
- 《数据法》限制数据持有者和数据接收者对产品及相关服务数据的某些使用。当共享或可获取的数据包含**个人数据**时，任何进一步处理还必须符合**GDPR**，其法律依据可能并非同意。**不要**假设同意是唯一法律依据。

**第三方共享权（第 5-7 条）：**
- 用户可指示数据持有者将数据提供给**第三方**（数据接收者）
- 数据接收者可利用该数据向用户提供**增值服务**
- 数据持有者必须**无不当延迟**地回应，并实现直接获取或提供数据副本
- 数据持有者仅在条例明确承认的理由下可限制或拒绝共享，尤其是：尽管采取了保护措施，**商业秘密**仍将受到损害；请求方是**DMA 守门人**或代表其行事的当事人；或其他第 6 条保护适用。**不要**依赖笼统的"资源不足"理由，除非其与条例中的具体法律依据挂钩。
- **守门人排除（第 6 条第 2 款(e)项）：** 不得强制数据持有者与 DMA 指定的守门人共享数据
- **中小企业豁免（第 7 条第 1 款）：** 微型和小型企业（员工 < 10 人，营业额 < 200 万欧元）作为数据持有者时**豁免**数据共享义务
- **补偿/收费：** 仔细评估第**8 和 9 条**。《数据法》并**不**创设仅因请求"频繁"或"复杂"即可收费的一般规则。任何补偿机制必须对照请求方的具体角色、适用章节以及条例对可收费内容的限制进行检查。

**数据持有者的关键义务：**
1. 建立数据获取的技术手段（API、接口、安全通道）
2. 记录哪些数据可用、以何种格式、如何请求
3. 在合理时间内回应用户/第三方请求
4. 应用相称的安全和身份验证
5. 将拒绝通知用户并说明理由

询问：
- 您的组织制造或运营哪些互联产品？
- 产品使用生成了哪些数据？
- 用户今天能否实时获取其数据？
- 是否有面向第三方数据接收者的 API 或接口？
- 拒绝数据获取的正当理由是什么（商业秘密、安全）？

→ 关于详细的获取义务、技术要求和拒绝理由，阅读 references/data-access-rights.md。

### 第 3 步——售前透明度（第 3 条）

如果您的组织是**制造商**，您必须在购买或租赁**之前向用户提供信息**。

在订立合同或下订单之前，告知用户：
1. 使用互联产品或相关服务会**生成哪些数据**
2. 这些数据**是否可由用户获取**，如可获取，以何种方式
3. 应用户请求，这些数据**是否可由第三方获取**，如可获取，以何种方式
4. 如果获取需要**付费**，费用的计算依据

**注意：** 第 3 条的信息事项比上述列表更广泛——请核实第 3 条的确切清单，而非将其视为穷尽列举。

信息必须：
- **清晰、易懂且易于获取**
- 以**显著方式**提供，而非埋没在条款中
- 在用户受合同约束**之前**提供

询问：
- 产品描述、规格表或售前材料是否解释了会生成哪些数据？
- 是否清楚说明用户能否获取其数据，以及通过哪些渠道？
- 数据获取的费用结构是否预先披露？
- 信息对非技术用户是否可理解？

这是一项**透明度义务**，而非完整的同意要求，但它使知情的购买决策成为可能。

### 第 4 步——B2B 数据共享合同中的不公平条款（第四章）

如果您的组织订立**数据获取或使用的 B2B 合同**，评估合同条款是否依据第 13-14 条构成**不公平**条款。

《数据法》为企业间合同确立了**双层不公平性测试**：

**不公平条款控制（第 13 条）：** 不要将第 13 条简化为一段自制的黑名单。条例包含：
- 一组在第 13 条第 1 款下以"要么接受要么放弃"的 B2B 背景下强加时**不具有约束力**的条款，以及
- 一组根据第 13 条第 2 款**推定不公平**、除非依赖方证明并非如此的条款。

进行法律审查时，将条款文本**直接**与第 13 条第 1 款和第 2 款对照，而非依赖简略标签。

**关于第 13 条第 3 款的重要提示：** 不要将其呈现为宽泛的"安全港"。单独谈判和使用示范条款可能与不公平性分析相关，但它们**不**自动使条款免受第 13 条审查。

**示范合同条款（MCT）：**
- 第 41 条要求委员会在 2025 年 9 月前制定不具有约束力的 MCT
- 专家报告草案于 2025 年 4 月 1 日发布，委员会建议于 2025 年 11 月 20 日发布
- 四套条款：(1) 数据持有者至用户，(2) 用户至数据接收者，(3) 数据持有者至数据接收者，(4) 数据共享者至数据接收者（自愿共享）
- MCT 是**不具有约束力的示范条款**，可作为起草基准，但**不**创设全面的法定安全港。合同条款仍应依据其自身措辞、谈判历史和商业背景对照**第 13 条**进行测试。

询问：
- 在 B2B 数据共享协议中，您是数据持有者还是数据接收者？
- 您的标准条款是否包含单方终止、解释或责任排除？
- 数据获取权或救济是否受到限制？
- 条款是单独谈判的，还是"要么接受要么放弃"？
- 相对方是否为中小企业，使不公平的可能性更高？

→ 关于不公平条款的完整目录及示例和安全港指引，阅读 references/unfair-terms-catalogue.md。

### 第 5 步——B2G 数据共享：公共机构请求（第五章）

如果您的组织是**数据持有者**，在条例的**特殊需要**条件满足时，您可能在严格受限的情况下被要求向**公共部门机构、欧盟委员会、欧洲央行或欧盟机构**提供数据。

**注意：** 第五章不是绕过 GDPR 的方式。当 B2G 请求涉及个人数据时，GDPR 合规仍然强制适用。

**B2G 数据请求的两个理由：**

**紧急请求（第 15 条）：**
- 公共紧急情况（如公共卫生危机、自然灾害、重大事故）
- 数据对应对紧急情况是必要的
- 没有其他手段可及时获得
- 请求必须说明必要性、目的、数据范围、紧急性
- **紧急情况提供数据不给予补偿**

**基于公共紧急情况之外的特殊需要的请求（第 17 条）：**
- 防止公共紧急情况或协助恢复的特殊需要
- 无法从其他来源获得数据
- 必须相称且有时间限制
- 对成本给予**补偿**，包括合理利润（第 20 条）

**数据持有者义务：**
1. **无不当延迟**地回应请求
2. 尽合理的技术、组织和财务努力
3. 任何拒绝或限制必须与**第五章中的具体理由和程序**挂钩，包括条例关于**商业秘密、保密、防止滥用、相称性和可用审查机制**的规则。**不要**在未检查确切法律依据的情况下，将笼统的"商业利益"反对意见作为独立规则使用。
4. 通知拒绝并说明理由
5. 除非公共机构允许公布，否则保持保密

询问：
- 您的组织是否持有可能与应急响应相关（健康、基础设施、交通、环境）的数据？
- 接收和评估 B2G 数据请求的流程是什么？
- 是否有评估相称性和保护商业秘密的机制？
- 公共机构请求的指定联系人是谁？

→ 关于详细的 B2G 请求程序、相称性测试和补偿规则，阅读 references/b2g-data-sharing.md。

### 第 6 步——云切换与可移植性（第六至七章）

如果您的组织是**数据处理服务提供者**（云/边缘提供者），您负有**切换促进**和**互操作性**义务。

**客户切换权（第 23-25 条）：**
1. **无处罚退出**——客户可在合同结束时切换提供者或迁移至本地部署
2. **切换收费：** 收费制度受条例下**过渡性逐步取消**安排约束。**不要**在未检查**第 25 条**确切文本及适用于相关合同的过渡性规定之前，将其简化为简单的"新合同与现有合同"规则。
3. **终止与切换流程：** 直接检查**第 24 条**了解允许的最长通知期/过渡机制。**不要**将其概括为普适的"最短 2 个月"规则。
4. **最短合同期限**不得超过客观上合理的限度
5. **数据导出协助**——提供者必须使客户数据、应用程序和数字资产能够以结构化、常用、机器可读的格式导出
6. **功能等效性**——评估导出的数据和元数据是否足以让客户在其他地方继续使用等效服务，同时认识到这是合规评估视角，而非在所有背景下保证服务可替代性或迁移对等的全面义务

**互操作性义务（第 26 条）：**
- 制定和实施**自律行为准则**或标准
- 实现跨云平台的可移植性
- 促进云与边缘之间以及混合部署的切换

**国际数据传输限制（第 32 条）：**
- 云提供者必须采取充分的**技术、组织和法律措施**，防止外国/第三国政府获取欧盟境内持有的非个人数据，前提是这将与欧盟/国家法律相冲突
- **例外：** (a) 有国际协议的第三国法院命令，或 (b) 有保障措施的紧急情况
- 适用于与切换义务相同的参与者，但属独立合规领域（第七章）

询问：
- 您是否提供商业云计算、存储或数据处理服务？
- 您当前的合同终止通知期是多少？
- 您是否对切换、退出或数据导出收费？
- 客户能否以标准格式导出数据而不损失功能？
- 互操作性标准或行为准则是否适用于您的服务？

→ 关于切换时间线、技术导出要求和互操作性路线图，阅读 references/cloud-switching.md。

### 第 7 步——商业秘密保护（第 5 条第 4 款、第 6 条、第 15 条第 3 款）

在用户获取、第三方共享或 B2G 请求下共享数据时，如果满足特定条件，数据持有者可**不披露商业秘密**。

**商业秘密保障措施：**
1. **相称性**——拒绝必须与保护秘密的合法利益相称
2. **详细解释**——数据持有者必须解释哪些数据包含商业秘密，以及披露为何会损害商业利益
3. **技术/组织措施**——在可能的情况下，应用措施（匿名化、聚合、访问限制）以实现共享同时保护秘密。在彻底拒绝之前，应探索保护性措施。
4. **接收者保障**——数据接收者和公共机构必须保持保密，并仅将数据用于指定目的
5. 交叉引用：第三方共享拒绝的论证负担见第 6 条，B2G 拒绝见第五章。

**数据持有者义务：**
- 不要将商业秘密保护主张作为全面拒绝
- 识别包含商业秘密的具体数据要素或子集
- 考虑删改、聚合或合同保障是否允许部分披露
- 应用实现保护的最小限制性措施

询问：
- 哪些数据要素包含专有算法、业务逻辑或商业敏感信息？
- 商业秘密能否通过聚合、过滤或使用限制而非完全拒绝来保护？
- 是否对数据接收者设有保密协议或技术访问控制？

商业秘密保护是**合法的限制理由**，但并非自动豁免。

### 第 8 步——争议解决（第 10 条）

用户、数据持有者和数据接收者可诉诸**经认证的争议解决机构**处理《数据法》争议。

**争议解决机制：**
1. **认证机构**——成员国必须认证争议解决机构（第 10 条第 1 款）
2. **涵盖的争议：**
   - 数据获取拒绝
   - 费用分歧
   - 补偿条款
   - 商业秘密主张
3. **程序效力：** 检查**第 10 条**及相关国家框架，了解经认证争议解决机构的决定或结果的法律效力。**不要**在所有情况下假设结果纯粹不具有约束力。
4. **各方均可发起**——用户、数据持有者和数据接收者均可发起

询问：
- 诉诸法院之前升级争议的流程是什么？
- 哪些认证机构在您的司法辖区运作？
- 数据共享合同中是否包含争议解决条款？

→ 关于争议解决升级模板和程序，阅读 references/templates.md。

### 第 9 步——用于自动化数据共享的智能合约（第九章）

如果您的组织使用或提供**智能合约**来自动化数据获取或共享，则适用特定义务（第 30-31 条）。

**智能合约要求：**
1. **稳健性与安全性**——必须达到最高的安全、韧性和容错标准
2. **可中断性**——必须包含在发生错误、欺诈或不可预见结果时**停止或中断执行**的机制
3. **可审计性与问责制**——必须允许第三方评估和测试
4. **法律合规**——智能合约逻辑必须尊重数据获取权、不公平条款禁令和商业秘密保护

**范围说明：** 区分专门用于依据条例执行数据共享协议的智能合约，与可能不在具体义务框架范围内的更广泛通用型区块链或自动化工具。

询问：
- 您是否为数据交易、访问控制或条件数据共享部署智能合约？
- 是否实施了中断机制、断路器或紧急停止功能？
- 智能合约逻辑能否就符合《数据法》义务进行审计？
- 对自动化执行是否有人员监督或治理？

这是一项**设计与治理义务**，而不仅仅是技术实施细节。

### 第 10 步——新产品设计即获取义务（自 2026 年 9 月 12 日起）

如果您的组织是**互联产品制造商**，则触发**设计即获取义务**的产品（锚定于条例的适用机制，而非简单的设计日期公式）必须满足**设计即获取**要求。

**设计义务（第 3 条第 2 款）：**
1. 数据默认必须**易于、安全且（在相关情况下）可直接**供用户获取
2. 制造商必须以便利数据获取和可移植性的方式设计产品和相关服务
3. 技术架构应避免对按用户指示进行的第三方数据获取设置不必要障碍

询问：
- 您目前是否正在设计新的互联产品或物联网设备？
- 这些产品将在何时投放市场（2026 年 9 月之前还是之后）？
- 产品规格是否包含默认的用户数据获取机制？
- API、数据接口或导出功能是否属于初始设计的一部分，而非事后补充？

**对于触发义务的产品，设计即获取是强制性的**——请依据条例核实适用日期和过渡规则，避免将其简化为简单的设计日期公式。

### 第 11 步——跨法规映射：GDPR、AI 法案、CRA 的相互作用

《数据法》与现有欧盟法规**并行**运作。不要将其孤立对待。

**与 GDPR 的相互作用：**
- **个人数据**继续受 GDPR 保护
- 《数据法》获取权**不覆盖 GDPR**——当数据包含个人数据时，两种制度均适用
- 数据最小化、目的限制和合法依据规则仍然适用
- 数据接收者依据《数据法》权利处理共享个人数据时必须符合 GDPR
- 数据持有者可能需要匿名化或假名化数据以同时符合两个框架
- **当涉及多人的个人数据时**，获取权必须与他人的权利和自由相协调
- **摩擦点：** 《数据法》获取权可能与 GDPR 数据最小化产生张力——当数据持有者被要求保留或提供按最小化原则本可删除的数据时，需要进行相称性评估

**与 AI 法案的相互作用：**
- 依据《数据法》共享的数据可用于**训练、测试或验证 AI 系统**
- AI 法案关于数据质量、透明度和文档化的义务适用于 AI 训练数据
- 高风险 AI 系统可能处理来自《数据法》的数据——确保在两个框架下均合法
- **摩擦点：** AI 法案对高风险系统的透明度要求（如训练数据来源、模型逻辑的文档化）可能与《数据法》第 6 条下的商业秘密保护冲突——保护措施必须在可能的情况下设计为同时满足两种制度

**与《网络弹性法案》（CRA）的相互作用：**
- CRA 对带有数字元素的产品施加网络安全义务
- 《数据法》数据获取义务必须**安全地**实施（身份验证、加密、访问日志）
- 数据获取接口中的安全漏洞构成 CRA 合规风险
- 在《数据法》和 CRA 框架之间协调事件响应
- **摩擦点：** CRA 的安全设计（security-by-design）要求可能施加技术约束（如访问日志、身份验证强度、更新机制），限制《数据法》第 4 条下实时数据获取的可行性和格式，需要在获取与安全之间进行平衡

**与《数据治理法》（DGA）的相互作用：**
- DGA 规范数据中介机构和数据利他主义——与《数据法》用户获取权互补
- 数据合作社可代表用户充当数据接收者

询问：
- 相关数据是否包含受 GDPR 管辖的个人数据？
- 数据是否将用于 AI 训练或高风险 AI 系统？
- 数据获取的网络安全措施是否与 CRA 要求一致？
- 是否存在需要综合合规的重叠义务？

→ 关于详细的相互作用分析和合规整合策略，阅读 references/cross-regulation-mapping.md。

### 第 12 步——DACH 地区特定考量

如果您的组织在**德国、奥地利或瑞士**运营，考虑国家实施和执法的细微差别。

**德国：**
- **指定机构：** 对照**现行德国实施立法和行政实践**核实机构指定情况。**不要**假设存在主导机构，除非其已被正式指定。
- **州机构：** GDPR-《数据法》重叠事项由 Landesdatenschutzbehörden（州数据保护机构）处理
- **BNetzA**（联邦网络局）可能承担行业特定角色（电信、能源）
- **BetrVG**（《企业宪法法》）在涉及员工数据时可能需要劳资委员会协商
- **GWB**（《竞争法》）与 B2B 公平性条款的相互作用

**奥地利：**
- **指定机构：** 对照**现行奥地利实施立法和行政实践**核实机构指定情况。**不要**假设存在主导机构，除非其已被正式指定。
- **DSB**（Datenschutzbehörde，数据保护机构）处理数据保护重叠事项

**当执法指定未定时：**
- 检查相关成员国现行实施法规
- 检查行业监管机构指引（如适用行业特定规则）
- 检查 GDPR 重叠是否将执法路由至数据保护机构
- 将执法不确定性作为风险假设记录在合规评估中

**瑞士：**
- **不直接适用**（非欧盟），但可通过合同纳入或作为市场最佳实践适用
- **瑞士联邦数据保护法（revFADP）**适用于个人数据
- 欧盟与瑞士实体之间的跨境数据流动受等效制度约束

询问：
- 哪个国家机构将在您的司法辖区执行《数据法》义务？
- 是否存在职权重叠的行业特定机构（能源、电信、金融）？
- 在涉及员工数据获取时是否需要劳资委员会参与？
- 对于瑞士实体：自愿合规或合同纳入是否合适？

→ 关于 DACH 机构映射、国家实施状况和执法方式，阅读 references/dach-specific.md。

### 第 13 步——非欧盟企业的欧盟代表（第 39 条）

如果您的组织**设在欧盟境外**但在欧盟境内提供属于《数据法》范围的商品或服务，您必须指定一名**欧盟代表**。

**代表义务：**
1. 在欧盟设立的自然人或法人
2. 被授权代表非欧盟实体行事
3. 可被市场监督机构和用户联系
4. 必须与机构合作并按请求提供文件

询问：
- 您的组织是否设在欧盟境外，但在欧盟销售互联产品或云服务？
- 您是否已指定具有适当权限和资源的欧盟代表？
- 代表的联系信息是否公开可获取并已告知用户？

这是非欧盟实体**确保可执行性的门户性合规义务**。

## 快速问题集

在进行全面合规评估之前，在受理时使用这些问题：

**范围与角色**
1. 您的组织是否制造互联产品、物联网设备或智能设备？
2. 您是否持有产品或服务生成的数据（无论是否由您制造）？
3. 您是否提供商业云计算、数据存储或处理服务？
4. 您是否是可能因紧急或公共利益目的请求数据的公共机构？
5. 您是否应用户请求从数据持有者处接收数据以提供增值服务？

**产品与服务背景**
6. 哪些互联产品或服务在范围内？
7. 产品使用或服务运营生成了哪些数据？
8. 用户今天能否获取这些数据？以何种格式、通过哪些渠道？
9. 是否已建立第三方数据共享机制？
10. 产品是何时设计的，将于何时投放市场？

**合同与商业**
11. 您是否订立数据获取或共享的 B2B 合同？
12. 您的合同条款是单独谈判还是基于标准模板？
13. 您是否对数据获取、切换或导出收费？
14. 您当前的合同终止通知期和退出费用结构是什么？

**技术与安全**
15. 数据获取有哪些 API、接口或技术机制？
16. 数据如何格式化，是否机器可读？
17. 是否已实施安全、身份验证和访问日志？
18. 您是否使用智能合约进行自动化数据交易？

**跨法规与执法**
19. 数据是否包含受 GDPR 管辖的个人数据？
20. 数据是否用于 AI 系统训练或高风险 AI 应用？
21. 《网络弹性法案》下的网络安全义务是否适用？
22. 哪个国家机构（德国、奥地利、瑞士、其他）拥有管辖权？

如果关键答案缺失，说明假设，并将其识别为合规缺口或实施阻碍。

## 参考文件

在评估过程中按需加载：

| 文件 | 何时阅读 |
|------|-------------|
| references/scope-assessment.md | 确定适用哪些《数据法》角色——制造商、数据持有者、用户、数据接收者、云提供者、公共机构 |
| references/data-access-rights.md | 用户获取和第三方共享权、技术要求、拒绝理由、费用结构 |
| references/unfair-terms-catalogue.md | B2B 合同公平性——本身不公平与推定不公平条款、安全港条件、示例 |
| references/cloud-switching.md | 云可移植性、切换时间线、费用逐步取消、导出格式、互操作性标准 |
| references/b2g-data-sharing.md | 公共机构请求、紧急与公共利益理由、相称性、补偿 |
| references/cross-regulation-mapping.md | GDPR、AI 法案、CRA、DGA 相互作用分析和综合合规策略 |
| references/dach-specific.md | 德国/奥地利/瑞士机构、国家执法、劳资委员会、行业叠加 |
| references/templates.md | 合规检查清单、数据获取请求响应模板、合同审查检查清单、差距分析 |

## 输出格式

每次《数据法》合规委托都应产出以下交付物：

1. **范围评估备忘录**——确定哪些《数据法》角色适用于组织、范围内的产品/服务，以及触发的关键义务。

2. **合规差距分析**——对数据获取、透明度、合同条款、云切换和设计即获取方面现状与要求状态的对比进行结构化评估。

3. **实施路线图**——使系统、合同和流程达到合规的时间表，按适用日期排序（2025 年 9 月主要要求、2026 年 9 月设计即获取、2027 年 1 月费用逐步取消）。

4. **数据获取权矩阵**——映射互联产品/服务、数据类型、当前获取机制、所需改进、责任团队和截止日期的表格。

5. **合同审查检查清单**——依据不公平条款目录评估 B2B 数据共享协议的评估工具，附建议修订。

6. **B2G 请求响应模板**——接收、评估和回应公共机构数据请求的标准流程。

7. **跨法规整合计划**——将《数据法》义务映射到 GDPR、AI 法案、CRA 合规计划，以避免重复并确保一致性。

→ 关于模板和示范措辞，阅读 references/templates.md。

## 关键合规说明

- **分阶段适用日期：** 主要要求自 **2025 年 9 月 12 日**起，设计即获取自 **2026 年 9 月 12 日**起，云切换费用取消至迟于 **2027 年 1 月 12 日**。
- **角色特定义务：** 并非所有义务适用于所有实体——范围评估是关键的第一步。
- **不覆盖 GDPR：** GDPR 下的个人数据保护仍然有效——《数据法》和 GDPR 并行适用。
- **执法：** 国家市场监督机构、数据保护机构（针对 GDPR 重叠），以及视国家实施情况可能的竞争主管机构。**处罚：** **第 40 条**下的欧盟层面框架要求成员国制定有效、相称且具有威慑力的处罚规则。德国《数据实施法》（Datendurchführungsgesetz，DADG）草案规定最高 500 万欧元的罚款，或对 DMA 守门人处以全球营业额 2% 的罚款。《数据法》本身不存在欧盟层面的百分比上限。
- **中小企业简化：** 微型和小型企业（员工 < 50 人，营业额 < 1000 万欧元）作为制造商受益于简化义务。微型/小型企业（员工 < 10 人，营业额 < 200 万欧元）作为数据持有者时豁免数据共享义务（第 7 条第 1 款）。
- **守门人排除：** 《数字市场法》守门人具有单独的数据获取义务——不得强制数据持有者与 DMA 守门人共享数据（第 6 条第 2 款(e)项）。
- **示范合同条款（MCT）：** 委员会 2025 年 11 月发布的建议为数据共享合同提供了不具有约束力的 MCT。MCT 是起草基准，但**不**创设全面的法定安全港。合同条款仍应依据其自身措辞、谈判历史和商业背景对照第 13 条进行测试。
- **争议解决：** 经认证的争议解决机构可用于处理数据获取拒绝、费用分歧、补偿条款和商业秘密主张（第 10 条）。

## 免责声明

本技能为 Regulation (EU) 2023/2854（欧盟《数据法》）提供结构化工作流支持。它不构成法律意见。某实体是否构成制造商、数据持有者或公共服务提供者，合同条款是否不公平，商业秘密保护是否正当，或 B2G 请求是否相称，可能取决于国家法律、行业规则、判例法和监管指引。分析应由合格律师审查，尤其是在产品上市、合同定稿、与机构接洽或执法程序之前。