AI governance 不只是核准模型，更要提出證據，說明模型的資料來自哪裡，以及誰獲准傳送這些資料。

多數 AI governance 審查都把心力放在模型上。但這是找錯地方了。當稽核人員問起，一份敏感的訓練檔案是如何離開核心銀行系統時，「模型已經核准」並不是答案。銀行需要提供這份檔案歷程的相關紀錄。

 模型是目前還能交代清楚的部分：它已經經過審查並獲得核准，相關文件也已經放在檔案櫃裡，隨時可以供人查閱。

沒有人能完整交代的，是模型用來學習的資料。資料從哪裡來？誰獲准傳送？當一個系統將資料交給另一個系統時，是否有任何紀錄顯示這次交接曾經發生？核准模型無法回答這些問題。資料早在模型看到之前就已經移動，而檔案離開銀行的方式可能根本沒有可供稽核的紀錄。

治理資料的移動，而不只是治理模型

因此，請沿著資料往回追蹤。在模型使用這份檔案進行訓練之前，一個系統先傳送了它，另一個系統則接收了它。這是你最後還能看見誰釋出資料，以及對方是否獲得授權的地方。

這個時刻有一個名稱：檔案傳輸。每次傳輸都有一個邊界，也就是資料離開一個系統並進入另一個系統的那個節點。治理在這個邊界不再只是書面政策，而會轉變成一個關於保管責任的問題：誰傳送了檔案、誰接收了檔案、檔案經過什麼路徑、受到什麼保護，以及數個月後是否仍存在足以證明這一切的紀錄。模型審查無法回答其中任何一項；到了這個階段，檔案早已跨越那道邊界。

你可能會期待最常被引用的 AI governance framework 涵蓋這件事。它幾乎做到了。NIST AI Risk Management Framework (AI RMF) 將可信賴性視為必須貫穿設計、開發、使用與評估的管理事項，而不是一次認證後就歸檔了事。但它仍停留在政策層次：告訴你要管理風險，卻沒有說明如何記錄證據，證明某份檔案在某個夜晚獲得授權並完成移動。

如果缺少的部分是證明檔案按照預期方式移動，那麼你需要的就是一套以檔案移動為核心建立的管理機制。這就是 Managed File Transfer (MFT)：協助管理檔案在系統之間的移動，並在傳輸發生時記錄檔案活動，讓每次傳輸都能事先獲得授權，並可在需要時重現完整歷程。Progress Automate MFT 就是其中一種做法，不必讓每個例外狀況都變成數位鑑識專案。

因此，這裡其實有兩項工作，而混淆兩者正是資料缺口形成的原因：

• 模型治理關心的是系統是否應該存在：模型是否健全，以及是否獲准執行？
• 傳輸治理關心的是模型學習所使用的資料是否獲准移動，以及事後是否能重建這次移動的完整歷程。

傳輸紀錄必須回答哪些問題

當稽核人員或資安主管詢問某次傳輸時，他們並不在意你的架構圖。他們要的是能證明保管責任的答案，而這些答案就在傳輸本身所留下的紀錄裡。

每個月，都有一份檔案離開核心銀行系統，前往執行模型的分析工作區。就把它稱為模型風險擷取檔。第一次檢視時，問題不是「檔案有沒有送達？」而是「我們能不能不只靠記憶，就重建這次移動的完整歷程？」

這次移動是以排程工作執行，而排程工作會保留紀錄。請從這裡開始，但不要只看狀態欄位。Task Run and File Activity reports 會記錄狀態、執行時間、工作如何啟動或由誰啟動、檔案名稱，以及來源與目的地路徑。審查往往在狀態欄位這裡就停止了。02:10 執行的工作顯示 Success，所有儀表板也都表示正常。但 Success 只代表檔案已送達，並不代表檔案來自哪裡。如果你重新指定工作讀取的網路共享資料夾，而工作仍能完成、仍顯示綠燈，那麼你現在餵給工作區的檔案，可能根本不是核准來源所產生的檔案。檢查結果是真的，但資料歷程是錯的。

來源路徑是協助辨識這個問題的欄位之一。這份擷取檔理應只來自一個特定目錄，而報表可以記錄每次執行的來源路徑。因此，保管責任的問題不是「傳輸是否成功？」而是「本季每次執行所記錄的來源路徑，是否都符合唯一核准的路徑？」一次路徑不一致，可能就是一項你能夠辯護的傳輸，與一項你無法說明的稽核發現之間的差別。

接著，還要證明這個路徑背後的授權。Role-based access control (RBAC) 在資料夾層級分配權限，因此排程工作的紀錄會與允許某人執行該工作的權限並列。當問題從「誰執行了傳輸？」轉為「傳輸執行前是誰修改了設定？」時，Audit reports 會記錄系統與工作活動中的使用者操作。身分與金鑰是底層基礎，但保管責任建立在已記錄的路徑，以及背後所對應的權限上。

但這不是模型團隊的工作嗎？

明智的質疑者可能會說，治理應該由模型團隊負責，因為模型漂移與產生幻覺式輸出的問題都發生在那裡。他們的說法有道理，也有相關規範作為依據：銀行監理機關將 model risk management 視為一套明確的專業領域，並對大型銀行如何開發、驗證與治理模型提出正式要求。這項反對意見並沒有錯，只是不完整。

模型治理決定系統可以推論什麼。傳輸治理則協助提出模型核准流程從未涵蓋的證據：資料在移動時是否合法且已獲授權，並且保有能夠延續到下一次稽核的證據。如果只停留在模型核准，你可能確實控制了模型的答案，卻忽略了讓資料抵達模型的來源、目的地與使用者操作。

真正的測試不是你的團隊能否說出政策名稱，而是能否在不猜測哪把金鑰保護了傳輸、哪項權限允許操作人員執行工作的情況下，重建整條路徑。這些紀錄可以提供給團隊目前已使用的風險與作業系統，而不是留在沒有人打開的主控台裡。

這也會讓模型團隊取得更乾淨的紀錄，讓審查能專注於答案的品質，而不是費力辯護答案背後的檔案。

治理資料移動後會帶來什麼改變

將傳輸視為邊界後，討論會變得更加清楚。合作夥伴上線不再只是「我們能不能把檔案送到那裡？」而會變成「檔案送出後，我們能不能提出紀錄，說明誰傳送了檔案，以及檔案受到什麼保護？」當回答稽核要求的紀錄是在檔案移動當下就寫入時，稽核也不再是到處翻找資料的工作。

這並非假設情境。PaperTrl 代表銀行傳送 ACH 檔案，將由人工維護的傳輸指令碼替換為 Automate MFT。Automate MFT 的詳細記錄與稽核軌跡，有助於支援 PaperTrl 因應 SOC 2 與 GLBA 要求所進行的相關工作。

這項道理並不華麗，但確實成立：將強制執行機制放在傳輸附近，並依照嚴謹的日誌管理保存證據，讓治理團隊能在稽核人員找到之前，就先找到這些紀錄。

因此，請先挑選一條重要的傳輸路徑，並證明你能夠端到端交代清楚：

• 工作的來源與目的地
• 工作紀錄：執行時間、是否成功、移動了哪些內容，以及由誰啟動
• 允許操作人員執行工作的資料夾角色
• 與端點相關聯的金鑰或憑證
• 任何設定變更的稽核軌跡
• 工作失敗或重新執行時會發生什麼事

先證明一條路徑。當紀錄足以支援對離開銀行之檔案的審查後，關於模型的討論會變得更容易，而不是更困難。

進一步了解 Progress Automate MFT。