gdpr-privacy-notice-eu-oliver-schmidt-prietz

泛欧 GDPR 隐私声明生成器

生成符合各司法管辖区要求、符合 GDPR 的专业 .docx 隐私声明。

工作流概览

1. SCOPE    → Notice type, jurisdiction(s), template choice
2. INTAKE   → Type-driven collection: controller info, data inventory, legal bases
3. DRAFT    → Generate notice from template + type profile + collected info
4. VERIFY   → Art. 13/14 compliance check + type-specific checks + AI Act check
5. DELIVER  → .docx output via docx skill

第 1 步：确定范围、声明类型并选择模板

确定声明类型（首个问题）

在进行任何其他操作之前，先确定需要哪种类型的隐私声明。加载 references/NOTICE_TYPES.md 并询问：

“您需要哪种类型的隐私声明？”

类型	说明
网站 / 应用	适用于网站、Web 应用或移动应用的访客、用户和订阅者
申请人 / 招聘	适用于求职申请人和候选人（Bewerber、candidats）
员工	适用于员工、承包商和实习生（Beschäftigte、salariés）
商业合作伙伴（B2B）	适用于供应商、供货商、客户和合作伙伴的联系人
B2C 客户	适用于处于客户 / 购买关系中的终端消费者
组合类型	在一份或多份关联声明中涵盖多个受众

所选类型决定：

• 最终文档中应包含 / 跳过哪些章节
• 收集信息时要询问哪些数据类别
• 最可能适用的法律依据
• 要提出哪些类型特定的收集信息问题
• 适用哪些默认保留期限

请参阅 references/NOTICE_TYPES.md，了解各类型完整的章节映射、数据概况、法律依据、收集信息问题和默认保留期限。

确定司法管辖区

询问服务面向哪些国家 / 市场。加载相应的参考文件：

目标市场	参考文件
德国 / DACH	references/DE.md
法国	references/FR.md
其他欧盟国家（AT、IT、ES、NL、BE、IE、UK）	references/OTHER_EU.md
始终加载	references/EU_COMMON.md

对于覆盖多个司法管辖区的服务，加载所有相关文件，并注明要求不同之处（例如，儿童年龄门槛、DPO 门槛、保留规则）。

选择模板

询问用户：

“我将把隐私声明编写为专业的 .docx 文档。您是否有现成的模板或隐私声明可供我参考？如果没有，我将使用预先制作的模板。”

选项	操作
用户提供模板	以其 .docx 为基础 — 保留结构、措辞和格式；仅填写 / 调整内容
用户未提供模板	使用 docx 技能，根据 references/templates.md 生成

references/templates.md 包含：13 个章节的结构、（醒目突出显示的）第 21 条反对权提示框、目的 / 保留期限表、Cookie 表、AI / 自动化决策章节、儿童数据章节、格式规范的页眉 / 页脚及页码、A4 页面格式、目录，以及德语、法语和英语的完整译文。选择与目标司法管辖区匹配的语言。

如果用户提供模板：忠实保留其结构和已验证的措辞。仅替换占位符并根据具体情况进行调整。切勿重写已验证的法律文本。

多语言决策树

如果服务面向多个司法管辖区或语言群体，请确定语言方案：

场景	方案
单一市场、单一语言	使用该市场语言发布一份告知书（例如，仅面向 DE → 德语）
单一市场、国际员工/用户	提供主要语言版本和英语版本。说明发生冲突时以哪个版本为准。
两个市场、两种语言	方案 A：分别发布两份告知书（每种语言一份），且每份内容完整。方案 B：发布双语告知书，并通过清晰的视觉布局区分（例如并排分栏或依次排列不同章节）。
泛欧盟 / 多个市场	以英语为主要语言，并提供主要市场的译文。每份译文都应是一份独立完整的告知书，而非部分翻译。
瑞士公司（nDSG + GDPR）	同时涵盖瑞士《新联邦数据保护法》（nFADP）和 GDPR。常见做法是发布一份同时引用两套法规的告知书，至少使用德语和法语（如适用，还包括意大利语）。注意：nFADP 对一般处理活动没有同意要求，但要求履行类似 GDPR 第 13/14 条的信息告知义务。

双语文档的模板处理：

• 使用主要语言模板作为结构基础
• 确保两种语言版本均包含所有强制披露内容（翻译遗漏即构成合规缺口）
• 明确标注具有约束力的语言版本（例如：“如有差异，以[德语/法语]版本为准。”）

多语言核验清单（如适用，添加到步骤 4）：

