设计隐私：它是什么以及如何应用它

您可能已经在服务条款页面和隐私政策文件中看到过“设计隐私（privacy by design）”这个短语。但这是一个诚实的事实：大多数时候它只是公司在上线前勾选的一个复选框。

在现实中，设计隐私是完全不同的东西。它不是您填写的一份表格。它是软件实际构建的方式——从第一行代码开始——这样您的数据就会受到保护，而不需要任何人在以后记住去做这件事。把它想象成从第一天起就用坚实的基础建造一座房子，而不是指望在人们搬进去之后再修复结构问题。

为什么这在 2026 年很重要

2026 年 7 月 1 日，隐私法规比以往任何时候都更加严格。GDPR 已经存在好几年了，忽视它的公司面临着严重的罚款。但除了法律风险之外，人们终于开始关注他们的数据去向了。隐私不再只是一个可有可无的功能——它是您的用户实际期望和应得的东西。从一开始就内置隐私意味着您将来会花更少的时间去修复问题，并从您的客户那里赢得更多的信任。

GDPR 实际上说了什么？

GDPR 的第 25 条涵盖了被称为“设计和默认的数据保护（data protection by design and by default）”的内容。如果您从未读过它，不要担心——它是用让几乎所有人都感到困惑的法律语言写的。这里有一个简单的版本：在构建软件时，您需要将保护人们的数据作为设计本身的一部分来考虑，而不是作为附加组件。

关键短语是“设计（by design）和默认（by default）”。这是两件独立的事情，理解它们之间的区别很重要。

设计和默认之间的区别

设计（Design） 意味着您在构建软件时做出的选择。例如，在收集用户的位置信息之前，您是否会征求他们的许可？您是否会加密他们的密码？您是否限制保留他们数据的时间？这些是您在规划和构建应用时做出的设计决策。

默认（Default） 意味着自动发生的事情，无需用户采取任何操作。例如，新用户的个人资料默认应该公开还是私密？通知应该开启还是关闭？默认的隐私设置应该始终倾向于保护用户，而不是最大化公司的数据收集。如果用户必须深入研究设置才能隐藏他们的信息，那不是默认隐私——那是隐晦隐私（privacy by obscurity）。

如何应用设计隐私

设计隐私不是您在项目结束时完成的一份清单。它是您在构建过程中做出的每一个决定所带来的一种思维方式。以下是如何实际做到这一点的方法。

步骤 1：询问您实际需要什么数据

在收集任何东西之前，停下来问问：我们真的需要这个吗？如果您正在构建一个购物应用程序，您需要客户的地址来发货。您可能不需要他们的生日、浏览历史或宗教信仰。您收集的每一条数据都是一种责任——一件您必须保护的事情，一件可能被盗的事情，一件您可能会意外暴露的事情。收集的数据越少，需要保护的数据就越少。

步骤 2：最小化和限制

数据最小化是设计隐私的核心原则。只收集您需要的，用完后删除。如果客户退货，您可能不需要将他们的退货数据永远保存在您的数据库中。为已过时的数据设置自动删除。使用有时限的令牌代替永久凭证。限制您公司内部谁可以访问敏感信息——如果客户支持代表不需要查看财务数据，他们就不应该能够访问。

步骤 3：将隐私作为默认设置

当用户创建一个帐户时，他们的个人资料默认应该是私密的，而不是公开的。通知默认应该关闭，除非用户选择加入。位置跟踪默认应该关闭。如果您的商业模式取决于人们分享他们的数据，您可以要求他们选择加入——但默认设置应该始终保护他们。

步骤 4：加密敏感数据

数据加密意味着将信息打乱，只有拥有正确密钥的人才能读取。密码、支付信息、健康数据和任何其他敏感信息，无论是在存储时（静态）还是在通过互联网发送时（传输中），都应被加密。在存储时使用行业标准加密，例如 AES-256，连接时使用 TLS 1.3。不要发明您自己的加密方式——使用安全专家已经审查过的库和框架。

步骤 5：对您收集的内容保持透明

