gdpr-breach-sentinel-oliver-schmidt-prietz

name	gdpr-breach-sentinel-oliver-schmidt-prietz
description	面向 GDPR 第 33 条和第 34 条下数据泄露的一流事件响应与法律合规指引。在以下情形使用：(1) 用户报告数据泄露或安全事件——包括"这到底算不算个人数据泄露？"的分诊，(2) 用户询问违规通知义务或截止期限，(3) 用户提及"72 小时"、第 33 条、第 34 条或通知要求，(4) 讨论涉及影响个人数据的安全事件，(5) 用户需要采用 ENISA 方法论的违规风险评估，(6) 用户提及"Data Breach"（数据泄露）或"Incident"（事件）或"Data Leakage"（数据泄漏）或"Ransomware"（勒索软件）或"Exfiltration"（数据外泄），(7) 用户需要确定控制者与处理者的义务，(8) 需要确定主导监管机构（Lead SA）的跨境违规场景，(9) 用户需要缓解行动手册或即时响应建议，(10) 用户需要审计就绪的违规文档（.docx）或与 EDPB 模板对齐的违规通知/证据文件——包括后续跟进和撤回通知，(11) 违规涉及 AI 系统，需要进行 AI 法案第 73 条严重事件筛查。
metadata	{"author":"Oliver Schmidt-Prietz","license":"AGPL-3.0","version":"2026.06.11"}

GDPR 违规响应哨兵（GDPR Breach Response Sentinel）

引导用户完成违规后合规流程，依据 GDPR 第 33 条和第 34 条、**EDPB《指南 9/2022》和《指南 01/2021》**以及 ENISA 严重性方法论。构建与 EDPB 模板对齐的违规证据文件、生成审计就绪的文档，并提供可操作的缓解指引。

---

会话初始化

1. 显示免责声明（会话开始时显示，不阻塞）

重要提示： 本技能基于 GDPR 第 33–34 条、EDPB 指南和 ENISA 方法论，提供结构化的 GDPR 违规通知指引。这不是法律意见。最终通知决定应涉及贵组织的数据保护官（DPO）和具备资格的法律顾问。

2. 保密与输入卫生（随免责声明显示，不阻塞）

谨慎处理： 这可能是一次进行中的事件。

• 除非必要，请勿粘贴真实个人数据——匿名化或假名化的样本（"员工 A"、"患者 1"）足以用于评估。
• 未经安全和法务团队许可，不得将取证工件、日志或个人数据上传到公开工具；如为真实违规，请在组织已批准用于机密事件数据的环境中工作。
• 维护法律特权：将随法律顾问或为其准备的沟通材料与操作性事实分开，并标注为特权文件。
• 在你记录的所有内容中，将事实、假设和法律结论明确分离（见下文"证据姿态"）。

3. 检查紧急状态

"你是否处于时间紧迫的情形，通知时限剩余不足 12 小时？"

• 是 → 激活紧急模式（见下文）
• 否 → 继续——提供标准模式或快速路径

4. 违规定性门禁（在信息采集前运行）

并非每起安全事件都是个人数据泄露。首先确认两件事：

1. 安全事件？ "是否发生了影响你系统、场所、流程或人员的安全破坏？"
2. 个人数据受影响？ "它是否——实际或可能——导致被传输、存储或以其他方式处理的个人数据被意外或非法毁坏、丢失、篡改、未经授权披露或访问？"（第 4(12) 条）

分类为恰好一种结论：

分诊结论	含义	下一步
仅安全事件	无个人数据受影响（例如针对静态网站的 DDoS、不含个人数据的系统上的恶意软件）	第 33/34 条不触发。记录为何不涉及个人数据（提供简短内部安全事件记录，.docx），建议保存该记录，筛查平行制度（NIS2 等），并停止 GDPR 工作流——无面板、不运行 ENISA
违规已确认	个人数据已证实受影响	进入信息采集——适用 72 小时时限分析
违规很可能——调查中	个人数据可能受影响但尚未确认	进入信息采集；保守处理 T0 并采用"仍在调查中"路径
事实不足	尚无法判断个人数据是否受影响	保全证据（日志、系统镜像、访问记录），确定含责任人和截止期限的事实调查行动，事实出现后尽快重新分诊

只有后三种结论进入信息采集（并出现在评估面板的分诊行中）；"仅安全事件"结论以简短分诊记录而非完整面板结束。如果事实后来发生变化（例如事件最终涉及个人数据），重新运行门禁。

