Deborah Raji 為什麼說 AI 稽核不能只是驗收？從偏誤測試到部署後的責任

Deborah Raji 為什麼說 AI 稽核不能只是驗收？從偏誤測試到部署後的責任

Deborah Raji 真正改變的，不是替 AI 多加一張檢查表，而是把問題從「模型準不準」推到「誰有權驗證、驗證後能不能改變決定」。一套系統即使在基準測試上表現漂亮，也可能在真實部署中傷害特定群體；若稽核只發生在產品上線前的最後一刻，它往往已經太晚。

Raji 長期研究演算法稽核、模型評估與 AI 問責。她的核心判斷很直接：AI 稽核不是公關式的合格章，而是一條能追溯目的、資料、測試、部署與修正責任的制度鏈。缺少這條鏈，企業再多談公平、透明與安全，也很容易只留下漂亮原則。

實體索引｜AI 稽核與責任實體

• 研究者與系統：Deborah Raji為什麼說AI稽核不能只是驗收？從偏誤測試到部署後的責任；核對 Deborah Raji、模型／資料、偏誤測試、部署場景、稽核方法、受影響者、責任主體與時間。
• 原文錨點：Deborah Raji 真正改變的，不是替 AI 多加一張檢查表，而是把問題從「模型準不準」推到「誰有權驗證、驗證後能不能改變決定」。一套系統即使在基準測試上表現漂亮，也可能在真實部署中傷害特定群體；若稽核只發生在產品上線前的最後一刻，它往往已經太晚。 Raji 長期研究演算法稽核、模型評估與 AI 問責。她的核心判斷很直接：AI 稽核不是公關式的合格章，而是一條能追溯目的、資料、測試、部署與修正責任的制度鏈。缺少這條鏈，企業再多談公平、透明與安全，也很容易只留下漂亮原則。
• 治理脈絡：把資料、測試指標、模型版本、部署監控、申訴、修正與組織責任連成完整生命週期。
• 編輯界線：區分測試結果、研究者主張、公司稽核與規範性建議；稽核不是一次驗收，也不能取代部署後監測。

重點快讀

• Deborah Raji 的重要貢獻，是把 AI 稽核從單次測試推向完整生命週期：系統要做什麼、資料怎麼來、誰會受影響、如何測試、上線後如何追蹤，都必須留下可檢查的證據。
• 模型效能與社會責任不是同一件事。準確率高，不代表用途正當，也不代表錯誤不會集中落在特定人身上。
• 內部稽核有較完整的資料與系統存取權，外部稽核則較能提供獨立挑戰；兩者不能互相取代。
• 稽核報告若沒有後續修正、重新測試、暫停部署或外部追蹤的機制，容易淪為風險文件，而非問責工具。
• 對台灣的企業與公共機構來說，導入高影響 AI 前最該先問的，是系統是否必要、誰承擔錯誤、能否拒絕與申訴。

背景與核心脈絡

Inioluwa Deborah Raji 是研究演算法偏誤、模型評估與 AI 問責的研究者。她與 Joy Buolamwini 的工作，讓外界更具體看見商業臉部分析系統可能出現的群體差異；而她後續關心的問題更難：發現偏差之後，組織究竟如何把發現轉成能影響產品決策的制度？

2020 年，Raji 與多位研究者共同提出〈Closing the AI Accountability Gap〉，主張把內部演算法稽核放進產品開發全程。這份研究的出發點不是把工程團隊變成更慢的行政流程，而是承認 AI 的風險往往無法只靠最終測試抓到：資料來源、預定用途、部署環境、使用者行為與組織誘因，都會改變一套系統實際造成的後果。

這條問題線和 Timnit Gebru 的資料責任、Cathy O’Neil 對高風險模型的批判，以及 Frank Pasquale 對審計權的要求彼此相連。Raji 補上的，是如何讓這些原則真正進入產品決策。

AI稽核的關鍵，不是多做一次測試，而是先把問題問對

許多團隊把稽核理解成產品完成後的檢查：選一組資料、跑幾個指標、確認模型沒有明顯偏差，然後準備上線。但 Raji 的觀點指出，這種做法太接近驗收，而不是問責。因為當系統的目標、資料來源與部署場景都已經被固定，很多最根本的風險早就被帶進產品。

