用户数据删除与账号注销

本文属于《从 0 到 1 AI 产品出海知识库》中的「合规、安全与风控」章节。

账号注销不是可选功能，是法律要求。很多出海产品在早期版本中把账号注销藏到设置页的第三层子菜单，甚至干脆不提供——这种做法在 GDPR 覆盖的欧洲市场、CCPA 覆盖的加州市场，以及中国《个人信息保护法》的管辖范围内，都可能带来行政处罚和法律风险。

数据删除和账号注销看似是一个简单的「删数据」操作，实际上涉及法律合规、数据分类、技术实现、用户沟通等多个维度。你需要回答的问题包括：哪些数据必须删除？哪些数据可以保留？保留多久？备份系统中的数据怎么处理？第三方服务中的数据怎么同步删除？用户发起请求后多久必须完成？

本文将从法律要求出发，系统梳理数据删除的实现方法、保留策略、用户沟通流程和技术实现方案，给出可落地的对照表格和检查清单。

一、法律要求：不同市场的删除权规定

账号注销的法律基础是「数据删除权」，不同市场有不同的法规名称和具体要求。

GDPR 第 17 条明确规定了数据主体的「被遗忘权」（Right to be Forgotten）。用户在以下情形有权要求删除个人数据：

数据对于收集目的已不再必要
用户撤回同意（且无其他合法依据）
用户反对数据处理，且控制者无压倒性的合法理由
数据被非法处理
删除是法律义务的要求

GDPR 要求数据控制者在收到删除请求后一个月内响应，特殊情况下可延长两个月。响应不仅是确认收到请求，还需要实际完成数据删除或给出合理的拒绝理由。

需要注意的是，GDPR 的删除权并非绝对。以下情形可以拒绝删除请求：

行使言论自由和信息权
履行法律义务（如税务记录保留）
公共健康领域的公共利益
建立、行使或辩护法律索赔

1.2 CCPA / CPRA（加州消费者隐私法）

CCPA 赋予消费者要求企业删除个人信息的权利，CPRA 进一步扩展了这一权利。核心要求包括：

企业必须提供「不要出售或分享我的个人信息」的选项
消费者提交删除请求后，企业必须在 45 天内响应（可延长 45 天）
需要验证请求者身份，防止冒名删除
删除义务同时适用于企业自身和第三方服务商（Service Provider）

CCPA 的例外情形与 GDPR 类似：法律义务、公共安全、法律索赔等。

1.3 中国《个人信息保护法》

中国《个人信息保护法》第 47 条规定了个人信息删除权。核心要求：

处理目的已实现、无法实现或为实现处理目的不再必要
个人信息处理者停止提供产品或服务，或保存期限已届满
个人撤回同意
个人信息处理者违反法律、行政法规或与个人的约定处理个人信息

响应时限为 15 个工作日内。中国的监管实践还特别关注：

注销入口不能过于隐蔽（建议不超过 3 次点击可达）
不得设置不合理的注销障碍条件
注销反悔期应合理，不宜过长

1.4 其他市场

市场	法规	删除权响应时限	特殊要求
欧盟/EEA	GDPR	30 天	DPO 可能需要参与审查
加州	CCPA/CPRA	45 天	需提供多种请求渠道（网站、电话）
中国	个保法	15 个工作日	注销入口需清晰可达
巴西	LGPD	合理时间	类似 GDPR，需指定代理人
日本	APPI	6 个月（通知）	需通过指定窗口受理
韩国	PIPA	30 天	严格的数据最小化原则

二、实现方法：三种删除策略对比

数据删除的技术实现不是简单的 DELETE FROM users WHERE id = ?。不同场景下需要采用不同的删除策略。

2.1 软删除（Soft Delete）

软删除是在数据记录上标记一个「已删除」状态字段，数据本身仍然保留在数据库中。

