金融業導入生成式 AI 的法遵與資安要點:金管會規範、個資、模型治理與稽核軌跡

去年底一家區域型銀行找上我們,想把一套生成式 AI 問答助手推進理財專員的日常。技術團隊三週就做出 Demo,回答流暢、引用精準,主管會議上一致通過。真正卡住的不是模型,是法遵長在上線前一週丟出的一句話:「這個回答的資料,是從哪一份文件、哪一個版本來的?你能在稽核來的時候把它調出來嗎?」

現場沉默了。系統答不出來。專案就停在那裡。

金融業導入生成式 AI 的難處,從來不在能不能做出東西,而在能不能通過檢查。金融 AI 法遵與資安的核心,不是事後補一份報告,而是把可稽核性、資料落地與模型治理從第一天就寫進架構裡。以下是我們幫金融客戶上線時,實際會逐項勾選的清單——寫給 CISO 與法遵長,而不是寫給行銷簡報。

上線前的法遵與資安檢查清單

這張表裡,金融客戶最容易低估的是最後兩欄。

稽核軌跡不是 log 檔案而已。金管會與內稽內控要的是「可還原的決策」:當一位客戶投訴理專給了錯誤的商品說明,你要能證明當時系統引用的是哪一版銷售文件、模型是哪一版、有沒有人複核。這意味著 RAG 系統從設計之初就要把來源版本、切片位置、模型指紋一起寫進每一筆回應紀錄,而不是上線後才想辦法補。補不回來的。

資安面,生成式 AI 帶來的是傳統資安沒有的攻擊面。prompt injection 可以誘導模型吐出系統指令或跨權限資料;知識庫如果沒做列級(row-level)存取控制,一個理專就能問出理應看不到的授信資料。我們的經驗是:權限模型必須綁在檢索層,而不是靠 prompt 叮嚀模型「不要回答」。靠提示詞守機密,遲早會破。

別把治理當成上線後的補丁

最貴的錯誤,是先求 Demo 驚豔、再回頭補法遵。等系統跑起來、業務開始依賴,你要在活體上加稽核軌跡、重做資料落地、補權限控管,成本是原本的數倍,而且往往得停機重來。那家區域型銀行後來多花了兩個月,把來源版本與模型指紋回填進整條檢索鏈,才重新過審。

我們在金融專案的做法,是讓工程師直接進駐現場,和法遵、內稽、資安坐在同一張桌子上,把上面這份清單變成上線的驗收條件——先確定每一筆回答都調得出來、資料都留在該留的地方,再談模型答得多漂亮。Demo 過關不算數,通過稽核、有人天天在用,才算真的上線。