隱私法塑造設計
另有 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（英文）。