同意與被遺忘權
另有 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。