更有用的起點是把問題往前移：這個系統預計替誰做什麼判斷？它會影響什麼權益？哪些人可能被資料忽略、誤讀或過度監控？在什麼條件下，模型建議不應被採用？這些問題看似不像技術測試，卻決定了技術測試究竟要測什麼。

例如，一個能辨識影像的模型，用在相簿整理與用在身分驗證，風險完全不同；一個能預測付款違約的系統，用於內部提醒與用於直接拒絕服務，也會有不同後果。模型本身未必改變，但用途一變，稽核的標準就不能照搬。

稽核真正要追問的，不是模型是否看起來夠好，而是組織是否有資格在這個場景裡使用它。

準確率高，不代表系統已經對人負責

AI 團隊最容易交出的成績單，通常是準確率、錯誤率、速度與成本。這些指標當然重要，但它們只能回答系統在特定測試條件下做得如何，無法自動回答系統是否適合被部署在現實世界。

一套模型可以在平均表現上很穩定，卻對少數語言、罕見情境、特定地區、不同膚色、特定年齡或不同設備條件有明顯落差。它也可能技術上運作正常，卻把人推進不合理的程序：讓求助者更難取得服務、讓創作者無法理解降權理由，或讓前線人員過度依賴一個看似客觀的分數。

這也是 Raji 與 Joy Buolamwini 的研究脈絡為何重要。群體差異不是只有統計上的細節；當技術被放進招聘、金融、治安、教育、醫療或公共服務，錯誤會變成某些人更高的拒絕、監控與證明成本。

內部稽核與外部稽核，各自看見不同的盲點

內部稽核的優勢，是能接觸訓練資料、產品文件、決策紀錄、模型版本與部署流程。它比較有機會找出問題從哪個環節開始，也能在產品尚未廣泛上線前提出修改，甚至建議停止某個高風險用途。

但內部稽核也有明顯限制：稽核者仍在組織內部，可能面對時程、營收、主管權限與產品目標的壓力。外部稽核則相反。它通常缺少內部資料與完整系統存取權，卻能提出組織不願意面對的問題，並將受影響者、研究者、媒體與公民社會帶進監督過程。

比較合理的設計，不是宣稱其中一方足夠，而是讓兩者形成互補：內部機制留下可追溯的紀錄、修正與風險判斷；外部機制檢查這些承諾是否可信、是否被執行，也能對被忽略的風險提出挑戰。Raji 後續對第三方監督的研究，正是提醒稽核不能只靠一張由公司自己簽發的報告。

稽核失敗的常見原因，是它沒有改變任何人的權力

一份稽核報告可能寫得很完整，卻完全沒有改變產品。原因通常不是缺少技術細節，而是稽核結果沒有對應到明確的決策權：誰能要求重新訓練？誰能延後上線？誰能拒絕某個用途？誰要對錯誤修正時程負責？如果這些角色不存在，稽核很容易被收進資料夾，變成組織證明自己「已經關心風險」的文件。

Raji 在較新的研究中進一步提醒，只有部分 AI 稽核能真正轉化為問責結果。差別不只在方法是否嚴謹，也在稽核是否有足夠的制度支撐：結果能否公開、受影響者能否參與、組織是否必須回應、第三方是否有能力持續追蹤。

這和 Danielle Citron 所說的程序正義相通。當系統對人的帳號、名譽、工作、信用或公共權益產生影響，責任不能停留在抽象的模型倫理；人需要知道理由、能更正資料、可以要求真人覆核，也要有實際可用的救濟。

對台灣讀者來說，AI稽核應先從高影響用途開始

台灣企業與公共機構正在把 AI 放進客服、內容分發、支付風險、教育、招募、身分驗證與行政流程。最容易被忽略的，不是模型夠不夠新，而是每一個部署是否留下了人能理解、介入與反駁的空間。

實務上，較高風險的用途至少應先留下五種紀錄：用途與禁止用途、資料來源與限制、受影響群體與可能傷害、測試與失敗情境、上線後的申訴與修正流程。這些紀錄不是為了讓組織看起來更正式，而是讓問題發生時，還找得到責任落點。

