数据保留与删除：怎么做到真的删掉

删除常常不是真的删。本文给出先画数据地图的方法、四种删除做法与彻底程度、删除可验证的三个动作（凭证/抽查/自动化）与三个常见坑。

"删除"常常不是真的删

合规要求"用户撤回同意后删除数据" ✔，但技术上手常犯三类错 ✗：

只删了主表 ✔、派生数据没删 ✔、备份与日志里还在 ✔。

**要做到"真的删掉"，必须先盘点"数据都在哪"** ✔。

列出该用户数据的所有存放位置 ✔：

```

主库（业务表）｜向量库（嵌入向量 ✔）｜缓存（Redis 等 ✔）

日志（访问/错误日志 ✔）｜备份（快照、归档 ✔）｜导出文件（用户下载过的 ✔）

第三方（模型服务商、SaaS 工具 ✔）

```

**向量库与缓存最容易被漏** ✗：嵌入向量"看起来不是原文" ✔，但它能反推出原文语义 ✔。

| 做法 | 说明 | 适用 |

|---|---|---|

| 硬删 | 物理删除记录 ✔ | 主库、向量库（首选 ✔） |

| 假名化 | 删除标识与关联，保留匿名统计 ✔ | 需要保留统计口径时 ✔ |

| 标记删除 + 定期清理 | 先标记，后台任务清理 ✔ | 有性能顾虑时 ✔（必须真跑清理 ✔） |

| 备份淘汰 | 备份无法定点删 → 声明"最长 N 天后随备份淘汰" ✔ | 备份 ✔（必须**如实告知** ✔） |

**关键**：无论用哪种，都要**如实说明** ✗ ✔（"备份中最多保留 30 天" ✔ 比含糊的"会删除"可信 ✔）。

**删除凭证**：记录"何时、删了哪些位置、由谁触发" ✔；

**定期抽查**：随机抽一个已删除用户 ✔，检查各存放位置确实没有 ✔；

**自动化**：删除流程要走**同一个服务** ✔（避免"某个库忘了删" ✔）。

**只删主表** ✗（向量库与缓存仍在 ✔）；

**假名化不彻底** ✗（保留了可关联的 id ✔）；

**只承诺不验证** ✗（没有抽查，出问题时才发现没删干净 ✔）。

1. 先画数据地图 ✔（半天就能有初稿 ✔）；

2. 把删除实现成**一个可调用的服务** ✔（按用户维度触发 ✔）；

3. 加删除凭证与抽查 ✔；

4. 在隐私说明里**如实写明**保留期限与备份策略 ✔。

> 随机抽一个"已删除"的用户 ✔，你能否在**半小时内**证明各存放位置都没有其数据 ✔？

> 不能，说明删除还只是承诺 ✗。