先判断业务在哪里、对谁、做什么

隐私合规常被压缩成上线前生成一份 Privacy Policy，再安装一个 Cookie 弹窗。文档可以说明业务怎样处理数据，却不能替代码、数据库、第三方工具和日常操作改变。页面说只收邮箱，产品却同时记录设备、会话、点击、录屏和广告标识；政策写账号删除，客服却无法从分析平台、邮件工具和备份中找到相关数据，这些差距才是实际风险。

一人公司也可以从可维护的系统开始：先画出数据地图，为每项处理活动确定目的、适用规则、角色、权限、保留与删除，再让隐私说明、Cookie 设置、供应商合同和产品功能与地图一致。以后增加字段、SDK、AI 模型、营销渠道或用户地区时，更新同一套记录。^[1][2]

数据规则的适用范围不能只按公司注册地或用户国籍判断。欧盟委员会当前面向企业的说明将 GDPR 的常见适用情形概括为：企业在欧盟设立机构并在其活动中处理个人数据，或者欧盟以外的企业向欧盟境内个人提供商品或服务，或监测其在欧盟境内的行为。偶然有一名欧洲游客访问网站，与长期用欧元定价、当地语言、广告和行为追踪面向欧盟市场，不应写成同一种事实。^[3]

美国没有一部覆盖全部行业与州的统一综合隐私法。以加州为例，CCPA 是否适用要结合营利属性、是否在加州经营、是否决定处理目的和方式，以及当前收入、处理规模或数据交易等法定条件判断；相关门槛会调整。受约束企业还要处理知情、删除、更正、退出出售或共享、限制敏感个人信息使用和不受歧视等权利。^[4]

中国《个人信息保护法》和《网络数据安全管理条例》也包含特定境外适用情形。中国境内团队把客户、员工或产品用户数据传给境外公司、云服务或 AI 模型时，还要检查个人信息出境路径。数据数量、敏感程度、主体身份、处理目的和当前规则会影响是否涉及安全评估、标准合同、认证或其他条件。^[5]

因此，第一张表不宜叫「GDPR 清单」，可以叫「法域与活动清单」。至少记录：

• 公司、分支机构、团队和数据管理人员在哪里；
• 产品主动面向哪些国家与地区，使用什么语言、币种和渠道；
• 用户、客户联系人、员工、承包商和潜在客户分别在哪里；
• 是否做广告、再营销、会话录屏、画像、定位或自动化决策；
• 是否处理儿童、健康、财务、身份、生物识别、精确位置等高风险数据；
• 数据从哪里进入，存在哪个地区，又被哪些供应商和人员访问；
• 用户如何购买、签约、撤回选择、请求访问或删除。

这张表用于筛选需要进一步确认的法律，不负责用一套规则覆盖全球。产品进入新地区、开始当地投放、增加本地人员或处理新的敏感数据时，都应重新评估。

数据地图从一次真实流程画起

小团队不必先盘点数据库的每一列。可以从一名用户完成一次任务开始，沿着界面和系统逐步追踪。

一个订阅制网站的常见路径包括：

1. 访客打开页面，CDN、服务器和安全服务形成 IP、请求、设备与日志；
2. Cookie、Local Storage、像素或脚本记录同意状态、来源和行为；
3. 用户注册，身份服务处理邮箱、验证码、密码凭据或第三方登录标识；
4. Onboarding 收集角色、经验、学习偏好和渠道来源；
5. 产品记录创建内容、上传文件、搜索、点击、错误和关键事件；
6. 分析或 Replay 工具接收页面、事件、热图和会话信息；
7. 支付服务商处理账单、支付工具、地址、税务和风控数据；
8. 邮件、客服、社群和访谈工具保存沟通、反馈和支持记录；
9. AI 服务接收 Prompt、附件和产品上下文，返回输出并生成运行日志；
10. 数据进入 Dashboard、导出表格、备份、告警和内部协作工具。

相关案例中的网站实践会用 Google Analytics、Plausible、Clarity 或 Hotjar 查看流量、事件、热图和会话，用支付、客服与邮件工具承接交易和支持，也会把 Onboarding 字段用于渠道判断。^[6][7] 这些动作有明确的增长价值，也意味着访问、录屏、反馈和自动化工具都要进入数据地图，不能只登记主数据库。

为每项处理活动记录以下字段：

一条记录应对应具体目的。例如「产品分析」仍然过宽，可以继续拆成核心漏斗计数、错误诊断、会话录屏和跨站广告归因。不同目的可能需要不同字段、保留期、用户选择和供应商合同。

个人数据不只包括姓名和邮箱

个人数据通常覆盖能够直接或间接关联到自然人的信息。账号标识、IP、Cookie ID、设备标识、精准位置、订单、支持记录和可回到单个会话的事件，都可能属于范围。把姓名换成随机 ID 通常只是 Pseudonymisation；只要团队还能通过其他表或供应商把记录对应到个人，就不能当作已经匿名。

真正匿名的数据需要无法以合理方式重新识别。生成聚合报表之前发生的采集、清洗和聚合仍可能处理个人数据。团队应在地图中同时记录原始数据和派生数据，避免只关注最终 Dashboard。

