gdpr-dsgvo-expert

GDPR/DSGVO 专家

提供欧盟《通用数据保护条例》（GDPR）和德国《联邦数据保护法》（BDSG）合规工具与指南。

---

目录

• 工具
  • GDPR 合规检查器
  • DPIA 生成器
  • 数据主体权利跟踪器
• 参考指南
• 工作流

---

工具

GDPR 合规检查器

扫描代码库，查找潜在的 GDPR 合规问题，包括个人数据模式和高风险代码实践。

# Scan a project directory
python scripts/gdpr_compliance_checker.py /path/to/project

# JSON output for CI/CD integration
python scripts/gdpr_compliance_checker.py . --json --output report.json

检测内容：

• 个人数据模式（电子邮件、电话、IP 地址）
• 特殊类别数据（健康、生物识别、宗教）
• 财务数据（信用卡、IBAN）
• 高风险代码模式：
  • 记录个人数据
  • 缺少同意机制
  • 无限期保留数据
  • 未加密的敏感数据
  • 禁用了删除功能

输出：

• 合规评分（0-100）
• 风险分类（严重、高、中）
• 附有 GDPR 条款参考的优先级建议

---

DPIA 生成器

根据第 35 条要求生成数据保护影响评估文档。

# Get input template
python scripts/dpia_generator.py --template > input.json

# Generate DPIA report
python scripts/dpia_generator.py --input input.json --output dpia_report.md

功能：

• 自动评估 DPIA 门槛
• 根据处理特征识别风险
• 记录法律依据要求
• 提供风险缓解建议
• 生成 Markdown 报告

评估的 DPIA 触发条件：

• 系统性监控（第 35(3)(c) 条）
• 大规模处理特殊类别数据（第 35(3)(b) 条）
• 自动化决策（第 35(3)(a) 条）
• WP29 高风险标准

---

数据主体权利跟踪器

管理 GDPR 第 15-22 条规定的数据主体权利请求。

# Add new request
python scripts/data_subject_rights_tracker.py add \
  --type access --subject "John Doe" --email "[email protected]"

# List all requests
python scripts/data_subject_rights_tracker.py list

# Update status
python scripts/data_subject_rights_tracker.py status --id DSR-202601-0001 --update verified

# Generate compliance report
python scripts/data_subject_rights_tracker.py report --output compliance.json

# Generate response template
python scripts/data_subject_rights_tracker.py template --id DSR-202601-0001

支持的权利：

权利	条款	时限
访问	第 15 条	30 天
更正	第 16 条	30 天
删除	第 17 条	30 天
限制处理	第 18 条	30 天
可携带性	第 20 条	30 天
反对	第 21 条	30 天
自动化决策	第 22 条	30 天

功能：

• 跟踪时限并在逾期时发出提醒
• 身份验证工作流
• 生成回复模板
• 合规报告

---

参考指南

GDPR 合规指南

references/gdpr_compliance_guide.md

全面的实施指南，涵盖：

• 处理的法律依据（第 6 条）
• 特殊类别数据要求（第 9 条）
• 数据主体权利实施
• 问责要求（第 30 条）
• 国际数据传输（第五章）
• 数据泄露通知（第 33-34 条）

德国 BDSG 要求

references/german_bdsg_requirements.md

德国特定要求，包括：

• 任命 DPO 的门槛（《BDSG》第 38 条——20 名及以上员工）
• 雇佣数据处理（《BDSG》第 26 条）
• 视频监控规则（《BDSG》第 4 条）
• 信用评分要求（《BDSG》第 31 条）
• 州级数据保护法（Landesdatenschutzgesetze）
• 工会委员会的共同决定权

DPIA 方法

references/dpia_methodology.md

DPIA 分步流程：

• 门槛评估标准
• WP29 高风险指标
• 风险评估方法
• 风险缓解措施类别
• 咨询 DPO 和监管机构
• 模板和检查清单

---

请先澄清

运行评估前，请先确定以下输入。如果某项缺失或含糊不清，且会影响结果，请先询问；如果不会影响结果，则采用合理的默认值，并说明所用默认值。

