https://yennj12.js.org/yennj12_blog_V4/tags/compliance/Recent content in Compliance on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 22 Jun 2026 04:30: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/kubernetes-autoscaling-complete-guide-part8-security-compliance-governance/Mon, 10 Nov 2025 02:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/kubernetes-autoscaling-complete-guide-part8-security-compliance-governance/Part 8 of the Kubernetes Autoscaling series: Complete guide to securing autoscaling infrastructure with RBAC, policy enforcement, compliance frameworks (PCI-DSS, HIPAA, SOC2), multi-tenancy patterns, audit logging, and governance best practices for enterprise Kubernetes.https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-9-data-residence-sovereign-ai-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-9-data-residence-sovereign-ai-zh/資料主權不是「把資料放在某個 bucket 就好」，而是一套覆蓋儲存、運算、網路傳輸、金鑰管理、審計稽核的完整地理邊界保證——任何一層缺口都讓合規承諾形同虛設。 一、為什麼面試官問這個 面試官出這道題，真正測試的是三個維度的工程判斷力： 法規翻譯能力：HIPAA 的「Protected Health Information 不得離開美國」、台灣個人資料保護法（PDPA）的「特種個資需要額外保護措施」、金管會對金融機構雲端使用的指引——這些法規條文候選人能否翻譯成具體技術控制？弱答是「我們用私有雲」，強答是列出五層控制並說明每層的法規對應點。 AI 系統特殊性理解：傳統應用的資料主權相對直覺（資料庫在哪裡），但 LLM 系統的複雜在於：推論時的 KV cache 是暫存資料、Embedding 是資料的另一種形式、Fine-tuning 過程資料會進入梯度計算——這些「衍生資料」的地理位置同樣受合規要求限制。 陷阱識別與風險評估：Batch Prediction 跨 region 執行的預設行為、VPC-SC dry-run 忘了切換 enforce、multi-region KMS key 的金鑰複製行為——這三個是最常在真實合規審計中踩到的地雷，能說出這些才代表有實戰經驗。 典型弱答（5 分）：「我們把 GCS bucket 設定在 asia-east1，資料就在台灣了。」只解決儲存層，完全忽略推論、金鑰、傳輸三層。 典型中答（7 分）：「Vertex AI 要設 region，VPC-SC 要設邊界，要簽 DPA。」方向正確但沒有深度，說不出 VPC-SC 的機制、Batch Prediction 的陷阱、延遲數字。 強答（9–10 分）：系統性列出五層控制，說明 VPC-SC 在控制平面層攔截的原理，主動點出 Batch Prediction 必須顯式設 region，量化 VPC-SC 執行延遲 < 5ms，並提出 GDC 作為最高主權要求的升級路徑。 二、核心原理與技術深度 為什麼 AI 系統的資料主權比傳統應用更難 傳統三層式 Web 應用的資料主權相對簡單：資料庫在 asia-east1，應用伺服器在 asia-east1，問題解決。LLM 系統的難點在於資料在多個地方以多種形式存在：https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part30-constraint-driven-architecture-zh/Thu, 04 Jun 2026 21:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part30-constraint-driven-architecture-zh/大多數的架構設計課程從「最優解」出發。 但 FDE 的真實工作，是從「客戶的限制」出發。 「所有資料不能出 VPC」、「模型不能用 SaaS API」、「每個 API call 都要有審計日誌」—— 這些限制不是問題，是你設計的起點。 面試情境 面試官：「你的客戶是一家銀行。他們的 IT 安全政策規定：所有含有客戶 PII 的資料不能傳送到外部網路，所有 API 呼叫必須在私有網路內完成，並且每個 AI 模型的調用都要有審計日誌。他們想在這個條件下部署一個 RAG-based 合約審閱 Agent。你的架構是什麼？」 一、FDE 面對限制的第一步：分類 收到限制條件，先做分類，不要立刻開始設計架構： 限制分類框架： 類型 1：資料主權限制（Data Residency） 「資料不能離開特定地理區域」 → GCP Region 選擇問題 → 影響：model endpoint 必須在指定 Region 類型 2：網路隔離限制（Network Isolation） 「API 呼叫必須在私有網路內」 → VPC 架構問題 → 影響：需要 Private Service Connect / VPC-SC 類型 3：資料分類限制（Data Classification） 「PII 不能傳給外部服務」 → 資料流設計問題 → 影響：需要 PII detection + 資料遮罩 pipeline 類型 4：審計與合規限制（Audit & Compliance） 「所有 AI 調用要有 audit log」 → Observability 架構問題 → 影響：Cloud Audit Logs + SIEM 整合 本題的限制：類型 2 + 3 + 4，三個同時 二、核心技術：VPC Service Controls（VPC-SC） 這是 Google Cloud 上的金融/政府客戶必備知識：https://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.https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part46-byok-cmek-zh/Mon, 08 Jun 2026 09:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part46-byok-cmek-zh/大多數工程師聽到「CMEK 合規」就只想到：把 Cloud KMS 打開、勾選客戶管理密鑰就完事了。 真正的挑戰在於：當 Vertex AI 向量搜索每秒發起 5,000 次 ANN 查詢、每次都要跨海解密時， 延遲從 30ms 暴增到 12 秒——合規達成了，系統卻癱瘓了。 Staff FDE 的答案是：用信封加密的 DEK/KEK 分層，讓地端 HSM 只做密鑰授權， 日常解密在 GCP Memory Enclave 裡完成，真正做到主權資安與極限性能同時成立。 面試情境 面試官： 某家公營銀行的 CISO 要求所有上傳到 Vertex AI 的 Embedding 向量和 LLM Context Cache 快照，加密密鑰必須由行內地端機房的 HSM 自主控管，絕對不能讓雲端供應商持有明文密鑰。但向量搜索的 SLA 是 P99 < 50ms，Context Cache 的命中率目標是 85%。你如何設計這套系統，讓合規與性能同時成立？ 一、核心問題：為什麼 CMEK 在 GenAI 場景特別難 1.1 金融業的監管壓力 台灣金融監理局（FSC）、PCI DSS Level 1、以及個人資料保護法（PDPA）三重框架對金融業的加密要求達到史上最嚴格水準： 密鑰主權：加密密鑰的控制權必須留在金融機構手中，雲端供應商不得持有明文 KEK 審計可追溯：每一次密鑰使用（加密/解密/輪轉）必須留下不可竄改的操作日誌 密鑰隔離：不同業務線（個人金融、企業金融、投資銀行）的密鑰必須完全隔離 快速撤銷：監管機構要求在 15 分鐘內能夠撤銷任何密鑰的使用授權 1.