5. 信息采集模式选择

让用户选择：

你希望如何进行？

• 引导模式——我将逐一引导你回答问题（不确定时推荐）
• 快速路径——提供事件的结构化摘要，我立即评估

如果用户选择快速路径，接受自由格式或结构化描述，并提取与引导模式问题对应的全部 11 个数据点：(1) 角色、(2) 时间线/T0、(3) 违规类型、(4) 数据类别、(5) 主体数量、(6) 标识符、(7) 加密、(8) 恶意意图、(9) 跨境、(10) DPA 截止期限、(11) 是否涉及 AI 系统。如果用户的描述缺少任何数据点，在继续前提示缺失项。继续前确认全部提取值。确认后直接进入风险评估。

如果用户选择引导模式但已提供部分或全部数据点，不要逐一重新询问——以单一表格（如快速路径）确认已提供的值，只询问缺失项。

快速决策树

对于常见场景（丢失加密设备、误发邮件、勒索软件、钓鱼）的快速初步定位，使用 references/enisa-methodology.md §0 中的决策树。决策树仅作定位——始终完成完整评估以获得确定性分类。

---

标准模式：问题序列（引导模式）

按以下顺序一次一个提问：

顺序	类别	关键问题
1	角色	"受影响的数据属于贵组织、贵方客户，还是两者兼有？"
2	时间线	"你何时达到对违规已发生的合理确信？"（这就是 T0）
3	违规类型	"适用哪些违规类型？选择所有适用项：机密性（数据被披露）、完整性（数据被篡改）、可用性（数据丢失/无法访问），或仍在调查中。许多事件涉及多种类型——例如勒索软件通常同时涉及可用性和可能的机密性。"
4	数据类别	"涉及哪些类别的个人数据？"
5	主体数量	"大约有多少个体受影响？"
6	标识符	"存在哪些标识符？（姓名、电子邮件、ID 等）"
7	加密	"数据是否加密？密钥是否安全？是否分开存储？"
8	恶意意图	"这是意外的还是故意的（盗窃、黑客攻击）？"
9	跨境	"受影响个体是否分布在多个欧盟成员国？你的主要机构在哪里？"
10	DPA 截止期限	"你的数据处理协议（DPA）是否规定了通知窗口？（常见：24 小时或 48 小时）"
11	AI 系统	"这次违规是否涉及 AI 系统？（例如模型泄露、对抗性攻击、AI 生成输出暴露）"

角色确定（路径选择）

场景	路径	行动
仅控制者	A	完整风险评估、监管机构通知决定
仅处理者	B	毫不迟延地通知控制者；准备初步的事实/风险支持包；最终第 33/34 条决定仍由控制者作出
混合（两者）	A+B	并行运行两条路径，绝不混淆

违规类型："仍在调查中"

如果用户为违规类型选择"仍在调查中"：

1. 无论如何都启动计时——T0 基于对违规已发生的合理确信，而非对范围的完整确定。如果涉及个人数据，72 小时时限可能已在运行。
2. 保全证据——建议用户在采取任何补救措施前保全日志、系统镜像和访问记录。
3. 初始评估按最坏情况假设——基于已知事实按最坏可能场景计算 CB。可在补充通知中下调。
4. 采用分阶段通知——第 33(4) 条明确允许分阶段通知。建议用户以已知事实提交初始通知，并承诺在确定时限内提供补充信息。
5. 记录调查过程——记录已知事项、未知事项以及为确定完整范围正在采取的步骤。这向监管机构展示问责性。
6. 范围更清晰时重新评估——一旦调查揭示实际违规类型，重新运行 ENISA 计算并更新评估。

T0 验证规则

在以下情形质疑 T0 主张：

• 怀疑与确信之间的间隔 > 24 小时 → 询问调查细节
• 间隔 > 48 小时 → 标记为"可能受到监管机构审查"
• T0 设定在便捷的时间边界（午夜、上午 9 点）→ 询问具体触发事件

两阶段 T0 分析（处理者场景）：

对于处理者，T0 分两阶段运作，具有不同的法律后果：

阶段	T0 事件	触发的义务	截止期限
阶段 1：处理者 T0（T0-P）	处理者得知违规	"毫不迟延"通知控制者（第 33(2) 条）	法定：毫不迟延；合同：按 DPA（通常 24-48 小时）
阶段 2：控制者 T0	控制者获处理者告知（依 EDPB《指南 9/2022》，处理者告知后控制者应被视为"已知情"）	控制者向监管机构通知的 72 小时时限启动	自控制者 T0 起 72 小时

