4. 收集环节的最小必要与告知同意
敏感个人信息的收集环节，是整个处理链条中风险最集中的一段。一旦在收集时超范围、缺告知、错授权，后续的存储、使用、共享再规范也难以补救。本节围绕三个核心问题展开：合法性基础怎么选、告知同意机制怎么设计、最小必要原则怎么落地，并给出一套可直接用于收集场景的合规评估与同意界面优化方法。
一、先定合法性基础，再谈同意
《个人信息保护法》第十三条给出了七类合法性基础，敏感个人信息还叠加第二十九条的"单独同意"要求。实务中最常见的误区是：把所有收集场景都默认走"同意"这一条路，结果既增加了用户负担，又掩盖了本可以依据其他基础处理的场景。
判断顺序应当是：先看是否属于履行法定义务或法定职责（如反洗钱身份核验、劳动人事管理中的必要信息），再看是否属于订立、履行合同所必需（如支付所需的银行卡信息），最后才考虑以同意作为基础。只有在没有其他基础可用时，同意才是唯一路径。这个判断顺序直接决定了后续告知文本的写法与同意界面的形态。
需要特别注意的是，敏感个人信息一旦选择"同意"作为基础，就必须是单独同意——不能与其他授权打包在一个勾选框里，也不能用"继续使用即视为同意"的默示方式替代。
二、最小必要原则的落地方法
最小必要不是一句口号，它需要落到字段级别。可操作的做法是建立"字段—目的—必要性"三列对照表，对每一个拟收集字段追问三个问题：
- 目的关联性：该字段是否直接服务于已声明的具体目的？例如"人脸识别门禁"需要人脸特征，但不需要同时收集身份证号。
- 不可替代性：是否存在侵入性更低的替代方案？例如能用"手机号+验证码"完成身份确认时，就不应强制收集身份证影像。
- 最小范围：字段的精度、粒度、保存时长是否已压到满足目的的最低限度？例如仅需判断"是否成年"，就不应收集完整出生日期。
下表是一个示例性的字段必要性评估表，用于演示评估过程（表中数据为教学示例，非实测结果）：
| 字段 | 收集目的 | 必要性判断 | 结论 |
|---|---|---|---|
| 人脸特征 | 门禁身份核验 | 直接服务目的，无更低侵入替代 | 保留，单独同意 |
| 身份证号 | 门禁身份核验 | 与人脸核验重复，非必需 | 删除 |
| 完整出生日期 | 判断是否成年 | 仅需年龄区间，精度过高 | 改为"是否满18岁" |
| 手机号 | 异常告警通知 | 与门禁目的弱相关 | 改为可选 |
评估完成后，字段清单应固化为收集表单的"白名单"，任何新增字段都必须重新走一遍上述三问，避免开发过程中"顺手多收一个字段"。
三、告知同意机制的设计要点
告知的核心是"让用户在做出同意动作之前，真实理解收集了什么、为什么收、怎么用、存多久、给谁"。实践中常见的失败模式是：告知文本藏在二级页面、用词晦涩、同意按钮与拒绝按钮视觉权重严重失衡。
同意界面优化应遵循四条原则：分层告知（首屏给要点，展开给全文）、单独同意（敏感项独立勾选，不与通用条款捆绑）、对称选择（同意与拒绝按钮同等可见、同等易点）、可撤回（提供与授权同等便捷的撤回入口）。
四、收集场景合规评估与同意界面优化
把上述内容串成一条可执行的评估路径：先识别场景与合法性基础，再逐字段做必要性判断，然后检查告知文本与同意交互是否满足单独、对称、可撤回，最后形成整改项。下面的信号链图展示了从"收集请求"到"合规放行或拦截"的判断流向，其中任一环节不通过都会阻断收集动作。
把这张判断链落到具体操作上，可以形成一份收集场景合规评估清单，逐项打勾后再上线：
- 该场景的合法性基础是哪一条？是否已排除"默认走同意"的惯性？
- 拟收集字段是否逐一通过了关联性、不可替代性、最小范围三问？
- 敏感个人信息是否实现了单独同意，而非打包勾选？
- 告知文本是否在同意动作之前可见，且说明了目的、方式、范围、保存期限？
- 拒绝同意后，是否仍能使用不依赖该信息的基础功能？
- 撤回同意的路径是否与授权路径同样便捷？
最后要强调的是，最小必要与告知同意不是两次独立动作，而是同一套收集设计的两个侧面：字段清单决定了告知什么，合法性基础决定了同意的形态，而同意界面的交互质量决定了用户是否真正知情。三者对齐，收集环节的合规才算真正落地。