pia-generation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/pia-generation

Load

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→ PIA house style (trigger, structure, depth, sign-off).

Run the workflow below.
Check: is a PIA actually needed? (House trigger + research the mandatory-assessment triggers for each applicable regime — cite primary sources, verify currency.)
Intake: ask the product-team questions. Can pull from PRD if provided.
Write PIA in house format. Include privacy policy consistency check.
Output with conditions list and named owners. Route for sign-off.

/privacy-legal:pia-generation "Location sharing feature"

/privacy-legal:pia-generation
PRD: [Drive link]

加载
```
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
```
→ 内部PIA格式（触发条件、结构、深度、签署流程）。
执行以下工作流。
检查：是否确实需要PIA？（结合内部触发条件，以及各适用监管体系下的强制评估触发条件——引用原始来源，确认时效性。）
信息收集：向产品团队询问相关问题。若提供PRD（产品需求文档），可从中提取信息。
按照内部格式撰写PIA，包含隐私政策一致性检查。
输出时附带条件清单和指定负责人，提交签署流程。

/privacy-legal:pia-generation "Location sharing feature"

/privacy-legal:pia-generation
PRD: [Drive link]

PIA Generation

PIA生成流程

Matter context

事项上下文

Matter context. Check

## Matter workspaces

in the practice-level CLAUDE.md. If

Enabled

✗

