---
name: consent-mechanism-checker
description: >
  同意机制合规审查——检查个人信息处理活动中同意机制的设计与实现
  是否符合PIPL要求。适用情形：用户说"检查我们的同意弹窗"、
  "同意机制是否合规"、"用户授权页面设计"、"撤回同意流程"、
  "是否需要单独同意"、"未成年人同意怎么处理"。
argument-hint: "[同意机制描述 + 数据场景 + 用户群体]"
legal_frame: cn-mainland
last_reviewed: 2026-06
version: 1.0.0
risk_level: high
escalation_triggers:
  - 涉及敏感个人信息处理未取得单独同意
  - 涉及未成年人个人信息处理
  - 同意机制存在"捆绑同意"或"强制同意"设计
  - 用户投诉或监管关注
trigger_phrases:
  - '检查'
  - '数据合规'
  - '个人信息'
  - 'PIPL'
  - '跨境'
---

# /consent-mechanism-checker — China Mainland

## 法律背景与法规框架

PIPL第13条确立了个人信息处理的七类合法性基础，其中"取得个人同意"是适用范围最广的基础。第14条要求同意应当"自愿、明确"，并在充分知情的前提下作出。第15条赋予个人撤回同意的权利，且撤回同意不得影响撤回前已进行的处理。第16条禁止因拒绝同意而拒绝提供产品或服务（非必要场景）。第29条对敏感个人信息提出"单独同意"要求。第31条对未成年人信息需取得其父母或监护人同意。

PIPL实施后，CAC执法实践中"同意机制不合规"是最常见的处罚原因之一。常见违规场景包括：默认勾选同意、隐私政策与用户协议捆绑、撤回同意渠道隐蔽、单独同意与一般同意合并、未成年人识别和同意机制缺失等。《App违法违规收集使用个人信息行为认定方法》和GB/T 35273《个人信息安全规范》对同意机制的实现方式提供了具体指引。

## 工作流程

### 第一步：识别处理场景与合法性基础

确定当前数据处理场景，判断是否需要同意作为合法性基础：

| 场景 | 建议合法性基础 | 是否需要同意 |
|------|---------------|-------------|
| 直接提供服务所需（如账号注册） | 合同必要（第13条第二项） | 不需要（但须告知） |
| 履行法定义务（如税务报送） | 法律义务（第13条第三项） | 不需要 |
| 营销推送 | 同意（第13条第一项） | 必须 |
| 第三方数据共享 | 同意或单独同意 | 通常需要 |
| 敏感信息处理（健康/金融/位置） | 单独同意（第29条） | 必须单独同意 |
| 跨境传输 | 同意+出境路径 | 必须 |

### 第二步：检查同意获取界面

**视觉设计检查清单：**

```
□ 隐私政策/同意弹窗是否在首次使用/首次打开时展示
□ 是否提供了"同意"和"不同意/拒绝"两个明确选项
□ 拒绝的入口是否与同意同等显著（不得默认勾选）
□ 同意是否通过主动勾选或主动点击获取（不得默认同意）
□ 隐私政策文本是否易于访问（字号不小于正文大小）
□ 敏感信息是否单独弹窗/单独弹层获取同意
□ 未成年人模式是否识别并引导监护人同意流程
□ 撤回同意的入口是否在同等显著位置（如设置页面）
```

**常见违规红线：**
- ❌ 默认勾选"我已阅读并同意"
- ❌ 隐私政策与用户协议捆绑（必须同意全部才能使用）
- ❌ "不同意"按钮灰色/不可用/字号极小
- ❌ 拒绝后反复弹窗要求同意（骚扰式设计）
- ❌ 撤回同意找不到入口或需联系客服人工操作

### 第三步：检查同意记录与追溯能力

PIPL要求个人信息处理者对处理活动承担举证责任。同意机制须具备记录和追溯能力：

**同意记录应包含：**
- 用户标识（用户ID或设备ID）
- 同意时间（精确到秒的时间戳）
- 同意的具体内容（版本号/本次同意的项目列表）
- 同意的方式（明确主动操作证据）
- 同意版本历史（每次更新的时间线）

**记录存储要求：**
- 同意记录保存期限：从最后一次处理活动结束起不少于3年
- 同意记录可作为执法检查时的合规证明

### 第四步：检查撤回同意机制

| 检查项 | 合规做法 | 常见违规 |
|--------|---------|---------|
| 撤回渠道 | 设置页面 / 隐私中心 / 功能开关 | 仅能通过客服电话 |
| 撤回便捷度 | 与给予同意同等便捷 | 需拨打客服+邮件+提交表单 |
| 撤回影响告知 | 明确告知撤回后的影响 | 误导用户撤回会无法使用 |
| 撤回后处理 | 停止处理并删除（除非另有合法基础） | 继续处理 |
| 历史数据 | 撤回前已处理的数据不受影响 | 错误地删除所有数据 |

### 第五步：输出合规评估

## 输出模板

```
═══════════════════════════════════════
同意机制合规审查报告
═══════════════════════════════════════
产品/功能：[名称]
检查日期：[日期]
场景类型：[账号注册/营销推送/数据共享/敏感信息/跨境传输]
═══════════════════════════════════════

## 同意机制总评

[通过 / 条件通过 / 不通过 — 具体说明]

## 检查结果明细

### 同意获取界面
- [✅/❌] 首次使用展示同意弹窗
- [✅/❌] 拒绝选项显著
- [✅/❌] 无默认勾选
- [✅/❌] 敏感信息单独同意
- [✅/❌] 未成年人识别机制

### 同意记录
- [✅/❌] 记录用户操作日志
- [✅/❌] 保存同意版本历史
- [✅/❌] 可追溯至具体用户

### 撤回同意
- [✅/❌] 撤回入口显著
- [✅/❌] 撤回便捷度达标
- [✅/❌] 撤回后合规处理

## 需整改项

1. [优先级:高/中/低] [具体问题] — [整改建议]
2. ...

## 升级建议

[如涉及敏感信息同意缺失/监管关注/用户投诉等升级情形]
```

## 升级决策门

以下情况须移交专业律师处理：

- 涉及敏感个人信息处理但未取得单独同意（须立即停止处理）
- 同意机制涉嫌违反未成年人保护规定
- 存在"捆绑同意"或"强制同意"设计导致用户投诉形成规模
- 监管机关已介入或已收到整改通知
- 需要设计全新的同意框架（如从无同意机制切换为合规同意机制）
- 涉及自动驾驶/金融风控/公共安全等特殊场景的同意设计

---
*Greater China Legal — data-compliance consent-mechanism-checker v1.0.0*
*[model] — 基于PIPL第13-31条、GB/T 35273、CAC执法案例框架*