從資料管線到決策管線：讓銀行 AI 在模型運行前就具備可解釋性

AI 治理總是從模型層開始，但可解釋性往往得從餵給決策系統的檔案著手，早在評分執行之前。

如果您在金融服務業工作，AI 很可能已經在替您做決策。貸款獲得核准、交易被標記為詐欺，而且中間往往沒有任何人工簽核。因此，一個合理的問題是：當其中一個模型拒絕客戶時，您能否向稽核人員說明這項決策的具體原因，而不只是概略描述系統如何運作？

如果誠實的答案是否定的，您並不孤單，而且解決方法可能不是您原本預期的。您不需要是機器學習工程師，也不必拆解模型內部運作來解釋它的判斷。稽核人員要的說明更早就開始了：餵給決策系統的資料從哪裡來、何時到達、是否有人檢查，以及在評分執行前由誰核准。這些部分是可以追溯的。

可解釋性在評分前就開始

在許多銀行作業流程中，決策所依據的資料並不是即時串流而來，而是以檔案形式送達，通常是合作夥伴提供的資料串流或信用評等機構擷取資料；這些資料會在模型處理前，從上游系統交接而來。評分則發生在之後。若這項交接不可見，評分就只是對一個您無法背書的數字，講出一套看似很有把握的故事。沿著檔案往上游追查，最後通常會找到一張沒人負責的工單，以及一個共用磁碟機。決策可能早已送出，但支撐它的佐證資料尚未經過檢視。

當決策背後的檔案能明確證明它是預期會收到、已完成檢查、已核准，並且在評分開始前留下紀錄時，信用決策才具備可解釋性。事後敘述評分結果並不是同一回事。

監管機關十年來一直在傳達類似的要求，但業界持續將它理解成模型問題。這正是 BCBS 239 的核心：Basel Committee 提出的風險資料彙整與報告原則，要求您了解自己的數字，並能展示計算與處理過程。

目前做得如何？不太好。該委員會的 2023 progress report 評估了全球 31 家最大的銀行，結果僅有兩家完全符合規範。

這些銀行未達標的原因並不是模型太弱。而是它們無法追溯自己的資料。報告將問題歸咎於分散的 IT 架構，以及沒有任何團隊持續維護的系統連線。

SR 26-2 是 2026 年取代 SR 11-7 的跨機關模型風險指引，從另一個角度強調健全的開發、驗證、治理及控制機制。若檔案在上游所走的路徑模糊不清，模型仍然會運作，只是它會建立在假設之上（而「假設」其實是對猜測相當客氣的說法）。

美國與歐盟監管機關已不再將此視為選擇性的要求。在美國，Consumer Financial Protection Bureau 於 Circular 2022-03 中告知放款機構，複雜或「黑箱」模型不能成為免責通行證：拒絕他人的信貸申請時，您必須提供所依據的具體且正確理由。您無法提出一個自己無法追溯的理由。在歐盟，AI Act 將信用評分列為高風險項目，並自 2026 年 8 月起要求具備文件化的資料治理及自動事件記錄。

兩方監管機關都不會因為模型很聰明就感到滿意。他們要的是受到治理、且留有紀錄的輸入資料路徑。

傳輸層才是佐證所在

在傳送檔案的系統與執行評分的模型之間，就是傳輸層。它並不亮眼，這也正是它常被忽略的原因；但它同時也是佐證資料產生的地方。Progress MOVEit Automation 和 Progress Automate MFT 可將檔案交接轉化為可供稽核的流程，而非必須憑記憶回想的作業——每次傳輸都會留下紀錄。這份傳輸紀錄正是法遵與營運團隊想看到的資料。

假設某家合作夥伴在週二悄悄變更檔案格式，模型從週三開始做出異常判斷。在有人深入檢查模型評分之前，首先值得排除的問題是：上游路徑是否發生了任何變動。MOVEit Automation 中的 Task Runs report 可顯示工作何時執行及其完成狀態，讓您掌握交接是否依照排程完成。這通常是確認交接是否已傳送的最快方法。它無法直接解決問題，但能提供一個站得住腳的起點。

這一切都不需要風險團隊整天待在傳輸主控台中。自動化層提供 REST API：監控系統或治理、風險與法遵（GRC）系統完成驗證後，即可依排程收集工作詳細資訊與狀態更新，並將它們放在所要解釋的決策旁邊。同一個介面也能執行稽核人員最終會要求的傳輸報告。每天夜間執行一次呼叫，將工作狀態複製到稽核工作區，即可讓佐證資料保持最新。沒有人需要建立第二套監控主控台，也沒有人需要持續盯著儀表板。

這不代表要把每一次傳輸都變成專案。只要呈現少數幾項能證明檔案處理正確，或能及時發現處理異常的關鍵事實：

略過這些項目，可解釋性就會變成事件發生後才補寫的文書作業，而那正是最不該開始撰寫的時候。

規則很直接：只要一個檔案可能改變決策，在決策引擎處理它之前，就應該可以查詢其狀態。應該先讓檔案通過驗證，再進行評分，而不是反過來做。

懷疑論者有一點說得沒錯

敏銳的懷疑論者可能會反駁：模型已經有監控與可解釋性工具，加上人工覆核機制，因此上游管線是其他人的問題。這些工具確實存在，也確實重要；但它們回答的是錯的問題。它們檢查模型如何使用資料，卻沒有任何一項工具能證明這些資料一開始就有資格被納入決策。

這類監控會觀察模型輸出並偵測評分漂移。然而，合作夥伴是否變更了 Schema，或半失敗的傳輸是否卡在一個從未完成的核准佇列後面，則完全屬於不同層次，是輸出監控無法觸及的範圍。

這種盲點的代價往往無聲無息：過期、未經核准的檔案被當成乾淨資料通過，而沒有人察覺；直到數個月後，當稽核人員要求提供某項決策背後的紀錄時，問題才浮現，而答案是沒有人保留這些資料。

傳輸狀態與驗證結果應納入決策紀錄中。若將它們視為後勤管線作業，就會掩埋稽核人員真正會要求查看的唯一佐證項目。一份能顯示誰在何時變更了什麼內容的稽核報告，可將傳輸路徑從人們口頭描述的故事，轉化為審查人員可檢視的資料血緣。將這份紀錄放在風險與法遵團隊原本就使用的地方，您提供的就不只是安撫性的保證。

在下一次模型審查之前，請確認傳輸狀態與驗證結果可在擁有決策權責的工作流程系統中查詢。也請將稽核歷程加入同一個檢視畫面。若這些紀錄仍散落在各個儀表板與電子郵件討論串中，模型就已跑在控制機制之前，而您正在解釋自己無法辯護的決策。

深入了解 Progress Software 提供的解決方案：MOVEit for banking 和 Automate MFT for banking。

文章來源: From Data Pipeline to Decision Pipeline: Making Banking AI Explainable Before the Model Runs