O1.01.1Privacy by design设计研究
隐私需在架构阶段纳入而非事后补救
别名: 隐私保护设计 · 架构隐私 · privacy engineering
概念解释
隐私保护设计（privacy by design）是把数据保护要求转化为系统架构约束，而不是在产品完成后再添加政策文字或设置入口。它关心数据是否必须产生、在哪里处理、哪些主体能够关联、何时销毁，以及异常路径是否泄露。其对象不只是界面告知，还包括数据模型、日志、缓存、权限边界和供应商接口。
机制
架构会制造后续难以逆转的事实：一旦多个标识符以稳定主键关联，分离用途就需要重构整条数据链；一旦原始数据进入集中日志，任何前端开关都不能撤销既有副本。相反，本地处理、分区存储、短生命周期标识符和能力受限的接口会减少可观察、可关联和可保留的数据。隐私因此具有路径依赖：早期的数据流与信任边界决定后期补救的上限。
怎么研究
常用方法包括数据流图与威胁建模、代码和配置审计、隐私影响评估，以及对真实任务的可用性测试。研究变量可覆盖可识别数据的产生量、跨边界传输次数、默认暴露面和用户完成控制任务的成本。评估时需同时追踪正常路径与失败、调试、客服、分析等旁路；只审查可见界面会系统性漏掉后台数据流。
边界
架构前置不能消除所有风险。法定留存、反欺诈和安全审计可能要求保存部分数据；端到端加密也不能隐藏通信时间、端点等元数据。原型阶段的数据流还会变化，但“不确定”不等于可以无限采集：应记录假设并设置到期复核。合规清单通过也不证明架构符合用户所在情境的合理预期。
怎么落地
- 在功能评审前画出数据从采集、推断、共享到删除的完整路径，并为每个信任边界指定责任人。
- 优先选择不产生数据、本地计算、聚合后上传和短期标识符；把集中保存原始数据视为需要论证的例外。
- 将隐私约束写入接口、数据库和日志设计，覆盖失败重试、备份与第三方处理者。
- 用测试账户走完核心任务和异常路径，抓取网络请求并核对存储、日志与删除结果；发现未声明的数据副本即阻断发布。