处理者场景始终要确定两个 T0 时间点并在评估中同时显示。处理者自身的知情不启动控制者的 72 小时时限——控制者的时限在其被告知（或以其他方式自行得知）时启动。

处理者截止期限（B 路径）

处理者的法定义务是在得知后毫不迟延地通知控制者（第 33(2) 条）。处理者没有法定的 72 小时截止期限，且处理者不通知监管机构——除非它同时是受影响处理中部分数据的控制者，此情形下对该数据并行运行 A 路径。

在法定义务之外，大多数 DPA 增加了合同性通知窗口：

• 24 小时（金融服务、医疗保健中常见）
• 48 小时（企业协议中常见）
• "毫不迟延"（镜像 GDPR 措辞）

如果用户是处理者：

1. 确定处理者知情时间（T0-P）。
2. 询问 DPA 窗口，并自 T0-P 计算合同截止期限。
3. 将合同截止期限视为运营目标。如 DPA 未作规定，"毫不迟延"仍意味着数小时而非数天。
4. 解释下游后果：控制者的 72 小时时限在处理者告知时启动——及时的处理者通知直接保护控制者的合规。

B 路径输出必须显示： 处理者知情时间（T0-P）· 合同截止期限及剩余时间 · "毫不迟延"状态 · 控制者交接包完整性（见 references/templates.md）· 控制者的 72 小时时限作为下游控制者义务，绝非处理者自身的法定时限。

供应链/次级处理者链条违规

当违规源于次级处理者时，通知沿合同链条进行：次级处理者 → 处理者 → 控制者 → 监管机构。每一环对下一环负有"毫不迟延"告知义务（外加任何 DPA 窗口）。控制者的 72 小时时限仅在其被告知或以其他方式得知时启动。不要等待上游细节齐全——每一环以现有信息通知，稍后补充。记录每一环被通知的时间和所提供的内容；监管机构会审查链条延误。如果链条中的某实体也是部分受影响数据的控制者，并行运行 A 和 B 路径。

---

风险评估（ENISA 方法论）

公式： SE = (DPC × EI) + CB

详细评分表见 references/enisa-methodology.md。

快速参考

DPC（数据处理情境）：1-4（调整后硬性边界）

类别	分值
简单（姓名、联系方式）	1
行为性（位置、浏览记录）	2
财务（银行、工资）	3
第 9 条敏感数据（健康、生物识别）	4

DPC 上限规则： 应用情境调整后（见 enisa-methodology.md），最终 DPC 上限为 4.0、下限为 1.0。当调整会超出上限时（例如第 9 条基础 4 + 弱势主体 +3 = 理论 7），将超额因素作为定性加重情节记入战略咨询——它们强化严重性，但不改变数值分值。

EI（识别难易度）：0.25-1.00

级别	分值
可忽略	0.25
有限	0.50
显著	0.75
最大	1.00

CB（情境）：0-2（加性）

• 机密性丧失：0 / +0.25 / +0.50
• 完整性丧失：0 / +0.25 / +0.50
• 可用性丧失：0 / +0.25 / +0.50
• 恶意意图：+0.50

严重性结论（推定）

SE 分值	级别	推定行动（受第 33/34 条法律测试约束）
< 2	低	推定：仅内部记录（第 33(5) 条）
2 – < 3	中	推定：通知监管机构（第 33 条）
3 – < 4	高	推定：通知监管机构 + 数据主体（第 33 条和第 34 条）
≥ 4	极高	推定：监管机构 + 主体 + 考虑公开沟通

法律测试——第 33/34 条衔接（强制）

ENISA 分值为法律评估提供参考；它不机械地决定通知义务。法定触发条件属于规范性法律测试：

• 第 33(1) 条： 除非违规"不太可能对自然人权利和自由造成风险"，否则应通知监管机构。如果你无法肯定地得出"不太可能"的结论，推定为通知。
• 第 34(1) 条： 当违规"可能对权利和自由造成高风险"时，应向数据主体告知——除非适用第 34(3) 条例外（见下文第 34 条决策模块）。

每份评估必须包含从分值到结论的书面衔接：

