同意与被遗忘权
另有 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)
第 5 个模块，共 6 个，属于 Data Architect 课程第 5 章数据质量与治理。每个模块都可以单独阅读。 上一篇：隐私法塑造设计 · 下一篇：保护、保留与证明
**本模块回答的问题：**如何为同意，以及为删除一个人的数据而做设计？
Steve Trucking 有一位收货人的电话号码。一个简单的问题：**我们可以给他们发短信吗？**也许可以。关于今天的配送？明天的？我们可以用这个号码做促销吗？如果他们说过不要短信，或者同意接收配送更新但拒绝营销，后来又改了主意呢？
再看另一个方向。收货人说：**删除我的个人信息。**它在哪里？多半在 Salesforce，但我们已经知道那不是完整的答案。它来自某个零售合作伙伴。它可能在一个客户数据平台、字段历史记录、某个归档、一条配送备注、一次导出、一份集成日志、一次智能体对话里。同意和删除听起来像是政策问题，但最终必须由系统来回答。这就是架构。
同意是数据
Section titled “同意是数据 ”第一条原则：**同意是数据。不要把它简化成 Has_Opted_In__c = true。真正的问题从来不只是“他们同意了吗？”，而是同意了什么，通过哪个渠道，用哪个地址或号码，为了什么目的，什么时候，后来有没有变化，我们能证明吗？**如果业务要根据这些答案做决定，它们就必须作为结构化数据存储下来。隐私政策里的一段话是不够的，网页表单上的一个复选框也不够：复选框记录的是一个事件；架构必须保留这个事件的含义。
使用 Salesforce 已经构建好的模型
Section titled “使用 Salesforce 已经构建好的模型 ”我的立场是：**尽可能使用开箱即用的同意模型，**而不是用自定义字段重建同样的东西。Salesforce 的同意数据模型在四个层次上管理同意，每一层都是一个更具体的问题（Understand the Salesforce Consent Data Model (opens in a new tab)，英文）：
- **全局同意，放在个人（Individual）上：**这个人是谁，他们是否对一切都说了不？
- 互动渠道同意（联系点类型同意，Contact Point Type Consent）：我们可以使用这类渠道吗，比如短信或电子邮件？
- **联系点同意：**这个具体的电话号码或电子邮件地址呢？
- **数据使用目的：**出于什么原因：配送通知、服务、营销？
把它们合在一起，架构就能回答**“我们可以通过这个联系点、为这个目的使用这个人的信息吗？”**，这比“同意 = 是”有用得多。任何与某个个人相关的记录都可以参与进来：潜在客户、联系人、个人客户、用户。
四个问题，一个比一个具体。单个选择加入标志一个也回答不好。
目的很重要
Section titled “目的很重要 ”一个零售合作伙伴把收货人的号码发给 Steve Trucking，是为了让配送小组协调配送。这并不会让收货人成为一条营销线索。同样的数据可以有不同的被允许用途：配送协调、服务回访、营销、AI 个性化。如果政策或法律对它们区别对待，模型就必须能把它们区分开。问题不是我们有没有这个电话号码？而是我们被允许用它做什么？
而且同意并不总是法律依据。有些用途依据的是法律规定的其他理由，而这由法务部门来判定。不要构建一个假设每个隐私决定都是一个选择加入复选框的架构。要支持政策所规定的任何情况：如果某种用途取决于同意，就为同意建模并执行它；如果适用的是另一种依据，仍然要存储决定这种用途是否被允许所需的信息。
同意有生命周期，也有权威来源
Section titled “同意有生命周期，也有权威来源 ”人们会给出同意，撤回同意，改变偏好，更换号码。业务会增加新的目的；法律会变化。所以要设计生命周期：选择了什么，什么时候，如何选择，为了哪个目的，以及撤回时会发生什么。而事情在这里变得有趣：当一位收货人撤回同意时，Salesforce 知道了。消息平台知道吗？分析系统知道吗？智能体知道吗？同意只存在于一个系统里，而其他系统却按照过时的许可行事，这算不上什么控制。
这就意味着要问**哪个系统是同意的权威来源。**Salesforce、一个偏好管理平台，还是别的地方？不管答案是什么，都不要让五个系统各自独立地决定同一个人是否同意了同一种用途。同意需要任何受治理数据所需要的东西：一个所有者、一份权威记录、一种同步方式，以及执行。
现在这个人说：忘掉我
Section titled “现在这个人说：忘掉我 ”第一反应是删除联系人，然后就算完事了。但这个人的数据可能存在于联系人、配送、配送备注、个案、照片、字段历史记录、Snowflake、归档、集成日志、搜索索引或智能体的对话历史中。这就是为什么我关于删除的立场要从更早的时候开始：**在实践中，删除既少见又困难，所以先控制个人数据去往何处。**设计成让它落在尽可能少的地方。然后，当请求到来时，在能够满足政策的地方对它做混淆或解除关联处理，并追查每一份副本：字段历史记录、归档、Data 360，现在还有搜索索引和智能体对话。
不要等到请求来了才开始追查。到那时，才开始了解全景就太晚了。模块 3 的词典、血缘和分类不是文书工作；正是它们让这一切成为可能。你已经知道哪些字段存放个人数据，以及副本去了哪里。
“忘掉我”请求意味着要为每一份副本做出决定。
时钟已经开始走了
Section titled “时钟已经开始走了 ”这些请求都有期限。根据 GDPR，组织必须在不过分拖延的情况下处理个人的请求，并且在收到请求后一个月内处理；对于复杂或数量众多的请求，期限可以再延长两个月，但必须在第一个月内告知这个人，并说明理由（第 12 条第 3 款，Regulation (EU) 2016/679 (opens in a new tab)，英文）。其他法律有各自的期限；法务部门会告诉你哪些适用。无论如何，一个月都不够你去摸清全景图。副本地图必须赶在这个期限之前就画好。
删除、去标识化还是保留？
Section titled “删除、去标识化还是保留？ ”一个请求并不一定意味着所有地方的所有东西都要消失。有些记录必须或者可以保留；有些运营记录可以留下，但不再能识别出这个人；有些数据可以去标识化。由适用的政策和法律来决定；架构逐个地点地支持每一种结果：删除它，去标识化它，或者根据经批准的要求保留它（那么谁可以看到它，看多久，为什么？）。
记住模块 4 的区别。只有当这个人无法被合理地重新识别时，解除关联才算是遗忘。假名化的数据仍然是个人数据。不要把混淆当作绕过法律要求的捷径。
你找不到的东西，你就删不掉
Section titled “你找不到的东西，你就删不掉 ”在你能删除某人的数据之前，你得先找到他们。请求来自一个电子邮件地址。一个零售合作伙伴发来的是“Jane Smith”，另一个发来的是“J. Smith”，电话号码还换过。收货人根本不是一个联系人；他们的详情放在每一次配送上。同一个人收到过两个不同合作伙伴的配送。一个系统通过电子邮件认识他们，另一个通过外部 ID。删除依赖于身份，而你不想因为匹配得过于激进，就删掉了别人的数据。身份架构是隐私架构的一部分。
Steve Trucking 让这件事更难了。一个零售合作伙伴绝不能看到另一个合作伙伴的配送或收货人。如果同一个人收到过两个合作伙伴的配送，运营上必须把这两种关系分开，而隐私上可能仍然需要跨越两者找到这个人。不要通过打破安全边界来解决隐私问题，也不要为了保护边界而让隐私请求无法完成。架构必须两者兼顾。
照片和自由文本也是数据
Section titled “照片和自由文本也是数据 ”人们很容易把隐私想成字段：姓名、电子邮件、电话、地址。但 Steve Trucking 每年要拍几百万张配送照片，其中有些拍到了人或住宅内部。一项只看结构化字段的保留或删除策略是不完整的；一项忽略文件、文档、转录文本、日志以及 AI 提示和回复的策略也同样不完整。
而自由文本是危险的。你删掉了姓名、电话和地址，然后发现了这条配送备注：*“打电话给 Jane，602-555-0198。门禁密码 4821。院子里有狗。”*它就在那里。把配送备注分类为敏感，只能告诉你那里可能有问题；它并不能找出并删除文本中的个人数据。有时最好的答案是从一开始就阻止不必要的个人细节落到那里。先控制个人数据去往何处。
Privacy Center 是一个工具，而不是整个架构
Section titled “Privacy Center 是一个工具，而不是整个架构 ”Salesforce Privacy Center 能帮助运行这些流程。它的被遗忘权策略是按对象构建的，用来覆盖你想删除的所有东西，并针对某条具体的客户记录运行（Delete Data with Right to Be Forgotten Policies (opens in a new tab)，英文）。这很有用。但“我们买了 Privacy Center，所以我们完事了”不是一个架构。这个人的数据可能存在于任何单一工具都够不到的地方：Data 360、数据仓库、合作伙伴系统、归档、日志、搜索、文件、智能体对话。企业仍然需要一个企业级的答案，而在依赖每个工具之前，你需要核实它实际覆盖了什么。
可携带性与证明
Section titled “可携带性与证明 ”有些法律还赋予人们获取自己数据副本的权利。注意，这是同一个发现问题：删除问的是**这个人的数据在哪里，以便我们对它采取行动？可携带性问的是它在哪里，以便我们提供它？**两者都依赖于身份、分类、血缘、系统清单和所有权。
然后是：你如何证明你做了？收到请求，核实身份，搜索各个系统，采取行动，记录例外，说明保留数据的理由，记录完成。这里有一种真实的张力：你在删除某人的个人数据，同时又要保留足够的证据来表明你妥善处理了这个请求。这正是架构师不应该自己发明保留规则的原因。必须保留什么证据，由法务和合规部门决定；架构保留这些证据，而不保留本该删除的数据。
**考试之外：AI 改变了什么。**AI 带来了新的目的和新的副本。为提供服务而使用数据的许可，并不自动涵盖为智能体提供落地依据、个性化或训练；数据使用目的正是区分它们的自然之处。而个人数据可能会残留在提示、落地上下文、对话、摘要、搜索和向量索引以及日志中。如果 AI 层仍然记得，“我们删除了源记录”就不是一个完整的答案。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 同意和被允许的用途如何建模，让系统能回答是谁、哪个渠道、哪个联系点以及什么目的。
- 哪个系统是同意的权威来源，以及撤回如何到达每一个据此行事的系统。
- 个人数据可能扩散到哪里：字段、自由文本、文件、历史、分析、归档、集成、搜索和 AI。
- 一个请求如何找到正确的人，并在每个地点驱动删除、去标识化或经批准的保留。
- 保留什么证据，来证明同意和隐私请求得到了妥善处理。
同意和删除看起来是相反的（我们可以使用这些数据吗？我们能停止并删除它吗？），但它们建立在同样的基础之上：身份、目的、分类、血缘、所有权、执行和证据。使用标准的同意模型，控制个人数据去往何处，知道副本在哪里，并在第一个请求到来之前就设计好删除流程。当有人问“你们能忘掉我吗？”时，架构需要一个比“我们觉得可以”更好的答案。
- Salesforce Help，Understand the Salesforce Consent Data Model (opens in a new tab)（英文），查阅日期 2026-10-14。
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab)（英文），第 12 条第 3 款，处理请求的期限，查阅日期 2026-10-14。
- Salesforce Help，Delete Data with Right to Be Forgotten Policies (opens in a new tab)（英文，Privacy Center），查阅日期 2026-10-14。