(the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run

/privacy-legal:matter-workspace switch <slug>

or say

practice-level

." Load the active matter's

matter.md

for matter-specific context and overrides. Write outputs to the matter folder at

~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/

. Never read another matter's files unless

Cross-matter context

on

事项上下文：查看业务级CLAUDE.md中的

## Matter workspaces

部分。如果“启用”状态为

✗

（内部用户默认设置），则跳过本段剩余内容——技能将使用业务级上下文，事项机制对用户不可见。如果已启用但无活跃事项，请询问：“这属于哪个事项？请运行

/privacy-legal:matter-workspace switch <slug>

或说明‘业务级’。”加载活跃事项的

matter.md

文件，获取事项特定上下文和覆盖规则。将输出写入事项文件夹：

~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/

。除非“跨事项上下文”开启，否则不得读取其他事项的文件。

Destination check

输出目标检查

Before producing output, check where it's going. If the user has named a destination (a channel, a distribution list, a counterparty, "everyone"), ask whether it's inside the privilege circle. Public channels, company-wide lists, counterparty/opposing counsel, vendors, and clients (for work product) waive the protection. When the destination looks outside the circle, flag it and offer (a) the privileged version for legal only, (b) a sanitized version for the broader channel, or (c) both — don't silently apply a privileged header and then help paste it somewhere the header won't protect it. See the canonical

## Shared guardrails → Destination check

in this plugin's CLAUDE.md.

生成输出前，检查输出目标。如果用户指定了目标（如频道、分发列表、交易对手、“所有人”），请询问该目标是否属于特权保护范围。公共频道、全公司列表、交易对手/对方律师、供应商以及客户（针对工作成果）会导致特权保护失效。当目标看起来在保护范围外时，需进行标记并提供以下选项：(a) 仅供法务使用的特权版本，(b) 适用于更广泛频道的脱敏版本，(c) 同时提供两者——不得静默添加特权页眉后将其粘贴到页眉无法提供保护的地方。请参考本插件CLAUDE.md中标准的

## Shared guardrails → Destination check

部分。

Purpose

目的

A PIA is a conversation with the product team, captured. It asks: what data, why, how long, who sees it, what could go wrong. This skill structures that conversation and writes the output in this team's format — the one learned from the seed PIA during cold-start.

PIA是与产品团队对话的记录。它会探讨：涉及哪些数据、为何使用、存储时长、访问人员、可能出现的风险。本技能将结构化该对话，并按照团队指定格式生成输出——即冷启动阶段从初始PIA中学习到的格式。

Jurisdiction assumption

司法管辖区假设

This assessment assumes the jurisdictional scope specified in your configuration. Privacy rules, assessment triggers, and lawful bases vary materially by jurisdiction (GDPR vs. state consumer privacy laws vs. sectoral). If the processing activity, controller, or affected data subjects fall under a different jurisdiction, this analysis may not apply as written.

本评估假设管辖范围符合配置中的指定内容。隐私规则、评估触发条件和合法依据因司法管辖区不同而存在显著差异（GDPR vs. 美国各州消费者隐私法 vs. 行业特定法规）。如果数据处理活动、控制方或受影响的数据主体属于其他司法管辖区，本分析可能无法直接适用。

Load prior context on this feature / activity

加载该功能/活动的历史上下文

Before writing a new PIA, check the outputs folder for prior work on the same feature, processing activity, or counterparty. Read

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→

## Outputs

for the path. Scan for:

Prior
use-case-triage
results covering this activity — the triage's risk rating, mandatory conditions, and called-out concerns are the entry point for the PIA.
Prior
pia-generation
outputs for the same or an overlapping activity — a superseding PIA should reconcile (what changed, what carried over). A PIA that silently produces different conclusions than a prior PIA on the same activity is a contradiction a reviewing attorney cannot see.
Prior
dpa-review
outputs for vendors in scope — the DPA review's findings inform the PIA's analysis of subprocessor / cross-border / retention risk.

If a prior output is found, cite it in the PIA:

"Prior triage ([date]) rated this [risk level] and required [conditions]. This PIA builds on that finding — [which conditions are satisfied, which remain, which are re-scoped]."

If a prior PIA exists:

"This PIA supersedes the [date] PIA because [reason — scope change, new data category, vendor change, regulatory change]. Conclusions carried over: [X]. Conclusions revised: [Y, because Z]."

Carry severity from upstream as a floor per the cross-skill severity floor rule in

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→

## Shared guardrails

. A use-case-triage that rated the activity high-risk cannot become a PIA that concludes low-risk without stating why and what changed.

If no prior output is found, say so explicitly — "No prior triage or PIA on this activity in outputs folder; this is a cold start" — so the reviewing attorney knows the check ran and didn't find anything to reconcile.

撰写新PIA前，检查输出文件夹中是否有关于同一功能、处理活动或交易对手的历史成果。查看

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→

## Outputs

部分获取路径。重点查找：

过往
use-case-triage
结果：涵盖该活动的风险评级、强制条件和突出关注问题，这些是PIA的切入点。
过往
pia-generation
输出：针对相同或重叠活动的PIA——更新后的PIA需说明（哪些内容已变更、哪些内容延续）。如果针对同一活动生成的PIA与过往结论存在差异却未说明，会导致审核律师无法发现矛盾。
过往
dpa-review
输出：针对相关供应商的审查结果，将为PIA中的分包商/跨境传输/留存风险分析提供信息。

如果找到过往输出，需在PIA中引用：

“过往分类评估（[日期]）将该活动评为[风险等级]，并要求满足[条件]。本PIA基于该结论展开——[哪些条件已满足、哪些仍未满足、哪些已调整范围]。”

如果存在过往PIA：

“本PIA取代[日期]的PIA，原因是[范围变更、新增数据类别、供应商变更、监管变更等]。延续的结论：[X]。修订的结论：[Y，原因Z]。”

将上游风险等级作为最低标准：遵循

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→

## Shared guardrails

中的跨技能风险等级最低标准规则。如果用例分类评估将活动评为高风险，PIA不得直接得出低风险结论，必须说明原因和变更内容。

如果未找到过往输出，需明确说明——“输出文件夹中无针对该活动的过往分类评估或PIA；本次为全新启动”，以便审核律师确认已完成检查且未发现需协调的内容。

Load house style

加载内部格式

Read

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→

## PIA house style

. That has:

What triggers a PIA here (may not match regulatory DPIA triggers — some teams PIA everything, some only high-risk)
The structure template extracted from the seed PIA
Typical depth
Who signs off

If the seed PIA structure is in the config CLAUDE.md, use it. The point is that this PIA looks like the other PIAs this team produces, not like a generic one.

阅读

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→

## PIA house style

部分，其中包含：

内部PIA触发条件（可能与监管要求的DPIA触发条件不同——部分团队对所有内容做PIA，部分仅针对高风险内容）
从初始PIA中提取的结构模板
典型深度要求
签署人员

如果配置文件CLAUDE.md中包含初始PIA结构，请务必使用该结构。核心目标是让生成的PIA与团队其他PIA格式一致，而非通用格式。

Step 0: Is a PIA needed?

步骤0：是否需要PIA？

Check the trigger criteria in

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

. That is the team's house answer.

In addition, research the currently operative mandatory-assessment triggers for each regime in the regulatory footprint (GDPR/UK GDPR DPIA triggers, CCPA/CPRA risk-assessment triggers, other US state data-protection assessment triggers, sectoral regimes). Cite the controlling statute, regulation, or regulator guidance with pinpoint references. Verify currency — assessment thresholds and definitions shift through new state laws, rulemaking, and enforcement guidance. Flag uncertainty rather than guess.

No silent supplement. If a research query to the configured legal research tool returns few or no results for a regime's DPIA / risk-assessment triggers or lawful-basis rules, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "The search returned [N] results from [tool]. Coverage appears thin for [regime / question]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged
[web search — verify]
and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?" A lawyer decides whether to accept lower-confidence sources.
Source attribution. Tag every citation in the PIA with where it came from:
[Westlaw]
,
[regulator site]
, or the MCP tool name for citations retrieved from a legal research connector;
[web search — verify]
for web-search citations;
[model knowledge — verify]
for citations recalled from training data;
[user provided]
for citations the user supplied. Citations tagged
verify
carry higher fabrication risk and should be checked first. Never strip or collapse the tags.

Beyond statutory mandates, treat these as strong indicators that a PIA is worth doing even if not strictly mandatory (research whether any of them independently triggers a mandatory assessment under the applicable regime):

New technology or novel use of existing tech
Children's data
Combining datasets that weren't collected together
Data that could enable discrimination
Processing that users wouldn't expect

If no statutory trigger applies and the house trigger also isn't met → "Doesn't look like this needs a PIA. Here's a one-paragraph note for the file explaining why, in case anyone asks."

检查

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

中的触发标准，这是团队内部的判断依据。

此外，研究各监管体系当前有效的强制评估触发条件（GDPR/UK GDPR DPIA触发条件、CCPA/CPRA风险评估触发条件、美国其他州数据保护评估触发条件、行业特定法规）。引用核心法规、规章或监管指南，并标注精确出处。确认时效性——评估阈值和定义会随新州法、规则制定和执法指南而变化。如有不确定性，需标记说明，而非猜测。

不得静默补充内容：如果向配置的法律研究工具发起的查询对某一体系的DPIA/风险评估触发条件或合法依据规则返回结果极少或无结果，请报告已发现内容并停止操作。不得未经询问就通过网络搜索或模型知识填补空白。请说明：“从[工具]检索到[N]条结果。针对[体系/问题]的覆盖范围不足。可选方案：(1) 扩大搜索查询范围，(2) 尝试其他研究工具，(3) 进行网络搜索——结果将标记为
[web search — verify]
，使用前需与原始来源核对，或(4) 标记为未验证并停止操作。请问您希望选择哪种方案？”由律师决定是否接受低可信度来源。
来源归因：PIA中的每一处引用都需标记来源：从法律研究连接器获取的引用标记为
[Westlaw]
、
[regulator site]
或MCP工具名称；网络搜索的引用标记为
[web search — verify]
；从训练数据中召回的引用标记为
[model knowledge — verify]
；用户提供的引用标记为
[user provided]
。标记为“verify”的引用存在更高的错误风险，需优先核对。不得删除或合并标记。

除法定要求外，以下情况即使并非强制要求，也应视为强烈建议进行PIA的指标（需研究这些情况是否会独立触发适用体系下的强制评估）：

新技术或现有技术的创新性使用
儿童数据
合并未同时收集的数据集
可能导致歧视的数据
用户意料之外的数据处理行为

如果既无法定触发条件，也未满足内部触发条件→“看起来不需要针对该内容做PIA。以下是一段存档说明，解释原因，以备后续查询。”

The intake

信息收集

Before writing anything, get answers to these from the product team. Conversational is fine — this isn't a form to send them.

撰写PIA前，请向产品团队获取以下问题的答案。采用对话形式即可——无需发送正式表单。

What and why

内容与目的

What's the feature/product/change?
What problem does it solve for users?
What personal data does it touch? Be specific — "user data" is not an answer. Which fields?
Is any of it new collection, or is it all data you already have?
What's the processing — storage, analysis, sharing, automated decisions?

该功能/产品/变更是什么？
它为用户解决了什么问题？
涉及哪些个人数据？请具体说明——“用户数据”并非有效答案。具体涉及哪些字段？
是否包含新收集的数据，还是全部使用已有的数据？
数据处理方式是什么——存储、分析、共享、自动化决策？

Legal basis / regime-specific checks

合法依据/体系特定检查

For each applicable regime, research the currently operative framework for the question below and cite primary sources:

Under regimes that require an identified lawful basis for processing (e.g., GDPR, UK GDPR), identify the basis for each purpose (contract / legitimate interest / consent / legal obligation / vital interests / public task / other). Research the specific requirements and any balancing-test or consent-standard expectations; cite controlling authority.
Under regimes that regulate disclosures (e.g., CCPA/CPRA and other US state privacy laws), check whether any flow looks like a "sale," "share," or other regulated disclosure under the currently operative statutory definitions. Third-party advertising is a recurring trap — research whether it falls within the regulated category for the applicable regime.
Under sectoral regimes (HIPAA, GLBA, COPPA, FERPA, etc.), research any regime-specific basis or disclosure rules.

Verify currency; statutory definitions and bases are amended often. Flag uncertainty for attorney verification.

针对每个适用的监管体系，研究当前有效的框架并回答以下问题，同时引用原始来源：

对于要求明确处理合法依据的体系（如GDPR、UK GDPR），为每个处理目的确定合法依据（合同/合法利益/同意/法定义务/重大利益/公共任务/其他）。研究具体要求以及任何平衡测试或同意标准的预期；引用权威依据。
对于规范数据披露的体系（如CCPA/CPRA及其他美国州隐私法），检查是否存在符合当前法定定义的“出售”“共享”或其他受监管的披露行为。第三方广告是常见陷阱——需研究其是否属于适用体系下的受监管类别。
对于行业特定体系（HIPAA、GLBA、COPPA、FERPA等），研究体系特定的合法依据或披露规则。

确认时效性——法定定义和依据经常修订。如有不确定性，需标记供律师验证。

Who and where

人员与地域

Who inside the company can see this data? Engineers? Support? Analysts?
Any third parties? Vendors, partners, analytics?
Where is it stored? Which region? New infrastructure or existing?
How long is it kept? Is there a deletion schedule or does it live forever?

公司内部哪些人员可以访问这些数据？工程师？客服？分析师？
是否涉及第三方？供应商、合作伙伴、分析服务商？
数据存储在哪里？哪个地区？使用新基础设施还是现有基础设施？
数据留存时长是多久？是否有删除计划，还是永久留存？

What could go wrong

潜在风险

If this data leaked, what's the harm to the person?
Could this data be used to discriminate, even accidentally?
Would users be surprised this is happening? (The "creepy test" — not a legal standard but a useful one.)
Is there an opt-out? Should there be?

如果数据泄露，会对用户造成什么危害？
这些数据是否可能被用于歧视，即使是无意的？
用户是否会对该处理行为感到意外？（“不适测试”——并非法律标准，但实用有效。）
是否提供退出选项？是否应该提供？

Writing the PIA

撰写PIA

Use the seed PIA structure from the config CLAUDE.md. If none was captured, use this default. Prepend the work-product header from

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

## Outputs

(it differs by user role — see

## Who's using this

markdown

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

使用配置文件CLAUDE.md中的初始PIA结构。如果未捕获到初始结构，可使用以下默认模板。在开头添加

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

中

## Outputs

部分的工作成果页眉（根据用户角色不同而有所差异——请查看

## Who's using this

部分）。

markdown

[WORK-PRODUCT HEADER — 遵循插件配置## Outputs部分]

Privacy Impact Assessment: [Feature/Product Name]

隐私影响评估：[功能/产品名称]

Prepared by: [name] | Date: [date] | Status: DRAFT / APPROVED Product owner: [name] | Privacy reviewer: [name]

编制人： [姓名] | 日期： [日期] | 状态： 草稿 / 已批准 产品负责人： [姓名] | 隐私审核人： [姓名]

Executive summary

执行摘要

[Two sentences: what this is, whether it's okay. E.g., "Feature X collects location data to provide Y. Processing is consistent with existing privacy policy commitments and uses consent as lawful basis. Two mitigations recommended below; no blockers identified."]

Overall risk: [Reviewer to set: 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high]

[两句话说明：内容概述、合规性结论。例如：“功能X收集位置数据以提供Y服务。数据处理符合现有隐私政策承诺，以同意为合法依据。以下推荐两项缓解措施；未发现阻塞性问题。”]

总体风险： [由审核人设定：🟢 低 / 🟡 中 / 🟠 高 / 🔴 极高]

1. Description of processing

1. 处理活动描述

What: [the feature, in plain English] Data categories: [specific fields — not "user data"] Data subjects: [customers / end users / employees / etc.] Purpose: [why — tie to user benefit] New collection? [yes — these fields are new / no — reusing existing data]

内容： [用通俗易懂的语言描述功能] 数据类别： [具体字段——不得笼统写“用户数据”] 数据主体： [客户 / 终端用户 / 员工 / 等] 目的： [说明原因——关联用户收益] 是否为新收集数据？ [是——新增以下字段 / 否——复用现有数据]

2. Lawful basis

2. 合法依据

Purpose	Basis	Notes
[purpose 1]	[Contract / LI / Consent / etc.]	[if LI: balancing test summary; if consent: how obtained]

目的	依据	说明
[目的1]	[合同 / 合法利益 / 同意 / 等]	[如果是合法利益：平衡测试摘要；如果是同意：获取方式说明]

3. Data flow

3. 数据流

Collection: [how/where data enters] Storage: [system, region, encryption] Access: [who, via what controls] Sharing: [third parties, purpose, governed by which DPA] Retention: [how long, deletion mechanism]

收集： [数据进入的方式/渠道] 存储： [系统、地区、加密方式] 访问： [访问人员、控制措施] 共享： [第三方、共享目的、适用的DPA（数据处理协议）] 留存： [时长、删除机制]

4. Privacy policy consistency

4. 隐私政策一致性

Policy commitment	Consistent?	Notes
[commitment from config CLAUDE.md privacy policy section]	🟢 / 🟡

[If any 🟡: policy update needed before launch, or processing needs to change]

政策承诺	是否一致？	说明
[来自配置文件CLAUDE.md隐私政策部分的承诺]	🟢 / 🟡

[如果存在🟡标记：需在上线前更新政策，或调整处理活动]

5. Risks and mitigations

5. 风险与缓解措施

#	Risk	Likelihood	Impact	Mitigation	Status	Owner
1	[specific risk, tied to the design — not "data breach" generically]	L/M/H	L/M/H	[specific control]	Done / Planned / Gap	[name]

Residual risk after mitigations: [assessment]

#	风险	可能性	影响	缓解措施	状态	负责人
1	[具体风险，关联设计细节——不得笼统写“数据泄露”]	低/中/高	低/中/高	[具体控制措施]	已完成 / 计划中 / 缺口	[姓名]

缓解后剩余风险： [评估结论]

6. Data subject rights

6. 数据主体权利

Right	Can be exercised?	How
Access
Deletion
Correction
Portability
Objection

权利	是否可行使？	行使方式
访问权
删除权
修改权
可携权
反对权

7. Recommendation

7. 建议

[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED]

Conditions (if any):

[specific thing that has to happen before launch]

Sign-off: [name, date]

undefined

[批准 / 有条件批准 / 需要变更 / 不批准]

条件（如有）：

[上线前必须完成的具体事项]

签署： [姓名，日期]

undefined

Risk quality standards

风险质量标准

Risks in a PIA should be specific and tied to the design, not generic. Bad risks pad the document and train readers to skim.

Bad risk	Why bad	Better
"Data breach"	Applies to everything; says nothing	"Location history accessible by support staff via the admin panel without audit logging — a malicious insider could track a user undetected"
"Non-compliance with GDPR"	Circular — the PIA is supposed to assess compliance	Name the specific article and the gap
"Users might not like it"	Vague	"Users who opted out of marketing may still receive this because the opt-out flag isn't checked in this flow"

Aim for 2-5 real risks, not 15 padded ones.

PIA中的风险应具体且关联设计细节，而非泛泛而谈。模糊的风险会增加文档篇幅，导致读者忽略关键内容。

不良风险描述	问题所在	优化后描述
“数据泄露”	适用于所有场景，无实际意义	“支持人员可通过管理面板访问位置历史记录且无审计日志——恶意内部人员可在未被察觉的情况下追踪用户”
“不符合GDPR要求”	循环论证——PIA的作用正是评估合规性	明确指出具体条款和缺口
“用户可能不满意”	表述模糊	“已退出营销的用户仍可能收到相关信息，因为该流程未检查退出标记”

目标是列出2-5个真实风险，而非15个凑数的模糊风险。

Privacy policy diff

隐私政策差异

Every PIA should cross-check against the privacy policy commitments in

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

. The common drift:

Policy says "we collect X, Y, Z" — new feature collects W. Policy needs updating, or stop collecting W.
Policy says "we don't sell data" — new feature shares with an ad partner. That might be a CCPA sale.
Policy says retention is "as long as your account is active" — new feature keeps data post-deletion.

Flag every mismatch. One of them has to change before launch.

每份PIA都需与

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

中的隐私政策承诺进行交叉核对。常见差异包括：

政策规定“我们收集X、Y、Z”——新功能收集W。需更新政策，或停止收集W。
政策规定“我们不出售数据”——新功能与广告合作伙伴共享数据。这可能构成CCPA定义下的“出售”。
政策规定“数据留存至账户存续期间”——新功能在账户删除后仍保留数据。

标记所有不一致之处。上线前必须调整政策或处理活动。

Handoff

交接

To product team: Conditions list with owners and deadlines. Not "improve security" — "add audit logging to the admin panel's location lookup, owner: [eng lead], before launch."
To reg-gap-analysis skill: If the PIA uncovered a policy inconsistency, that skill tracks the policy update.

To the sign-off process: Per

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→ who approves PIAs.

给产品团队： 附带负责人和截止日期的条件清单。不得写“提升安全性”——需明确为“在管理面板的位置查询功能中添加审计日志，负责人：[工程主管]，上线前完成”。
给reg-gap-analysis技能： 如果PIA发现政策不一致，该技能将跟踪政策更新。

给签署流程： 遵循

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

→ PIA批准人员的规定。

Gate: submitting a DPIA to a regulator

关卡：向监管机构提交DPIA

Producing an internal PIA is research and documentation. Submitting a DPIA to a supervisory authority — or voluntarily disclosing one to a regulator in response to an inquiry — is the consequential act.

Before proceeding to submit a DPIA (or any equivalent impact assessment) to a regulator, supervisory authority, or enforcement body: Read

## Who's using this

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

. If the Role is Non-lawyer:

Submitting to a regulator has legal consequences — the document becomes part of the supervisory record and any material omission or error becomes enforcement exposure. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:

[Generate a 1-page summary: regime and regulator, why a submission is being made (mandatory trigger or voluntary), the risks identified, residual risk after mitigations, any flagged uncertainty, and the three things to ask the attorney before filing.]

If you need to find a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).

Do not proceed past this gate without an explicit yes.

生成内部PIA属于研究和文档工作。向监管机构提交DPIA——或在调查中主动向监管机构披露——是具有重大影响的行为。

在向监管机构、监督机构或执法机构提交DPIA（或任何等效影响评估）之前： 阅读

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md

中的

## Who's using this

部分。如果角色为非律师：

向监管机构提交文件会产生法律后果——该文档将成为监管记录的一部分，任何重大遗漏或错误都会导致执法风险。您是否已与律师审核过该内容？如果是，请继续。如果否，请将以下摘要提交给律师：

[生成1页摘要：涉及的体系和监管机构、提交原因（强制触发或自愿）、已识别的风险、缓解后的剩余风险、标记的不确定性，以及提交前需向律师询问的三个问题。]

如果您需要在所在司法管辖区寻找持牌律师、事务律师、出庭律师或其他授权法律专业人士：您所在行业的监管机构推荐服务是最快的起点（美国州律师协会、英格兰及威尔士SRA/律师标准委员会、苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚律师协会，或所在司法管辖区的等效机构）。

未获得明确同意前，不得越过此关卡。

Close with the next-steps decision tree

以下一步决策树收尾

End with the next-steps decision tree per CLAUDE.md

## Outputs

. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.

根据CLAUDE.md

## Outputs

部分的下一步决策树收尾。根据本技能生成的内容自定义选项——五个默认分支（起草X、升级、获取更多事实、观察等待、其他）仅为起点，并非固定选项。决策树即为输出内容，由律师选择下一步行动。

What this skill does not do

本技能不执行的操作

It doesn't approve the processing. A human signs the PIA.
It doesn't write a DPIA for a supervisory authority — that's a more formal document with specific regulatory requirements. This is the internal assessment.
It doesn't design the mitigation. It describes what needs mitigating; engineering designs the fix.

不批准数据处理活动。需由人工签署PIA。
不为监管机构撰写DPIA——此类文档更正式，有特定监管要求。本技能仅生成内部评估文档。
不设计缓解措施。仅说明需要缓解的内容，由工程团队设计解决方案。