AI 專案驗收檢查表

怎麼用這份表

這份表不是正式標案範本，也不是律師意見。它比較像一張會議桌上的工作表：幫業主、機關、廠商、IT、資安、法務把同一件事講清楚。

數發部目前提供的《公部門人工智慧應用參考手冊》是 V1.0 正式版本，並把 AI 專案驗收列成獨立專章。官方頁把手冊定位為供各機關參考運用、後續仍會滾動調整；因此可以拿來補驗收問題，但不能直接寫成所有政府標案都必須照抄的固定規格。

最重要的判斷是：

AI 專案不是 demo 能跑就算完成。要能說清楚它用在哪裡、吃什麼資料、怎麼測、錯了怎麼辦、上線後誰管、最後能不能移交。

可複製欄位

下面這段可以直接複製到文件、試算表或 Notion，再依專案刪減。

面向	檢查問題	驗收證據	狀態
需求	AI 要解決哪個業務問題？使用者是誰？影響哪些流程或權益？	使用情境、需求規格、流程圖	未填
需求	哪些情境不能讓 AI 回答、判斷或自動處理？	排除情境、轉人工規則	未填
資料	使用哪些資料來源？資料是否可合法使用？是否含個資、機密或營業秘密？	資料盤點表、授權或來源說明	未填
資料	資料如何更新、去識別化、保存、刪除與控管權限？	資料處理紀錄、權限表	未填
模型	使用什麼模型、RAG、規則或系統？測試資料是否接近真實情境？	架構圖、測試資料集說明	未填
模型	驗收指標是什麼？錯誤類型、最低門檻、低信心輸出怎麼處理？	測試報告、錯誤案例、轉人工規則	未填
風險	有沒有個資、資安、偏誤、著作權、營業秘密或對外責任風險？	風險評估、修正措施	未填
風險	哪些輸出需要人工覆核？誰覆核？覆核紀錄保存在哪裡？	人工覆核流程、覆核紀錄	未填
維運	上線後誰監控？監控哪些指標？多久檢查一次？	維運計畫、監控報表	未填
維運	模型、知識庫或資料更新時，誰核准？如何留下版本紀錄？	更新紀錄、版本紀錄	未填
移交	廠商交付哪些文件、帳號、設定、操作手冊與教育訓練？	移交清單、教育訓練紀錄	未填
移交	出事時查不查得到人、時間、資料、輸出與操作紀錄？	操作日誌、稽核紀錄	未填

先定義多種驗收指標

數發部手冊提醒，AI 專案有技術不確定性，驗收標準要跟實際用途和後果一起設計。至少先從四類指標組合，不要只放一個平均準確率：

指標類型	驗收時要問什麼
模型性能	測試資料是否接近真實情境？指標、門檻與錯誤類型是否適合這個用途？
系統穩定性	回應時間、可用性、錯誤處理、負載與服務水準是否符合實際流程？
使用者體驗	使用者能不能完成任務、理解限制、取得人工協助並回報問題？
公平性	不同群體的錯誤率或被排除情形是否有明顯差異？如何複查與修正？

依專案需要，還可加入營運成本、資源效益、安全與隱私、可擴展性。門檻應和技術人員、業務使用者及受影響單位一起確認；同一個百分比不會自動適合每種 AI 系統。

採購前供應商問卷

下面可以直接貼進 RFI、需求訪談或採購前會議紀錄。它不是主管機關核定表單；每一題都要追到可交付證據，不能只收「支援」或「符合」兩個字。