• **任务：**代码库合规扫描、生成 DPIA，或数据主体权利跟踪（决定使用的工具和工作流）。
• **角色和司法管辖区：**控制者还是处理者；仅适用 GDPR，还是也适用德国 BDSG（BDSG 增加了 DPO 门槛、§26 雇佣规则和 §4 视频监控规则）。
• **处理特征：**高风险处理，例如画像分析、AI，或大规模处理特殊类别数据（决定是否需要 DPIA）。

针对当前请求，请询问最重要的两三项输入，而不是询问全部内容。如果用户希望立即获得结果，请直接生成结果，并在开头说明你的假设。

工作流

工作流 1：新处理活动评估

Step 1: Run compliance checker on codebase
        → python scripts/gdpr_compliance_checker.py /path/to/code

Step 2: Review findings and compliance score
        → Address critical and high issues

Step 3: Determine if DPIA required
        → Check references/dpia_methodology.md threshold criteria

Step 4: If DPIA required, generate assessment
        → python scripts/dpia_generator.py --template > input.json
        → Fill in processing details
        → python scripts/dpia_generator.py --input input.json --output dpia.md

Step 5: Document in records of processing activities

工作流 2：数据主体请求处理

Step 1: Log request in tracker
        → python scripts/data_subject_rights_tracker.py add --type [type] ...

Step 2: Verify identity (proportionate measures)
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update verified

Step 3: Gather data from systems
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update in_progress

Step 4: Generate response
        → python scripts/data_subject_rights_tracker.py template --id [ID]

Step 5: Send response and complete
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update completed

Step 6: Monitor compliance
        → python scripts/data_subject_rights_tracker.py report

工作流 3：德国 BDSG 合规检查

Step 1: Determine if DPO required
        → 20+ employees processing personal data automatically
        → OR processing requires DPIA
        → OR business involves data transfer/market research

Step 2: If employees involved, review § 26 BDSG
        → Document legal basis for employee data
        → Check works council requirements

Step 3: If video surveillance, comply with § 4 BDSG
        → Install signage
        → Document necessity
        → Limit retention

Step 4: Register DPO with supervisory authority
        → See references/german_bdsg_requirements.md for authority list

---

GDPR 核心概念

合法依据（第 6 条）

• **同意：**营销、新闻简报、分析（必须是自由、自愿、具体且知情的）
• **合同：**订单履行、服务交付
• **法律义务：**税务记录、劳动法
• **合法利益：**防止欺诈、安全保障（需要进行利益衡量测试）

特殊类别数据（第 9 条）

需要明确同意或适用第 9(2) 条例外：

• 健康数据
• 生物识别数据
• 种族／民族出身
• 政治观点
• 宗教信仰
• 工会成员身份
• 遗传数据
• 性取向

数据主体权利

必须在 30 天 内满足所有权利请求（复杂请求可延长至 90 天）：

• **访问：**提供数据副本和处理信息
• **更正：**更正不准确的数据
• **删除：**删除数据（法律义务等情况除外）
• **限制：**在问题解决期间限制处理
• **可携带性：**以机器可读格式提供数据
• **反对：**停止基于合法利益进行的处理

德国 BDSG 补充规定

主题	BDSG 条款	主要要求
DPO 门槛	§ 38	员工人数达到 20 人及以上时必须任命 DPO
雇佣	§ 26	详细规定员工数据处理规则
视频	§ 4	标识告知和比例原则
评分	§ 31	算法必须可解释

---

交叉参考：CCPA/CPRA 美国隐私对比

在欧盟和美国司法管辖区开展业务时，应将 GDPR 合规与经 CPRA 修订的《加州消费者隐私法案》（CCPA）保持一致。需要管理的主要差异：

维度	GDPR	CCPA/CPRA
适用范围	任何处理欧盟居民数据的组织	达到收入／数据门槛的营利性企业
合法依据	必须具备 6 项合法依据（第 6 条）	无合法依据要求；采用选择退出模式
同意	默认选择加入	选择退出（未成年人和敏感数据除外）
数据主体权利	访问、更正、删除、可携带性、反对	知情、删除、更正、选择退出销售／共享、限制敏感数据使用
数据泄露通知	72 小时内通知监管机构（第 33 条）	在「最可行的时间」通知消费者
执法	由 DPA 执法，罚款最高可达全球营业额的 4%	加州隐私保护局（CPPA），每次违规罚款 2,500 至 7,500 美元
DPO 要求	许多情况下必须任命（第 37 条）	无 DPO 任命要求
儿童数据	16 岁以下须取得家长同意（第 8 条）	16 岁以下选择加入数据销售；13 岁以下须取得家长同意

