VOCABULARY / 词条
隐私保护设计
Privacy by Design
把隐私保护作为系统与业务流程的默认运行方式，在设计阶段就嵌入，而不是事后补加：用户什么都不做时，其个人数据仍受保护；默认只处理达成既定目的所必需的数据；数据的用途在收集时被说明，且不用于说明之外的目的。
识别特征
- 默认状态就是保护性最强的合理选项，用户无需先动手
- 在收集数据的位置说明用途，且只收集该目的所需的数据
- 查看、撤回和调整数据处理的入口与使用功能的入口同样容易到达
概念边界
它是一种贯穿设计过程的理念，不是一组同意横幅或隐私开关的清单——开关多并不等于默认受保护。它也不等于安全：安全关注数据不被未授权访问，隐私保护设计还要问是否应当收集、收集多少、用来做什么；Cavoukian 明确把"隐私对安全"视为需要避免的伪二选一，两者应同时成立。与 GDPR 第 25 条的"数据保护设计与默认"相关但不完全等同：后者是针对控制者的法律义务，本条目讨论的是设计取向。
什么时候考虑它
- 产品需要采集位置、通讯录、行为记录等个人数据才能提供功能
- 定义新功能的默认设置与初次引导流程时
- 产品面向受 GDPR 等法规约束的市场，需要证明在设计阶段已考虑数据保护
什么时候慎用
- 把上线前加一层同意弹窗当作已经实现隐私保护设计
- 以"隐私"为名把数据处理的判断与劳动全部推给用户逐项决定
- 用安全审计通过来替代对收集必要性与用途的审视
取舍
保护性默认与数据最小化可能减少可用于个性化、分析和增长的数据，也让部分功能需要用户主动开启；Cavoukian 主张正和而非零和，但每个具体功能仍需说明其数据需求是否真的必要。
条件规则 · 编辑建议
相关词条
把退出做得比进入难，直接违背"撤回应与给出同样容易"的原则，会把隐私保护设计变成阻碍型反模式。
未在收集点说明的数据用途与晚期才出现的费用同属"迟到的披露"，都削弱用户在决策时的知情。
保护性默认减少了必须打断用户的权限请求次数，剩下的请求应在真正需要时出现并说明理由。
来源与支持范围
列出七项基础原则，其中"隐私作为默认设置"要求用户什么都不做时隐私仍受保护，"嵌入设计"反对事后补加，"正和而非零和"把隐私对安全视为伪二选一；原文为 2009 年发布、2011 年修订的 IPC Ontario 文件，本次核查使用 SFU 托管副本。
检索日期：2026-09-15 · 存档于 2026-09-01第 25 条第 2 款要求控制者确保默认只处理每一具体目的所必需的个人数据，覆盖收集数量、处理范围、存储期限和可访问性；支持本条目的默认设置规则与数据最小化建议。
检索日期：2026-09-15原则 2.2.1 要求把传输的数据限制在达成用户目标所必需的范围；2.10.1 与 2.10.2 要求在访问数据时说明目的且不作他用；2.12.3 指出查看、撤回同意或选择退出应与给出同意同样容易；1.1.1 主张设置保护隐私的默认值以减少"隐私劳动"。
检索日期：2026-09-15 · 存档于 2026-09-20定义参考以上来源；数字界面示例、选择建议、条件关系及配方由本样例编辑，尚未经用户研究验证。
类型扩展与实现说明
尚无可操作样例；插图为编辑示意。应用到产品时仍须核实：每个默认值是否真的处于保护性最强的合理选项、收集点是否说明了用途、以及撤回路径的步骤数是否不多于开启路径；法规合规性需由法律专业人士另行评估。
{
"values": [
"默认受保护",
"数据最小化",
"用途透明"
],
"tension": "保护性默认与数据驱动的功能和增长",
"questions": [
"用户什么都不做时，哪些数据会被收集？为了什么？",
"关闭这项数据收集是否和打开它一样容易？"
]
}打开本词条的 Agent JSON 文件这个文件原样收录本词条的全部字段，并附上来源、存档与编辑声明。