題目	要附的證據	驗收門檻	狀態
實際交付的模型、版本、部署位置與第三方服務是什麼？	版本清單、架構圖、外部服務清單	與測試及契約版本一致	未填
哪些情境可以用、不能用、必須轉人工？	使用與排除情境、轉人工規則	覆蓋高風險與例外情境	未填
訓練、微調、RAG、提示詞與日誌使用哪些資料？	資料盤點、來源授權、資料流圖	來源、用途、權限可查	未填
輸入資料會不會留存、跨境、再訓練或交給第三方？	保存刪除設定、部署與合約說明	符合核准的資料邊界	未填
使用者、管理者、API 與 AI Agent 各有什麼權限？	權限矩陣、金鑰管理、人審設定	最小權限且可撤回	未填
測試集如何組成，是否含真實、邊界與失敗案例？	測試集版本、樣本分層、測試報告	可重現且符合實際用途	未填
指標與門檻為何適合本專案？高風險錯誤如何計算？	指標定義、逐案結果、錯誤分類	門檻與錯誤後果相稱	未填
引用 AIEC、認證或排行榜時，測的是哪個版本？	官方連結、送測版本、日期與限制	版本相符且未誇大用途	未填
提示注入、資料外洩、越權與服務中斷怎麼測？	安全測試、修正與事故流程	高風險案例有處置	未填
更新、事故、重新驗收、移交與退出如何處理？	維運、版本、通報、移交與刪除文件	責任、時限與證據明確	未填

更完整的提問理由與證據對照，可回到公務 AI 專案驗收、供應商問卷與委外規格。

外部評測怎麼放進驗收

AIEC 目前公布語言模型基準，也列出準確性、可靠性、公平性、隱私與資安等評測面向。這些資料可以幫你選模、設問題與要求供應商交代證據，但不要把「某模型高分」直接複製成專案通過條件。

至少再補四個核對：

1. 版本核對： 送測模型、實際交付模型、日期、參數與部署方式是否一致。
2. 情境重測： 用自己的文件、使用者、權限、錯誤案例與真實流程測試。
3. 系統重測： 把 RAG、API、提示詞、防護、日誌、人工覆核與故障轉人工一起測，不只測裸模型。
4. 法遵與維運： 另查資料權利、契約、個資、資安、版本更新、事故與退出責任。

數產署 2026 年 9 月的新聞稿把主權 AI 評測定位為協助業者掌握產品優勢與精進方向，也讓使用端依實際場域選擇合適模型。這是很好的採購線索，但不是主管機關替每個專案做完驗收，更不是所有企業的合規證書。

六個驗收面向

面向	要填什麼	不要只寫
需求	業務問題、使用者、流程位置、影響範圍、不可使用情境	建置 AI 系統
資料	來源、權限、品質、個資、機密、保存、刪除、更新方式	使用既有資料
模型	模型來源、測試資料、指標、限制、錯誤案例、人工覆核	準確率達標
風險	個資、資安、偏誤、著作權、營業秘密、對外責任	風險可控
維運	監控指標、更新週期、事故回報、版本紀錄、負責人	廠商維護
移交	文件、帳號、權限、日誌、教育訓練、驗收會議紀錄	完成交付

需求欄位

需求欄位先回答「為什麼要做」。如果這裡寫不清楚，後面資料、模型和驗收指標通常都會歪掉。

• 專案名稱：
• 業務問題：
• 使用者：
• 使用流程：
• 對外或內部使用：
• 會不會影響民眾、客戶、員工或交易決定：
• AI 可以處理的情境：
• AI 不可以處理的情境：
• 需要轉人工的條件：
• 驗收時要看到的業務效果：

資料欄位

資料欄位要回答「AI 吃什麼」。這裡不清楚，後面很容易變成個資、機密、授權或資料品質問題。

• 資料來源：
• 資料負責單位：
• 是否含個人資料：
• 是否含營業秘密或機密文件：
• 是否含第三方著作或授權資料：
• 資料更新頻率：
• 資料品質檢查方式：
• 去識別化或遮蔽方式：
• 讀取權限：
• 保存與刪除規則：

模型欄位

模型欄位要回答「怎麼測」。不要只填模型名稱，也不要只填一個分數。

