什么是 GDPR？面向应用构建者的通俗指南

GDPR（通用数据保护条例，General Data Protection Regulation）是欧盟的主要数据保护法律。它规定了组织如何收集、使用、存储和共享个人数据（即与可识别的在世自然人相关的任何信息），并赋予个人对自己数据的权利，例如查看数据或要求删除数据。该条例自 2018 年 5 月 25 日起适用，如果企业为欧盟境内的人群提供服务，即使身处欧盟以外，也可能适用。

**非法律建议。**本指南是一份一般性说明，旨在帮助你理解基本概念并提出更好的问题，并不能替代针对你具体情况的专业意见。如需权威细节，请参阅欧盟委员会的数据保护页面和欧洲数据保护委员会面向小企业的指南。

用 AI 构建应用时为什么它很重要

AI 构建工具让收集数据变得非常容易。一个提示词就能生成注册表单、联系表单、数据分析、文件上传以及列出所有用户的管理仪表板。这些功能都会收集个人数据，而 GDPR 关注的正是所有这些数据。

好消息是，GDPR 的大部分要求同时也是良好的产品实践：

• 只收集你真正需要的内容。
• 告知人们你如何使用这些数据。
• 确保数据安全。
• 在不再需要时删除数据。
• 让人们能够查看、更正或删除自己的数据。

从一开始就将这些考虑纳入设计，远比上线后再补救容易得多。尽早向 AI 构建工具提出正确的问题，可以避免日后痛苦的返工。

一个日常类比

可以把个人数据想象成人们存放在你这里的物品——就像衣帽间寄存的东西，只不过寄存的是信息。GDPR 就是衣帽间的管理规则：

• 只保管对方同意寄存的物品，并且要有对方理解的用途。
• 不要为了其他目的翻看口袋里的东西。
• 保持房间锁好。
• 应对方要求或在不再需要时，把物品归还或丢弃。
• 如果东西丢失，要及时告知相关人员。

即使你雇人来管理房间，只要衣物还在你的照管之下，你就要对它们负责。

核心概念

什么属于个人数据

欧盟委员会将个人数据定义为与已识别或可识别的在世自然人相关的任何信息。这个定义相当宽泛，包括姓名、电子邮箱地址、家庭住址、IP 地址、Cookie ID 和照片。经过“假名化”处理的数据——例如用代码替换姓名——如果仍可以关联回某个人，依然属于个人数据。

某些类别的数据受到额外保护，包括健康数据、生物识别数据、种族或民族出身，以及政治观点。

适用于哪些主体

根据欧盟委员会的说明，GDPR 适用于在欧盟设立的组织，以及向欧盟境内的人提供商品或服务（无论是否收费）或监控其行为的欧盟以外的组织。一家拥有欧洲客户的美国或阿联酋初创企业很可能在适用范围之内。英国有其自己的版本，即英国 GDPR，它以 GDPR 为蓝本，内容高度相似。

基本原则

GDPR 建立在一组简短的原则之上。用通俗的话说：

合法性基础

你每使用一种个人数据的方式，都需要一个法律理由——即“合法性基础”。GDPR 列出了六种：同意、履行合同、法定义务、重大利益、公共任务和合法利益。同意只是其中之一。例如，为了交付订单而处理订单信息，通常以合同为依据，而不是同意。哪种依据适合，需要依照官方指引进行判断。

人们的权利

欧盟委员会列出了以下个人权利：

• 了解其数据如何被使用的知情权
• 访问其数据的权利
• 更正其数据的权利
• 删除其数据的权利
• 限制处理的权利
• 数据可携带权（以可用的格式获取数据）
• 反对权
• 与自动化决策和画像相关的权利

数据泄露

如果个人数据发生泄露，并且此次泄露可能危及个人的权利和自由，组织通常必须在知悉后不无故拖延地通知其数据保护监管机构，并在可行的情况下于 72 小时内完成通知。在某些情况下，还必须告知受影响的个人。

实例演示：瑜伽工作室预约应用

假设你正在为一家在德国拥有客户的瑜伽工作室构建预约应用。下面是 GDPR 如何影响这一设计。

**少收集。**注册表单要求填写姓名、邮箱，以及可选的电话号码。最初的草稿还要求填写出生日期和家庭住址——但应用中没有任何功能使用它们，因此予以删除。

**健康数据需要谨慎处理。**工作室希望询问学员的伤病情况。这属于健康数据，是需要适用更严格规则的特殊类别数据。工作室决定改为当面询问，因此应用不收集此类信息。

**保持透明。**隐私政策会说明收集了哪些信息、为何收集、保留多长时间、还有哪些其他方参与处理（托管服务商、邮件服务、支付服务商），以及如何联系工作室。

**营销与之分开。**预约课程不会自动把用户添加到新闻邮件订阅中。营销订阅有单独的、默认未勾选的复选框。

**产品中的权利。**客户可以查看和编辑个人资料、下载预约历史，并可以在账户页面申请删除。

**保留期限。**不活跃的账户在设定期限后会被标记，如果客户没有回应，则予以删除。保留期限由工作室决定。

**Cookie。**登录 Cookie 是必要的。数据分析脚本只有在访客同意后才会加载。参见什么是 Cookie。

**安全。**密码经过哈希处理，管理区域需要双因素认证，并且只有所有者可以导出客户名单。

常见术语解释

常见错误与误解

• **“我们不在欧盟，所以不适用。”**它可能根据你用户的所在地而适用。
• **“GDPR 意味着所有事情都需要同意。”**同意只是六种合法性基础之一，而且往往并不是正确的依据。
• **“放一个 Cookie 横幅就合规了。”**Cookie 只是很小的一部分。数据收集、安全、权利和保留期限更为重要。
• **“我们的托管服务商符合 GDPR，所以我们也符合。”**服务商能提供帮助，但应用收集什么、做什么，由你决定。
• **“以防万一”而收集。**每多一个字段，就多一份需要保护、说明和删除的责任。
• **照搬其他网站的隐私政策。**隐私政策必须描述你的应用实际做了什么。
• **让删除无法实现。**如果没有开发者的帮助，无人能删除用户，那么每一次权利请求都会变成紧急事件。

向你的 AI 构建工具提出的要求

• “列出此应用收集的每一项个人数据，说明它存储在哪里，以及为什么需要它。”
• “删除我们不使用的任何表单字段。”
• “添加一个账户页面，让用户可以查看、编辑和下载自己的数据，并申请删除。”
• “添加一个管理员操作，可以彻底删除某位用户及其相关记录，或将我们必须保留的记录匿名化。”
• “将营销订阅保留为单独的、默认未勾选的复选框。”
• “在获得同意之前，不要加载数据分析或营销脚本。”
• “列出所有会接收用户数据的第三方服务，以便我将它们添加到隐私政策中。”
• “将管理员导出功能限制为所有者角色，并记录谁导出了什么内容。”

之后，请阅读如何撰写服务条款和隐私政策以及如何添加 Cookie 同意功能。

GDPR 与 Mythex

Mythex 为你提供的是构建模块，而不是合规证书。启用后，你应用的数据存储在其独立的项目数据库和文件存储中；你拥有代码的所有权；在 Pro 计划中，如需迁移，你可以导出项目。你的应用收集什么、保留多久，以及人们如何行使其权利，都是由你做出的决定，并请智能体为你构建相应功能。数据所有权文档页面说明了 Mythex 托管的内容，而为你构建的应用的安全性则提醒不要声称自己并不具备的合规资质。如果你需要了解具体内容，例如数据的托管地点或数据处理协议，请在上线前联系 Mythex 支持。

常见问题