创新方案
需要为数字产品起草或更新隐私政策并覆盖数据收集、司法辖区与…
为数字产品或服务起草可发布的隐私政策,并整理数据类型、适用法律、用户权利及需法律审查的条款。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 49/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
需要为数字产品起草或更新隐私政策并覆盖数通用
解决思路
- 以数据隐私与合规专家角色,为数字产品或服务起草全面、清晰、合规的隐私政策。
- 明确政策目的:覆盖处理的数据类型、适用司法辖区,并清晰标记需要法律审查的条款;提供通俗解释以保障可访问性和透明度。
- 加入免责声明:内容仅供信息参考,不构成法律建议;发布前必须由专注数据隐私法的合格律师审查最终政策。
- 说明隐私政策是有法律约束力的文件,会确立公司责任和用户权利,专业法律审查必不可少。
- 收集 $PRODUCT_NAME:产品或服务名称。
- 收集 $PRODUCT_URL:产品 URL 或描述,可选;如果提供则进行调研。
- 收集 $COMPANY_NAME:公司的法定名称。
- 收集 $COMPANY_ADDRESS:公司总部或注册地址。
- 收集 $CONTACT_EMAIL:隐私咨询邮箱,例如 privacy@company.com。
- 收集 $INFORMATION_TYPES:收集的数据类型,例如 names、emails、usage behavior、location data、payment information、device identifiers。
- 收集 $JURISDICTION:适用司法辖区,例如 United States、European Union (GDPR)、California (CCPA)。
- 步骤 1:如果提供 $PRODUCT_URL,访问产品网站。
- 步骤 1:识别网站收集哪些数据,包括表单、跟踪、登录、支付。
- 步骤 1:记录第三方集成,包括 analytics、payment processors、SDKs。
- 步骤 1:理解产品主要功能和用例。
- 步骤 2:梳理直接收集的数据,即用户输入的内容,如姓名、邮箱、偏好。
- 步骤 2:梳理自动收集的数据,如 IP 地址、使用行为、设备信息、cookies。
- 步骤 2:梳理第三方数据,即来自合作伙伴、集成或服务提供商的数据。
- 步骤 2:判断特殊类别数据,如健康数据、财务数据、儿童数据、生物识别数据。
- 步骤 3:识别 GDPR 是否适用(EU 用户);GDPR 更严格,要求明确同意、数据主体权利、DPA。
- 步骤 3:识别 CCPA/CPRA 是否适用(California);消费者有访问、删除、选择退出等权利。
- 步骤 3:识别其他美国州法,例如 VIPA、TDPSA 等新兴法律。
- 步骤 3:识别行业特定法律,例如 HIPAA(health)、GLBA(finance)、FERPA(education)。
- 步骤 3:判断产品是否服务国际用户。
- 步骤 4:按标准章节结构组织隐私政策。
- 步骤 5:使用通俗语言撰写,避免技术术语,首次使用术语时定义,帮助用户理解收集哪些数据以及为什么。
- 步骤 6:在需要辖区特定语言、特定数据权利或法律条款的部分标记 [⚠️ LEGAL REVIEW REQUIRED]。
- 步骤 7:提供上下文说明,包括每节为何重要、公司必须做哪些决定、合规考虑。
- 撰写 Preamble:简要介绍政策覆盖范围、最后更新时间、用户如何联系提问。
- 撰写第 1 节 Information We Collect:列出个人信息、使用数据、设备信息、位置数据、支付信息、通信内容;对敏感或特殊类别数据标记 [⚠️ LEGAL REVIEW REQUIRED]。
- 撰写第 2 节 How We Collect Information:说明直接收集、自动收集(cookies、analytics、设备传感器)、来自第三方(合作伙伴、服务提供商、data brokers)的方法。
- 撰写第 3 节 How We Use Information:具体列出用途,包括提供服务和客户支持、改进和个性化产品、分析和理解用户行为、营销和推广沟通、安全和欺诈预防、法律合规;对计划用于新用途的其他目的标记 [⚠️ LEGAL REVIEW REQUIRED] 并明确说明。
- 撰写第 4 节 Legal Basis for Processing:标记 [⚠️ LEGAL REVIEW REQUIRED],尤其对 GDPR;列出 consent、contract、legal obligation、vital interests、public task、legitimate interests。
- 撰写第 5 节 Data Sharing and Third Parties:说明谁可访问数据,包括服务提供商(hosting、analytics、email、payments)、业务伙伴、法律当局;对第三方所在位置标记 [⚠️ LEGAL REVIEW REQUIRED],尤其在美国用户辖区之外时。
- 撰写第 6 节 International Data Transfer:如适用,标记 [⚠️ LEGAL REVIEW REQUIRED];说明跨境传输方式、使用的机制(Standard Contractual Clauses、adequacy decisions、用户同意)、数据存储和处理地点。
- 撰写第 7 节 Data Retention:写明账户数据在账户活跃期间保留及之后 X months/years、使用日志保留 X months、删除内容在永久删除前保留 Y days;标记 [⚠️ LEGAL REVIEW REQUIRED] 并保持具体不模糊,因为许多法规要求如此。
- 撰写第 8 节 User Rights:标记 [⚠️ LEGAL REVIEW REQUIRED],按辖区列出访问权、删除权/被遗忘权、更正权、限制处理权、数据可携带权、选择退出权、向数据保护机构投诉权,并说明用户如何行使这些权利(联系信息和流程)。
- 撰写第 9 节 Cookies and Tracking:标记 [⚠️ LEGAL REVIEW REQUIRED],说明使用哪些 cookies 和跟踪工具、各自用途(功能、分析、营销)、如何管理/禁用 cookies、是否需要明确同意(GDPR 对非必要 cookies 要求明确同意)。
- 撰写第 10 节 Security:说明保护数据的措施,包括传输中和静态加密、访问控制和认证、定期安全审计、事件响应程序,以及没有系统 100% 安全的局限性。
- 撰写第 11 节 Children's Privacy:若产品服务 13 岁以下用户,标记 [⚠️ LEGAL REVIEW REQUIRED];说明父母同意机制、年龄门或验证、遵守 COPPA(US)、UK Children's Code 及类似法律。
- 撰写第 12 节 Contact and Rights:提供隐私联系邮箱、邮寄地址、请求响应时间、Data Protection Officer(如需要)。
- 撰写第 13 节 Policy Changes:说明如何通知变更,包括通知期(例如 30 days)、通知方式(email、in-app、website)、重大变更时用户选择退出的能力。
- 撰写第 14 节 Additional Provisions:说明是否出售/分享数据(若不出售则明确声明)、第三方链接免责、管辖法律、生效日期。
- 内容准则:具体化,不要写“we use your data for product improvement”,而应写例如分析使用模式以识别用户觉得困惑的功能并优先改进这些功能。
- 内容准则:使用通俗语言,面向普通受众而非律师,用简单术语解释收集哪些数据以及为什么。
- 内容准则:保持透明,如实说明所有数据收集,包括 analytics、第三方和用途。
- 内容准则:说明用户控制,解释用户如何访问、删除或选择退出数据处理。
- 内容准则:与实践一致,政策必须匹配产品实际行为;如果不匹配,修改产品或政策。
- 内容准则:使用 $INFORMATION_TYPES 使政策贴合实际数据收集。
- 输出第 1 部分 Summary:快速参考产品名称和目的、收集的数据类型、覆盖的辖区、关键用户权利、保留期限、联系信息。
- 输出第 2 部分 Full Privacy Policy Document:完整、可发布的隐私政策。
- 输出第 3 部分 Customization and Compliance Notes:提供标记需法律审查的章节、辖区特定考虑(GDPR、CCPA 等)、合规清单、基于产品类型的常见修改、下一步(法律审查、实施、用户沟通)。
- 合规提醒:若服务 EU 用户,按 GDPR 要求明确同意、清晰权利、与处理者签 DPA、对高风险处理做 DPIA。
- 合规提醒:若服务 California 用户,按 CCPA/CPRA 要求访问、删除、选择退出权利;详细披露;行使权利不受歧视。
- 合规提醒:确保透明度,用户必须理解收集什么数据、如何使用、谁可访问。
- 合规提醒:保持准确性,数据实践变化时更新政策。
- 合规提醒:注意执法风险,隐私违规可能导致罚款、用户诉讼和声誉损害。
- 合规提醒:发布前由所在辖区的数据隐私律师审查政策。
- 发布前检查:由数据隐私律师审查政策。
- 发布前检查:确保政策匹配实际数据收集和使用。
- 发布前检查:让用户容易提出隐私请求,提供可访问联系信息和快速响应。
- 发布前检查:实施政策中提到的技术措施,例如加密、访问控制等。
- 发布前检查:建立处理数据主体权利请求的系统,例如访问、删除等。
- 发布前检查:记录每种处理类型的 legal basis。
- 发布前检查:与所有第三方处理者签 Data Processing Agreement(DPA)。
- 发布前检查:重大变更时通知用户;考虑让用户选择退出。
适用边界 · 注意事项
- 不要在没有合格数据隐私律师审查的情况下发布或依赖该政策作为法律建议。
- 产品实际数据处理与政策不一致时不要使用;必须先修改产品或政策。
- 涉及高度监管行业(如医疗、金融、教育、儿童数据)但缺少专项法律/合规审查时,不宜仅依赖通用模板。