-- 软删除实现
ALTER TABLE users ADD COLUMN deleted_at TIMESTAMP DEFAULT NULL;
ALTER TABLE users ADD COLUMN deletion_requested_at TIMESTAMP DEFAULT NULL;
 
-- 标记删除
UPDATE users SET deleted_at = NOW() WHERE id = $1;
 
-- 查询时排除已删除用户
SELECT * FROM users WHERE deleted_at IS NULL;

优点：

可恢复，用户可以在反悔期内撤销注销
不会破坏外键约束和关联数据的完整性
可以保留业务统计数据的完整性

缺点：

数据仍然占用存储空间
如果忘记在查询中过滤 deleted_at，可能泄露「已删除」用户的数据
不满足 GDPR 的实质删除要求（数据仍然存在）

2.2 硬删除（Hard Delete）

硬删除是从数据库中物理删除数据记录，不可恢复。

-- 硬删除用户记录
DELETE FROM users WHERE id = $1;
 
-- 级联删除关联数据
DELETE FROM user_sessions WHERE user_id = $1;
DELETE FROM user_preferences WHERE user_id = $1;
DELETE FROM user_content WHERE user_id = $1;

优点：

彻底删除，满足 GDPR 的实质要求
释放存储空间
不存在数据泄露风险

缺点：

不可恢复
可能破坏外键约束——需要处理级联关系
可能影响业务统计数据的完整性
备份系统中的数据无法立即删除

2.3 延迟删除（Delayed Deletion）

延迟删除是软删除和硬删除的组合：先标记为「待删除」状态，经过一段等待期后再执行物理删除。

-- 第一阶段：标记删除（立即生效）
UPDATE users
SET deleted_at = NOW(),
    deletion_scheduled_at = NOW() + INTERVAL '30 days',
    status = 'pending_deletion'
WHERE id = $1;
 
-- 第二阶段：定时任务执行物理删除
-- 由 cron job 或后台 worker 定期执行
DELETE FROM users
WHERE deletion_scheduled_at <= NOW()
  AND status = 'pending_deletion';

优点：

给用户留出反悔期
可以完成数据导出请求（用户可能在删除前要求数据可携带）
业务上有缓冲时间处理关联关系

缺点：

实现复杂度最高
需要维护两套删除逻辑
等待期内数据仍然存在，需要限制访问

2.4 删除策略对比

维度	软删除	硬删除	延迟删除
数据可恢复性	可恢复	不可恢复	等待期内可恢复
GDPR 合规性	不满足（数据仍存在）	满足	等待期内不满足
实现复杂度	低	中	高
外键约束处理	无需处理	需要级联处理	需要级联处理
业务数据影响	可保留统计完整性	可能影响统计	等待期内保留
推荐场景	内部系统、数据审计	简单系统、无关联数据	面向消费者的 SaaS

对于出海 SaaS 产品，推荐采用「延迟删除」方案：先软删除并禁用账号，经过等待期后再执行物理删除。这样既满足法律合规要求，又给用户留出反悔空间。

三、数据保留策略：哪些必须保留、保留多久

账号注销不意味着所有数据都必须立即删除。有些数据因法律义务需要保留，有些数据因业务需要可以匿名化后保留。

3.1 必须保留的数据

以下数据因法律义务或合法利益，在用户注销后仍然需要保留一段时间：

数据类别	保留原因	建议保留期限	法律依据
交易和支付记录	税务、审计要求	5-7 年	各国税法差异
合同和协议记录	法律索赔防护	合同终止后 3-6 年	诉讼时效规定
反洗钱记录	合规要求	5 年	AML 法规
安全日志（登录 IP、操作记录）	安全审计、入侵检测	6 个月-2 年	合法利益
客服沟通记录	争议解决	1-3 年	合法利益

3.2 可以匿名化后保留的数据

以下数据在匿名化处理后（去除个人标识信息）可以保留用于业务分析：

