原則免費，紀錄計價：演算法問責在臺灣的五本帳

2026年1月14日，《人工智慧基本法》公布。第4條列出七項政府推動AI的原則，從人類自主、隱私保護與資料治理、資安與安全，到透明與可解釋、公平與不歧視、問責；第16條把風險分類框架交給數位發展部；第17條要求政府針對高風險應用明確責任歸屬、歸責條件與救濟機制。條文到此為止。對民間企業，具體義務要接回《個人資料保護法》與各目的事業主管機關的規範，基本法本身未逐條列出。

距公布八個多月，產業討論的位置已經移動，從「要不要管」移到「紀錄怎麼留」。這一步的分量容易被低估。原則本身不產生費用，把原則轉換成事後能被另一個人重新檢查的證據，才開始花錢，而且分別記在五個性質不同的科目上。

義務不寫在基本法裡：三層治理結構

治理安排可以看成三層。最上層是基本法，只給方向。中間是數發部的AI風險分類框架，提供四步操作流程：盤點應用情境、識別風險、評估風險、應對風險；官方定位明確，這套框架是跨部會溝通的共同語言，治理執行的權力與責任仍在各目的事業主管機關。最下層才是企業實際會被檢查的兩張網：目的事業規範，以及個資法。

個資法那一側的介面比多數人想像的寬。第2條把個人資料處理定義為十一種行為，從記錄、輸入、儲存、編輯、更正，到複製、檢索、刪除、輸出、連結與內部傳送。AI系統裡每一次把資料送進模型的動作，幾乎都落在法定處理的範圍內；第19條與第20條又要求蒐集與處理須有特定目的，利用須在必要範圍內。資料欄位、用途、儲存期限與刪除條件因此都要進入紀錄，只寫在隱私政策裡並不構成答案。

國際參考框架指向同一個方向。美國NIST的AI RMF把風險管理拆成Govern、Map、Measure、Manage四項功能，要求清楚記錄角色、責任與人工監督方式，並指出文件紀錄能支援透明度與人工覆核。它在臺灣不具法規效力，適合作為流程設計的參照。共識相當一致：問責的最小單位是紀錄，前提是那些紀錄真的存在。

五類紀錄，五個成本科目

把問責拆到可執行的層級，AI決策至少要留下五類紀錄，而它們對應的錢，性質各不相同。

第一類，用途與影響範圍。記錄這個AI做的是摘要、排序、預測、建議，還是直接觸發動作，連同使用者、受影響的人、可接受的錯誤水準與禁止用途。成本屬於治理工時，一次寫完之後，每次用途變更都要重新評估，不能因為模型名稱沒換就沿用舊紀錄。直接觸發動作的系統影響面最大，重評的頻率也最高。

第二類，資料來源與使用理由。要能回答來源、欄位、合法使用理由、儲存地區、存取角色、次處理者與刪除時間；涉及病歷、醫療、基因或健康檢查資料時，個資法第6條另有特殊限制。這個科目的成本落在盤點與分類：哪些欄位可以送進模型，是先於模型選型的決策。

第三類，模型版本與測試證據，最像工程帳的一本。版本紀錄不能只存產品名稱，至少要記模型版本、系統提示、檢索資料、工具權限、輸出格式、測試資料版本與發布時間，七個欄位缺一項，事後歸因就出現斷點。模型更新後，固定案例、錯誤分類、人工修改率與延遲等指標，要能與上一版逐項比較。

第四類，人工覆核與申訴路徑。覆核紀錄要留下覆核者、覆核時間、看過的輸入與輸出、採納或駁回的理由、覆核後採取的動作；NIST AI RMF Playbook進一步建議記錄人工監督程度、推翻輸出的統計、申訴案件與回應時間，以及誰拍板續用或停用。當AI結果影響資格、付款、僱用或醫療安排，還要設計一條讓受影響者取得說明、要求重新處理的路徑。這是最勞力密集的科目，每一案都要人，無法靠一次性採購消化。

第五類，事故、變更與停用回復。事故發生時要能回答時間點、受影響範圍、輸出內容，以及如何停止、修正與通知。一個現成的對照，是小米AI消除在照片殘留兩條腿、又憑空生成假人的案例：修復要靠OTA更新，而歸因的前提是知道出錯的輸出來自哪一版模型、哪一份系統提示。沒有版本與事故紀錄，連修好了沒有都難以驗證。

成本的時間軸：一段像建置費，一段像訂閱費

五類紀錄的成本時間軸並不一致。用途與資料兩類以一次性盤點為主，變更時才再觸發；版本紀錄隨更新次數增加；覆核與申訴按決策量滾動，屬於按月支出的經常帳；事故回復則是平時建置、出事才動員的待命成本。

更新頻率是這條時間軸上最大的變數。可以參考頂尖模型分差一年縮掉八成的量測：LiveBench的差距從15%收斂到3%，換上更新的模型版本已是每季例行作業，版本比較的測試工時隨之常態化。對更新頻繁的團隊來說，問責支出的性質貼近訂閱費，逐年逐月發生，一次結清的專案預算涵蓋不了它。

規模則決定攤提能力。大型平臺本來就保有日誌、模型登錄與權限管理系統，把問責欄位補進既有架構的邊際成本有限；中小團隊面對自建或採購的選擇，兩者都不便宜。紀錄義務因此帶有規模遞減效果，攤得平的通常是規模較大的那一端。

受惠的三組人，承壓的三種處境

受惠位置有三組。MLOps與模型可觀測性工具業者排第一，版本管理、日誌與測試證據本來就是他們的貨架，問責需求把可選採購變成必備採購。第二組是法遵與稽核服務，從紀錄格式設計到第三方檢查，都是按專案計價的新需求。第三組是大型雲端平臺，當日誌與版本紀錄預設內建，使用者遷移時要連同紀錄一起搬，轉換成本跟著上升。

承壓的位置同樣具體。高風險應用的導入企業排在最前，凡是結果影響資格、付款、僱用或醫療安排的系統，覆核與申訴機制都是省不掉的經常支出。其次是中小團隊，五類紀錄的建置工時，對人手有限的組織相對負擔最重。第三種被壓縮的是部門自行引入AI的影子應用：沒有用途核準、沒有版本紀錄，在覆核與事故回復的要求下等於自動不合格，採購權會往有治理能力的中心單位收攏。

兩種情境，一個共通點

情境一，各目的事業主管機關把風險分類框架寫進行業規範，高風險應用的紀錄義務明確化。五類紀錄從自願變必修，MLOps與稽核服務的採購提前放量，合規成本的行業落差開始顯現，醫療與金融可望先行。

情境二，框架停留在共同語言層級，各機關按自身節奏處理。紀錄投入出現雙軌：有跨市場合規需求的大型企業按高標準自建，其餘企業沿個資法最低線應付，問責深度變成採購能力的函數。

兩種情境指向同一個共通點。基本法把原則寫進法條，帳單卻在每一次模型更新、每一次人工覆核、每一次事故回報裡逐筆累積。能被另一個人重新檢查的紀錄，才是這套治理真正的計價單位。

資料來源：本站編輯參考 APPI News〈演算法問責怎麼落地？AI決策要留哪些紀錄〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。