**实践对齐：**构建统一的隐私计划，默认满足要求更严格的 GDPR，再叠加 CCPA/CPRA 特有机制（例如「请勿出售或共享我的个人信息」链接、年度指标披露）。

另请参阅：../ccpa-cpra-specialist/SKILL.md，了解完整的 CCPA/CPRA 合规工作流和工具。

---

基础设施隐私控制

Cookie 同意与追踪

根据 GDPR 第 6 条和《电子隐私指令》实施合规的 Cookie 同意机制：

类别	示例	是否需要同意	默认状态
严格必要	会话、CSRF、负载均衡器	否	启用
功能性	语言偏好、UI 设置	是	未启用
分析	Google Analytics、Matomo、Hotjar	是	未启用
营销	Facebook Pixel、Google Ads、再营销	是	未启用

实施要求：

• 在用户明确同意之前，横幅必须阻止所有非必要 Cookie
• 预先勾选的复选框不构成有效同意（Planet49 判决，CJEU C-673/17）
• 撤回同意必须与给予同意同样容易
• 记录同意凭证（时间戳、版本、所作选择）
• Cookie 政策发生重大变更时，重新征求同意

Global Privacy Control（GPC）信号

根据 CCPA/CPRA 法规和新兴的欧盟指南：

• 检测 Sec-GPC: 1 HTTP 标头和 navigator.globalPrivacyControl JavaScript API
• 将 GPC 视为 CCPA/CPRA 下有效的退出信号
• 对 GDPR：GPC 可作为第 21 条规定的反对信号——需根据具体情况评估
• 记录 GPC 信号检测情况并自动遵从

数据本地化与跨境传输

传输机制	状态（Schrems II 之后）	适用情形
欧盟充分性决定	有效	向获得充分性认定的国家传输（例如日本、英国、韩国、通过 DPF 传输至美国）
标准合同条款（SCCs）	配合 TIA 时有效	向未获得充分性认定的国家传输时的默认机制
有约束力的公司规则（BCRs）	有效	跨国企业集团内部传输
欧盟-美国数据隐私框架（DPF）	有效（自 2023 年 7 月起）	根据 DPF 获得认证的美国公司
例外情形（第 49 条）	仅限有限使用	明确同意、合同必要性——不适用于系统性传输

SCCs 的传输影响评估（TIA）要求：

1. 梳理数据流（数据内容、接收方、传输地点）
2. 评估接收方所在国家的法律框架（监控法律、主管部门的访问权限）
3. 评估所需的补充措施（加密、假名化、合同措施）
4. 记录评估并每年审查

---

AI 专属 GDPR 要求

自动化决策（第 22 条）

第 22 条限制仅基于自动化处理且会产生法律效力或类似重大影响的决策：

要求	实施方式
不受自动化决策约束的权利	为会产生重大影响的决策提供人工审查机制
获得解释的权利	记录并解释逻辑、重要性和后果
提出异议的权利	允许数据主体对自动化决策提出异议
明确同意或合同必要性	在部署前确保具备第 22(2) 条规定的法律依据
适当的保障措施	实施人工监督，并保障表达观点的权利

AI 透明度清单：

• 用通俗语言记录算法逻辑
• 对高风险决策（信贷、就业、保险）实施人在回路机制
• 为完全自动化的决策提供退出机制
• 开展并记录偏见测试（第 9 条规定的受保护特征）
• 记录所有自动化决策及其理由，以便审计
• 在隐私声明中说明 AI 决策（第 13(2)(f) 条、第 14(2)(g) 条）

AI 训练数据要求

