📚 课程目录第2章个人数据定义与分类

第二章：个人数据定义与分类

这一章，咱们得把最基础的概念掰扯清楚。个人数据、敏感数据、假名化、匿名化——这些词在GDPR里定义了你的归档策略该怎么做。我早期做项目时，经常见到客户把假名化数据当匿名化处理，结果审计一查就翻车。所以，咱们先厘清这些边界。

GDPR第4条第1款的原文很长，但核心就一句：“与已识别或可识别的自然人相关的任何信息”。你想想看，哪怕是一条IP地址、一个设备ID、一段Cookie，只要能跟你这个人对上号，那就是个人数据。

关键特征：可识别性。识别手段包括直接识别（姓名、照片）和间接识别（住址、职业、行为轨迹）。

我在项目中遇到过一家电商公司，他们把订单号存进归档系统，觉得订单号不包含姓名就没问题。结果审计发现，订单号+时间戳可以反查出具体用户的支付记录——这就踩了“间接识别”的雷。

个人数据里有一类“奇葩”——GDPR第9条专门列出来了：种族或民族出身、政治观点、宗教/哲学信仰、工会成员身份、基因数据、生物特征数据（用于唯一识别）、健康数据、性生活或性取向数据。

说白了，这类数据一旦泄露，对个人尊严和自由的影响是爆炸性的。归档时处理这类数据，必须额外加严管控。

注意：敏感数据的处理原则是“原则上禁止”，除非满足第9条第2款的10项例外。归档场景下，最常见的例外是“数据主体明确同意”或“重大公共利益”。

GDPR第4条第5款定义：假名化是通过处理，使得个人数据在不借助额外信息的情况下，无法关联到特定数据主体。这个额外信息必须被单独保管，并采取技术和组织措施确保不能关联。

举个例子：你把用户ID替换成随机生成的“P12345”，对应的映射表存在另外一台加密服务器上。这就是假名化。

经验之谈：假名化后的数据仍然受GDPR保护。它只是降低了风险，不代表可以随意归档。我曾经帮一个医疗档案系统设计假名化方案，因为映射表权限没控制好，差点被罚——记住，映射表就是“核按钮”。

归档实践中，假名化常用在数据迁移、长期留存场景。它能满足“数据最小化”原则，同时保留数据的可用性。

匿名化指的是处理后的数据无法再通过任何合理方式识别出自然人。关键标准：不可逆。

GDPR的适用对象不包括匿名化数据。这也是为什么很多企业想把数据匿名化后归档保存——因为后续就不用再管GDPR了。但问题在于，真正的匿名化非常难实现。

核心差异：假名化可以反向还原，匿名化不能。只要你保留了任何“可再识别”的线索（哪怕只有0.1%的概率），那就不算匿名化。

我曾经评估过一个日志归档项目，客户把用户IP地址去掉最后8位，觉得这样就匿名了。结果我用一个月的数据做关联分析，仍然能唯一锁定86%的用户——这哪是匿名化，顶多算个弱假名化。

概念	是否受GDPR管辖	能否还原为个人数据	归档适用性
个人数据	是	本身就是	全部条款适用
敏感数据	是（更严）	本身就是	第9条限制
假名化数据	是	可以（借助额外信息）	受保护，但风险降低
匿名化数据	否	不可以	几乎无限制

避坑指南：我曾经在项目里遇到一个团队，他们把数据库字段直接置空就宣布“匿名化完成”。这不是开玩笑——只要你删除方式可逆（比如标记删除而非物理清除），数据依然存在。真正的匿名化需要经过k-匿名、l-多样等验证，不能靠手工删字段。

下面这张图帮大家直观理解这四个概念的关系与法律边界。

拿到一段数据，先问三个问题：
- 这条数据能直接或间接找到一个人吗？ ——个人数据
- 它属于第9条列出的类别吗？ ——敏感数据
- 我们有没有用不可逆的技术消除识别性？ ——只有“是”才叫匿名化
归档前的数据分类检查清单：
- 如果数据包含姓名、身份证、电话、邮箱 → 个人数据
- 如果数据包含医疗诊断、基因序列、指纹模板 → 敏感数据
- 如果数据只保留了哈希值，且哈希值无法与原始数据比对 → 可能匿名化（需验证）
- 如果数据采用了可逆的化，映射表独立存储 → 假名化

我个人的建议：在归档系统的元数据字段里，明确标注每条数据的分类级别。我参与过的一个项目，就因为漏标了敏感数据的标签，导致隔年内部审计时花了两个月重新排查——这笔账，划不来。

一个小技巧：建立“数据分类矩阵”，把业务字段映射到GDPR的分类。比如：“手机号码”→个人数据，“健康状况”→敏感数据，“用户行为日志（已脱敏）”→假名化数据。这个矩阵能帮你的归档团队少走弯路。