隐私政策起草器

问题：手写隐私政策的三大坑

隐私政策不是把模板里的公司名替换掉就能交差。工程团队常见的翻车方式有三种：

• 法规适用判断错误。只看公司注册地，不看用户所在地。一家注册在美国的 SaaS，只要服务欧盟用户，GDPR 就要管。
• 数据流梳理不全。自动收集的 cookie、第三方 OAuth 登录、支付网关的数据处理——漏掉任何一条链路，政策就和实际架构脱节。
• 条款写法不合规。法律依据缺失、cookie 同意粒度不够、数据保留期写成"必要时保留"——这些都会在监管审查或用户投诉时暴露。

工作方式：从业务上下文到合规草案

这个技能把隐私政策起草拆成五个步骤：

1. 收集业务信息。 从业务实体名称、司法管辖区、产品类型、目标用户群和地理覆盖范围入手。关键判断是：适用哪些法规，取决于用户在哪里，而不是公司在哪里注册。

2. 梳理数据收集实践。 把每个类别的个人数据都映射出来：直接输入（表单、注册）、自动收集（cookie、分析工具、设备信息、IP）、第三方来源（OAuth 提供商、数据经纪商）、衍生数据（使用模式、偏好）。每类都要记录收集方式、存储位置、保留期限、是否包含敏感数据。

3. 对照法律框架映射要求。 GDPR 要求每个处理活动都有合法依据；CCPA 要求披露出售/共享实践和退出机制；COPPA 在用户可能低于 13 岁时触发；HIPAA、FERPA、GLBA 等行业规则会叠加额外义务。

4. 逐节起草政策。 必需章节包括：收集的数据及目的、处理的法律依据（针对 EEA/UK 用户）、数据共享与第三方、cookie 与跟踪技术、数据保留、用户权利及行使方式、国际数据传输、儿童隐私、安全措施、政策变更通知。

5. 合规缺口审查。 用监管清单逐项核对：每个处理活动是否有法律依据、所有必要权利是否列出、是否包含隐私联系渠道、cookie 同意机制是否描述完整、数据泄露通知程序是否提及。发现缺口直接标记。

适用边界与注意点

这个技能适合结构相对标准的产品——SaaS、移动应用、有 Web 前端的服务。它不替代律师的正式法律审查，尤其是在涉及合并、收购或破产等复杂场景时。

几个需要特别注意的边界情况：

• 面向儿童或混合年龄受众：COPPA（美国，13 岁以下）和英国 Age Appropriate Design Code 施加严格要求，包括可验证的父母同意。如果产品没有强制年龄门控，政策必须假设儿童用户可能访问。
• 与关联方或广告网络共享数据：CCPA 把这视为"出售"或"共享"个人信息，即使没有金钱交易。政策需要包含 "Do Not Sell or Share" 链接，并响应 Global Privacy Control 信号。
• 欧盟数据跨境传输：Schrems II 裁决后，把欧盟用户数据传到美国，需要援引 EU-US Data Privacy Framework 或 Standard Contractual Clauses。"适当的保障措施"这种模糊表述已经不达标。
• AI/ML 模型训练：如果用户数据被用于训练机器学习模型，必须作为独立的处理目的披露，并有对应的法律依据。GDPR 第 22 条允许用户反对自动化决策。