要求	GDPR 依据	措施
训练数据的合法依据	Art. 6	合法利益（需进行 DPIA）或同意
目的限制	Art. 5(1)(b)	训练目的必须与原始收集目的相容
数据最小化	Art. 5(1)(c)	仅使用必要的最少数据；优先使用合成数据或匿名化数据
准确性	Art. 5(1)(d)	确保训练数据准确且为最新数据
存储限制	Art. 5(1)(e)	为训练数据集设定保留期限
特殊类别数据	Art. 9	对健康或生物识别数据，须取得明确同意，或符合 Art. 9(2)(j) 的研究豁免
删除权	Art. 17	实施从训练集删除个人数据的机制（或记录无法删除的原因）
数据抓取	Art. 14	使用公开数据进行训练时，告知数据主体

---

融合 EU AI Act 的增强版 DPIA 方法

DPIA 与 AI Act 符合性评估的重叠情形

对于处理个人数据的 AI 系统，可能需要同时进行 GDPR Art. 35 DPIA 和 EU AI Act 符合性评估：

AI 风险等级（EU AI Act）	是否需要 GDPR DPIA？	综合评估方法
不可接受（Art. 5）	不适用 — 禁止	不要部署
高风险（Annex III）	几乎总是需要	联合进行 DPIA 和符合性评估
有限风险（Art. 50）	根据 Art. 35 标准评估	如涉及系统性监控或画像，则进行 DPIA
最低风险	根据 Art. 35 标准评估	按标准 DPIA 门槛进行评估

AI 系统的增强版 DPIA 流程

Step 1: AI System Classification
        → Classify under EU AI Act risk levels
        → Map to GDPR Art. 35(3) triggers

Step 2: Data Flow and Processing Analysis
        → Document training data sources and legal basis
        → Map inference data flows
        → Identify automated decision points (Art. 22)

Step 3: AI-Specific Risk Assessment
        → Bias and discrimination risk (protected groups)
        → Accuracy and reliability risk
        → Explainability and transparency gaps
        → Data quality and representativeness
        → Model drift and ongoing monitoring needs

Step 4: Fundamental Rights Impact
        → Right to non-discrimination
        → Right to privacy and data protection
        → Freedom of expression (content moderation AI)
        → Right to an effective remedy

Step 5: Combined Mitigation Measures
        → Technical: differential privacy, federated learning, model cards
        → Organizational: AI ethics board, human oversight procedures
        → Contractual: AI-specific DPA clauses with processors
        → Monitoring: continuous bias monitoring, performance drift detection

Step 6: DPO and Supervisory Authority Consultation
        → Consult DPO on combined assessment
        → Prior consultation with SA if high residual risk (Art. 36)
        → Notify national AI authority if high-risk AI system

---

隐私保护设计的技术控制措施

数据最小化技术

技术	说明	用例
字段级加密	对静态存储的特定 PII 字段进行加密	数据库存储
令牌化	用不可逆令牌替换 PII	支付处理、分析
数据遮蔽	隐藏部分数据（例如，邮箱：j***@example.com）	UI 显示、日志记录
聚合	仅处理聚合或统计数据	分析、报告
按目的限定访问	将数据访问限制在特定处理目的内	多用途系统
自动过期	基于 TTL 删除数据	会话数据、临时处理

假名化实施（Recital 26，Art. 4(5)）

方法	可逆性	强度	最适用场景
基于 HMAC	可使用密钥还原	强	需要重新识别的内部分析
保持格式的加密	可使用密钥还原	强	旧版系统兼容性
确定性哈希（加盐）	单向	中	不含 PII 的跨数据集关联
随机 ID 映射	可通过查找表还原	强	研究数据集

假名化的密钥管理：

• 将重新识别密钥与假名化数据分开存储
• 对密钥材料实施严格的访问控制（至少两人共同操作）
• 记录密钥轮换计划
• 记录所有重新识别事件

加密标准

层级	最低标准	建议
静态数据	AES-256	使用信封加密的 AES-256-GCM
传输中	TLS 1.2	TLS 1.3
数据库	透明数据加密（TDE）	对 PII 进行列级加密
备份	AES-256	AES-256，并使用与生产环境不同的密钥
密钥管理	硬件支持（HSM/KMS）	使用客户管理密钥（BYOK）的云 KMS

---

跨框架隐私映射

