3. 数据最小化原则：只采集必要数据、数据字段裁剪、数据聚合技术、边缘端预处理
数据最小化，说白了就是「能少采就少采，能早处理就早处理」。
这是隐私设计七原则里最实在的一条。我见过太多项目，一开始觉得「多采点数据总没错」，结果后面隐私合规审查时，光是清理历史数据就花了三个月。嗯，这个坑我踩过。
3.1 只采集必要数据：从源头做减法
很多工程师拿到需求，第一反应是「先把所有传感器数据都读上来再说」。这其实是个坏习惯。
我个人的习惯是：先问三个问题——
- 这个功能真的需要这个数据吗？
- 没有它，功能还能跑吗？
- 能不能用更低精度的数据替代？
举个例子。一个智能温控器，你只需要知道「人在不在房间」就够了。没必要采集精确的GPS坐标。用红外传感器或者简单的蓝牙RSSI判断，效果差不多，但隐私风险小得多。
3.2 数据字段裁剪：别把整张表都传上去
数据字段裁剪，就是只保留真正需要的字段，把多余的扔掉。
我曾经接手过一个智能门锁项目。设备上报的数据包里有20多个字段，包括设备型号、固件版本、WiFi信号强度、电池电量、用户操作时间、操作类型、操作结果……但云端真正用到的只有5个。剩下的字段，说白了就是「顺便传上来，万一以后有用」。
后来我做了裁剪，只保留：
- 设备ID（匿名化后）
- 操作类型（开锁/关锁/异常）
- 时间戳（精确到分钟即可）
- 结果状态（成功/失败）
数据量直接降了70%，而且隐私风险也小了很多。
- 能传ID就不传姓名
- 能传类别就不传精确值
- 能传聚合结果就不传原始数据
- 能传时间范围就不传精确时间
3.3 数据聚合技术：用统计值代替原始值
数据聚合，就是把多个原始数据点合并成一个统计值。这样既保留了业务需要的特征，又抹掉了单个用户的细节。
常见的聚合方式有：
| 聚合类型 | 示例 | 隐私收益 |
|---|---|---|
| 均值/中位数 | 每小时平均温度 | 隐藏单次波动 |
| 计数 | 每小时开门次数 | 不暴露具体时间点 |
| 直方图 | 温度分布区间 | 不暴露精确值 |
| 差分隐私加噪 | 加拉普拉斯噪声后的计数 | 无法反推个体 |
我记得有个项目是做办公楼能耗分析。客户想要知道「每个楼层每小时的平均用电量」。如果直接上报每个插座的电表读数，那每个工位谁在用电脑、谁没在，一清二楚。后来我们在边缘端做了聚合：每层楼只上报一个均值，再加一点差分隐私噪声。数据照样能用，但隐私保护上了好几个台阶。
3.4 边缘端预处理：数据不出门，隐私自然好
边缘端预处理，就是在设备本地把数据处理完，只把结果传到云端。数据不出设备，隐私风险自然就小了。
常见的边缘端预处理方式：
- 特征提取：从原始音频中提取关键词，不上传录音文件
- 本地推理：在MCU上跑轻量级模型，只上传推理结果
- 数据过滤：只上传异常事件，正常数据本地丢弃
- 数据脱敏：在本地完成匿名化、加噪、裁剪后再上传
我做过一个智能音箱项目。一开始方案是把所有语音片段上传到云端做语音识别。后来改成在设备端用一个小型关键词检测模型，只识别「唤醒词」和「指令词」，其他语音数据直接丢弃。上传的数据量从每分钟几百KB降到了几十字节。用户隐私保护好了，带宽成本也降了。
3.5 知识体系总览
下面这张图把数据最小化的核心逻辑串起来了。从源头采集到最终上报，每一步都在做减法。
3.6 实战避坑指南
最后分享几个我踩过的坑：
- 别信「以后可能有用」——我曾经因为这句话多采了半年数据，最后全删了。数据字段能砍就砍，别犹豫。
- 聚合粒度要小心——聚合窗口太短，等于没聚合。我建议至少1小时起步，敏感场景建议24小时。
- 边缘端预处理不是万能的——如果模型本身有隐私泄露风险（比如成员推断攻击），光靠边缘端不够。还得配合差分隐私。
- 别忘了日志——很多人只关注业务数据，忘了日志里也可能包含敏感信息。设备日志也要做裁剪和脱敏。