产品使用统计：功能使用频率、用户活跃度趋势——去除用户标识后保留聚合数据
AI 模型训练数据：用户生成的内容（如果用户协议允许）——去除个人关联后用于模型改进
性能指标：API 调用量、响应时间——按时间窗口聚合后保留
错误日志：异常堆栈、错误类型——去除用户标识和输入内容后保留

匿名化必须是不可逆的。如果只是将用户名替换为「已注销用户」，这属于假名化（Pseudonymization），不算真正的匿名化，仍然受数据保护法规约束。

3.3 必须删除的数据

以下数据在用户注销后必须删除（或匿名化）：

个人身份信息（PII）：姓名、邮箱、手机号、头像
账号凭证：密码哈希、API Key、OAuth Token
个人偏好设置：主题、语言、通知设置
个人内容：用户上传的文件、创建的 AI 作品、对话历史
第三方关联：OAuth 绑定的第三方账号信息

3.4 数据保留策略设计原则

设计数据保留策略时遵循以下原则：

数据分类先行：按数据类别制定不同的保留规则，不要一刀切
最短保留原则：只保留实现目的所必需的最短时间
自动化执行：保留期限到期后自动删除，不依赖人工操作
文档化：将保留策略写成书面文件，定期审查和更新
透明告知：在隐私政策中明确告知用户各类数据的保留期限

四、用户沟通：流程设计和确认机制

账号注销的用户沟通不仅影响用户体验，也是法律合规的重要证据。GDPR 和中国《个保法》都要求注销流程清晰、便捷。

4.1 注销流程设计

一个合规的账号注销流程应该包含以下步骤：

适读画布 · 130%

Mermaid 流程图加载中...

流程设计要点：

入口清晰可达：从主页面不超过 3 次点击可以到达注销入口。中国监管实践明确要求「设置→账号与安全→注销账号」的路径不超过三次点击
注销前告知：清晰说明注销后的影响——数据将被删除、无法恢复、服务将终止。不要用模糊的法律用语，用用户能理解的语言
注销原因收集：提供一个可选的原因选择器，帮助产品改进。但不要将填写原因设置为强制条件
身份验证：注销前要求重新验证身份（输入密码、验证码或二次验证），防止账号被盗后恶意注销
未完成事项检查：检查用户是否有未完成的订单、未到期的订阅、未结清的款项。如果有，明确告知处理方式
二次确认：在最后一步要求用户明确确认。可以使用输入「CONFIRM」或「我确认注销」的方式，避免误操作

4.2 确认机制

确认方式	安全级别	用户体验	适用场景
简单弹窗确认	低	好	低风险操作
输入密码确认	中	中	一般账号操作
短信/邮箱验证码	高	中	涉及敏感数据的操作
输入特定文字确认	中	低	防止误操作的最终确认
多因素组合	最高	差	高价值账号

推荐方案是「密码确认 + 邮箱验证码 + 输入确认文字」的三重组合。密码确认防止他人操作，邮箱验证码确认账号归属，输入确认文字防止误操作。

4.3 等待期沟通

如果采用延迟删除方案（推荐 30 天等待期），需要在以下时间点与用户沟通：

注销申请时：告知等待期的存在和时长，说明等待期内可以撤销
等待期内：如果用户重新登录，提示账号处于「待注销」状态，提供撤销选项
删除执行后：发送最终确认邮件，告知数据已删除（发送到注销前预留的联系邮箱）

4.4 数据删除证明

GDPR 下，数据控制者需要能够证明删除操作已经完成。建议提供以下证据：

删除操作日志：记录删除时间、执行方式、影响的数据范围
自动化报告：定期生成数据删除合规报告
用户可查询的状态：在等待期内用户可以查询自己的删除进度

五、技术实现：数据库设计和备份处理

5.1 数据库设计

以下是一个面向出海 SaaS 的账号注销数据模型设计：