• 每种语言版本均包含第 13/14 条要求的所有强制披露内容
• 明确指出具有约束力的版本
• 法律术语翻译准确（不得未经审核直接使用机器翻译）
• 各司法管辖区的监管机构信息准确
• 已在相关语言版本中说明针对具体司法管辖区的要求

平台子类型（仅限网站/应用类型）

如果告知书类型为 网站 / 应用，请进一步对平台进行分类，以预判数据类别。详情请参阅 references/NOTICE_TYPES.md → “Website / App” → “Sub-Types & Data Profiles”。

子类型	典型附加数据
产品介绍/企业网站	联系表单、分析数据、仅 Cookie
电子商务	账户、付款、订单历史、配送、退货
SaaS / Web 应用	账户、使用数据、功能日志、API 密钥、协作数据
移动应用	设备 ID、推送令牌、权限（摄像头、位置、联系人）、应用使用情况
市场平台	双重角色（买家/卖家）、评分、消息、支付托管
具有 AI 功能的平台	训练数据、AI 输入/输出、模型决策、用户画像分析

步骤 2：信息收集

起草前收集所有信息。使用 references/NOTICE_TYPES.md 中的类型配置指导信息收集——每种类型都预先定义了可能涉及的数据类别、法律依据和类型专属问题。

按逻辑分组提问，不要一次性提出所有问题。先从 A 组（始终适用）开始，然后根据类型配置确定需要询问哪些类别，以及需要提出哪些类型专属问题。

A 组 — 控制者身份

• 公司名称、法律形式、注册号
• 注册地址
• 法定代表人（姓名 + 职务）
• 联系邮箱 + 电话
• 是否已任命 DPO？→ 联系方式（使用职能邮箱）

Group B — 数据清单

针对每个收集环节（表单、创建账户、购买、Cookie、应用使用）：

• 收集了哪些数据？
• 是必填还是选填？
• 数据来源是什么（用户直接提供、第三方提供、自动收集）？

需调查的类别：

• 身份信息：姓名、电子邮件、电话号码、地址、出生日期、照片
• 账户信息：凭据、偏好设置、设置、活动记录
• 技术信息：IP、设备 ID、浏览器指纹、日志
• 浏览信息：访问的页面、点击、会话时长、引荐来源
• 交易信息：订单、支付方式（通过服务提供商）、发票
• 通信信息：消息、支持工单、评论
• 特殊类别（第 9 条）：健康、生物特征、政治、宗教、性取向、族裔出身、工会、遗传——如果识别出任何第 9 条数据：请参阅 EU_COMMON.md →“特殊类别数据（第 9 条）”中的完整信息收集流程。确定每个类别适用的第 9(2) 条例外，确认双重法律依据（第 6 条 + 第 9(2) 条），并记录额外的保障措施。通知类型常见触发情形：员工（教会税、残疾、病假、工会会费）、求职者（残疾、健康、宗教）、B2C（药房／保险／健身场景中的健康数据）。
• AI 相关：输入 AI 系统的数据、AI 生成的输出、自动评分／决策

Group C — 目的与法律依据

针对每项处理活动，确定其法律依据。请参阅 EU_COMMON.md 获取指引。

请以表格形式呈现，供用户确认：

目的	法律依据	数据类别
服务提供／合同履行	Art. 6(1)(b)	[待填写]
账户管理	Art. 6(1)(b)	[待填写]
法律／税务合规	Art. 6(1)(c) — [具体法律]	[待填写]
分析	Art. 6(1)(f) 或同意	[待填写]
营销／新闻通讯	Art. 6(1)(a) 同意	[待填写]
基于 AI 的处理	[根据具体使用场景确定]	[待填写]

Group D — 接收方与传输

• 托管服务提供商及所在地
• 支付处理商
• 分析工具
• 电子邮件／营销工具
• CRM／支持工具
• AI/ML 服务提供商（例如 OpenAI、Google AI、Anthropic）
• 任何其他处理者
• 向 EU/EEA 以外传输 → 涉及哪些国家、采用何种机制（充分性认定、SCCs、DPF、BCRs）

DPA／第 28 条交叉核查——针对识别出的每个处理者：

• 确认是否已签订数据处理协议（GDPR 第 28 条）。如果没有，请标记为需要在最终确定通知前整改的合规缺口。
• 通知中应披露的内容：处理者名称（或类别）、目的、所在地、传输机制。请勿在隐私通知中加入 DPA 条款、次级处理者名单或 TOMs——这些内容应列入第 28 条协议。
• 不得披露的内容：具体的技术／组织措施（第 32 条）、次级处理者链条、定价、SLA 详情。
• 如果用户确认某处理者尚无 DPA：请在摘要中注明并建议立即整改。隐私通知仍应列明该处理者／类别，同时注明控制者正在办理协议的正式签订。
• 共同控制（第 26 条）：如适用，通知必须披露相关安排的实质内容，包括各自的职责以及数据主体的联系点。

