一、个人信息保护法核心概念解读
大家好，我是老张。今天咱们聊聊个人信息保护法里最基础、也最绕不开的几个概念。说实话，我刚接触这些条款时，也觉得有点抽象。但做了几年合规项目后，我发现这些概念就像盖房子的地基——地基没打牢，后面全是坑。
这一节，我带你逐个拆解：个人信息与敏感个人信息的界定、告知同意规则、最小必要原则，还有影响评估要求。每个点我都会结合项目里的真实案例来讲。
1.1 个人信息 vs 敏感个人信息：边界在哪？
先问个问题：用户的手机号算个人信息吗？当然算。那用户的精确位置呢？也算，但性质不一样。
根据《个人信息保护法》，个人信息是指以电子或者其他方式记录的与已识别或者可识别的自然人有关的各种信息。说白了，只要这条信息能关联到某个具体的人，就算。
而敏感个人信息，是指一旦泄露或者非法使用，容易导致自然人的人格尊严受到侵害或者人身、财产安全受到危害的个人信息。包括生物识别、宗教信仰、特定身份、医疗健康、金融账户、行踪轨迹等，以及不满十四周岁未成年人的个人信息。
核心区别：敏感个人信息需要「单独同意」，普通个人信息「一般同意」即可。但别以为普通个人信息就能随便收——后面还有最小必要原则等着你。
我在项目中遇到过一件事：有个社交App想收集用户的通讯录，用来推荐好友。产品经理觉得通讯录不算敏感信息，直接弹了个通用授权框。结果呢？被监管点名了。为什么？因为通讯录里包含第三方的个人信息，你收集它，得获得通讯录里每个人的同意——这在实际操作中几乎不可能。最后我们只能改成「用户手动上传联系人」的方案。
| 信息类型 | 典型示例 | 同意要求 | 典型场景 |
|---|---|---|---|
| 一般个人信息 | 姓名、手机号、邮箱 | 一般同意 | 注册、登录 |
| 敏感个人信息 | 人脸、指纹、位置、病历 | 单独同意 | 支付验证、健康监测 |
| 未成年人信息 | 14岁以下儿童信息 | 监护人同意 | 儿童模式、教育App |
我的习惯：在代码层面，我会把敏感信息的采集入口单独封装成一个组件。这样每次调用时，系统强制弹出单独的同意对话框，而不是混在通用授权里。代码结构清晰，审计也方便。
1.2 告知同意规则：别让用户「被同意」
告知同意，说白了就是「你告诉用户你要干什么，用户说行」。但现实中很多App的做法是：弹一个几百字的隐私政策，用户点「同意」才能用。这叫告知吗？这叫绑架。
法律要求的是「显著方式」告知。什么叫显著？我个人的理解是：
- 弹窗不能太小，字体不能太小
- 不能藏在二级菜单里
- 不能默认勾选
- 不能通过「用户继续使用」来推定同意
我曾经帮一个电商App做合规改造。他们原来的做法是：用户注册时弹一个隐私政策，里面包含了20多项数据收集说明。用户根本不会看完，直接点同意。后来我们改成「分步告知」——注册时只告知收集手机号和昵称，用到位置时再单独弹窗告知。转化率反而提升了，因为用户觉得这个App「透明」。
注意：「同意」必须是自由的。如果用户不同意就不能用App，那这个同意就不算「自由给予」。所以现在很多App提供「仅浏览模式」——不收集任何个人信息，也能看内容。
1.3 最小必要原则：够用就行，别贪多
这个原则我特别喜欢，因为它很「工程师思维」——只拿你需要的，不多拿一分。
最小必要原则包含三层意思：
- 目的相关：收集的信息必须直接服务于产品功能
- 最小范围：只收集实现目的所必需的最少信息
- 最短时间：信息保留时间不得长于实现目的所需的时间
举个例子：一个手电筒App，它需要收集你的位置吗？不需要。它需要读取你的通讯录吗？更不需要。但现实中真有这样的App——我见过一个手电筒App申请了20多项权限。你说它想干嘛？
嗯，这里要注意：「必要」不是由产品经理说了算，而是由功能逻辑决定。比如一个地图App，位置信息是必要的；但一个计算器App，位置信息就不是必要的。
避坑指南：我曾经遇到一个项目，开发同学为了方便，把用户的所有数据都存到了同一个数据库表里，包括手机号、位置、浏览记录。结果用户要求删除某条数据时，我们不得不全表扫描。后来我强制要求：每类数据独立存储，且设置自动过期策略。这样既符合最小必要原则，也方便数据清理。
1.4 影响评估要求：事前想清楚，事后不慌张
个人信息保护影响评估，听起来很官方。说白了就是：在做一个新功能或新产品之前，先坐下来想清楚——这个功能会收集哪些个人信息？有没有风险？怎么防范？
法律要求，以下情形必须做影响评估：
- 处理敏感个人信息
- 利用个人信息进行自动化决策（比如大数据杀熟）
- 委托处理个人信息
- 向境外提供个人信息
- 其他对个人权益有重大影响的情形
我在团队里推行过一个做法：每次新功能上线前，产品经理必须填写一份《个人信息影响评估表》，内容包括：
| 评估项 | 内容示例 |
|---|---|
| 处理目的 | 用于用户画像，推荐个性化内容 |
| 信息类型 | 浏览记录、点击行为、停留时长 |
| 是否涉及敏感信息 | 否 |
| 风险分析 | 可能推断出用户健康状况、政治倾向 |
| 风险控制措施 | 数据脱敏、差分隐私、限制访问权限 |
| 数据保留期限 | 30天后自动匿名化 |
你想想看，如果每个功能上线前都走一遍这个流程，还会出现「偷偷收集用户信息」的情况吗？不会。因为流程本身就把风险暴露出来了。
我的建议：影响评估不是一次性工作。产品迭代了，数据用途变了，都得重新评估。我习惯在代码仓库里放一个「隐私合规检查清单」，每次PR合并前，CI流水线自动触发检查——如果涉及个人信息处理，必须附带评估报告才能合并。
知识体系总览
下面这张图，是我自己梳理的本章核心逻辑。你看一遍，基本就能把四个概念串起来了。
你看这张图，四个概念不是孤立的。先界定信息类型，再告知用户并获得同意，然后按最小必要原则收集，最后做影响评估。这是一个完整的闭环。我在实际项目中，就是按这个顺序来设计合规流程的。
好了，这一节的内容就到这里。记住：合规不是束缚，而是保护——保护用户，也保护你自己。
公众号:蓝海资料掘金营，微信deep3321