健康、遗传、生物识别、种族或族裔、政治观点、宗教、工会和性生活等数据在 GDPR 下属于特殊类别，其他法域对敏感个人信息的定义又可能包括政府证件、财务账户、精确地理位置和通信内容。涉及儿童、医疗、金融、身份核验和人员管理时，产品架构与专业审查要提前进行。^[3][4]

公开网页、社交资料和公共记录也可能包含个人数据。公开可见不等于可以无限抓取、合并画像、导入营销系统或批量联系。要继续判断来源规则、合理预期、平台条款、处理目的、营销法规、退出机制和信息准确性。竞品社区监听或批量 DM 自动化尤其需要在人工作出联系决定前完成这一步。^[7]

每个字段都要对应一个目的

GDPR 的数据最小化要求处理与目的相关、必要且适度的数据。较直接的做法，是在设计表单和埋点时逐项提问：去掉这个字段，用户还能否获得核心服务；若能，它为什么必须强制填写；能否在真正需要时再收；能否使用范围更小的替代数据。^[1][3]

某个产品曾用不可跳过的 Onboarding Form 收集角色、无代码经验、学习偏好和获客来源，并据此判断教程渠道的长期价值。^[7] 这个案例说明表单能产生经营信息，但不能证明所有产品都应强制收同样字段。可以将核心服务必需项与研究项分开，让研究字段可选，说明用途，并用产品事件或自愿访谈替代一部分自报信息。

目的还决定后续使用边界。为发送登录验证码收集的邮箱，不应自动进入广告名单；为排查错误保存的技术日志，不应未经评估变成长期用户画像；为人工客服上传的文件，也不应默认用于模型训练。准备新增用途时，需要重新检查兼容性、适用依据、用户合理预期、说明、选择、供应商和保留期。^[1]

合法基础不是一个通用同意框

GDPR 下的处理并非全部依赖同意。欧盟委员会当前企业指南列出的常见基础包括同意、履行合同所必需、法定义务、公共任务、重大利益和合法利益等；特殊类别数据还要满足额外条件。^[3]

处理活动需要逐项选择和记录，不能先收集，再为同一数据随意切换解释：

• 创建账号、提供用户主动请求的核心功能，可能需要评估合同必要；
• 保存发票和税务记录，可能来自法定义务；
• 维护网络安全、预防欺诈或处理部分正常客户关系，可能评估合法利益，并记录必要性、利益和个人权利之间的平衡；
• 可选广告追踪、特定营销或某些敏感数据处理，可能需要有效同意；
• 产品偏好或研究字段没有核心服务必要性时，不宜仅因写入服务条款就视为合同所需。

有效同意应当自由、具体、知情并通过明确行动给出，用户也应能方便撤回。把勾选框预先选中，把广告同意捆绑进无法拒绝的服务，或者拒绝后仍加载相同脚本，都无法由弹窗外观补救。^[1][8]

Privacy Notice 要跟真实系统一起写

对外 Privacy Notice 负责让用户理解业务。内部数据地图负责让团队把说明执行出来。两者应使用同一事实来源，但用途不同。

隐私说明通常需要覆盖：负责处理的主体与联系方式、数据类别与来源、处理目的和依据、接收者、跨境传输、保留期或判断标准、个人权利、投诉方式，以及自动化决策等适用事项。若数据从公开来源、合作伙伴或数据供应商间接获得，也要检查相应告知要求。^[9]

一份很长的页脚政策不能替代收集时的说明。注册、上传、录屏、Newsletter、招聘和敏感权限可以使用分层通知：界面先说明当前动作最重要的信息，再链接完整政策。政策正文不必列出每个数据库字段，但必须与数据地图的类别、目的和供应商保持一致。

模板可以提供结构，不能提供事实。上线前应对照浏览器 Network、移动端 SDK、环境变量、数据库、支付后台、邮件、客服、日志、分析和 AI 配置逐项核验。政策版本、发布日期和重要变更应留档；新增目的或明显改变用户预期时，要评估是否需要重新通知或取得选择。

Cookie 弹窗先从脚本审计开始

Cookie 规则还会受到 ePrivacy、成员国法律和英国 PECR 等制度影响，不能只用 GDPR 的合法基础回答。英国 ICO 当前 Cookie 指南要求向用户清楚说明存储或访问技术的用途，并在适用时取得主动、清楚的同意；严格为用户请求的在线服务所必需的技术可能有例外。像素、Local Storage、指纹、脚本和 App 端设备访问也可能进入范围。^[8]

上线弹窗之前，可以先做一次技术审计：

1. 在全新浏览器和不同页面观察首次加载的 Cookie、Local Storage、请求、像素和 SDK；
2. 记录每项技术的提供者、目的、数据、持续时间和是否连接其他标识；
3. 区分严格必要、安全、偏好、分析、广告与社交功能；
4. 按目标地区的当前规则判断哪些需要事前同意或其他选择；
5. 在需要同意时，确认拒绝前不会加载相关脚本；
6. 让接受、拒绝和按类别选择都清楚可用，并保存选择记录；
7. 提供随时修改或撤回的入口；
8. 每次增加 Tag、SDK、A/B 工具或广告伙伴后重跑测试。

不能默认把 Analytics 写成「必要」。分析工具的配置、数据精细程度、跨站识别、广告用途和当地规则都会影响判断。会话录屏还要屏蔽密码、支付、私聊、敏感表单和用户内容；即使工具提供自动遮罩，也应使用测试账号逐页检查。^[6][7]