https://yennj12.js.org/yennj12_blog_V4/tags/pii/Recent content in PII on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-8-pii-deidentification-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-8-pii-deidentification-zh/核心定義：PII 去識別化是在資料進入 LLM 嵌入或推論管線之前，透過抑制、偽名化或格式保留加密，將個人識別資訊轉化為不可直接識別的形式，同時保留資料在分析和 JOIN 場景中的可用性。 一、為什麼面試官問這個 面試官問 PII 去識別化，實際上在測試三件事： 法規意識 vs 技術深度：候選人能否區分「符合 GDPR 的匿名化」與「只是改欄位名稱」的差異？能否說出匿名化後為什麼不能反向推導，以及 k-匿名性、差分隱私如何提供數學保證？ 系統設計能力：AI 管線中 DLP 掃描要放在 embedding 之前還是之後？tokenization 要在哪一層做？Outbound LLM response 還需要反向還原嗎？如何在不破壞語意的前提下讓 LLM 仍然能有效推論？ 取捨判斷：anonymization 讓 JOIN 斷掉，pseudonymization 保住 JOIN 但還需要同意機制——什麼場景選哪個？DEK 洩漏後如何在技術層面執行「被遺忘權」？ 面試情境（面試官會這樣問）： 你正在為一家醫療平台設計 AI 問診助理。用戶提問「我的電話是 0912-345-678，身分證 A123456789，最近診斷出糖尿病，應該怎麼吃？」整段文字要送進 LLM。你的架構如何在保護 PII 的前提下，讓 LLM 仍能給出有意義的醫療建議？同時這些資料未來還要做跨科別的統計分析，你如何設計？ 弱答案長什麼樣：「就把姓名欄位刪掉，或者用星號遮住就好了。」沒有提到 quasi-identifier 重新識別風險、FPE 可逆性與密鑰管理，也不知道 DLP 掃描延遲對管線吞吐量的影響，更沒有提到 outbound 掃描。 **強答案長什麼樣：**從 PII 分類型講到偵測手段（regex + ML hybrid），再到 inbound tokenize → embed → store、outbound LLM response → reverse tokenize → return 的雙向管線，並指出 FPE 的確定性讓跨科別統計 JOIN 仍可行，最後用具體數字收尾：「Cloud DLP 掃描約 30ms/KB，FPE tokenization < 1ms/field，整體管線 p99 < 200ms 仍可達標。」https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part40-pii-security-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part40-pii-security-zh/傳統系統的 PII：存在資料庫，加密，控制誰能查。 AI 系統的 PII：流進 Prompt，流進 LLM，流進 Log，流進 Vector Index。 每一個流動的路徑，都是洩漏的可能。 問題不是「有沒有加密」，而是「PII 根本不應該出現在那裡」。 面試情境 面試官：「客戶是一家醫院，想建一個 AI 助手幫助醫護人員查詢病患病歷和用藥記錄。病患資料是最敏感的個人資訊。你作為架構師，如何設計這個系統確保 PII 不會洩漏？請說明你的設計決策和 trade-off。」 一、為什麼 AI 系統的 PII 比傳統系統更難控制 傳統資料庫系統的 PII 流動路徑（有限、可審計）： Application → DB（加密）→ 取回資料 → 顯示給用戶 PII 節點：1 個（DB） AI 系統的 PII 流動路徑（多節點、難以控制）： 醫護查詢：「李先生今天的血糖值？」 │ ▼（節點 1：Prompt 組裝） Agent Context = System Prompt + Query + Retrieved Docs + History ↑含 PII ↑含 PII ↑含 PII │ ▼（節點 2：LLM API 傳輸） LLM API Call（PII 被傳送到外部服務） │ ▼（節點 3：LLM 輸出） Response（PII 出現在輸出文字中） │ ├──→（節點 4）Application Log（PII 可能被完整記錄） ├──→（節點 5）Trace Span Attributes（PII 可能在 Debug 資訊） ├──→（節點 6）Conversation History DB（PII 持久化） └──→（節點 7）Vector Index（病患姓名被 Embedding 進向量空間） 傳統系統：保護 1 個節點 AI 系統：需要保護 7 個節點，每個節點的保護方式不同 核心結論： 加密不夠。加密是傳輸和儲存的保護， 但 PII 在流進 LLM 的那一刻，加密已經被解開了。 真正的保護是：讓 PII 不需要以明文形式流入不必要的節點。 二、三個安全強化階段 ╔══════════════════════════════════════════════════════════════╗ ║ Phase 1：POC / 概念驗證 ║ ║ 策略：基本防護，確保不發生重大事故 ║ ╚══════════════════════════════════════════════════════════════╝ 必做項目： ├── TLS 1.