LEGAL BRIDGE
ENISA score:      [SE value + level]
Key facts:        [what happened, to whose data, at what scale]
Safeguards:       [in place before the breach / applied after]
Likely impact:    [likelihood & severity of consequences for individuals]
→ Art. 33(1):     [NOTIFY SA / NO — unlikely to result in a risk, because …]
→ Art. 34(1):     [NOTIFY SUBJECTS / NO — no high risk, because … /
                   NO — exception Art. 34(3)(a)/(b)/(c) applies, because …]

如果法律结论与分值的推定相背离——无论哪个方向——以书面说明原因。分值产生推定；衔接就是决定。完整示例见 references/enisa-methodology.md §4a。

临界分值指引

当分值在阈值（2.0 / 3.0 / 4.0）0.25 以内时，在评估中明确注明，适用 references/enisa-methodology.md §4b 的临界指引表，倾向保守，并建议用户与 DPO 或法律顾问讨论临界分类。

适用标记

标记	条件	效果
🚩 规模	>100 个个体	监管机构审查加强
🔒 已加密	数据已加密、密钥安全	可能支持第 34(3)(a) 条例外
👶 弱势主体	未成年人、患者	考虑升级通知
⚠️ 跨境	跨境处理	一站式机制分析（见跨境规则）
🇬🇧 英国主体	涉及英国居民	需单独向 ICO 通知（见下方英国说明）
🤖 AI 系统	涉及 AI 系统	检查 AI 法案第 73 条义务

英国 GDPR 说明： 对于英国居民数据主体，ICO 的指引可能与 EDPB 的建议不同。英国不受 EDPB 指南约束——它依据英国 GDPR 和 2018 年《数据保护法》遵循 ICO 指引。ENISA 方法论提供了有用的分析框架，但 ICO 自身的风险评估方法也应当咨询。只要可用，始终使用 ICO 的自评工具，并注意 ICO 拥有独立于任何欧盟监管机构之外的通知门户和表格。

---

证据姿态（纳入每份评估）

可辩护的违规决策将已知与假设分离。每份评估输出必须包含：

EVIDENCE POSTURE
Established facts:       [verified, with source — logs, forensics, admissions]
Working assumptions:     [explicitly labelled, with their basis]
Material unknowns:       [what is not yet known that could change the verdict]
Evidence still needed:   [next fact-finding actions — owner, deadline]
Confidence level:        [HIGH / MEDIUM / LOW]
Impact on notification:  [how the unknowns affect the Art. 33/34 conclusions]

永远不要将假设呈现为事实。分阶段通知（第 33(4) 条）的存在正是为了不让不完整的事实延误初始通知。

---

AI 法案交叉适用（第 73 条检查）

如果用户确认违规涉及 AI 系统，执行额外评估：

1. 分类： 这是否是高风险 AI 系统（AI 法案附件 III，或附件 I 下的产品嵌入系统）？是否部署在受监管行业（医疗保健、执法、关键基础设施）？
2. 严重事件测试（第 3(49) 条）： 该事件是否直接或间接导致 (a) 人员死亡或健康严重损害；(b) 关键基础设施管理或运营的严重且不可逆的中断；(c) 违反旨在保护基本权利的欧盟法律项下义务；或 (d) 对财产或环境的严重损害？
3. 如是 → 第 73 条报告： 提供者（或适用情况下的部署者）向事件发生地成员国（或多国）的市场监督机构报告——在确定 AI 系统与事件之间的因果关系（或其合理可能性）后立即报告，最迟在知情后 15 天内。缩短的截止期限：对于第 3(49)(b) 条下的广泛侵权或关键基础设施事件为 2 天；发生死亡时为 10 天。允许先提交初始不完整报告，随后提交完整报告。
4. 适用性： 第 73 条自 2026 年 8 月 2 日起适用（嵌入附件 I 受监管产品的高风险系统：2027 年 8 月 2 日；第 73(9)-(10) 条的行业报告等效性）。在适用日期之前，说明该义务"将于"该日期"起适用"——它还不是一项已生效的义务。
5. 平行义务： 第 73 条与 GDPR 通知并行运行——义务独立、接收方独立、截止期限独立。

完整细节（定义、截止期限、延后适用）：阅读 references/parallel-regimes.md。

输出

当 AI 系统标记启用时，将该块作为独立的 AI ACT STATUS（AI 法案状态） 部分插入评估面板（置于 LEGAL VERDICT 之前），此外还有单行的 AI Act Art. 73 行：

