4. 用户同意与授权机制设计

同意机制不是一张弹窗，而是一套贯穿采集、存储、使用、共享、删除全生命周期的产品能力。很多团队把“用户点了同意”当作合规终点，结果在监管检查或用户投诉时才发现：同意粒度太粗、撤回入口藏得太深、未成年人没有识别、人脸信息混在总协议里一并勾选。本节从产品实现角度，拆解四类关键设计。

一、同意粒度：从“一揽子授权”到场景化分层

《个人信息保护法》要求处理目的明确、合理，同意应当基于充分知情自愿作出。产品上最直接的做法，是把同意拆成“基础必要”与“可选扩展”两层，再按业务场景细分。

以一款含推荐、定位、通讯录好友、个性化广告的App为例，可设计如下粒度：

• 必要信息：手机号、设备标识，用于账号注册与安全风控，属于提供服务所必需，不勾选则无法使用核心功能；
• 可选场景：位置（附近门店）、通讯录（好友推荐）、相册（头像上传）、个性化广告（广告标识符）；
• 敏感信息：人脸、声纹、指纹、行踪轨迹、医疗健康，需单独弹窗、单独勾选，不与普通可选场景混排。

实现要点是“一场景一开关、一开关一记录”。每个开关对应独立的同意项ID、版本号、时间戳、来源页面。后端建议用一张同意流水表，字段至少包括：用户ID、同意项编码、同意状态、协议版本、采集端（iOS/Android/小程序）、IP与设备指纹、操作时间。这样在用户主张“我没同意过”时，可以回溯到具体版本和入口。

二、撤回路径：与授权同等便捷

法律要求撤回同意的方式应当与给予同意同样便捷。产品上常见错误是：授权在首屏一键完成，撤回却要发邮件、打客服电话。正确做法是在“设置—隐私—授权管理”中提供与授权页对称的开关列表，并保证撤回后即时生效。

撤回不是删除，需要区分三种状态：

1. 停止后续处理：关闭个性化广告后，不再基于该标识做定向投放；
2. 停止采集：关闭位置权限后，不再请求定位；
3. 删除或匿名化：对已采集的敏感信息，按用户请求删除或去标识化。

工程上要处理“撤回的传播”。例如用户关闭通讯录授权，除了前端不再上传，还要通知推荐服务清空已导入的好友关系缓存，并触发下游数据清理任务。建议为每个同意项定义一张“撤回影响清单”，明确需要通知哪些服务、清理哪些表、是否保留审计日志。

三、未成年人保护：识别、分层、监护人同意

未成年人保护的关键是先“识别”，再“分层”。产品可通过注册年龄、实名认证、支付行为、使用时段等信号判断用户是否可能为未成年人。对不满十四周岁的儿童，应取得监护人同意，并制定专门的儿童个人信息处理规则。

产品实现上通常分三步：

• 年龄门：注册时要求填写出生日期，低于阈值进入儿童模式；
• 监护人验证：通过短信、人脸或支付验证等方式确认监护人身份，并记录同意凭证；
• 儿童模式限制：关闭个性化推荐、限制陌生人私信、默认不采集精确位置、限制夜间使用时长。

需要注意，年龄门本身不能成为“诱导绕过”的摆设。若用户修改年龄，应重新触发同意流程；对已进入儿童模式的账号，不应通过简单二次点击就退出。

四、生物识别信息：单独同意与本地优先

人脸、指纹、声纹、虹膜属于敏感个人信息，处理需具有特定目的和充分必要性，并取得单独同意。单独同意意味着不能与其他授权捆绑，必须用独立弹窗、独立勾选框、独立说明文字，明确告知处理目的、方式、保存期限和必要性。

以人脸识别登录为例，合规的产品实现通常遵循“本地优先、最小上传”原则：

• 在设备安全区完成人脸特征提取与比对，原始图像不出设备；
• 若必须上传，仅上传加密后的特征模板，并单独告知保存期限；
• 提供“不使用人脸，改用密码/短信”的替代路径，避免强制；
• 撤回时，同步删除本地模板与服务端模板，并给出删除完成提示。

下面这张图把四类机制放在同一条用户旅程上，展示从触发、授权、记录到撤回与清理的关键节点，便于对照产品实现位置。

五、把四类机制落到同一张“同意矩阵”

产品落地时，建议维护一张同意矩阵，把每个数据项与处理目的、是否敏感、是否必需、授权入口、撤回入口、保存期限、下游系统对应起来。下面给出一个可直接参考的示例结构（字段可按业务增删）：

这张矩阵的价值在于：它把“同意粒度、撤回路径、未成年人保护、生物识别单独同意”从抽象原则变成了可分配、可测试、可审计的工程对象。每个字段都能对应到具体的页面、接口和清理任务，避免合规要求停留在文档层面。

最后，建议在发版前做一次“同意链路走查”：从新用户注册开始，逐项检查每个开关的默认状态、文案是否清晰、拒绝后功能是否可用、撤回后是否真正停止处理、未成年人是否被正确识别、生物识别是否有替代路径。走查结果应形成记录，作为合规审计的组成部分。