面向 DACH SaaS 的 GDPR 与欧盟 AI 法案：当前规划框架

如果你在 DACH 地区销售 SaaS 并使用 AI，GDPR 与欧盟 AI 法案可能同时适用，但并非每项控制都适用于每个功能。应先明确用例、个人数据处理活动，以及你在 AI 价值链中的角色。按照欧盟委员会当前实施时间表，第 50 条透明度义务自 2026 年 8 月 2 日起适用，附件 III 高风险要求自 2027 年 12 月 2 日起适用，嵌入附件 I 受监管产品的高风险要求自 2028 年 8 月 2 日起适用。法律与治理负责人确认分析结论，产品与工程团队生成与系统相关的证据。

本文提供工程视角，不构成法律建议。我们已在 GDPR 制度下为 DACH 客户交付 AI 功能，也已根据 AI 法案时间表重新界定在建项目。

实际需要规划的执法时间表是什么？

AI 法案分阶段适用，相关日期取决于角色和系统：

• 2025 年 2 月 2 日。禁止的做法（第 5 条）和 AI 素养义务（第 4 条）开始适用。
• 2025 年 8 月 2 日。治理规定和通用 AI 模型提供者义务开始适用，较早模型适用过渡规则。
• 2026 年 8 月 2 日。第 50 条义务适用于特定 AI 交互以及生成或操纵的内容。
• 2027 年 12 月 2 日。依据 AI Omnibus 时间表，附件 III 高风险系统要求开始适用。
• 2028 年 8 月 2 日。嵌入附件 I 受监管产品的高风险 AI 要求开始适用。

GDPR 监管取决于司法辖区和处理情境。德国设有联邦和州级监管机构，奥地利则由 Datenschutzbehörde 负责。AI 法案主要由国家主管市场监督机构执行，AI 办公室和欧洲数据保护监督员在特定领域负责。应确认主管机构，不要假定某个特定监管机构会审查每个 SDLC。

我的 AI 功能是否属于附件 III 高风险系统？

附件 III 涵盖生物识别、关键基础设施、教育、就业、基本服务、执法、移民、司法和民主进程中的特定用途。具体目的和适用条件至关重要。例如，某些简历筛选、员工监控和信用评估系统可能在内，但行业标签或使用 AI 本身不足以确定分类。请结合立法文本使用欧盟委员会当前的高风险系统指南草案，并留意后续正式指南。

1. 预期目的是否符合附件 I 或附件 III 的某个类别及其条件？如果不符合，也应评估 AI 法案和 GDPR 的其他义务，而不是假定只剩第 50 条。
2. 对于附件 III 系统，第 6 条第 3 款是否因系统不构成重大风险且满足列明条件而将其排除？画像系统不适用该排除。记录评估，并检查是否存在注册义务。
3. 如果系统属于高风险，应分别映射提供者、部署者和其他角色的义务。完整的提供者控制集并不会自动由每个 SaaS 部署者承担。

构建与治理团队可能需要哪些证据？

不存在由工程团队统一负责的九项通用交付物清单。适用性与问责取决于角色、处理活动和系统分类。实用的证据地图可以包括：

1. 在 GDPR 第 30 条要求时维护处理活动记录，并以持续更新的数据流和系统记录作为支撑。
2. 当处理活动依据 GDPR 第 35 条可能对个人权利和自由造成高风险时开展数据保护影响评估。
3. 当公司承担相关高风险系统提供者义务时，准备附件 IV 规定的技术文档。
4. 根据适用的 AI 法案角色和系统进行适当日志记录。第 19 条的六个月规则涉及高风险系统在提供者控制期间自动生成的日志，其他法律另有规定的除外。
5. 为适用的高风险系统设置人工监督措施，包括胜任人员、相应权限和可用控制。
6. 针对第 50 条涵盖的交互与内容类别提供通知或机器可读标记。
7. 仅当公司实际是通用 AI 模型提供者时，准备训练内容和版权政策材料，而不是仅因使用了微调。
8. 为高风险系统提供者建立严重事件工作流，体现第 73 条规定的两天、十天和十五天期限。
9. 在提供者义务要求时开展上市后监测，其范围应与系统和所需证据相称。

EUR-Lex 上的 AI 法案综合文本是确认各角色具体要求的权威依据。

示例责任矩阵可以是什么样？

下表只是协调示例，并非法定分工或完整清单。五人公司可能合并角色、使用外部顾问或指定不同的责任人。首先将每项控制标记为适用或不适用。

"合规设计始于架构，而非上线。如果无法指出生成证据的那一行代码，这份证据就是虚构的。"

GDPR 与 AI 法案在实践中如何叠加？

两套制度可能重叠，但每个触发条件都必须单独评估：

• 训练数据。处理个人数据时，GDPR 要求具备合法依据并遵守其其他原则。AI 法案第 10 条的数据治理要求适用于相关高风险系统。
• 自动化决策。GDPR 第 22 条涉及完全基于自动化处理并产生法律或类似重大影响的决策。人工干预保障适用于特定例外情形。AI 法案第 14 条另行规定高风险系统的监督。
• 透明度。GDPR 第 13 条和第 14 条可能要求提供个人数据处理信息，AI 法案第 50 条涵盖特定交互与内容。两者都不是针对每项 AI 输出的通用通知。
• 记录。GDPR 第 30 条记录与 AI 法案第 11 条技术文档有不同的触发条件和责任角色。共享证据可以减少重复工作，但不能混同法律要求。
• 风险评估。GDPR 数据保护影响评估与 AI 法案风险管理系统可以复用证据，但二者不可互换，也不一定总要合并成一份文档。

映射第 22、30 和 35 条时，请查阅 EUR-Lex 上的 GDPR 官方文本。

通用 AI 提供者与部署者应如何区分？

一家集成第三方模型的 DACH SaaS 公司，可能既是该模型的部署者，也是其自行开发并投放市场的 AI 系统的提供者。各角色必须分别评估。微调不会自动使公司成为新的通用 AI 模型提供者。欧盟委员会的通用 AI 模型提供者指南指出，重大修改可能改变这一角色，而轻微修改通常不会。第 25 条另行规定其他主体何时承担 AI 系统提供者义务，例如对系统作出实质性修改或改变预期目的。

应如何估算构建阶段的成本？

不存在适用于这些证据改造或设计的可靠通用百分比。应依据适用控制、当前架构、数据血缘、模型与供应商访问条件、测试缺口、文档状态、安全控制、审查频率和外部鉴证估算。尽早分类可以避免返工，但不会让合规证据变得没有成本。对于 RAG、AI 智能体和 MCP 功能，应从实际角色和用例界定透明度、日志记录与人工控制需求。

其他制度可能影响同一产品路线图，但其适用日期和技术范围需要分别分析。我们的 Stripe Billing 与德国电子发票概览会单独说明计费要求。

隐私供应商或假名化层可能改变风险与数据流，但不会自动消除或保留数据控制者的所有义务。请阅读假名化网关如何改变 GDPR 范围，再重新评估具体处理活动和角色。