金融 AI 專案進度怎麼量：階段、觀察期間與接受證據

要知道金融 AI 專案走到哪裡，先確認「數的是什麼」。一家機構可以有多個專案，一個專案可以支援多種工作；機構曾採購 AI，不表示每個專案都在生產運作。

建立以專案為單位的紀錄，寫下任務、範圍、負責人、版本與觀察期間。原型測試、允許使用、正式發布和觀察到的工作品質，是不同證據。這篇提供量測方式，不提供區域市場落地率。

先建一份可回查的專案紀錄

每個專案使用穩定的識別碼，另列機構與工作流程。記錄啟動日期、目前範圍、來源及模型／工具版本、核准資料、適用使用者、接受人員與營運角色。狀態變更留下日期、理由與證據位置。

若專案拆分或範圍改變，保留前後關聯；不要為了讓進度看起來一致，將新範圍當成早已接受。跨機構比較時，也應先確認任務、資料及使用條件是否相近。

NIST AI 風險管理框架提供依情境治理、量測與管理風險的參考。它不設定通用的金融上線率或成功門檻，接受條件仍需依實際任務訂定。

下表可用來設計紀錄，階段安排依本案決定，不要求所有專案都依同一條線前進。

紀錄階段	要確認的範圍	可查看的證據	誰作下一個決定
原型已測試	哪個任務、哪些樣本與限制	測試版本、結果、重要錯誤及未測項目	任務與技術負責人
受控使用已獲同意	使用者、資料、權限、例外及停止條件	適用審查、接受與受控操作紀錄	本案指定的接受與核准角色
生產運作	實際系統介面、營運與支援範圍	發布版本、運作紀錄、事件與接手安排	發布與營運負責人
使用與品質已觀察	符合條件的工作、使用者與期間	完成、退回、覆核、錯誤及成本資料	業務與品質負責人

「已測試」不等於可用於任何資料；「已發布」也不代表已取得足夠使用或品質證據。觀察工作負擔時，把準備、等待、覆核、修正及接手一起算，不只計模型回應速度。

進行中的新專案可能尚未累積完整觀察期間。記為尚無足夠觀察，不要直接列為失敗。資料、權限或決策待定時，記錄暫停原因、責任人與下次決策條件。

如果評估後決定不繼續，保留理由與已完成的學習。停止不適合的工作，可以是明確的管理決定，與發布後無人使用或技術失效不同。缺少紀錄時標示未知，不補成成功或失敗。

若要算階段比例，先固定同一批專案、計算日期及每個狀態的定義。說明分母是全部專案，還是上一階段的專案；追蹤不足、退出與重複專案如何處理，也要能回查。

可以分別查看任務品質、資料及介面、權限、資安與適用要求、流程配合、容量與維運。多個原因可能同時存在。訪談提到某個原因，不表示它已被證明造成全部落差，也不能先排除模型或整合問題。

假設一個條款查詢原型答對開發樣本，但尚未測過歷史契約、不同權限與缺少來源的情況，就仍有技術與評估工作。先處理這些接受條件，再觀察符合條件的使用機會和實際退回原因。

金管會 2024 年金融業 AI 指引是行政、非強制性的風險管理參考，可協助討論客戶影響、資料、自主程度與補救。它不證明某項部署已合規，也不要求採用一個通用的上線漏斗。

專案檢視應產出下一個可執行決定：補評估、解除依賴、縮小範圍、繼續受控使用、移交營運或停止。指定工作、證據、決策人與支援安排，比單一市場百分比更能回答眼前的問題。

現有金融服務範圍可協助界定第一個工作；金融 AI 合規與安全規劃整理需要依實際情境確認的責任與控制。