"删除"常常不是真的删
合规要求"用户撤回同意后删除数据" ✔，但技术上手常犯三类错 ✗：
只删了主表 ✔、派生数据没删 ✔、备份与日志里还在 ✔。
要做到"真的删掉"，必须先盘点"数据都在哪" ✔。
一、先做数据地图（Data Map）
列出该用户数据的所有存放位置 ✔：
主库（业务表）｜ 向量库（嵌入向量 ✔）｜ 缓存（Redis 等 ✔）
日志（访问/错误日志 ✔）｜ 备份（快照、归档 ✔）｜ 导出文件（用户下载过的 ✔）
第三方（模型服务商、SaaS 工具 ✔）
向量库与缓存最容易被漏 ✗：嵌入向量"看起来不是原文" ✔，但它能反推出原文语义 ✔。
二、删除的四种做法（按彻底程度）
| 做法 | 说明 | 适用 |
|---|---|---|
| 硬删 | 物理删除记录 ✔ | 主库、向量库（首选 ✔） |
| 假名化 | 删除标识与关联，保留匿名统计 ✔ | 需要保留统计口径时 ✔ |
| 标记删除 + 定期清理 | 先标记，后台任务清理 ✔ | 有性能顾虑时 ✔（必须真跑清理 ✔） |
| 备份淘汰 | 备份无法定点删 → 声明"最长 N 天后随备份淘汰" ✔ | 备份 ✔（必须如实告知 ✔） |
关键：无论用哪种，都要如实说明 ✗ ✔（"备份中最多保留 30 天" ✔ 比含糊的"会删除"可信 ✔）。
三、删除要可验证
- 删除凭证：记录"何时、删了哪些位置、由谁触发" ✔；
- 定期抽查：随机抽一个已删除用户 ✔，检查各存放位置确实没有 ✔；
- 自动化：删除流程要走同一个服务 ✔（避免"某个库忘了删" ✔）。
四、三个常见坑
- 只删主表 ✗（向量库与缓存仍在 ✔）；
- 假名化不彻底 ✗（保留了可关联的 id ✔）；
- 只承诺不验证 ✗（没有抽查，出问题时才发现没删干净 ✔）。
五、落地顺序
- 先画数据地图 ✔（半天就能有初稿 ✔）；
- 把删除实现成一个可调用的服务 ✔（按用户维度触发 ✔）；
- 加删除凭证与抽查 ✔；
- 在隐私说明里如实写明保留期限与备份策略 ✔。
一条判据
随机抽一个"已删除"的用户 ✔，你能否在半小时内证明各存放位置都没有其数据 ✔？
不能，说明删除还只是承诺 ✗。