• 使用模型或服務：
• 是否使用 RAG、微調、規則或外部 API：
• 測試資料集來源：
• 測試資料是否接近真實業務：
• 驗收指標：
• 最低通過門檻：
• 錯誤類型分類：
• 低信心輸出處理方式：
• 不可回答或查無資料時的回覆：
• 人工覆核點：

風險欄位

風險欄位要回答「出錯會怎樣」。這不是恐嚇，而是先把責任和補救方式想清楚。

• 個資風險：
• 資安風險：
• 著作權或授權風險：
• 營業秘密風險：
• 偏誤或歧視風險：
• 錯誤輸出對外影響：
• 自動化操作風險：
• 必須人工確認的事項：
• 事故回報窗口：
• 補救或回復流程：

維運欄位

維運欄位要回答「上線後誰管」。AI 系統通常不是一次性交付，資料、模型、權限、需求都會變。

• 系統負責人：
• 廠商維護窗口：
• 監控指標：
• 檢查週期：
• 模型或知識庫更新流程：
• 版本紀錄保存位置：
• 權限複查週期：
• 異常警示方式：
• 事故回報流程：
• 重新驗收條件：

移交欄位

移交欄位要回答「業主能不能接手」。如果移交不清楚，專案很容易變成只有廠商懂、出事查不到、下次改不了。

• 操作手冊：
• 系統架構圖：
• API 或串接文件：
• 管理帳號與權限：
• 日誌位置與查詢方式：
• 測試報告：
• 限制與已知問題：
• 教育訓練紀錄：
• 驗收會議紀錄：
• 缺失改善紀錄：

驗收會議前的最低檢查

• 有沒有清楚寫出 AI 不能做什麼？
• 測試資料是不是接近真實使用情境？
• 錯誤案例有沒有被分類，而不是只看平均分數？
• 高風險輸出有沒有人工覆核？
• 資料權限、日誌、保存和刪除有沒有說清楚？
• 上線後維運與更新責任有沒有寫清楚？
• 移交文件是否足以讓業主自己查問題？

如果團隊還要把一次驗收接到上線後的責任、監控、事件與停用決定，可再用 NIST AI RMF 對台灣企業有什麼用 補治理流程。NIST 是自願性框架，不是台灣法律，也不會取代採購契約或數發部手冊。

若驗收標的是服務日本客戶或進入日本供應鏈的 AI 系統，還要把日本市場連結、角色、客戶要求、版本與事故通知寫進驗收條件；可搭配日本 AI 事業者指引對台灣企業有什麼用？整理證據，但不能把指引直接當成固定採購規格。

若驗收標的是進入韓國市場的招募、信貸、教育、醫療、公共服務或其他重大決策系統，還要把高影響 AI 自評、必要時的官方確認資料、風險管理、說明、使用者保護、人類監督、公開資訊與五年保存列入交付；可搭配韓國高影響 AI：台灣公司怎麼判斷與留證？，但不能把產業名稱或供應商聲明直接當成官方認定。

不要寫成這樣

常見問題寫法	為什麼不夠
交付 AI 模型一套	不知道用在哪裡、誰使用、如何驗收
準確率達 90%	不知道測試資料、錯誤類型與風險門檻
廠商負責維護	不知道維護項目、時間、回報與責任
系統具備資安機制	不知道權限、日誌、稽核、事件處理
提供教育訓練	不知道訓練對象、內容、紀錄與接手能力

現在不能講太滿

這份檢查表依數發部正式《公部門人工智慧應用參考手冊》、AI 公務人才 Beta 指引與課綱，以及 AIEC 官方評測資料整理，特別是多元驗收指標、履約規格、委辦監理、模型測試、專案驗收與營運管理等概念。

但它不是正式政府採購範本，也不是法律意見。AIEC 模型基準、第三方評測或供應商排行榜也不能單獨證明整套系統合規或驗收通過。正式採購、契約、驗收或爭議處理，仍應由機關、企業、採購、法務、資安與技術團隊依個案處理。