4. 个人信息收集环节的合规实务

收集是个人信息全生命周期的起点，也是监管执法最集中的环节。一旦在收集端越界，后续的存储、使用、共享再规范也难以补救。本节围绕四个抓手展开：最小必要原则的落地判断、告知同意的界面与文案设计、收集渠道的合规审查，以及常见违规场景的整改路径。

一、最小必要原则：从"能不能收"到"收多少才够"

《个人信息保护法》第六条确立了最小必要原则：处理个人信息应当具有明确、合理的目的，并限于实现处理目的的最小范围，不得过度收集。实务中，这条原则要拆成三个可判断的问题：有没有该业务功能？该功能是否必须依赖这项信息？收集的频率和精度是否超出功能所需？

以一款"扫码点餐"小程序为例。堂食点餐功能真正需要的是桌号与菜品选择，手机号并非必需；若商家以"会员积分"为由索取手机号，则必须把积分功能与点餐功能解耦，允许用户仅点餐而不授权手机号。再如"附近门店"功能，只需城市级或区级定位即可满足，若强制获取精确到米级的持续定位，就属于精度与频率双重超限。

判断时可用一张"功能—信息—必要性"对照表逐项过筛，把每项信息的收集目的、是否可拒绝、拒绝后的功能降级情况写清楚。凡是"拒绝即不可用"且该信息与核心功能无直接关系的，基本可判定为强制收集。

二、告知同意设计：把"同意"做成真实的选择

告知同意的核心不是"有没有弹窗"，而是用户是否在充分知情的前提下作出自由、明确的表示。设计上要抓住四个要素：告知内容、告知时机、同意方式、撤回机制。

告知内容应逐项列明处理者名称与联系方式、处理目的与方式、信息种类、保存期限，以及向第三方提供的情况。常见错误是把十几项处理活动塞进一份笼统的《隐私政策》，用户点击"同意"即视为全部授权。正确做法是：核心处理活动在隐私政策中完整披露，而对敏感个人信息、向第三方提供、公开披露等场景，单独取得同意。

同意方式上，不得使用"默认勾选""继续使用即视为同意"等捆绑手段。以App首次启动为例，合理的流程是：先展示隐私政策摘要，用户点击"同意"后再进入；对非必要权限（如通讯录、相机）应在具体功能触发时再申请，而不是启动时一次性索要全部权限。撤回机制同样重要——用户应能在设置中一键关闭个性化推荐、撤回第三方共享授权，且撤回后不得降低基础功能的服务质量。

三、收集渠道审查：把住"入口"的每一道缝

收集渠道不止App前端。常见的入口还包括：嵌入的第三方SDK、小程序与公众号、线下纸质表单、客服电话录音、第三方数据采购。每一类渠道的审查重点不同。

SDK审查要建立清单，逐项记录SDK名称、提供方、采集字段、采集时机、是否可关闭。很多违规并非出自自研代码，而是某个统计或广告SDK在后台静默读取设备标识符。审查时应要求提供方出具字段说明，并在测试环境中抓包验证实际传输内容，而不是只看其官网声明。

第三方数据采购必须核验来源合法性。若供应商无法说明数据的最初收集场景与授权依据，采购方同样要承担连带责任。合同中应约定来源合法性保证条款与违约赔偿。

线下表单常被忽视。纸质登记表应在表头注明收集目的、使用范围、保存期限和联系方式，并设置"是否同意用于营销"的独立勾选项，避免把办理业务与营销授权捆绑。

四、常见违规场景与整改路径

结合执法通报，收集端高频问题集中在五类：一是强制授权，拒绝非必要权限即无法使用；二是默认同意与一揽子授权；三是超范围采集，如读取通讯录、短信；四是未提供撤回与注销通道；五是隐私政策晦涩、更新不通知。

整改的基本路径是"盘点—对标—改造—验证—留痕"。先盘点全部收集点，形成字段级清单；再对照最小必要与告知同意要求逐项判定；随后改造界面与代码，把权限申请后置、把同意拆细；改造完成后在真机与弱网环境下验证拒绝路径是否可用；最后把同意记录、版本号、时间戳归档，确保可回溯。

把上述四道闸门固化为上线前的检查项，收集环节的合规风险就能被前置拦截，而不是等到监管通报后再被动补救。