用途
该技能用于起草符合 GDPR/DSGVO 的隐私声明（数据保护声明），并以专业 .docx 文档形式输出，适用于欧盟/欧洲经济区不同司法管辖区及不同受众。当用户提出创建隐私政策/声明、涉及 GDPR/DSGVO 合规声明等需求时可使用。
主要能力与工作流程
工作流程分为五个阶段：范围确定（SCOPE）、信息采集（INTAKE）、起草（DRAFT）、合规验证（VERIFY）、交付（DELIVER）。
1. 范围、声明类型与模板选择
首先确定声明类型，可选类型包括：
- 网站 / App：面向网站、Web 应用或移动应用的访客、用户、订阅者
- 求职者 / 招聘：面向求职者和候选人（Bewerber、candidats）
- 员工：面向员工、承包商、实习生（Beschäftigte、salariés）
- 业务伙伴（B2B）：面向供应商、供货商、客户、合作伙伴的联系人
- B2C 客户：面向客户/购买关系中的最终消费者
- 组合：多个受众在一个或多个关联声明中呈现
所选类型决定最终文档包含/跳过的章节、采集阶段探查的数据类别、可能适用的法律依据、需询问的类型特定问题以及保留期限默认值。
随后确定司法管辖区，按目标市场加载参考文件：德国/DACH 使用 references/DE.md，法国使用 references/FR.md，其他欧盟国家（AT、IT、ES、NL、BE、IE、UK）使用 references/OTHER_EU.md，并始终加载 references/EU_COMMON.md。多司法管辖区服务需加载所有相关文件，并注意要求差异（如儿童年龄阈值、DPO 阈值、保留规则）。
模板选择方面，用户可提供已有 .docx 模板作为基础，此时保留其结构、措辞和格式，仅填充/适配；若无，则使用预置模板（references/templates.md），其中包含 13 节结构、Art. 21 反对权框（视觉突出）、目的/保留表、Cookie 表、AI/自动化决策章节、儿童数据章节、带页码的页眉页脚、A4 格式、目录，以及 DE、FR、EN 完整翻译。
多语言决策依据场景而定：单一市场单一语言使用市场语言；单一市场国际用户使用主语言加英文版并说明冲突时以何版本为准；两个市场两种语言可选择两份独立声明或双语声明并明确视觉分隔；泛欧/多市场以英文为主并配关键市场翻译，每份翻译应为独立完整声明。瑞士公司需同时应对 nFADP 与 GDPR，通常采用一份声明引用两套制度，至少提供德语和法语版本。多语言验证清单包括各语言版本均含全部强制披露、明确主导版本、法律术语正确翻译、监督机构信息正确、各司法管辖区特定要求已处理。
对于网站/App 类型，还需进一步分类平台子类型以预判数据类别：宣传/企业站点、电商、SaaS/Web 应用、移动应用、市场平台、带 AI 功能的平台。
2. 信息采集
在起草前收集全部信息，按类型配置文件引导采集，按逻辑分组询问。
- 组 A 控制者身份：公司名称、法律形式、注册号、注册地址、法定代表人、联系邮箱与电话、是否任命 DPO 及联系方式。
- 组 B 数据清单：各采集点收集哪些数据、是否必需、来源（用户直接提供、第三方、自动化）；探查类别包括身份、账户、技术、浏览、交易、通信、第 9 条特殊类别数据、AI 相关数据。若识别出第 9 条数据，需查阅 EU_COMMON.md 相关协议，确定 Art. 9(2) 例外、确认双重法律依据并记录额外保障。
- 组 C 目的与法律依据：以表格形式让用户确认各处理活动的法律依据（如服务提供/合同执行 Art. 6(1)(b)、账户管理 Art. 6(1)(b)、法律/税务合规 Art. 6(1)(c)、分析 Art. 6(1)(f) 或同意、营销/通讯同意 Art. 6(1)(a)、AI 处理按用例确定）。
- 组 D 接收方与传输：托管商及位置、支付处理商、分析工具、邮件/营销工具、CRM/支持工具、AI/ML 服务商、其他处理者；欧盟/欧洲经济区以外传输需说明国家与机制（充分性认定、SCCs、DPF、BCRs）。对每个处理者核验 Art. 28 数据处理协议是否在位，若缺失则标记为合规缺口并建议立即补救；声明中应披露处理者名称/类别、目的、位置、传输机制，但不包含 DPA 条款、子处理者清单或 TOM；如适用共同控制（Art. 26），须披露安排要点及数据主体联系点。
- 组 E Cookie 与追踪：Cookie 类别、具体工具、CMP 方案、是否服务端追踪/指纹识别、Cookie 生命周期。
- 组 F AI 与自动化处理：使用的 AI 系统及目的、决策是否完全自动化或有人工介入、是否产生法律或类似重大影响（Art. 22）、用户数据是否用于模型训练、AI Act 分类。
- 组 G DPIA 指标（Art. 35 GDPR）：若满足两项或以上指标（如对个人的系统评估/评分、自动化决策、公共区域系统监控、大规模处理特殊类别数据、大规模处理、数据源匹配组合、弱势数据主体、创新技术使用），提示用户可能需要进行数据保护影响评估，并建议作为独立交付物准备；同时检查国家强制性 DPIA 清单。
采集完成后生成结构化摘要供用户确认，内容包括声明类型、控制者、司法管辖区、平台、DPO、数据类别、目的与依据、处理者、传输、Cookie、AI 处理、保留期限、特殊事项、应包含章节、应跳过章节。
3. 起草声明
按类型使用 references/NOTICE_TYPES.md 的章节映射，仅包含标记为应包含或适用时包含的章节，跳过不适用章节（例如求职者声明中不包含 Cookie 表）。组合声明可选择单一综合、分开或分层结构。
标准结构（完整版，按类型调整）包括：标题与最后更新日期；1. 我们是谁（控制者身份 + DPO）；2. 我们收集哪些数据（按类别，含来源与必需/可选）；3. 我们为何处理您的数据（目的与法律依据表，含各目的保留期限）；4. 谁接收您的数据；5. 国际传输（国家 + 保障措施）；6. 数据保留多久（保留表，可与第 3 节合并）；7. 您的权利（全部适用权利 + 行使程序）；8. Cookie 与追踪（类别 + 管理 + CMP 引用）；9. AI 与自动化决策（如适用 —— Art. 22 + AI Act）；10. 数据安全（一般措施，不含敏感技术细节）；11. 儿童数据（如适用 —— 年龄阈值 + 机制）；12. 本声明的变更（通知方式）；13. 联系方式。
起草规则：使用司法管辖区语言书写，多司法管辖区时主语言在前并明确主导版本；以「您」称呼读者，语言清晰易读；Art. 21 反对权必须突出且与其他权利分开呈现（德语声明中通常设独立「WIDERSPRUCHSRECHT」章节）；精确引用条款号；保留期限使用具体时长及法律依据，避免模糊表述；如使用 AI，即使 Art. 22 不严格适用也应设专门章节以满足 AI Act 透明度要求；目的/依据/保留及 Cookie 类别使用表格；最终文档不得包含对本技能、CNIL 指南或其他起草辅助工具的引用。
4. 合规验证
交付前按顺序执行结构化最终检查：
- 重读所加载的司法管辖区参考文件，交叉核对监督机构名称、地址、URL，保留期限与司法管辖区法律引用，标准措辞块使用参考文件中的有效措辞，以及尚未处理的司法管辖区特定要求（如德国员工/求职者的 § 26 BDSG、法国营销的 Art. L.34-5 CPCE）。
- 对照 EU_COMMON.md 的强制披露清单验证 Art. 13/14 每一项是否存在或明确说明不适用及原因。
- 额外检查：Art. 21 反对权是否单独突出呈现；监督机构是否正确；已任命 DPO 时其联系方式是否包含；Cookie 章节是否与实际使用一致；保留期限是否具体；传输机制是否与实际处理者位置匹配；AI/自动化决策是否已处理；儿童数据等。
5. 交付
通过 docx 技能生成 .docx 输出。
适用场景
适用于需要为欧盟/欧洲经济区市场准备隐私声明或数据保护声明的组织，覆盖网站/应用、招聘、员工、B2B、B2C 等不同受众，以及单语言、多语言、多司法管辖区等情形。
限制
该技能本身不进行 DPIA 编制，DPIA 被建议作为独立合规工作单独准备；输入中未提供关于收费、价格、平台兼容性或实际使用效果的说明，这些信息暂未提供。涉及监管判定的内容仍建议由专业法律人员复核。