privacy-policy

隐私政策

何时使用

当创始人需要为新产品发布制定隐私政策、针对新的数据实践或功能更新现有政策、拓展至新的司法管辖区（欧盟、加利福尼亚州等），或评估当前的数据处理方式是否已妥善披露时，启用此项。用户询问 GDPR、CCPA、CPRA 或一般数据隐私合规问题时，也启用此项。

所需背景信息

• 来自 startup-context： 产品类型、平台（Web/移动端/API）、目标客户群体、目标市场、商业模式、技术栈。
• 来自用户： 产品名称和 URL、公司法定名称和地址、隐私咨询联系邮箱、收集哪些个人数据及如何收集、哪些第三方服务会处理数据（分析、支付处理商、CRM、AI 提供商）、适用的司法管辖区、产品是否面向未成年人，以及任何现有隐私文档。

工作流程

1. 调研产品——访问产品网站或查看产品说明。识别所有数据收集方式、第三方集成，以及涉及个人数据的主要功能。
2. 梳理数据收集情况——将所有数据分类为：用户直接提供的数据（表单、创建账户）、自动收集的数据（Cookie、设备信息、使用数据、IP 地址）、来自第三方的数据，以及特殊/敏感类别的数据。建立结构化数据清单。
3. 识别适用法律——根据用户所在地区和公司运营地点，确定适用的隐私框架：GDPR、CCPA/CPRA、州隐私法、COPPA、行业特定法规。注明各司法管辖区的具体义务。
4. 构建政策结构——按照下方的 15 节模板组织内容。使用通俗易懂的语言，达到八年级阅读水平。明确说明实际做法——写“您注册时，我们会收集您的电子邮件地址”，而不是“我们可能会处理标识符”。
5. 标记需要法律审核的部分——使用 [需要法律审核] 标记注明需要律师审核的章节，包括法律依据的认定、国际传输机制和特定司法管辖区的权利。
6. 提供实施背景——说明各章节的重要性、公司需要作出的决定，以及适用的合规考量。附上发布前检查清单。
7. 生成合规摘要——另行生成一份文档，包含数据清单表、司法管辖区适用性矩阵、风险标记和实施检查清单。

输出格式

三部分交付内容：

第 1 部分：快速参考摘要

产品详情、收集的数据类型、适用的司法管辖区、用户权利摘要、数据保留概述和联系信息。

第 2 部分：完整政策文档（15 个章节）

1. 序言 -- 说明你是谁、本政策涵盖的内容、生效日期及联系方式。
2. 我们收集的信息 -- 类别：个人信息、使用数据、设备信息、位置、支付信息、通信内容、敏感数据。
3. 我们如何收集信息 -- 方式：用户直接输入、自动追踪、第三方。
4. 我们如何使用信息 -- 用途：提供服务、提供支持、改进服务、分析、营销、安全、遵守法律。
5. 处理信息的法律依据 -- 同意、履行合同、法律义务、重大利益、合法利益（侧重 GDPR）。
6. 数据共享与第三方 -- 服务提供商、合作伙伴、法律机构，具体说明对象和原因。
7. 国际数据传输 -- 跨境传输机制（SCC、充分性决定）、存储位置。
8. 数据保留 -- 明确说明账户数据、日志、已删除内容的保留期限。
9. 用户权利 -- 访问、删除、更正、限制处理、数据可携权、选择退出、投诉流程——按司法管辖区分类说明。
10. Cookie 和追踪 -- 使用的工具、用途、管理选项、同意要求。
11. 安全 -- 加密、访问控制、审计、事件响应、局限性。
12. 儿童隐私 -- 家长同意、年龄门槛、遵守 COPPA／英国《儿童守则》。
13. 联系与权利请求 -- 隐私邮箱、地址、响应时限、DPO 信息。
14. 政策变更 -- 通知期限、通知方式、用户选择退出的选项。
15. 其他条款 -- 数据出售披露、第三方链接免责声明、适用法律、生效日期。