要求	GDPR 条款	CCPA/CPRA 章节	HIPAA 规则	NIS2 条款
风险评估	Art. 35（DPIA）	§1798.185（风险评估法规）	§164.308(a)(1)	Art. 21(2)(a)
泄露通知	Art. 33-34（72 小时内通知 SA）	§1798.150（通知消费者）	§164.404-408（60 天）	Art. 23（24 小时内发出早期预警）
数据最小化	Art. 5(1)(c)	§1798.100(c)（收集限制）	§164.502(b)（最低必要原则）	Art. 21(2)(e)
加密	Art. 32(1)(a)	隐含要求（合理安全措施）	§164.312(a)(2)(iv)（可选要求）	Art. 21(2)(e)
访问控制	Art. 32(1)(b)	隐含要求（合理安全措施）	§164.312(a)(1)（访问控制）	Art. 21(2)(d)
事件响应	Art. 33-34	§1798.150	§164.308(a)(6)	Art. 21(2)(b)
供应链安全	Art. 28（处理者协议）	§1798.140(ag)（服务提供商合同）	§164.308(b)（BAA）	Art. 21(2)(d)
治理/问责	Art. 5(2)、Art. 24	§1798.185（审计法规）	§164.308(a)(1)	Art. 20（治理）
删除/擦除权	Art. 17	§1798.105	有限（保留规则）	不适用
数据可携权	Art. 20	§1798.130(a)(2)	不适用	不适用

交叉参考： 有关 ISO 27001 安全控制，请参阅 ../information-security-manager-iso27001/SKILL.md；有关 MDR 下医疗设备的数据保护，请参阅 ../mdr-745-specialist/SKILL.md。

---

跨框架隐私整合

GDPR ↔ CCPA/CPRA 对比

方面	GDPR	CCPA/CPRA
适用范围	任何处理欧盟居民数据的组织	营收达 2,500 万美元以上、消费者达 10 万人以上，或 50% 以上营收来自出售 PI
法律依据	必须具备 6 种法律依据之一（Art. 6）	选择退出模式（收集数据无需法律依据）
同意	必须选择加入	出售/共享时可选择退出
删除权	Art. 17	§1798.105
数据可携权	Art. 20	§1798.130
处罚	最高 2,000 万欧元或全球营业额的 4%	每次违规罚款 2,500 至 7,500 美元
是否要求 DPO	是（很多情况下）	否
是否要求 DPIA	是（高风险处理）	风险评估（CPRA）

AI 专属 GDPR 要求

• 自动化决策（Art. 22）： 有权不受完全基于自动化处理且会产生法律或重大影响的决策约束
• AI 训练数据： 必须具备合法权益或取得同意；目的限制原则适用于模型训练
• 画像分析： 对产生重大影响的自动化画像分析，必须取得明确同意
• 欧盟 AI 法案整合： 处理个人数据的高风险 AI 系统必须依照 GDPR Art. 35 进行 DPIA
• 交叉参考： 有关 AI 专属合规，请参阅 eu-ai-act-specialist

基础设施隐私控制

• Cookie 同意： 使用符合 TCF 2.2 的同意管理平台（CMP）
• 全球隐私控制（GPC）： 必须尊重 GPC 浏览器信号（CCPA 也有此要求）
• 数据本地化： 欧盟数据驻留要求、Schrems II 充分性决定
• 跨境传输： 标准合同条款（SCC）、充分性决定、约束性公司规则
• 隐私设计控制： 数据最小化、假名化、静态/传输中加密、访问日志记录

跨框架映射

控制项	GDPR	CCPA	HIPAA	NIS2
隐私声明	Art. 13-14	§1798.100	隐私实践	—
数据主体权利	Art. 15-22	§1798.100-125	访问/更正	—
泄露通知	Art. 33-34	§1798.150	§164.404-408	Art. 23
DPO/隐私专员	Art. 37-39	—	隐私专员	—
风险评估	Art. 35（DPIA）	风险评估	§164.308(a)(1)	Art. 21
加密	Art. 32	合理安全措施	§164.312(a)(2)(iv)	Art. 21.2.h
培训	Art. 39.1.b	—	§164.308(a)(5)	Art. 21.2.g

---

故障排除