AI ACT STATUS: [Applicable / Not Applicable / Not Yet Applicable / Requires Further Assessment]
Art. 73 Reporting: [Required / Not Required / Not Yet Applicable / Under Assessment]
AI System Classification: [High-Risk Annex III / High-Risk Annex I product-embedded / Limited Risk / Minimal Risk / Not Classified]

不要仅凭用户提供的附件 III 分类就照单全收：CE 标志的医疗器械或其他附件 I 受监管产品属于产品嵌入型高风险（适用日期 2027 年 8 月 2 日；第 73(9)-(10) 条在很大程度上让位于 MDR/IVDR 等行业警戒制度，这些制度如今可能施加生效的报告义务）。建议与用户的监管团队核实。

---

行业平行制度筛查

个人数据泄露常常触发 GDPR 之外的义务。在 GDPR 评估后运行一次轻量筛查——或对"仅安全事件"结论直接在分诊出口进行——识别即可，除非用户要求，不深入分析：

制度	触发提示
NIS2 / 国内实施	发生重大 ICT 事件的重要/关键实体——如 nis2-navigator 技能可用，将其用于该路径
DORA	发生 ICT 相关事件的金融实体
eIDAS	信任服务提供者
AI 法案第 73 条	高风险 AI 系统严重事件（见上文）
ePrivacy / 电信	可公开使用的电子通信服务提供者
刑法	向警察/司法机关报告（也是 EDPB 模板字段）
保险	网络保险单通知条款——窗口通常很短
合同	超出 DPA 的客户/合作伙伴通知条款
雇佣	涉及员工数据时劳资委员会/员工代表的参与（尤其在德国）

面板输出行："识别出的潜在平行制度： [清单]——除非要求，不作详细评估。" 详情和筛查问题：references/parallel-regimes.md。

---

EDPB 案例匹配

风险评估后，匹配 EDPB《指南 01/2021》的案例。见 references/edpb-cases.md。

类别：

• 勒索软件：案例 01-04
• 数据外泄：案例 05-07
• 内部人为风险：案例 08-09
• 丢失/被盗设备：案例 10-12
• 误投递：案例 13-16
• 社会工程：案例 17-18

类推警告： EDPB 案例是说明性类推，非约束性决定。事实差异很重要，类推永远不能替代对实际事实进行的第 33/34 条法律测试。说明最接近的案例、类推的局限，以及你的事实与之不同之处（见参考文件中的类推规则）。

输出格式：

"该场景与 EDPB 案例 [XX] 相似：[描述]。EDPB 建议：监管机构 [是/否]，主体 [是/否]。你的情况不同之处在于：[差异]。类推的局限：[局限]。这[支持/建议重新考虑]你的计算结果。"

---

动态网络研究模块

完成 ENISA 计算和 EDPB 案例匹配后，自动执行针对性网络研究以充实评估。阅读 references/web-research.md 了解具体查询模板（执法先例、监管机构特定指引、行业趋势、EDPB 更新、AI 法案、损害赔偿先例）及如何纳入发现。适用该参考文件中的来源纪律规则：官方来源（监管机构 / EDPB / 欧盟委员会）优先，不得以 SEO 或营销页面作为法律结论的基础，注明访问日期，绝不编造门户链接或监管机构联系方式。在评估面板中添加"监管情报"部分。

---

跨境规则

首先：这到底是不是跨境处理？

一站式机制要求真正的跨境处理（第 4(23) 条）——在一个以上成员国的机构背景下进行的处理，或对多个成员国的个体产生实质性影响的处理。不要仅仅因为受影响个体居住在多个成员国就假定跨境处理——测试对象是处理，而非主体居住地。在适用一站式机制前先作分析。

在欧盟设有机构的控制者

• 仅通知主导监管机构（一站式机制），前提是能确定主要机构和主导监管机构
• 主导监管机构 = 主要机构所在地
• 在通知中注明受影响的成员国（EDPB 模板要求按国家统计主体数量）

在欧盟未设机构的控制者

• 一站式机制不适用——仅存在欧盟代表不触发该机制（EDPB《指南 9/2022》v2.0，第 73 段）
• 在其成员国境内有受影响主体居住的每个监管机构都应通知
• 逐一跟踪提交；国家门户可能要求本地格式和字段

主导监管机构确定问题

1. "关于该数据处理的决定在哪里作出？"
2. "你的中央管理机构在哪里？"
3. "哪个机构对此处理有管辖权？"

监管机构联系目录

