隐私法塑造设计
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 4 个模块，共 6 个，属于 Data Architect 课程第 5 章数据质量与治理。每个模块都可以单独阅读。 上一篇：了解你的数据 · 下一篇：同意与被遗忘权
**本模块回答的问题：**隐私和行业法规对一个 Salesforce 设计提出了什么要求？
我在澳大利亚工作时，遇到过很多从没听说过 GDPR 的准架构师。欧洲人也常常没听说过加州的隐私法，或者加拿大的、巴西的。这很自然：你了解的是自己工作所在地的规则。但这些法律会跨越国界，而且它们会影响系统设计，尽管它们没有一部是关于 Salesforce 的。所以它们属于一门数据架构课程。
你不需要成为律师。但你确实需要看到，一项法规可能改变数据存储在哪里、你收集什么、谁能看到它、你为什么可以使用它、你保留多久、你把它发往哪里、你能否删除它、你保留什么历史，以及你以后能证明什么。这些不只是法律问题，也是数据架构问题。
**本模块是架构指导，不是法律意见。**哪些法律适用、它们要求什么，由法务和合规团队决定。架构师把这些要求转化为可执行的设计。
法律不止于国界
Section titled “法律不止于国界 ”先说最大的误解：“我们不在欧洲，所以 GDPR 不适用。”也许是，也许不是。GDPR 的地域适用范围延伸到欧盟以外、向欧盟境内的人提供商品或服务、或者监控他们在欧盟境内行为的组织（第 3 条，Regulation (EU) 2016/679 (opens in a new tab)，英文）。所以你的公司总部在哪里，并不是问题的终点。你的客户、员工、你持有其数据的人、你的系统、你的数据处理方在哪里？数据会流向哪里？这又是第 4 章的全景图。不知道数据去往何处，你就无法做出好的隐私决定。
你应该认识的法规
Section titled “你应该认识的法规 ”下面是架构师应该知道的名字，以及各自涵盖的内容。这是一张认知表，而不是适用性矩阵：不要读了它就断定“我们在加州有客户，所以要求 X 适用”。那是法务部门的判断。你的工作是知道得足够多，能在系统构建之前就提出这个问题。
| 法律或标准 | 地区或对象 | 架构师为什么应该认识它 |
|---|---|---|
| GDPR (opens in a new tab) | 欧盟 | 个人数据、合法处理、个人权利、保留、跨境传输、隐私设计 |
| CCPA，经 CPRA 修订 (opens in a new tab) | 美国加州 | 消费者对企业所收集的关于他们的个人信息享有的权利 |
| PIPEDA (opens in a new tab) | 加拿大 | 私营部门组织如何处理个人信息 |
| LGPD (opens in a new tab) | 巴西 | 巴西的个人数据保护通用法 |
| Privacy Act 1988 (opens in a new tab) | 澳大利亚 | 组织如何依照澳大利亚隐私原则处理个人信息 |
| HIPAA (opens in a new tab) | 美国医疗健康领域 | 适用情形下受保护的健康信息 |
| PCI DSS (opens in a new tab) | 支付卡 | 保护支付卡账户数据 |
| 萨班斯-奥克斯利法案（SOX） (opens in a new tab) | 美国上市公司 | 财务报告背后的控制措施和证据 |
| COPPA (opens in a new tab) | 美国，儿童在线 | 在线收集的儿童个人信息 |
这份清单还在增长（美国有更多的州有了自己的法律），法律也在变化。这就是为什么我不希望你背下一张表，就以为自己学会了隐私架构。记住这些名字，然后学习那些比它们存在得更久的问题。
这些法律的共同点
Section titled “这些法律的共同点 ”细节各不相同，但主要的隐私法总是回到同样几件事上，而每一件都会落到架构上。
**权利。**人们可以要求查看、更正、删除和带走自己的数据；根据加州和巴西的法律，他们还可以选择拒绝自己的数据被出售。每一项这样的请求，都意味着要找到这个人的数据，全部数据。
**跨境传输。**GDPR 和 LGPD 管控个人数据离开其管辖范围，并要求数据去往的地方提供充分的保护；PIPEDA 则要求第三方处理数据时提供同等水平的保护，无论数据在哪里。这又回到了全景图：哪些箭头跨越了国界？
**数据泄露通知。**当个人数据泄露时，法律要求你在一个期限内通知监管机构，有时还要通知受影响的人，期限因法律而异。你没法为自己不知道持有的数据发出通知；如果找不到那些副本，你也说不清泄露了什么。
**问责原则。**你必须能够证明合规：记录你处理什么数据以及为什么处理，对高风险的处理做影响评估，并且根据 GDPR 和 LGPD，设立数据保护官（DPO）。架构必须能产出这些记录。
从什么是个人信息开始
Section titled “从什么是个人信息开始 ”在保护个人信息之前，先找到它。有些显而易见：姓名、家庭住址、电话、电子邮件。有些则不然：位置、设备标识符、IP 地址、图片、行为数据，以及任何能被关联回某个人的东西。而且语境很重要。Steve Trucking 的一次配送带有收货人的姓名、地址、电话号码、配送备注和照片。一张照片可能拍到门廊上的一个箱子，也可能拍到一个人，或者某人家里的样子。配送是运营数据，但它的某些属性是个人数据。这就是为什么模块 3 要给字段分类：隐私始于知道你持有什么。
它存放在哪里？
Section titled “它存放在哪里？ ”“Salesforce。”多半不只是 Salesforce。它来自某个零售合作伙伴吗？它被复制到 Snowflake 了吗？被 Data 360 摄取了吗？被写进了集成日志吗？被某个用户导出了吗？留在字段历史记录里了吗？被归档了吗？被复制到沙盒里了吗？被传给某个合作伙伴了吗？在某次智能体对话中被使用了吗？个人数据会扩散。所以当法务部门问“我们在哪里持有这个人的信息？”时，“我们知道当前的值在哪里”不是一个答案。我需要全景图和血缘：副本去了哪里。
一个电话号码，许多份副本。隐私也适用于副本。
你为什么被允许使用它？
Section titled “你为什么被允许使用它？ ”拥有数据和被允许使用数据不是一回事。Steve Trucking 持有收货人的电话号码，是为了协调今天的配送。这会让它成为一份营销名单吗？不会。法律依据取决于司法管辖区和具体情况，由法务部门来指导，但架构必须承载这个答案：为什么收集它，授权了什么用途，是否需要同意，同意是否已给出、是否已撤回，针对哪个渠道、哪个地址、哪个目的。**使用数据的许可必须能够表示为数据，**因为一份政策文档无法在运行时做出决定。下一个模块会为它建模。
少收集是一个架构决定
Section titled “少收集是一个架构决定 ”最有力的隐私控制之一，是不收集数据，或者不把它复制到不需要的地方。Snowflake 需要收货人的电话号码吗？分析需要完整的街道地址吗？沙盒需要真实的配送照片吗？智能体回答这个问题需要收货人的个人详情吗？如果不需要，最有力的控制也许就是不把它放在那里。你没有制造的每一份副本，都是你不必去保护、保留、删除、跟踪同意、审计或在数据泄露时报告的副本。治理成本最低的敏感数据，是你从未复制过的数据。
保留是模型的一部分
Section titled “保留是模型的一部分 ”“我们先把所有东西都留着”也是一种保留策略，只是一种糟糕的策略。对于重要的数据，我想在设计时就知道：我们需要它多久，为什么；是否有某项法规规定了最短期限，或者另一项规定了最长期限；从什么时候开始计时；以及期满时怎么办：删除、归档、去标识化，副本又在哪里？财务记录可能必须保留一段规定的时间。一位收货人的门禁密码，在配送完成几年后就没有任何用途了。这些决定不能等到数据库变大了再做。
匿名化、假名化、加密、掩码
Section titled “匿名化、假名化、加密、掩码 ”把“Jane Smith”换成 7F92A1。Jane 被匿名化了吗？如果另一张表里仍然写着 7F92A1 = Jane Smith，那就没有。这是假名化：直接标识符被替换了，但数据可以借助单独保存的信息重新关联起来，而且根据 GDPR，假名化的数据仍然是个人数据（第 4 条第 5 款）。匿名化更进一步：数据再也无法被合理地关联到这个人（序言第 26 条）。所以当有人说“我们不需要删除它，把名字去掉就行了”时，要小心。如果这个人仍然可以被合理地识别出来，你就还没有跨过那条线。结果是否满足法律要求，由法务部门判断；架构师的工作是准确说明系统做了什么：它能否被重新关联，还剩下哪些键，映射关系在哪里？
准确地使用这些词，因为它们解决的是不同的问题。加密保护数据免遭未经授权的泄露；获得授权的用户仍然可以解密它。掩码改变特定用户或环境所看到的内容。假名化把直接身份分离出去，同时保留一条回去的路。匿名化消除了合理识别这个人的能力。只有最后一种能让数据不再属于“个人数据”。
法规变成需求
Section titled “法规变成需求 ”法务部门不需要告诉我去创建一个权限集；那是我这一侧的事。法务部门可能会说：“只有具有正当业务需要的员工才能访问这一类个人信息。”然后我来翻译：他们是谁，我们如何识别这一类信息，访问权限如何授予，有人换了工作会怎样，集成能读取它吗，智能体能吗，它能被导出吗，以及我们如何证明谁看过它？**所有者制定策略；架构师负责执行。**法务和合规部门确立义务，数据所有者制定业务策略，而架构师设计执行方式。
从法规到证据：法务部门解释，数据所有者制定策略，架构师让它起作用并且可证明。
而且合规不是一个产品。你买不到“合规：开启”。加密可以支撑一项要求，审计功能提供证据，保留工具执行策略，同意数据支撑被允许的使用，但获得一项功能的许可，并不会让一个架构变得合规。合规来自整个设计：人、策略、流程、数据、控制措施和证据。Salesforce 是其中的一部分，而不是全部。而如果一项策略重要到需要执行，就问一问它是否也重要到需要证明：3 月 17 日谁访问了这条记录，谁修改了这个字段，那次导出包含了什么？模块 6 会讲证据。
隐私会改变全景图
Section titled “隐私会改变全景图 ”在 Steve Trucking，收货人的个人数据通过三个合作伙伴的集成进来。Salesforce 需要它来运营配送；配送小组需要其中一部分，只为自己的停靠点，只在当天；Snowflake 想要配送分析数据；财务需要足够开票的信息，但不需要配送小组看到的那些。而且一个零售合作伙伴绝不能看到另一个合作伙伴的收货人。隐私会改变箭头：某些字段不进入 Snowflake，分析得到的是一个更难识别个人的版本，配送小组只看到自己的停靠点，下游的保留期限与运营的保留期限不同。隐私要求不是放在全景图旁边的东西。它会改变全景图。
比法规存在得更久的问题
Section titled “比法规存在得更久的问题 ”法规会变，所以对任何敏感或受监管的数据，都要带着一组经久不变的问题：
- **它是什么？**个人的、敏感的、财务的、健康的、支付的、儿童的，还是受其他监管的？
- **它存放在哪里？**每一份副本：集成、历史、分析、归档、沙盒、日志、AI 使用。
- **我们为什么可以使用它？**适用什么目的和法律依据？是否涉及同意？
- **谁可以使用它？**人、系统、合作伙伴、集成、智能体。
- **我们保留它多久，**期满时怎么办？
- **这个人能否对它行使自己的权利？**按法律规定的访问、更正、删除、可携带、反对等权利。
- **我们能证明发生了什么吗？**访问、修改、导出、同意、删除、保留。
AI 治理正在成为法律
Section titled “AI 治理正在成为法律 ”AI 又增加了一个受治理数据的消费者。一个 AI 系统能否使用这些数据，为了什么目的，作为落地依据，与什么结合，在输出中复述，记录在哪里，保留多久？对 AI 的治理正在从公司政策走向法律：欧盟的《人工智能法》（Regulation (EU) 2024/1689 (opens in a new tab)，英文）是第一个广泛的例子。它要求什么，取决于具体的系统和用途。对架构师来说，方向是清楚的：AI 并不在治理之外；它是受治理数据的又一个消费者。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 受监管或敏感的数据在全景中的哪里进入、存放、流动和被复制。
- 法务和合规政策如何变成可执行的需求，而不需要架构师去解释法律。
- 接收敏感数据的每个系统是否真的需要它，还是一个更难识别个人的版本就够了。
- 保留、删除、匿名化、假名化、保护和证据如何塑造数据的生命周期。
- 必须存在什么证据，来表明重要的控制措施确实起了作用。
法规不会因为把它们的名字放在一张幻灯片上就变成架构。当它们改变了数据如何被收集、分类、流动、保护、保留、删除和证明时，它们才变成了架构。
- 各项法规的官方来源已在上表中链接，查阅日期 2026-10-14。
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab)（英文）：第 3 条（地域适用范围），第 4 条第 5 款（假名化），序言第 26 条（匿名信息）。
- Regulation (EU) 2024/1689 (the AI Act) (opens in a new tab)，EUR-Lex（英文）。