findscripter 何时使用
当要为一个新功能、产品或数据处理活动撰写隐私影响评估（PIA），或需要判断「这个到底要不要做 PIA」时使用。本技能把一次「与产品团队的对话」结构化并按公司既定模板落成文档：收集了哪些数据、为什么、留多久、谁能看、可能出什么事。
不该用的边界：
- 不做审批决策——PIA 必须由人签字，本技能只输出草稿与建议。
- 不撰写向监管机构正式提交的法定 DPIA（那是更正式、有特定监管要求的文档），本技能只产出内部评估。
- 不设计缓解方案本身——它只说明「需要缓解什么」，具体修复由工程团队设计。
- 跨司法辖区时需谨慎：本评估默认配置中指定的辖区范围；GDPR、美国各州消费者隐私法、行业专法（HIPAA/GLBA/COPPA/FERPA 等）的评估触发条件与合法性基础差异巨大，若控制者、处理活动或数据主体落在不同辖区，结论可能不再适用。
步骤
- 加载公司 PIA 风格：从团队配置（house style）读取——本地触发条件、从样板 PIA 提炼的结构模板、惯常深度、由谁签批。目标是让产出看起来像本团队其他 PIA，而非通用模板。
- 判断是否真的需要 PIA（Step 0）：先看公司触发条件；再研究各适用法域当前生效的强制评估触发门槛（GDPR/UK GDPR 的 DPIA 触发、CCPA/CPRA 的风险评估触发、其他州法及行业专法），引用控制性法条/法规/监管指引并核验时效。若都未触发，输出一段「不需要 PIA」的归档说明备查。
- 加载本议题既有上下文：扫描输出目录中同一活动的既往
use-case-triage、pia-generation、dpa-review产物。若有，在 PIA 中引用并对账（沿用了什么、改了什么、为什么）；上游严重度作为下限继承——上游评为高风险的活动不能在 PIA 里无理由降为低风险。若无，明确写「冷启动，输出目录无既往记录」。 - 需求访谈：按下方四组问题向产品团队取数，对话式即可，不是发表单。可从 PRD 提取。
- 撰写 PIA：用样板结构（无则用默认模板），加上工作产物抬头，含隐私政策一致性核查。
- 输出：给出条件清单 + 具名责任人，路由至签批流程，并以下一步决策树收尾。
指令
访谈四组问题（取数后才动笔）：
- 是什么、为什么：功能/变更是什么？解决用户什么问题？触及哪些个人数据——「用户数据」不是答案，要具体到字段；是新采集还是复用已有数据；处理方式是存储/分析/共享/自动化决策？
- 合法性基础 / 法域专项：对每个适用法域研究当前生效框架并引用一手来源。需识别合法性基础的法域（GDPR/UK GDPR），为每个目的指明基础（合同/合法利益/同意/法律义务/重大利益/公共任务）；规制披露的法域（CCPA/CPRA 等），核查是否构成「出售/共享」等受规制披露——第三方广告是高频陷阱；行业专法的专项基础或披露规则。核验时效，不确定即标记。
- 谁、在哪：公司内部谁能看（工程/客服/分析）？是否有第三方/供应商/分析商？存储在哪个区域、新基建还是现有？保留多久、有无删除排期？
- 可能出什么事：泄露后对个人的伤害？是否可能（哪怕无意）被用于歧视？用户会不会觉得意外（"creepy test"，非法律标准但有用）？有无退出（opt-out），应不应该有？
来源不得静默补全：若对配置的法律检索工具查询某法域的 DPIA / 风险评估触发或合法性基础返回结果很少，报告所得并停止，向用户给出选项（拓宽检索 / 换工具 / 改用网络检索并标注 [web search — verify] / 标为未核实并停止），由律师决定是否接受低置信来源。
来源标注：PIA 中每条引用都打标——[Westlaw]、[regulator site] 或检索连接器的 MCP 工具名、[web search — verify]、[model knowledge — verify]、[user provided]。带 verify 的引用伪造风险高，应优先核查，切勿剥除或合并标签。
风险质量标准：风险必须具体且绑定到设计，不要泛泛。控制在 2–5 条真实风险，而非 15 条注水。
| 坏风险 | 为何坏 | 更好 |
|---|---|---|
| "数据泄露" | 放之四海皆适用，等于没说 | "客服可经管理后台访问位置历史且无审计日志——恶意内部人可不被察觉地追踪用户" |
| "不合规 GDPR" | 循环论证——PIA 本就是来评估合规的 | 点名具体条款与缺口 |
| "用户可能不喜欢" | 含糊 | "已退订营销的用户在此流程仍会收到，因为该流程未校验退订标志位" |
隐私政策 diff（每份 PIA 必做）：对照配置中的隐私政策承诺，标出每处漂移，例如政策称「不出售数据」而新功能与广告商共享（可能构成 CCPA 出售）、政策称「账户存续期内保留」而新功能在账户删除后仍留存。每处不匹配都要标记，且其中之一必须在上线前更改。
监管提交闸门：产出内部 PIA 属研究与文档化；向监管/监督机构提交 DPIA（或在问询中自愿披露）才是有后果的行为。提交前若使用者角色为非律师，必须提示其已与律师审阅，并生成一页摘要（法域与监管者、提交理由、识别的风险、缓解后剩余风险、标记的不确定项、提交前要问律师的三个问题）。未获明确同意，不得越过此闸门。
示例
为「位置共享功能」写一份 PIA
为这个新功能做隐私评审，PRD：[文档链接]
输出文档默认结构（无样板时）：
[工作产物抬头]
# 隐私影响评估：[功能/产品名]
**编制人：** [姓名] | **日期：** [日期] | **状态：** 草稿 / 已批准
**产品负责人：** [姓名] | **隐私评审人：** [姓名]
## 执行摘要
[两句话：这是什么、是否可行] **总体风险：** 🟢低 / 🟡中 / 🟠高 / 🔴很高
## 1. 处理描述
What / 数据类别（具体字段）/ 数据主体 / 目的 / 是否新采集
## 2. 合法性基础
| 目的 | 基础 | 备注（LI 附平衡测试摘要；同意附取得方式）|
## 3. 数据流
采集 / 存储（系统、区域、加密）/ 访问（谁、经何控制）/ 共享（第三方、目的、受哪份 DPA 管辖）/ 保留
## 4. 隐私政策一致性
| 政策承诺 | 是否一致 🟢/🟡 | 备注 |
## 5. 风险与缓解
| # | 风险 | 可能性 L/M/H | 影响 L/M/H | 缓解 | 状态 Done/Planned/Gap | 责任人 |
**缓解后剩余风险：**[评估]
## 6. 数据主体权利
| 权利（访问/删除/更正/可携/反对）| 能否行使 | 如何行使 |
## 7. 建议
[已批准 / 附条件批准 / 需变更 / 不批准]
**条件：** - [ ] [上线前必须发生的具体事项]
**签批：** [姓名、日期]
注意事项
- 就近交付检查：输出前确认去向。若用户点名了一个分发对象（频道、分发列表、对手方、"所有人"），询问是否在保密特权圈内；公开频道、全公司列表、对手方/对方律师、供应商、客户（针对工作产物）会丧失保护。圈外时应标记，并提供 (a) 仅供法务的特权版、(b) 面向更广渠道的脱敏版、(c) 两者，切勿静默加上特权抬头再帮其粘贴到抬头无法保护之处。
- 交接清单要可执行：给产品团队的条件不是"提升安全性"，而是"为管理后台位置查询加审计日志，责任人：[工程负责人]，上线前完成"；若发现政策不一致，移交给政策缺口分析流程跟踪。
- 不确定一律标记交律师核验；法定定义与合法性基础常被修订，务必核验时效。
- 以下一步决策树收尾（起草 X / 上报 / 补充事实 / 观望 / 其他），由律师选择，决策树本身即产出。
互见
- first-principles-thinking：拆解新颖处理活动的风险本质、跳出模板思考时配合使用。
- fact-checking：核验所引法条、监管指引的时效与真伪，配合「来源不得静默补全」纪律。
本条采编自 anthropics/claude-for-legal（Apache-2.0）。