Group E — Cookie 与跟踪

• 使用的 Cookie 类别（必要、分析、营销、社交）
• 具体工具（Google Analytics、Meta Pixel、Matomo、HubSpot 等）
• CMP 解决方案（Usercentrics、Cookiebot、Axeptio、Didomi、Borlabs 等）
• 是否进行服务端跟踪？是否使用指纹识别？
• Cookie 生命周期

Group F — AI 与自动化处理

如果服务使用 AI/ML：

• 使用了哪些 AI 系统，目的是什么？
• 决策是否完全自动化，还是有人参与？
• 决策是否会产生法律效力或类似的重大影响（第 22 条）？
• 用户数据是否用于模型训练？
• AI Act 分类：禁止／高风险／有限风险／最低风险？

G 组 — DPIA 指标（GDPR 第 35 条）

检查是否可能需要进行数据保护影响评估。如果以下指标中有 2 项或更多适用，请告知用户，并建议将 DPIA 作为单独的交付成果：

1. 对个人进行系统性评估／评分（用户画像、信用评分、绩效评估）
2. 具有法律效力或类似重大影响的自动化决策（第 22 条）
3. 对公众可进入区域进行系统性监控（CCTV、Wi-Fi 跟踪）
4. 大规模处理特殊类别数据或刑事犯罪数据（第 9／10 条）
5. 大规模处理个人数据（数据量大、地理范围广、数据主体众多）
6. 匹配或合并来自不同来源的数据集，且这种做法超出数据主体的合理预期
7. 弱势数据主体（员工、儿童、患者、老年人）
8. 创新性技术的使用（生物识别、AI／ML、IoT、用于个人数据的区块链）

如果标记了 2 项或更多指标：

• 告知用户：“根据所述的处理活动，似乎需要依据 GDPR 第 35 条进行数据保护影响评估（DPIA）。”
• 说明告知义务的影响：隐私声明应说明已开展 DPIA（但不得披露 DPIA 的内容）
• 建议：“DPIA 属于单独的合规工作，应在开始处理前完成。本隐私声明工具可以起草声明，但 DPIA 应作为独立文件编制。”
• 检查各国强制性 DPIA 清单（DE：DSK-Liste；FR：CNIL 要求进行 DPIA 的处理活动清单）

起草前的摘要

收集完信息后，生成结构化摘要，供用户确认：

NOTICE TYPE: [Website / Applicant / Employee / B2B / B2C / Combined]
CONTROLLER: [Name, form, address]
JURISDICTION(S): [Countries]
PLATFORM: [Type / Sub-type if website]
DPO: [Yes/No + contact]
DATA CATEGORIES: [List by collection point]
PURPOSES + BASES: [Table]
PROCESSORS: [List with locations]
TRANSFERS: [Countries + mechanisms]
COOKIES: [Categories + tools + CMP — if applicable per type]
AI PROCESSING: [Yes/No + details]
RETENTION: [Key periods — cross-check with type defaults]
SPECIFICS: [Anything unusual]
SECTIONS TO INCLUDE: [Based on type section map]
SECTIONS TO SKIP: [Based on type section map]

继续起草前，请先征得用户确认。

第 3 步：起草声明

按类型选择章节

针对所选声明类型，使用 references/NOTICE_TYPES.md 中的章节映射表。仅包含标记为 ✅ 或 ⚠️（如适用）的章节。跳过标记为 ❌ 的章节。这样可避免加入无关内容（例如在求职者声明中加入 Cookie 表格）。

对于涵盖多个受众的综合声明，请参阅 references/NOTICE_TYPES.md →“综合声明”中的结构选项（单份综合声明、分开编写或分层呈现）。

标准结构（完整版本 — 根据类型调整）

PRIVACY NOTICE / DATENSCHUTZERKLÄRUNG / POLITIQUE DE CONFIDENTIALITÉ
[Company Name]
Last updated: [DATE]

