https://yennj12.js.org/yennj12_blog_V4/tags/anonymization/Recent content in Anonymization on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://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.