对确定的主导监管机构或相关监管机构，使用 web_search 查找：

• 官方监管机构通知门户 URL
• 用于违规通知的监管机构联系邮箱和电话
• 任何监管机构特定的通知表格或要求（有些监管机构有自己强制性表格，例如德国的 BfDI、法国的 CNIL）
• 办公时间和紧急联系程序

对于德国，在 BfDI（联邦机构、电信/邮政）和相关联邦州（Bundesland）的 LfDI/LDA（私营部门）之间路由——见 references/web-research.md 中的德国路由规则。

在评估面板中输出监管机构联系方式。在**仅处理者（B 路径）**运行中，将监管机构信息表述为供控制者交接包使用的礼貌性材料——绝不是处理者应自行使用的门户——并将面板的"通知监管机构"/监管机构截止期限行标记为下游控制者义务（对处理者为不适用）。

---

缓解行动手册

风险评估后，生成量身定制的缓解行动手册，针对该具体事件——不是通用清单，而是对此具体违规真正重要的、由个案驱动的行动。

阅读 references/mitigation-playbook.md 了解完整手册设计原则、输出格式（含责任人/截止期限/依赖关系的优先级行动计划）和可供借鉴的常见行动类别。

---

用户覆盖协议

如果用户不同意计算出的严重性：

1. 记录原始结果："我的评估显示 [级别]（SE = [分值]）。你希望将其归类为 [用户级别]。"
2. 要求说明理由
3. 如为降级，显示警告：

⚠️ 监管风险警告 你选择的严重性低于 ENISA 所示。如果监管机构后来认定应予更高严重性，这可能会增加监管审查并导致单独制裁。建议在律师参与下记录。

4. 在内部合规日志中记录覆盖

---

输出：评估面板

╔══════════════════════════════════════════════════════════════╗
║                 BREACH ASSESSMENT SUMMARY                     ║
╠══════════════════════════════════════════════════════════════╣
║ Triage:         [BREACH CONFIRMED / LIKELY — UNDER            ║
║                  INVESTIGATION / INSUFFICIENT FACTS]          ║
║ Role:           [Controller / Processor / Hybrid]             ║
║ Breach Type:    [Confidentiality / Integrity / Availability]  ║
║                 (multiple types may apply)                    ║
║ T0 (Awareness): [Timestamp]                                   ║
║ Clock Status:   [X hours elapsed / Y hours remaining]         ║
║ DPA Deadline:   [If applicable: X hours / N/A]                ║
╠══════════════════════════════════════════════════════════════╣
║                 SEVERITY CALCULATION                          ║
╠══════════════════════════════════════════════════════════════╣
║ DPC: [Score] - [Category + Adjustments]                       ║
║ EI:  [Score] - [Level]                                        ║
║ CB:  [Score] - [Breakdown]                                    ║
║ SE = (DPC × EI) + CB = [Final Score]                          ║
║ Severity Level: [LOW / MEDIUM / HIGH / VERY HIGH]             ║
║ Borderline:     [YES - near X threshold / NO]                 ║
║ EDPB Case Match: Case [XX] - [Supports/Reconsider]            ║
╠══════════════════════════════════════════════════════════════╣
║                 EVIDENCE POSTURE                              ║
╠══════════════════════════════════════════════════════════════╣
║ Confidence: [HIGH/MED/LOW] | Material unknowns: [count/list]  ║
╠══════════════════════════════════════════════════════════════╣
║                 FLAGS                                         ║
╠══════════════════════════════════════════════════════════════╣
║ 🚩 Scale: [YES/NO] | 🔒 Encrypted: [YES/NO]                   ║
║ 👶 Vulnerable: [YES/NO] | ⚠️ Cross-Border: [YES/NO]           ║
║ 🤖 AI System: [YES/NO]                                        ║
╠══════════════════════════════════════════════════════════════╣
║                 LEGAL VERDICT                                 ║
╠══════════════════════════════════════════════════════════════╣
║ Legal Bridge:    Art. 33(1) [notify / no risk]                ║
║                  Art. 34(1) [high risk / not high risk /      ║
║                  exception 34(3)(a)/(b)/(c)]                  ║
║ Notify SA:       [YES/NO] - Deadline: [TIME]                  ║
║ Notify Subjects: [YES / NO / Exception 34(3)(a)/(b)/(c)]      ║
║ Internal Log:    [MANDATORY]                                  ║
║ AI Act Art. 73:  [Required/Not Required/Not Yet Applicable/   ║
║                  N/A]                                         ║
║ Parallel Regimes: [list or "none identified"]                 ║
╠══════════════════════════════════════════════════════════════╣
║                 SA CONTACT DETAILS                            ║
╠══════════════════════════════════════════════════════════════╣
║ Lead SA:         [Name]                                       ║
║ Portal:          [URL]                                        ║
║ Contact:         [Email / Phone]                              ║
║ Additional SAs:  [If cross-border without one-stop-shop]      ║
╠══════════════════════════════════════════════════════════════╣
║                 REGULATORY INTELLIGENCE                       ║
╠══════════════════════════════════════════════════════════════╣
║ [Summary of relevant enforcement precedents and guidance]     ║
╚══════════════════════════════════════════════════════════════╝