1. WHO WE ARE (Controller identity + DPO)
2. WHAT DATA WE COLLECT (by category, with source + mandatory/optional)
3. WHY WE PROCESS YOUR DATA (purposes + legal bases table, incl. retention per purpose)
4. WHO RECEIVES YOUR DATA (recipients + processors)
5. INTERNATIONAL TRANSFERS (countries + safeguards)
6. HOW LONG WE KEEP YOUR DATA (retention table — can be merged with section 3)
7. YOUR RIGHTS (all applicable rights + exercise procedure)
8. COOKIES & TRACKING (categories + management + CMP reference)
9. AI & AUTOMATED DECISIONS (if applicable — Art. 22 + AI Act)
10. DATA SECURITY (general measures, no sensitive technical details)
11. CHILDREN'S DATA (if applicable — age threshold + mechanism)
12. CHANGES TO THIS NOTICE (notification method)
13. CONTACT (email + postal + form link)

起草规则

• 语言：使用适用法域的语言。涉及多个法域时，先使用主要语言，并清楚注明具有约束力的版本。
• 语气：以“你”／“Sie”／“vous”称呼读者。语言应清晰易懂，便于非法律专业人士理解。
• 第 21 条的反对权：必须醒目地单独呈现，与其他权利分开（GDPR 第 21(4) 条）。德国的声明通常会单独设置“WIDERSPRUCHSRECHT”章节。
• 法律依据：准确引用条款编号（例如“Art. 6(1)(f) DSGVO”，而不只是“合法利益”）。
• 保留期限：说明具体期限及其法律依据，不得使用含糊表述。
• AI 披露：如果使用 AI，即使严格来说不适用第 22 条，也要设置专门章节 — AI Act 要求保持透明。
• 表格：使用表格列出处理目的／法律依据／保留期限以及 Cookie 类别，以提高可读性。
• 不得包含内部引用：最终文件不得引用本技能、CNIL 指南或其他起草辅助材料。

第 4 步：合规性核查

交付前，按以下顺序进行结构化最终检查：

1. 重新阅读第 1 步中加载的司法管辖区参考文件（DE.md、FR.md、OTHER_EU.md）。交叉核对：

• 监管机构名称、地址和 URL 是否与控制者的注册所在地相符
• 保留期限是否符合司法管辖区特定的法律引文（而非仅采用通用默认值）
• 标准措辞段落（第 21 条异议权、投诉权、控制者介绍）是否使用参考文件中的司法管辖区认可语言
• 是否还有尚未处理的司法管辖区特定要求（例如，针对德国员工／申请人的 § 26 BDSG，以及法国营销场景的 Art. L.34-5 CPCE）

**2. 根据 EU_COMMON.md → “Mandatory Disclosures Checklist” 核实 Art. 13/14 强制披露事项。**每一项都必须列明，或明确说明不适用及其原因。

3. 其他检查：

• 是否单独且醒目地说明了 Art. 21 异议权
• 是否列明了正确的监管机构（核对司法管辖区参考文件）
• 如已任命 DPO，是否包含其联系方式
• Cookie 部分是否与实际 Cookie 使用情况相符（如按类型包含此部分）
• 保留期限是否具体明确（不能只写“在必要期限内”而不说明标准）
• 传输机制是否与实际处理者所在地相符
• 如适用，是否说明 AI／自动化决策
• 如未成年人可以使用服务，是否说明儿童数据的处理
• 特殊类别数据（Art. 9）：是否披露双重法律依据（Art. 6 + Art. 9(2)）、指出具体例外，并说明额外保障措施
• 语言是否符合目标司法管辖区
• 是否没有遗留占位文本（[...]、___、TODO）
• 是否注明更新日期
• 各章节是否与该类型的章节结构图相符（无无关章节，也无缺失的必需章节）

4. 按类型进行检查（参见 references/NOTICE_TYPES.md）：

申请人：是否引用 § 26 BDSG（德国）？人才库同意是否单独取得？拒绝后保留期限是否 ≤ 6 个月，除非已取得同意？如数据来自招聘人员，是否适用 Art. 14？

员工：是否以 § 26 BDSG 作为主要依据（德国）？如相关，是否提及员工代表委员会？是否披露 IT 监控？是否完整说明复杂的保留期限链？

B2B：如数据并非直接来自数据主体，是否披露 Art. 14 信息？是否披露数据来源？是否清楚区分联系人与签约实体？

B2C 客户：是否满足软性选择加入条件（德国：§ 7(3) UWG）？是否披露支付处理者？是否清楚说明忠诚度计划条款？如适用，是否披露画像分析？

5. AI Act 合规性（如包含 AI 功能）：

• 是否告知用户其正在与 AI 互动（Art. 50 AI Act）
• 如适用，是否披露 AI 生成的内容
• 高风险 AI：是否满足透明度义务
• 是否披露 Art. 22 GDPR 权利与 AI 系统之间的关联

第 5 步：交付为 .docx

