https://yennj12.js.org/yennj12_blog_V4/tags/bias/Recent content in Bias 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 用戶 ══╗ 目標：最低限度治理，讓系統能合法上線做受控測試