-- 用户账号状态机
CREATE TYPE user_status AS ENUM (
    'active',               -- 正常使用
    'pending_deletion',     -- 等待删除（等待期内）
    'deleted',              -- 已删除（物理删除完成）
    'deactivated'           -- 已停用（软删除，可恢复）
);
 
-- 用户表增加注销相关字段
ALTER TABLE users ADD COLUMN status user_status DEFAULT 'active';
ALTER TABLE users ADD COLUMN deletion_requested_at TIMESTAMP;
ALTER TABLE users ADD COLUMN deletion_scheduled_at TIMESTAMP;
ALTER TABLE users ADD COLUMN deletion_completed_at TIMESTAMP;
ALTER TABLE users ADD COLUMN deletion_reason TEXT;
ALTER TABLE users ADD COLUMN anonymized_at TIMESTAMP;
 
-- 注销请求日志表
CREATE TABLE deletion_requests (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id),
    requested_at TIMESTAMP NOT NULL DEFAULT NOW(),
    reason TEXT,
    verification_method VARCHAR(50),
    status VARCHAR(20) NOT NULL DEFAULT 'pending',
    -- pending / confirmed / cancelled / completed
    cancelled_at TIMESTAMP,
    completed_at TIMESTAMP,
    completed_by VARCHAR(50)
    -- manual / scheduled_job
);
 
-- 数据保留规则表
CREATE TABLE data_retention_rules (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    data_category VARCHAR(100) NOT NULL,
    -- transaction / contract / security_log / personal_data / user_content
    legal_basis VARCHAR(100) NOT NULL,
    -- tax_law / contract_defense / legitimate_interest / consent
    retention_period INTERVAL NOT NULL,
    -- e.g. '7 years' / '180 days'
    action_after_expiry VARCHAR(20) NOT NULL
    -- delete / anonymize
);

5.2 注销执行 Worker

账号注销的数据删除通常涉及多个数据表和关联系统，不适合在请求中同步完成。推荐使用后台 Worker 异步执行：

// 阶段一：发起注销请求
async function requestDeletion(
  userId: string,
  reason: string,
  verificationMethod: string
) {
  const user = await db.users.findUnique({ where: { id: userId } })
  if (!user) throw new NotFoundError('用户不存在')
  if (user.status !== 'active') throw new BadRequestError('账号状态异常')
 
  // 创建注销请求记录
  const request = await db.deletionRequests.create({
    data: {
      userId,
      reason,
      verificationMethod,
      status: 'confirmed',
    },
  })
 
  // 更新用户状态为待删除，设定 30 天后执行
  await db.users.update({
    where: { id: userId },
    data: {
      status: 'pending_deletion',
      deletionRequestedAt: new Date(),
      deletionScheduledAt: addDays(new Date(), 30),
      deletionReason: reason,
    },
  })
 
  // 发送确认邮件
  await sendDeletionConfirmationEmail(user.email, request.id)
 
  return request
}
 
// 阶段二：定时任务执行物理删除
async function processScheduledDeletions() {
  const pendingUsers = await db.users.findMany({
    where: {
      status: 'pending_deletion',
      deletionScheduledAt: { lte: new Date() },
    },
  })
 
  for (const user of pendingUsers) {
    try {
      await executeUserDataDeletion(user.id)
      await db.users.update({
        where: { id: user.id },
        data: {
          status: 'deleted',
          deletionCompletedAt: new Date(),
        },
      })
      await db.deletionRequests.update({
        where: { userId: user.id, status: 'confirmed' },
        data: { status: 'completed', completedBy: 'scheduled_job' },
      })
    } catch (error) {
      // 记录错误，不标记完成，等待重试
      logger.error('数据删除失败', { userId: user.id, error })
    }
  }
}
 
