AI 專案驗收檢查表

怎麼用這份表

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

最重要的判斷是：

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

可複製欄位

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

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

六個驗收面向

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

需求欄位

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

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

資料欄位

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

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

模型欄位

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

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

風險欄位

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

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

維運欄位

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

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

移交欄位

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

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

驗收會議前的最低檢查

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

不要寫成這樣

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

現在不能講太滿

這份檢查表是根據官方 Beta 指引與課綱裡的方向整理，特別是履約規格、驗收標準、委辦監理、模型測試、驗收實務、專案驗收與營運管理等概念。

但它不是正式政府採購範本，也不是法律意見。正式採購、契約、驗收或爭議處理，仍應由機關、企業、採購、法務、資安與技術團隊依個案處理。