用户应了解您正在收集哪些数据以及原因。您的隐私政策应该用通俗易懂的英语编写，而不是只有律师才能解析的法律行话。告诉人们您如何处理他们的数据，您保留多久，以及您与谁分享。如果您改变了您的做法，请再次告诉他们。透明度建立信任，而信任一旦被破坏就很难恢复。

步骤 6：让用户拥有控制权

用户应该能够看到您掌握了关于他们的什么数据，下载、更改或删除它。这听起来像是额外的工作，但这是 GDPR 下的法律要求，无论如何也是正确的做法。从一开始就将这些工具构建到您的应用程序中，而不是稍后再附加它们。

步骤 7：为安全事件做好计划

迟早会有事情出错。数据库可能会被入侵。密码可能会被泄露。您应该准备好一个计划：您将如何发现？您将以多快的速度告诉用户？您将如何帮助他们保护自己？将其写下来并在真正的事件发生之前进行练习。

一个实际的例子

假设您正在构建一个追踪锻炼情况的健身应用。这就是设计隐私的样子：

• 您要求提供所需的最少信息：锻炼类型、持续时间和日期。您可能不需要他们的身高、体重或病史，除非他们注册了针对个人的辅导功能。
• 除非用户要求保留，否则您会在两年后删除旧的锻炼数据。
• 用户的个人资料和锻炼历史默认是私密的。如果他们想与朋友分享锻炼，他们可以明确地这样做——但默认情况是其他任何人都看不到它。
• 所有数据在存储到您的数据库之前都会被加密。
• 您的隐私政策以简单的术语解释了他们的数据会发生什么。
• 用户可以下载他们所有的的数据、更改其中的任何数据或请求您删除他们的帐户。
• 您制定了应对数据库被黑客入侵时的计划。

这种方法意味着未来会减少令人头疼的问题。您没有存储您不需要的数据，您没有猜测用户想要什么，您也没有在出现问题后手忙脚乱地增加安全性。

结论

设计隐私不是发布前勾选的复选框。它是一种思考软件的方式，从第一天起就将数据保护放在中心位置。GDPR 要求这样做，您的用户期望这样做，而且老实说，它只是成就了更好的软件。从询问您真正需要什么数据开始，加密您保留的数据，删除您不需要的数据，并始终将隐私作为默认设置。您的用户会感激的，而且因为知道自己做了正确的事情，您晚上也会睡得更好。

优点

• 降低法律风险和潜在的 GDPR 罚款
• 建立用户信任和忠诚度
• 更少的安全事件和数据泄露
• 管理、保障和保护的数据更少
• 更容易遵守隐私法规
• 节省事件响应和法律费用
• 使您的应用在具有隐私意识的市场中更具竞争力

缺点

• 需要更多前期的思考和规划
• 可能会限制一些基于数据收集的商业模式
• 意味着拒绝看似有利可图但不保护隐私的功能
• 需要持续努力来维护安全实践
• 培训和文化改变需要时间
• 一些隐私措施可能会增加延迟或复杂性

注意事项

本文中的名称和值（如 app.example.com、客户数据类型和加密方法）仅作为通用示例用于说明。在实际应用中实施设计隐私时，请始终咨询隐私和安全专业人士、法律顾问以及您的特定监管要求。在部署到生产环境之前全面测试您的实施。隐私失败会使真实的人面临真实的伤害，所以请谨慎和自信地进行，不要走捷径。本指南具有教育意义——请始终针对您的特定用例和管辖区验证您的方法。

常见问题解答

• 设计隐私（privacy by design）和默认隐私（privacy by default）有什么区别？
• 设计隐私如何帮助符合 GDPR 的要求？
• 我应该在我的应用程序中收集哪些数据？
• 如何在特定时间段后自动删除用户数据？
• 我应该对敏感数据使用什么加密方法？
• 我如何告诉用户我正在收集哪些数据而不让他们感到不知所措？
• 如果发生数据泄露，我的事件响应计划应该包括什么？
• 用户如何以简单的格式请求他们的数据？