// 阶段三：执行具体数据删除
async function executeUserDataDeletion(userId: string) {
  // 1. 删除用户个人数据
  await db.userProfiles.delete({ where: { userId } })
  await db.userPreferences.delete({ where: { userId } })
  await db.userSessions.deleteMany({ where: { userId } })
  await db.oauthConnections.deleteMany({ where: { userId } })
 
  // 2. 处理用户内容——区分可删除和需匿名化的部分
  await db.userContents.deleteMany({ where: { authorId: userId } })
 
  // 3. 匿名化不能删除但需去除个人关联的数据
  await db.auditLogs.updateMany({
    where: { userId },
    data: {
      userId: null,
      userIdentifier: 'deleted_user',
      ipAddress: '0.0.0.0',
    },
  })
 
  // 4. 通知第三方服务删除数据
  await notifyThirdPartyDataDeletion(userId)
 
  // 5. 从搜索索引、缓存中清除
  await invalidateUserCache(userId)
  await removeFromSearchIndex(userId)
}

5.3 备份系统处理

备份系统中的用户数据是一个常见难题。定期备份（如每日快照）中可能包含已注销用户的数据。处理方案：

方案	实现方式	合规性	成本
备份过期自动清除	备份设置保留期限（如 90 天），到期后自动覆盖	高（备份过期后数据自然消失）	低
备份中匿名化	恢复备份时将已删除用户数据匿名化	高	中
加密删除（Crypto-shreddbing）	用户数据用独立密钥加密，删除时销毁密钥	高（数据变成不可读密文）	中
忽略备份中的数据	不做特殊处理	低（可能不合规）	低

推荐使用「备份过期自动清除 + 加密删除」的组合方案。对用户个人数据使用独立加密密钥，用户注销时销毁密钥，数据变为不可恢复的密文。同时设置合理的备份保留期限（建议不超过 90 天），过期备份自动清理。

5.4 第三方服务数据同步

SaaS 产品通常会将用户数据同步到多个第三方服务（邮件服务商、分析工具、CDN、日志服务等）。用户注销时需要通知这些服务同步删除：

邮件服务商（SendGrid、Mailgun）：删除联系人记录和邮件地址
分析工具（Mixpanel、Amplitude）：删除用户标识和关联行为数据
日志服务（Datadog、Loggly）：清除包含用户 PII 的日志条目
CDN / 对象存储（S3、CloudFront）：删除用户上传的文件
支付服务（Stripe）：保留必要的交易记录，删除个人信息

六、案例分析

案例一：AI 写作工具的账号注销实现

某 AI 写作工具面向欧美市场，用户注册后会生成大量 AI 写作内容。用户请求注销时面临以下挑战：

数据分类挑战：

用户个人身份信息（邮箱、头像）→ 必须删除
用户创建的 AI 写作内容 → 区分个人创作和团队协作内容
AI 模型训练数据（如果用户协议允许使用用户内容训练）→ 需要评估是否已纳入训练数据集
协作空间中的内容 → 其他成员的内容不能因一个用户注销而删除

解决方案：

用户创建的个人内容（私有文档）→ 直接删除
协作空间中的内容 → 将作者标识替换为「已注销用户」，保留内容本身
已纳入 AI 训练数据集的内容 → 无法从已训练的模型中「撤回」，在隐私政策中提前告知用户这一点，并提供注销前手动退出的选项
交易记录 → 匿名化处理，保留金额和时间戳用于财务统计，去除用户个人信息

技术实现要点：

使用延迟删除方案，设置 30 天等待期
等待期内用户重新登录时提示「您的账号正在注销中，是否撤销？」
物理删除分三步执行：删除个人数据 → 匿名化协作内容 → 清理缓存和索引
备份采用加密删除方案，用户数据使用独立密钥加密

案例二：中国出海社交应用的注销合规

某社交应用同时面向中国国内和东南亚市场，需要同时满足中国《个保法》和目标市场的数据保护要求。

合规挑战：

中国要求 15 个工作日内响应注销请求
部分东南亚国家有本地数据保留要求（如越南要求部分数据本地存储）
社交应用中用户发布的内容涉及其他用户的隐私