AI 应用如何保护用户隐私：我们的实践方案

在 AI 应用中，用户隐私保护常常被当作"写进隐私政策就行"的合规问题。但我们认为，隐私保护应该是工程问题——需要用代码来落实，而不只是用文字来承诺。

数据最小化原则

数据最小化是 GDPR 的核心原则之一：只收集实现目的所必需的数据，不多收一分。在 MeMeGo 中，我们的实践是：

• 不要求实名注册，邮箱即可使用
• 不收集设备指纹、不追踪浏览行为
• AI 生成输入的提示词不长期存储
• IP 地址仅用于限流，不关联用户身份

自动清理机制

我们将"数据不长期留存"作为系统级功能实现，而非依赖人工操作。具体方案包括：

后台运行定时清理任务，每日扫描存储系统，自动删除超过 7 天的照片和生成记录。清理范围不仅包括生成结果文件，还包括数据库中的关联记录和存储桶中的孤立文件。

这套机制是自动的、不可配置的、不可关闭的。即使运营人员也无法手动关闭清理——这是设计层面的硬约束。

级联删除与 GDPR 合规

当用户行使 GDPR 赋予的删除权时，我们的系统会执行级联删除操作：

• 认证数据：删除账户凭证和会话信息
• 存储文件：删除用户上传的所有照片和生成结果
• 使用记录：删除生成历史、积分记录和交易记录
• 通知数据：删除与用户关联的所有通知和消息

级联删除确保用户数据被彻底清除，不存在"删除了账户但数据还在后台"的情况。

第三方数据边界

我们的服务依赖几个第三方平台，但我们在设计时严格划定了数据边界：

AI 模型 API：仅传输用户输入的提示词，不传递用户身份信息。生成完成后，API 侧不保留任何数据（取决于供应商的数据保留政策）。

支付平台：使用 Paddle 处理支付，我们从不接触完整卡号。Paddle 的 webhook 仅传递交易 ID 和积分数量，不传递多余信息。

CDN 服务：Cloudflare 作为反代和 CDN，可访问 IP 地址等传输层数据，但我们不在应用层将 IP 关联到用户身份。

自托管部署的优势

与使用 SaaS 平台不同，我们选择自托管部署（Docker + 自有 VPS）。这意味着：

• 数据完全在自有服务器上，不经过第三方云平台的应用层
• 数据库、Redis 等中间件完全自管，不依赖云数据库
• 可以随时审计数据存储情况，物理掌控数据

自托管确实增加了运维成本，但对于隐私优先的产品来说，这是值得的代价。掌控数据，就是掌控信任。