對內容工作者、品牌與平台經營者而言，也可以把 Raji 的思路轉成一個簡單判斷：當推薦、降權、封鎖或生成式摘要影響了人們的收入與可見性，平台是否能說明它做了什麼、為什麼這樣做，以及出了錯要怎麼補救？若答案始終只有「系統判定」，那就不是成熟的治理。

從 Deborah Raji 的稽核框架往下讀，Timnit Gebru 幫助理解資料責任從何開始，Joy Buolamwini 說明測試落差如何變成具體傷害，Frank Pasquale 則把問題推向外部審計與資訊不對稱。三者一起構成 AI 問責不該缺少的資料、證據與制度條件。

讀者常問

Deborah Raji是誰？

Deborah Raji 是研究演算法偏誤、AI 稽核與模型評估的研究者。她的工作聚焦於如何讓 AI 系統在開發與部署過程中接受更完整的測試、紀錄、外部檢查與責任追蹤，而非只依賴單次基準測試。

AI稽核和模型測試有什麼不同？

模型測試主要檢查效能，例如準確率、延遲或錯誤率。AI 稽核則更廣，還要問系統的用途是否合理、資料是否有問題、哪些群體可能承擔較高風險、部署後是否可被追蹤，以及發現問題後誰必須修正。

企業自己做AI稽核，算不算可信？

內部稽核有取得資料、程式流程與決策紀錄的優勢，因此不可或缺；但它也可能受產品時程與商業目標影響。較可信的做法是讓內部稽核、獨立檢查、受影響者回饋與必要的外部監督共同存在，而不是只相信公司自己的結論。

AI稽核可以保證系統不會傷害人嗎？

不能。稽核無法消除所有未知風險，但能讓組織更早發現問題、限制不合理用途、留下修正紀錄，並在出現傷害時建立追究與補救的路徑。真正危險的不是系統有風險，而是組織假裝自己不需要知道風險。

一般使用者怎麼判斷一個AI服務有沒有基本問責？

可以先看幾個訊號：服務是否說明資料用途與限制、重要決定是否提供理由、資料錯誤能否更正、是否有真人客服或覆核、申訴是否有明確時限，以及平台是否願意公開錯誤與修正方式。缺少這些條件時，使用者通常只能被動接受結果。

收尾

Deborah Raji 的價值，在於她拒絕把 AI 稽核當成系統出事後才補上的說明書。

一套真正值得信任的 AI，不是從來不被質疑的系統，而是能在被質疑時拿出證據、承認限制、修正錯誤，必要時願意停止的系統。

讓稽核真的能改變部署：四個不可缺的決策權

Raji 的框架若要落到產品現場，第一個控制點不是選哪一套公平指標，而是誰有權提出稽核問題。產品負責人通常最熟悉預定功能，卻也最容易受上線期限與商業目標影響；因此風險、安全、法務、前線服務與受影響群體必須能各自提出失敗情境，不能只接受模型團隊預先定義的測試集。端到端內部演算法稽核框架的重要性，就在於它把價值、範圍、文件與開發階段連在一起，使稽核不再是最後一關的效能驗收。

第二個控制點是證據存取。稽核者需要知道資料版本、模型版本、提示與門檻設定、已知例外、部署地區以及人工介入規則；若只能看到經過整理的平均分數，就無法判斷錯誤是否集中在某些群體，也無法重現產品真正使用的條件。每份結論都應連回可重跑的測試、決策紀錄與責任人，並清楚區分已確認、仍未知與暫時接受的風險。這讓後續版本改動時能比較差異，而不是每次都從一張新的簡報重新開始。

第三個控制點是停線與修正權。發現高風險缺陷後，稽核者必須能要求延後上線、縮小用途、增加人工覆核、重新蒐集資料或撤除功能，且產品團隊若不同意，要留下理由與核准者。沒有這項權力，稽核只會替既定決策補文件。Raji 等人對第三方監督生態的研究也顯示，外部參與是否有效取決於制度設計、資訊權與持續追蹤，而不只是找一個外部單位簽名。

第四個控制點在部署之後。組織要預先設定重新稽核的觸發條件，例如資料分布漂移、錯誤率跨過門檻、申訴集中、用途擴張或供應商更換模型；同時要保留回滾版本、人工替代流程與對使用者的通知方式。UC Berkeley Simons Institute 的官方人物頁概括 Raji 對模型工程選擇、消費者保護與制度問責的研究脈絡。真正成熟的稽核不是保證系統永遠不出錯，而是確保錯誤出現時，有人看得到、有權停止，也能用新的證據驗證修正是否有效。

