二、核心原则解析：合法、正当、必要原则；目的限制原则；数据最小化原则；存储限制原则

好，咱们直接进入正题。这四大原则，说白了就是数据合规的「四根柱子」。我做了这么多年隐私合规，见过太多翻车案例，十有八九都是在这四个点上栽了跟头。今天咱们一个一个掰开揉碎了讲。

2.1 合法、正当、必要原则

这个原则是基础中的基础。我习惯把它叫做「合规三件套」——缺一个都不行。

合法：你得有法律依据。比如用户同意、合同必要、法定义务等。不能「我觉得需要就收集」。
正当：收集方式要光明正大。偷偷摸摸埋点、诱导用户点击「同意」——这些都不正当。
必要：只收「不得不收」的数据。多一个字段都算越界。

我遇到过的一个真实案例：某电商App在注册时要求用户填写「婚姻状况」。产品经理说「为了推荐更精准」。我说：「你卖个衣服，跟人家结没结婚有什么关系？」后来我们砍掉了这个字段，转化率反而提升了3%。

小技巧：每次新增数据采集点，问自己三个问题——

法律依据是什么？
用户知道我在收吗？
不收这个字段，业务还能跑吗？

三个问题只要有一个答不上来，就别收。

2.2 目的限制原则

这个原则理解起来很简单：你当初说好用来干嘛，就只能用来干嘛。

举个例子：用户注册时同意你用手机号发验证码。结果你转头拿这个手机号做营销推送——这就是典型的「目的滥用」。

我见过最离谱的一次：某金融App收集用户的位置信息，隐私政策里写的是「用于推荐附近网点」。结果内部偷偷用这些数据做「用户画像——判断用户是否在竞品网点附近」。嗯，最后被罚了2000万。

警告：目的限制不是「写进隐私政策就完事了」。你得确保——

内部系统权限跟目的绑定
数据流转链路有审计
新用途必须重新获取同意

我曾经帮一家公司做合规审计，发现他们内部有17个系统在「共享」用户数据，但隐私政策里只写了3个用途。这17个系统，每个都是定时炸弹。

2.3 数据最小化原则

说白了就是：能少收就少收，能不收就不收。

很多产品经理有个误区：「数据越多，算法越准」。其实不是。数据多了，噪声也多了，合规风险更是成倍增长。

我给大家一个实用框架——「最小化三问」：

问题	说明	示例
这个字段真的需要吗？	去掉它业务还能跑吗？	注册只需要手机号，不需要性别
能不能用替代方案？	用匿名化/聚合数据代替	用「年龄段」代替「出生日期」
能不能延迟收集？	等到真正需要时再收	支付时才收地址，注册时不用

避坑指南：我曾经接手过一个项目，产品经理坚持要收集用户的「通讯录权限」，理由是「方便用户邀请好友」。我说：「那你改成手动输入手机号邀请不行吗？」他想了想，改了。后来数据合规检查时，这个改动帮我们省了一大笔整改费用。

2.4 存储限制原则

这个原则经常被忽略。很多人只关注「怎么收」，不关注「存多久」。

存储限制的核心就一句话：数据不能无限期保留。你得有个明确的「保质期」。

我建议的做法是：

分类定级：不同数据设不同保留期限。比如日志30天，交易记录5年，生物识别数据用后即删。
自动过期：别靠人工删。系统层面设置自动清理策略。
定期审查：每季度检查一次，有没有「超期服役」的数据。

一个实用模板：我习惯在数据库设计阶段就加上 expire_at 字段。比如：

CREATE TABLE user_logs (
    id INT PRIMARY KEY,
    user_id INT,
    action VARCHAR(255),
    created_at TIMESTAMP,
    expire_at TIMESTAMP  -- 自动过期时间
);

然后写个定时任务，每天扫一遍，把 expire_at < NOW() 的数据清理掉。省心又合规。

注意：存储限制不是「删了就完事」。你得考虑——

备份数据里有没有残留？
日志归档里有没有？
第三方合作方有没有同步删除？

我曾经遇到一个客户，主库数据删得干干净净，结果灾备库里的数据还躺了两年。嗯，最后被监管点名了。

小结一下

这四大原则，其实是一个逻辑链条：

合法正当必要：决定「能不能收」
目的限制：决定「收了用来干嘛」
数据最小化：决定「收多少」
存储限制：决定「存多久」

你想想看，只要把这四个环节卡死了，数据合规的大框架基本就稳了。剩下的就是执行层面的细节问题。

下一章咱们聊聊「数据主体权利响应」——那又是另一个有意思的话题了。