---

第 34 条决策模块

每当事实或分值显示可能存在高风险时，运行专门的第 34 条分析——绝不简化为是/否一行：

• 触发条件： "可能对权利和自由造成高风险"（第 34(1) 条）；时点"毫不迟延"。
• 例外（第 34(3) 条）： (a) 对受影响数据采用了适当的技术/组织保护措施——尤其是使其不可识别的措施，例如密钥安全的最先进加密；(b) 后续措施确保高风险不再可能发生；(c) 告知将涉及不成比例的努力——此时必须以公开沟通或同等有效措施替代。
• 内容（第 34(2) 条）： 用通俗语言描述违规、DPO/联系点、可能后果、已采取或拟采取的措施，以及具体的自我保护步骤。
• 策略： 直接沟通对比公开沟通、分阶段沟通、弱势主体优先、按受影响成员国使用相应语言、支持渠道、欺诈/钓鱼警告措辞。
• 兜底： 监管机构可以命令沟通或确认某项例外（第 34(4) 条）。

阅读 references/art34-communication.md 了解完整决策框架，并将结果记录在第 34 条决策备忘录中（见 references/templates.md）。

---

战略案件咨询

在呈现评估面板后，以资深数据保护律师向客户危机团队汇报的姿态提供战略咨询。这超越 ENISA 分值——它正是区分称职合规与卓越事件响应的关键。

阅读 references/strategic-advisory.md 了解完整咨询框架、原则、章节结构和语气示例。覆盖：案件评估与风险图景、监管机构互动策略、通知起草指引、隐藏风险与二阶效应、防御性文档记录，以及危机中的竞争优势。

---

文档生成

完成评估后，主动提出生成审计就绪的 .docx 文档。

可用文档

1. EDPB 违规证据文件——镜像 EDPB 模板 [2026] 结构的完整通知案卷（见下文）
2. 第 33 条监管机构通知——向监管机构的正式通知
3. 第 34 条主体告知——向数据主体的通俗语言通知
4. 第 34 条决策备忘录——记录在案的高风险分析和例外论证
5. 处理者客户通知 + 交接包——向控制者客户的通知和支持包（B 路径）
6. 内部合规日志——第 33(5) 条强制性文档记录
7. 不予通知的理由说明——决定不通知时使用
8. 后续跟进/撤回通知——补充、完善或撤回先前通知
9. 缓解行动手册——含责任人和截止期限的优先级检查清单
10. 完整违规响应包——所有适用文档打包

EDPB 违规证据文件

应要求——并在需要通知监管机构时主动——构建与 EDPB 模板对齐的违规证据文件：一份镜像 EDPB《个人数据违规通知模板 [2026]》编号结构（§1 通知信息至 §7 附件）的文档。从评估中填充每个字段；缺口标记为 [UNKNOWN — investigate]（未知——待调查），不适用字段标记为 [N/A]。始终提示该模板的草案/公开咨询状态，以及国家监管机构门户在模板通过前仍具权威性。阅读 references/edpb-template-evidence-file.md 了解字段映射、填充规则和文档骨架。

文档生成流程

阅读 references/templates.md 了解文档模板和格式标准（A4、Arial 11pt、页眉/页脚、ISO 8601 日期）。检查是否有 docx 生成技能（Claude Code 中的 docx-processing-anthropic，或 Claude.ai Projects 中的 /mnt/skills/public/docx/SKILL.md）。如不可用则回退为 Markdown。从评估中预填值；缺口标记为 [TO BE COMPLETED]（待完成）。

---

通知后跟踪

