https://yennj12.js.org/yennj12_blog_V4/tags/privacy/Recent content in Privacy on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 04:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part2-governance-zh/Mon, 22 Jun 2026 04:30:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/ai-eng-from-scratch-phase18-part2-governance-zh/大多數工程師把 AI 治理當成法務部門的事，等監管機關發函才開始補文件； 正確答案是：治理是系統設計的一等公民，在模型進 production 的第一天就必須量測公平性、記錄資料來源、控制隱私洩露量。 不做治理不是「省力」，是把合規風險、偏見訴訟、資料外洩的成本推遲到最貴的時間點——上線之後。 工程師不需要成為法律專家，但必須懂得把監管義務翻譯成系統元件和可量測的指標。 面試情境 你的團隊正要在 EU 市場推出一個信用評分 AI 系統，PM 說「先上線再合規」，CTO 問你：從工程架構角度，最低限度需要做哪些治理元件才能在 EU AI Act 生效後合法營運？如果資料集中有性別和種族代理變數，你打算怎麼處理偏見？隱私工程用什麼機制確保 GDPR 合規？ 一、核心問題：AI 治理為什麼是工程師的問題 AI 治理在過去五年從「道德宣示」進化為「法律義務」。EU AI Act 在 2024 年正式生效，預計 2026 年高風險系統進入強制合規期；NIST AI RMF 已成為美國聯邦採購的事實標準；中國、英國、加拿大相繼推出對等框架。 工程師為什麼不能把這件事推給法務？ 合規義務落在系統層：EU AI Act Article 9 要求「risk management system」必須以技術文件佐證，不是 policy PDF，是可追溯的程式碼和日誌 偏見來自資料 pipeline：統計公平性的破壞點在特徵工程、訓練集採樣、評估集分割——法務無法在那裡插手 隱私洩露是技術問題：差分隱私的 epsilon 預算、聯邦學習的梯度聚合——這些是數學和工程，不是合約條款 稽核需要系統支撐：監管機關要看 model card、訓練資料來源、版本歷史、A/B 決策記錄——這些必須在 CI/CD 裡自動生成 信用評分這個域的具體風險： EU AI Act 分類：高風險（Annex III, 5b — access to essential private services） GDPR Article 22：禁止純自動化決策影響個人法律地位，除非有明確告知和申訴機制 美國 FCRA/ECOA：對抵押貸款、信用卡的公平貸款義務，違規罰款可達 $1M/天 偏見訴訟：2021 年美國有 12 件 AI 信用歧視集體訴訟，和解金從 $2M 到 $98M 二、三個演進階段（POC → MVP → Scale） ╔══ Phase 1：POC / < 5K 用戶 ══╗ 目標：最低限度治理，讓系統能合法上線做受控測試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.