问题	可能原因	解决方案
合规检查器报告特殊类别数据存在严重问题	代码在未获得明确同意或未满足第 9(2) 条例外情形的情况下处理健康、生物识别或宗教数据	识别所有特殊类别数据处理活动；获取明确同意或记录适用的第 9(2) 条例外情形；对敏感字段实施字段级加密
DPIA 生成器判定需要评估，但组织没有 DPIA 流程	处理活动触发了第 35(3) 条标准（系统性监控、大规模处理特殊类别数据或自动化决策）	按照 references/dpia_methodology.md 中的 DPIA 方法执行；使用 dpia_generator.py --template 生成模板；继续之前咨询 DPO；如果剩余风险较高，考虑事先咨询监管机构（第 36 条）
数据主体权利请求持续超过 30 天的期限	手动处理且没有跟踪系统、数据位置不明确，或验证要求复杂	部署 data_subject_rights_tracker.py 自动监控期限；使用数据清单绘制所有个人数据的位置；将身份验证简化为与风险相称的措施
跨境传输机制被判定无效或存在不确定性	依赖已废弃的机制，或未针对 SCC 完成传输影响评估	查看当前的充分性决定（英国、日本、韩国、通过 DPF 的美国）；对于 SCC，根据 Schrems II 要求完成传输影响评估；记录补充措施（加密、假名化）
Cookie 同意横幅被标记为不合规	预选复选框、Cookie 墙阻止访问，或拒绝按钮比接受按钮更难找到	实施符合 TCF 2.2 的 CMP；确保在获得明确同意前阻止所有非必要 Cookie；使拒绝按钮与接受按钮同样醒目（依据 Planet49 裁决，CJEU C-673/17）；记录同意证明
GDPR 合规检查器在应用日志中检测到个人数据	应用日志包含电子邮件地址、IP 地址或用户标识符	在存储前对个人数据进行掩码处理或假名化，以清理日志；配置日志框架，排除 PII 字段；设置与处理目的相符的日志保留期限
处理个人数据的 AI 系统缺少第 22 条保障措施	自动化决策产生法律效力或重大影响，但没有人工审核机制	对高风险决策实施人机协同；提供解释权和异议权；用通俗语言记录算法逻辑；根据第 13(2)(f) 条，在隐私声明中说明 AI 决策

---

成功标准

• 代码库扫描合规评分达到 80 分以上——表明不存在严重的个人数据暴露问题，且所有高风险模式均已处理并记录
• 在 30 天内完成所有数据主体权利请求——通过 data_subject_rights_tracker.py 跟踪，完成身份验证、生成响应模板，且合规报告显示没有逾期请求
• 为所有高风险处理活动完成 DPIA——涵盖第 35(3) 条触发条件、WP29 标准、风险缓解措施和 DPO 咨询；在需要时记录事先征询 SA 的情况
• 维护并及时更新处理活动记录（第 30 条）——涵盖所有处理活动及其目的、法律依据、数据类别、接收方、保留期限和传输机制
• 验证跨境传输机制——所有国际数据流均采用充分性决定、含 TIA 的 SCC 或 BCR，并每年进行审核
• Cookie 同意机制符合要求——在获得明确同意前屏蔽非必要 Cookie；拒绝选项与接受选项同样便捷；记录带有时间戳和版本号的同意证明；尊重 GPC 信号
• 在规定情况下任命并注册 DPO——包括德国 BDSG 第 38 条规定的门槛（20 名以上员工自动处理个人数据），并通知监管机构

---

范围与限制

范围内：

• 扫描代码库中的个人数据模式和高风险处理实践
• 根据第 35 条要求生成 DPIA，包括门槛评估和风险缓解
• 跟踪数据主体权利请求（第 15-22 条），并监控截止日期、提供响应模板
• 德国 BDSG 特定要求（DPO 门槛、雇佣数据、视频监控、信用评分）
• 评估跨境传输机制（充分性决定、SCC、BCR、DPF）
• AI 特定 GDPR 要求（第 22 条自动化决策、训练数据治理、画像分析）
• 跨框架隐私映射（GDPR、CCPA/CPRA、HIPAA、NIS2）

范围外：