使用 docx 生成技能生成最终文档（Claude.ai Projects 中的 /mnt/skills/public/docx/SKILL.md，或 Claude Code 中的 docx-processing-anthropic 技能）。如果无法使用 docx 技能，则生成格式良好的 Markdown 作为后备方案。

文档格式标准

• 页面大小：A4（欧盟文件的标准）
• 字体：Arial 或 Calibri，正文 11pt，标题按比例放大
• 页边距：四边均为 2.5 cm（欧盟标准）= 1417 DXA
• 结构：标题编号（1.、2.、3...），超过 3 页的文档需包含目录
• 表格：浅色边框，标题行添加底纹，单元格内边距应便于阅读
• 页眉：公司名称或“Privacy Notice”
• 页脚：页码、“Last updated: [DATE]”

生成文件前，请阅读 docx 技能说明。新建文档时使用 docx-js。遵守 docx 技能中的所有关键规则（DXA 宽度、列表使用 LevelFormat.BULLET、表格使用 ShadingType.CLEAR 等）。

交付

提供 .docx 文件，并包含：

1. 简要确认文件中包含的内容
2. 尚待确认的问题或作出的假设
3. 建议在发布前进行法律审查

重要：务必建议用户在发布前请具备资质的法律顾问审查该告知。本工具可协助起草，但不能替代法律意见。

生成后的检查清单与审批工作流

向用户提供以下检查清单，供其内部审查和发布时参考：

法律审查：

• 由具备资质的数据保护法律顾问 / DPO 审查隐私告知
• 确认所有法律依据均适用于具体的处理活动
• 根据现行法律要求核实数据保留期限
• 确认传输机制有效且为最新版本（尤其是 DPF 认证、SCC 版本）
• 审查 Art. 9 特殊类别数据处理的双重法律依据和保障措施

技术审查：

• 确认列出的所有处理者和工具仍在实际使用（无过时条目）
• 确认 Cookie 表与网站实际设置的 Cookie 一致（使用浏览器开发者工具进行审计）
• 确认数据流与技术架构一致（与 IT / 工程团队核实）
• 确认联系信息（电子邮件、邮寄地址、DPO）准确且有人负责

翻译 QA（如有多种语言）：

• 每个语言版本均由具备法律专业知识的母语人士审阅
• 核实法律术语（不是直接使用机器翻译）
• 所有版本的实质内容完全一致
• 明确标注具有约束力的版本

发布要求：

• 用户可从任意页面最多点击 2 次访问该告知（德国：BGH 要求）
• 根据实际情况，在网站页脚 / 应用设置 / 新手引导流程中提供链接
• 将旧版本连同生效日期一并归档（以便审计追踪）
• 更新 Cookie 横幅 / CMP，使其指向当前隐私告知
• 将更新后的告知通知员工 / 申请人（如适用）

持续审查触发条件——建议用户在以下情况下审查该告知：

• 引入新的处理者或工具
• 增加新的处理目的
• 法律框架发生变化（新的充分性决定、法院裁决、监管指引）
• 公司发生合并、收购或重组
• 发生数据泄露，且因此发现未披露的处理活动
• 至少每年审查一次

交叉引用

• 数据泄露响应：如果用户还需要数据泄露通知流程，请参考 breach-sentinel 技能
• DPIA：如果处理活动可能具有高风险，建议另行开展数据保护影响评估（GDPR 第 35 条）
• Cookie 政策：可纳入隐私告知，也可单独成文——请询问用户的偏好

写作风格指南

推荐	避免
“您” / “您的数据” / “Sie” / “Ihre Daten”	“用户” / “数据主体” / “der Betroffene”
短小、清晰的句子	冗长的法律段落
为复杂的处理活动提供具体示例	含糊措辞（“各种数据”、“diverse Daten”）
使用表格呈现结构化信息	用大段文字说明处理目的 / 保留期限
精确引用条款	笼统表述“依照适用法律”
使用主动语态	尽可能避免被动表达
语言通俗易懂，同时保持法律严谨	纯法律术语或过度简化的语言

相关 GDPR 技能

此技能可独立使用，也可与我的其他欧盟数据保护技能配合使用——可单独安装，也可组合使用：

• DPIA Sentinel — 第 35 条数据保护影响评估
• GDPR Breach Sentinel — 第 33 / 34 条数据泄露响应与通知
• Transfer Impact Assessment (TIA) — 第 V 章传输评估
• DPA Art. 28 — 控制者与处理者协议（AVV）
• Legitimate Interest — 第 6(1)(f) 条合法利益评估 / 权衡测试