第 3 部分：合规说明

• 标出需要法律审查的章节并说明原因
• 特定司法管辖区的注意事项
• 发布前检查清单（见下文）
• 针对不同产品类型的修改建议

框架与最佳实践

GDPR 核心要求

• 每项处理活动都必须有合法依据（第 6 条）。
• 对高风险处理活动进行数据保护影响评估（第 35 条）。
• 在 72 小时内向监管机构报告数据泄露（第 33 条）。
• 与所有处理方签订数据处理协议（第 28 条）。
• 保障删除权，并明确规定例外情况（第 17 条）。
• 将隐私保护纳入设计并默认启用（第 25 条）。

CCPA/CPRA 核心要求

• 如适用，必须提供“请勿出售或共享我的个人信息”链接。
• 用户有权知情、删除、更正，并选择退出数据出售／共享。
• 数据收集披露需涵盖过去 12 个月。
• 敏感个人信息：有权限制其使用（CPRA 新增）。
• 服务提供商、承包商与第三方之间的区别很重要。

通俗易懂的语言原则

• 使用简短句子，按照适合八年级学生的阅读水平撰写。
• 使用具体示例，而非抽象类别。
• 想表达“会”时，避免使用“可能”。明确说明实际做法。
• 政策必须与产品的实际行为一致——既不要披露过多，也不要披露不足。

发布前检查清单

• 已完成律师审查
• 政策与实际数据处理做法一致
• 用户隐私请求流程便于使用且正常运行
• 已落实技术安全措施
• 已与所有第三方签订数据处理协议
• 已记录每项处理活动的法律依据
• 已实施 Cookie 同意机制（面向欧盟用户）
• 已建立针对政策重大变更的用户通知系统

初创公司的常见陷阱

• 复制其他公司的隐私政策（对方的数据处理做法并不适用于你）。
• 在披露中遗漏分析和广告 SDK（Google Analytics、Mixpanel、Facebook Pixel 均会收集个人数据）。
• 代码库中没有实际处理删除请求的机制。
• 认为 B2B 就没有隐私义务（你仍在处理个人用户数据）。
• 列出实际并未收集的数据类别（披露过多会招致审查）。

相关技能

• terms-of-service -- 起草隐私政策时应一并起草服务条款；两者应相互引用，并使用一致的定义。
• soc2-prep -- SOC 2 隐私信任服务准则与隐私政策中的承诺直接相关。
• security-review -- 隐私政策中描述的安全措施必须符合实际的技术控制措施。

示例

示例 1：面向美国和欧盟推出新的 SaaS 产品

用户：“我们计划下个月推出项目管理 SaaS，用户来自美国和欧洲。我们使用 Stripe、Mixpanel 和 AWS。”

**良好的输出：**包含三部分的交付内容。数据清单表将每类数据与收集方式、用途、法律依据、第三方和保留期限对应起来。管辖区分析指出 GDPR 是否适用，并监测 CCPA 门槛。还会标出风险：需要披露 Mixpanel 对 IP 地址的收集情况并签署 DPA，以及缺少面向欧盟用户的 Cookie 同意机制。

示例 2：新增 AI 功能后更新政策

用户：“我们添加了一个会处理客户消息的 AI 助手。需要更新隐私政策吗？”

**良好的输出：**指出新增的数据处理（由 AI 模型处理消息内容）、新增的第三方（作为子处理方的 AI 提供商）、需要进行新的法律依据分析，以及需要考虑 GDPR 第 22 条关于自动化决策的规定。还会列出需要更新的具体政策章节，并提供草案措辞。

---

**免责声明：**此技能生成的隐私政策草案和合规指导仅用于教育和规划目的，不构成法律建议。在发布最终隐私政策前，务必请获得相关管辖区执业资格的律师进行审查。违反监管要求可能导致高额罚款（根据 GDPR，最高可达全球年收入的 4%）。