為什麼銀行的 GenAI 專案卡在資安審查?法遵長最該問工程團隊的 7 個問題

去年冬天,一家區域型銀行的資安長把我們找去。他們的 GenAI 客服助理專案卡在資安審查已經第七個月,概念驗證早就過了,業務單位天天催,但資安委員會就是不放行。開會時我問了一句話,全場安靜:「你們現在爭的,到底是這個模型會不會出事,還是沒有人能證明它出事時你們查得到?」

沒有人答得上來。這就是問題所在。

多數銀行 GenAI 資安審查卡關,不是因為技術做不到,而是因為法遵長(CCO)和資安長(CISO)問的問題,跟工程團隊準備回答的問題,根本不在同一個平面上。工程團隊帶著「準確率 92%」的投影片進場,審查委員要的卻是「當監理官上門,你能不能在四小時內還原這筆對話為什麼這樣回」。這兩者之間隔著一條護城河,而多數專案就淹死在裡面。

銀行 GenAI 資安審查真正的死因,不在模型本身

我們經手過的金融業案子裡,被擋下來的 GenAI 專案有一個共同特徵:它們在「能用」和「能被稽核」之間,只做了前者。Demo 那天模型對答如流,但沒有人回答得出資料流向、留存邊界、以及出錯時的歸責路徑。監理環境下,一個查不到來源的正確答案,風險高於一個可追溯的錯誤答案。

法遵長不需要變成工程師。但你要能問對問題,逼工程團隊把地基露出來。以下七題,是我們進場前一定會替客戶的審查委員先問一輪的。

法遵長該丟給工程團隊的 7 個問題

第一,資料出了行內邊界嗎? 問清楚:prompt、檢索到的內文、模型輸出,三者分別停在哪裡。用外部 API 的話,合約有沒有寫明「不得用於訓練」與資料留存天數?很多團隊只答得出第一段。

第二,這筆回答的來源,你調得出來嗎? RAG 系統若不能對每一句輸出指回它引用的原始文件段落與版本,你就無法回應客訴、也無法過稽核。可溯源不是加分項,是入場券。

第三,幻覺發生時,誰先看到、系統怎麼擋? 要問的是「防呆機制在哪一層」——是靠 prompt 求模型別亂講,還是有獨立的事後檢核、信心門檻、以及低信心時強制轉真人?前者不算控制,只算祈禱。

第四,權限跟著人走,還是跟著模型走? 一個能存取全行知識庫的助理,若不繼承提問者本人的資料權限,等於開了一條繞過既有存取控制的側門。這是最常被漏掉、也最致命的一題。

第五,你們留了多少證據,能撐多久? 監理調閱往往回溯數年。問日誌保存了什麼:輸入、輸出、引用來源、模型版本、時間戳。只留輸出而不留上下文的日誌,等於沒留。

第六,模型換版時,誰重新驗證? 供應商悄悄升級模型是常態,而昨天通過測試的行為,今天可能就變了。要有版本鎖定或回歸測試機制,否則你的合規狀態每週都在悄悄失效。

第七,出事的時候,責任在合約的哪一行? 模型給了錯誤的理財建議、洩漏了客戶資料,追償條款寫在哪、上限多少、你這邊要自留多少風險。這題答不出來,前面六題答得再好也沒用。

審查不是關卡,是設計輸入

我們的經驗是,把這七題當成「上線後才補」的清單,專案九成會卡死;把它當成第一天的設計輸入,審查反而變快。差別在於,前者要工程團隊回頭改地基,後者一開始就把稽核性、權限繼承、日誌留存當成功能寫進架構。

這也是為什麼我們做金融業導入時,會讓工程師直接坐進客戶的資安與法遵會議,而不是交付完 Demo 就走人。因為在銀行裡,Demo 很美從來不算數——能通過審查、能被監理官調閱、而且真的有理專天天在用,才算把這件事做完了。