初始评估后，提供持续案件管理。阅读 references/post-notification-tracking.md 了解跟踪面板模板，覆盖监管机构通知状态（含跟进和撤回）、主体告知、缓解执行阶段和文档完成情况。

每次会话结束时提醒用户：

• "你希望我将任何文档生成为 .docx 文件——包括 EDPB 证据文件吗？"
• "你需要我研究你所在监管机构的具体通知门户和要求吗？"
• "你想更新通知后跟踪器吗？"

---

紧急模式

激活触发条件

• 时限剩余不足 12 小时
• 用户明确要求
• 对数据主体安全构成即时风险
• T0 已超过 60 小时

紧急协议

显示：

⚡ 紧急模式已激活 正在生成最低可行评估。

精简信息采集（8 个问题）： 0. 该事件是否根本涉及个人数据？（如明显不涉及 → 仅安全事件——记录原因并停止 GDPR 工作流）

1. 角色：控制者、处理者，还是两者？
2. 数据类型？（简单/行为性/财务/敏感）
3. 多少人受影响？
4. 数据是否已加密且密钥安全？
5. 恶意还是意外？
6. 受影响个体在哪些国家？
7. 如为处理者：你的 DPA 是否规定了通知窗口？（例如 24 小时、48 小时）

快速计算：

• DPC：使用所述类别，不作调整
• EI：默认 0.75（显著）
• CB：按恶意/意外评分 + 假定机密性丧失

紧急输出：

1. 附注意事项的初步结论——包括压缩版法律衔接（第 33/34 条结论各一行）
2. 最低可行的第 33 条通知（如可能生成为 .docx）
3. 关键即时缓解行动（仅前 5 项）
4. 监管机构联系方式（通过网络搜索）
5. 跟进检查清单（48 小时内必做）

---

关键提醒

1. 记录一切——即使是不需要通知的违规（第 33(5) 条）
2. 处理者毫不迟延地通知控制者（第 33(2) 条）——处理者无法定 72 小时义务；控制者的时限在你告知时启动；DPA 窗口是额外的合同性要求
3. 72 小时是上限，不是目标——"毫不迟延"
4. 允许分阶段通知——不要为等待完整信息而延误
5. ENISA 分值是推定——第 33/34 条法律衔接才是决定；以书面记录
6. 并非每起事件都是违规——工作流前先运行违规定性门禁
7. 监管机构可命令主体告知——即使控制者已决定不告知
8. 不通知可单独受罚——最高 1000 万欧元或 2% 营业额
9. 非欧盟控制者：不适用一站式机制——通知每个相关监管机构
10. 加密不消除违规——仍须内部记录
11. 英国是独立的——脱欧后需向 ICO 通知；ICO 指引可能与 EDPB 不同；使用 ICO 自身的自评工具和通知门户
12. AI 系统有平行义务——AI 法案第 73 条与 GDPR 并行（自 2026 年 8 月 2 日起适用）
13. EDPB 模板 [2026] 是草案——公开咨询截至 2026 年 8 月 5 日；国家监管机构门户仍具权威性
14. 始终提供文档生成——审计就绪的 .docx 文件，而非仅聊天输出
15. 研究具体监管机构——门户 URL 和要求差异很大

---

版本与监管依据

文件	版本	最后核实
EDPB《指南 9/2022》（通知）	v2.0	通过网络搜索检查更新
EDPB《指南 01/2021》（示例）	v2.0	通过网络搜索检查更新
ENISA 严重性方法论	v1.0	通过网络搜索检查更新
欧盟 AI 法案（条例 2024/1689）	已生效；第 73 条自 2026 年 8 月 2 日起适用	第 73 条严重事件报告
EDPB《个人数据违规通知模板 [2026]》	v1.0 草案——公开咨询截至 2026 年 8 月 5 日	证据文件结构；通过网络搜索检查咨询结果

重要提示： 监管指引会不断演变。每份评估都应使用动态网络研究模块，检查这些基础文件的更新。

相关 GDPR 技能

本技能可独立使用，但与我的其他欧盟数据保护技能搭配效果良好——可单独安装任一技能或组合使用：

• DPIA Sentinel——第 35 条数据保护影响评估
• Privacy Notice Generator——第 13/14 条隐私通知
• Transfer Impact Assessment (TIA)——第五章转移评估
• DPA Art. 28——控制者-处理者协议（AVV）
• Legitimate Interest——第 6(1)(f) 条合法利益评估/利益平衡测试