參考資料

• Inioluwa Deborah Raji 等，〈Closing the AI Accountability Gap: Defining an End-to-End Framework for Internal Algorithmic Auditing〉，FAT*，2020。
• Inioluwa Deborah Raji、Joy Buolamwini，〈Actionable Auditing: Investigating the Impact of Publicly Naming Biased Performance Results of Commercial AI Products〉，AIES，2019。
• Inioluwa Deborah Raji 等，〈Outsider Oversight: Designing a Third Party Audit Ecosystem for AI Governance〉，AIES，2022。
• Abeba Birhane、Ryan Steed、Victor Ojewale、Briana Vecchione、Inioluwa Deborah Raji，〈AI Auditing: The Broken Bus on the Road to AI Accountability〉，SaTML，2024。
• Victor Ojewale 等，〈Towards AI Accountability Infrastructure: Gaps and Opportunities in AI Audit Tooling〉，2024。

稽核的終點不是報告，而是可被追蹤的決策

Mozilla 官方 Fellowship 資料把 Deborah Raji 的研究焦點放在演算法稽核與評估，也把稽核區分成外部稽核、內部稽核與可行動的稽核。這個區分能補上許多「模型通過測試」敘事的缺口：稽核不只是把偏誤數字交給產品團隊，而是要問測試結果會改變哪一項決策、由誰承擔修正成本，以及受影響的人能否知道問題已被發現。

因此，稽核報告至少要有四層證據。第一層是系統做了什麼，例如輸入、輸出、模型版本、使用場景與人工介入點；第二層是它在哪些群體或情境中失效，包括資料不足、語言差異、無障礙需求與邊界案例；第三層是風險如何影響實際權利或資源，而不是只列出一個平均準確率；第四層是決策紀錄，清楚寫出哪些問題必須修正、哪些風險暫時接受、核准者是誰，以及何時重新檢查。

部署後監測才是責任真正開始的地方

上線前的測試只能描述某個版本、某批資料與某組假設。產品進入真實環境後，使用者行為會改變，輸入分布可能漂移，外部供應商也可能更新模型或政策；原本看似穩定的指標，未必代表不同群體仍受到同樣的待遇。完整的 AI 稽核流程，應在部署前就設定重新稽核的觸發條件，例如錯誤率跨過門檻、申訴集中在特定群體、用途從輔助擴大到決策，或模型、資料與供應商發生變更。

監測也不能只由開發團隊自己看儀表板。較可靠的安排是把產品、工程、風險、安全、法務、客服與受影響社群的訊號放在同一個回應流程中，並預先定義誰可以要求暫停、縮小用途、增加人工覆核或回滾版本。這種停線權不是對創新的否定，而是把「出了問題誰負責」從口號變成部署條件。若組織沒有替代流程，前線往往只能繼續使用有缺陷的系統，稽核就會淪為事後備查文件。

如何把稽核結果轉成可驗證的改善循環

一份可執行的稽核結論，應該能在下一輪驗證中被反駁或確認。團隊可以為每個風險建立責任人、修正期限、證據位置與重新測試方法；修正後不只重跑原本的基準，也要檢查是否把錯誤轉移到另一群體，或因增加人工審查而產生新的等待與拒絕成本。若風險無法立即消除，就必須公開暫時限制、適用範圍與申訴方式，讓使用者知道系統的能力邊界。

這也解釋了為什麼「通過稽核」不是永遠有效的標章。稽核回答的是在特定時間、特定用途與特定證據下，系統是否達到某個可接受條件；責任則要求組織持續觀察、回應與修正。閱讀 Raji 的工作時，最值得帶走的不是一套固定檢查表，而是把稽核放進產品生命週期：先界定問題，再蒐集可重現證據，讓不同角色能挑戰結論，最後把修正與追蹤寫回治理紀錄。

延伸閱讀：Mozilla Foundation 官方作者頁：Deb Raji；Mozilla Foundation 官方 Fellowship 介紹。本文新增肖像僅用於辨識作者，不能被解讀為任何稽核結果或機構背書。