• 针对特定法律依据选择或合法利益衡量测试提供法律建议——请咨询 DPO 和法律顾问
• 就违规事件报告（第 33-34 条）通知或联系监管机构
• 实施 Cookie 同意管理平台或同意管理代码
• 为非欧盟组织安排 GDPR 代表任命事宜（第 27 条）
• 申请或审批具有约束力的公司规则（BCR）
• 超出一般指导范围的德国各州数据保护法

重要说明：

• 2025 年 GDPR 执法罚款总额达到 23 亿欧元，同比增长 38%；医疗保健领域违规行为激增，平均罚款为 203,000 欧元
• 欧盟《人工智能法案》对处理个人数据的 AI 系统提出双重义务——可能需要同时进行 DPIA（GDPR 第 35 条）和合格评定（《人工智能法案》）
• 监管机构正加强对同意界面中暗黑模式的执法审查；Cookie 墙、操纵性 UI 和隐蔽的拒绝选项均可能受到处罚

---

集成点

技能	集成	使用时机
ccpa-cpra-privacy-expert	统一的隐私计划，涵盖 GDPR 和 CCPA/CPRA；跨框架映射	组织处理欧盟居民和加州消费者的数据时
eu-ai-act-specialist	针对处理个人数据的高风险 AI 系统，结合 DPIA 和 AI Act 合规性评估	AI 系统同时触发 GDPR 第 35 条 DPIA 要求和 EU AI Act 高风险分类时
information-security-manager-iso27001	ISO 27001 安全控制措施支持 GDPR 第 32 条关于处理安全性的要求	为保护个人数据实施技术和组织措施时
infrastructure-compliance-auditor	验证技术隐私控制措施（加密、访问控制、日志记录、数据屏蔽）	评估支持 GDPR 隐私保护设计要求的基础设施时
dora-compliance-expert	对于处理个人数据的金融行业 ICT 系统，DORA 补充 GDPR 的要求	金融实体需要使 DORA ICT 安全要求与 GDPR 数据保护要求保持一致时

---

工具参考

gdpr_compliance_checker.py

扫描代码库，查找潜在的 GDPR 合规问题，包括个人数据模式和高风险代码实践。

标记	必填	说明
<project_dir>	是	要扫描的项目目录路径
--json	否	以 JSON 格式输出结果，以便集成到 CI/CD 中
--output <file>	否	将报告导出到指定文件路径

检测内容： 电子邮件、电话号码、IP 地址、信用卡、IBAN、德国身份证模式；特殊类别数据（健康、生物特征、宗教）；高风险代码模式（记录 PII、缺少同意、无限期保留、敏感数据未加密、禁用删除）。输出： 合规评分（0-100）、风险分类（严重/高/中），以及附有 GDPR 条款引用的优先级建议。

dpia_generator.py

根据第 35 条要求生成数据保护影响评估文档。

标记	必填	说明
--template	否	将空白 DPIA 输入模板生成到标准输出
--input <file>	是（除非使用 --template 或 --interactive）	处理活动描述 JSON 文件的路径
--output <file>	否	将 DPIA 报告导出到指定文件路径（Markdown 格式）
--interactive	否	启动交互模式，引导创建 DPIA

功能： 根据第 35(3) 条触发条件和 WP29 标准自动评估 DPIA 阈值；基于处理特征识别风险；记录法律依据；提供缓解建议；生成 Markdown 报告。

data_subject_rights_tracker.py

根据 GDPR 第 15–22 条管理数据主体权利请求，并跟踪截止日期、提供回复模板。

子命令	描述
add	添加新请求（必需参数：--type、--subject、--email）
list	列出所有已跟踪的请求
status	查看或更新请求状态（必需参数：--id；使用 --update 更改状态）
report	生成合规报告（使用 --output 导出到文件）
template	为特定请求生成回复模板（必需参数：--id）

标志	描述
--type <right>	权利类型：access、rectification、erasure、restriction、portability、objection、automated
--subject <name>	数据主体姓名
--email <email>	数据主体的电子邮件地址
--id <request_id>	请求标识符（例如，DSR-202601-0001）
--update <status>	新状态：received、verified、in_progress、completed、denied、extended
--output <file>	将报告或模板导出到指定文件路径

功能： 30 天截止日期跟踪与逾期提醒、身份验证工作流、按权利类型生成回复模板，以及包含指标的合规报告。