GDPR核心原则（下）：准确性、存储限制、完整性与保密性、问责原则
好，我们接着聊剩下的四条原则。说实话，前面三条原则（合法公平透明、目的限制、数据最小化）是地基，那今天要讲的这四条，就是真正让你落地时头疼的地方。
我经常跟团队说一句话：原则背得再熟，不如踩过一个坑来得实在。今天我们就用实战视角，把这四条原则掰开揉碎了讲。
一、准确性原则（Accuracy）
这条原则字面意思很简单：你手里的个人数据，必须是准确的。如果发现不准确，你得及时更新或删除。
但问题来了——什么叫「准确」？
我举个例子。用户三年前填的地址，现在搬家了。你系统里还存着老地址。这算不算不准确？
算。但你要不要每条都去核实？
嗯，这里要注意：GDPR没说你要实时验证每条数据。它要求的是「合理措施」确保准确性。
关键点：
- 数据来源要可靠（比如用户自己填的，比第三方推断的更可信）
- 要有更新机制（比如每年让用户确认一次联系方式）
- 发现错误后，要在合理时间内纠正
我曾经遇到过一个项目，CRM系统里存了十几万条客户数据。一查，30%的电话号码是错的。为什么？因为销售团队为了完成KPI，随便填的。嗯，这就是典型的「源头污染」。
我的建议是：在数据采集入口就做校验。比如手机号格式校验、邮箱格式校验、地址通过地图API反查。别等到数据入库了再清洗，成本高得吓人。
实战技巧：
我习惯在数据表中加一个 last_verified_at 字段。每次用户主动更新数据时，记录时间戳。超过一年的数据，系统自动打标，提醒业务部门去核实。这样既合规，又不会给用户造成骚扰。
二、存储限制原则（Storage Limitation）
这条原则说白了就是：数据不能永久保留。你得有个明确的保存期限，到期就删。
很多公司一听就头大：「我们业务需要历史数据啊！」
我理解。但GDPR没说不能存历史数据，它说的是：保存期限必须与处理目的相匹配。
举个例子：
- 用户注册信息：用户注销账号后，最多保留30天用于处理退款等遗留问题，然后删除
- 交易记录：根据税法要求，保留7年。这是合法目的，没问题
- 日志数据：用于安全审计，保留6个月。超过后匿名化或删除
注意：
别想着「先存着，万一以后有用」。GDPR的监管机构可不会买账。我见过一家公司被罚款，就是因为把用户聊天记录存了8年，理由是「做AI训练用」。但用户当初根本不知道这事。
我个人习惯的做法是：在系统设计阶段就定义好数据生命周期。每个数据表都配一个「保留策略」，用定时任务自动清理。别指望人工去删，人一定会忘。
这里给个简单的策略示例：
# 数据保留策略示例
用户表：
- 活跃用户：保留至账号注销
- 已注销用户：保留30天后物理删除
订单表：
- 保留7年（税法要求）
- 7年后匿名化处理（去掉用户ID，只保留统计信息）
操作日志表：
- 保留6个月
- 6个月后自动归档到冷存储，再保留18个月后删除三、完整性与保密性原则（Integrity and Confidentiality）
这条原则，其实就是我们常说的信息安全。GDPR把它写进了原则层面，可见有多重视。
完整性：数据不能被篡改或破坏。
保密性：数据不能被未授权的人访问。
说白了，就是防篡改、防泄露。
我遇到过最典型的案例：一家创业公司，所有用户数据存在一个公共的AWS S3桶里，权限设置成「公开可读」。结果被爬虫抓了个精光。嗯，这就是保密性没做好。
那具体怎么做？
- 传输加密：所有API必须走HTTPS，别用HTTP
- 存储加密：数据库里的敏感字段（身份证、银行卡号）要加密存储
- 访问控制：最小权限原则，谁需要谁才能看
- 审计日志：谁在什么时间看了什么数据，都要有记录
我的经验：
很多公司只关注「防外部攻击」，却忽略了内部风险。我见过一个案例：运维人员直接用root账号登录数据库，导出了全量用户数据。这其实比外部攻击更常见。
所以我的建议是：内部权限管控比外部防火墙更重要。每个员工只能看到自己工作必需的数据，而且要定期审计权限。
四、问责原则（Accountability）
这条原则是GDPR的「杀手锏」。它说：你不仅要合规，还要能证明你合规。
什么意思？
监管机构来查你，你不能光嘴上说「我们合规了」。你得拿出证据：
- 数据处理活动记录（ROPA）
- 数据保护影响评估（DPIA）
- 用户同意记录
- 数据泄露事件记录
- 员工培训记录
说白了，就是所有合规动作都要留痕。
我曾经帮一家公司做合规审计。他们跟我说「我们肯定合规」。结果我让他们拿出数据处理记录，他们愣了半天：「呃...我们没记。」
嗯，这就是典型的「有合规之心，无合规之实」。
我的建议：
从第一天开始就建立文档体系。别等到被查了再补。我习惯用一套模板，每次上线新功能时，自动生成一份数据处理记录。这样既省事，又不会遗漏。
问责原则还要求你指定数据保护官（DPO）。如果你的核心业务涉及大规模监控或敏感数据处理，DPO是强制要求的。即使不强制，我也建议你设一个。因为出了事，总得有人负责对吧？
小结一下
这四条原则，其实可以浓缩成一句话：数据要准、要删、要安全、要有据可查。
你想想看，如果每条数据你都做到了：
- 来源可靠、及时更新（准确性）
- 到期自动清理（存储限制）
- 加密存储、权限管控（完整性与保密性）
- 所有操作都有记录（问责）
那监管机构来了，你怕什么？
下一章我们开始讲数据主体的权利，那才是真正考验你系统设计能力的地方。到时候见。