公務 AI 專案驗收、供應商問卷與委外規格

主題說明

這件事的重點不是「政府以後一定會怎麼標 AI 案」，而是官方文件已經把一個訊號講出來了：公務體系不能只會買 AI、看 AI demo，還要有人能寫規格、設驗收、盯委外、看風險。

數發部目前提供的 V1.0《公部門人工智慧應用參考手冊》已不是試辦草案。它是供機關參考運用、會持續調整的正式手冊；AI 公務人才認定指引則仍是 Beta 文件。兩者的法律狀態與用途要分開，不要合併寫成一套強制採購規範。

2026 年 9 月，數產署也公布臺灣主權 AI 評測結果，AIEC 並持續發布語言模型基準。這表示採購方多了一層可參考的模型證據，但不是「排行榜高分就驗收完成」。模型基準、第三方評測、專案驗收與法遵判斷是四件不同的事。

AI 公務人才認定指引把 履約規格、驗收標準、委辦專案監理 放進 AI 政策人才能力，也把 專案-規劃類 認證列為公務特有項目。這代表政府 AI 專案未來真正難的地方，不一定是模型多炫，而是能不能被管理、被驗證、被移交、被追責。

官方已經講到哪裡

目前官方文件可以確認幾件事：

• 數發部正式手冊把 AI 導入拆成服務評估、專案導入與營運管理，並設有 AI 專案驗收標準專章。
• 手冊列出的常見驗收類型包含模型性能、系統穩定性、使用者體驗與公平性，也提醒可依情境加入營運成本、資源效益、安全隱私與可擴展性。
• AI 政策人才不只做政策規劃，也包含資料治理、倫理法規、風險控管、採購驗收機制。
• AI 政策人才能力裡明確出現履約規格、驗收標準設定與委辦專案監理。
• 專案-規劃類認證重點是 AI 服務導入規劃與履約監理，屬於公務特有項目。
• 專案-技術類則偏向完整 AI 專案實作、需求分析、資料收集、模型建置、系統部署、治理設計、技術審查與品質控管。
• 學習模組裡有「委外 AI 系統規格制定與驗收實務」，訓練目標包含 AI 模型測試、驗收基礎、指標流程、報告判讀與風險辨識。
• 「機關導入 AI 線」把需求定義、導入模式、資料評估、專案驗收與營運管理放在同一條流程裡。
• AIEC 公開的主要評測項目包含準確性、可靠性、公平性、隱私與資安；2026 年 8 月的語言模型基準另看國文、社會與臺灣價值觀等在地化表現。

白話講，政府已經不只是在問「公務員會不會用 AI」。它開始問：AI 專案從需求、資料、委外、測試、驗收到上線後營運，有沒有能力一路管下去。

驗收不能只看模型分數

AI 專案最容易出現的錯覺，是把驗收寫成一個漂亮數字。

例如：

模型準確率達 90% 即完成驗收。

這種寫法太薄。因為它沒有回答：測什麼資料？資料是不是接近真實業務？錯誤類型是什麼？低信心輸出怎麼處理？遇到敏感資料怎麼擋？上線後模型表現變差誰要看？使用者被錯誤影響時怎麼補救？

比較像樣的 AI 驗收，至少要拆成六個面向。

驗收面向	要問的問題	廠商或內部團隊要交付的證據
情境與需求	AI 用在哪個流程？影響誰？哪些情境不能用？	使用情境、需求對照表、排除情境
資料	資料從哪裡來？能不能用？品質如何？是否含個資或機密？	資料盤點、資料處理紀錄、權限說明
模型與系統	模型表現怎麼測？API 或系統如何整合？失敗時怎麼退回？	測試報告、架構圖、錯誤處理流程
風險與法遵	有沒有人工覆核？有沒有偏誤、資安、個資、著作權風險？	風險評估、人工審核紀錄、資安檢核
營運維護	上線後誰監控？資料或模型怎麼更新？事件怎麼回報？	維運計畫、監控指標、事故通報流程
移交與留痕	機關或企業能不能接手？出了事查不查得到？	操作手冊、日誌、教育訓練與移交紀錄

正式手冊也提醒，不同 AI 專案的合理門檻不會一樣。身分驗證、公共服務或會影響權益的用途，不能直接沿用低後果工具的準確率；模型分數也不能取代系統穩定性、使用者測試、公平性與後續維護。要把一次驗收接到持續治理，可以參考 NIST AI RMF 對台灣企業有什麼用，但 NIST 仍是自願性框架，不是台灣採購義務。

模型評測成績不等於專案驗收

AIEC 的模型基準與主要評測項目很有用，但用途要放對位置。它可以幫採購方比較模型、找到要追問的風險，也可以要求供應商說明送測版本、測試日期與結果；它不能單獨證明整套系統已適合某個機關或企業。

評測資料可以回答	評測資料不能單獨回答
某個模型版本在特定基準上的相對表現	供應商實際交付的是否就是同一模型、同一版本與同一設定
國文、社會、臺灣價值觀或準確性等測試線索	你的公文、客服、法務、醫療或金融資料上會不會答對
準確性、可靠性、公平性、隱私與資安的提問方向	權限、日誌、RAG 文件、API、人工覆核與故障轉人工是否真的可用
選模或概念驗證階段的比較依據	個資、著作權、營業秘密、資安與採購契約是否已處理
要求廠商提供更多測試證據的起點	上線後漂移、版本更新、事故回報、停用與移交責任是否已約定

最安全的做法，是把外部評測當成「供應商主張的佐證之一」，再用自己的真實情境測試。數產署新聞稿也把評測定位為協助業者掌握產品優勢與精進方向、讓使用端依實際場域選擇模型；這和通案合規證書或固定採購門檻不同。

採購前先問供應商 12 題

這不是主管機關核定問卷，而是依官方手冊、人才指引與評測資料整理的需求訪談底稿。答案若只有「有」、「支援」或「業界領先」，都還不算可驗收。

類別	要問供應商	應拿到的證據
產品身分	實際交付的模型、版本、部署位置與第三方服務是什麼？	版本清單、架構圖、次處理者或外部服務清單
使用邊界	系統可做、不可做及必須轉人工的情境是什麼？	使用情境、排除情境、轉人工規則
資料來源	訓練、微調、RAG、提示詞與紀錄各用了哪些資料？	資料盤點、來源／授權說明、資料流圖
資料處理	輸入資料會不會留存、跨境、再訓練或交給第三方？	保存刪除設定、合約條款、部署與傳輸說明
權限	使用者、管理者、API 與 AI Agent 能做哪些事？	權限矩陣、金鑰管理、人審與到期撤權設定
測試方法	測試集從哪裡來，是否包含真實業務、邊界與失敗案例？	測試集說明、版本、樣本分層與測試報告
指標門檻	為什麼選這些指標與門檻？高風險錯誤是否另算？	指標定義、通過門檻、錯誤分類與逐案結果
外部評測	提到 AIEC、認證或排行榜時，測的是哪個版本與哪些項目？	官方結果連結、送測版本、日期、適用限制
安全風險	提示注入、資料外洩、越權操作與惡意輸入怎麼測？	安全測試、修正紀錄、攔截與事件處理流程
監控更新	模型、知識庫或規則更新後，誰核准、何時重測？	版本紀錄、變更流程、監控與重新驗收條件
事故責任	發生錯誤、侵權、資安或服務中斷時，誰通知、修復與留證？	服務水準、事故通報、責任與補救流程
移交退出	契約終止時，資料、帳號、日誌、設定與文件如何取回或刪除？	移交清單、可匯出格式、刪除證明與退出測試

問卷的目的不是讓廠商多填一張表，而是把每一個「產品宣稱」接到「可查證證據」與「驗收門檻」。可直接複製的欄位與會議表格放在 AI 專案驗收檢查表。

規格可以怎麼寫得比較不危險

下面不是正式標案文字，只是幫讀者理解「AI 規格要寫到什麼程度」。

不夠好的寫法	比較可驗收的寫法
建置 AI 客服系統	建置可回答特定服務範圍的 AI 客服，列明可回答題庫、不可回答事項、信心不足轉人工、對話紀錄保存、錯誤回報與知識庫更新流程
建置 RAG 知識庫	列明文件來源、更新頻率、權限分級、引用來源顯示、查無資料回覆、測試問題集、回收率與錯誤案例處理
導入 AI 文書工具	定義可用文件類型、不可輸入資料、輸出覆核責任、版本紀錄、敏感資料遮蔽與教育訓練
模型準確率達 90%	定義測試資料集、評估指標、錯誤類型、最低門檻、人工覆核點、上線後監控與重新評估條件

重點不是把規格寫得很厚，而是讓驗收真的能回答：這套 AI 到底能不能在指定情境裡被安全使用。

政府機關與廠商各自要準備什麼

角色	應該先準備
機關或業主	需求情境、資料盤點、風險等級、不可接受的錯誤、人工覆核點、驗收指標、維運責任
AI 廠商	技術架構、模型限制、測試方法、資料處理方式、資安設計、日誌與監控、維運與移交文件
專案管理者	需求變更紀錄、測試與驗收排程、缺失改善追蹤、跨部門溝通、上線後檢討
法務或資安	個資、營業秘密、著作權、委外契約、權限、資料保存、事件通報與責任邊界

接政府案的廠商尤其要注意：政府可能越來越不滿足於「你們模型很準」這種說法。比較有說服力的是你能不能把資料、測試、限制、風險、維運、移交全部講清楚。

民間企業也可以借鏡

即使不接政府案，這套拆法也很適合企業內部買 AI 或導入 AI。

公司真正要問的不是「這套 AI 好不好用」，而是：

1. 它用在哪個流程？
2. 它吃什麼資料？
3. 它錯了會怎樣？
4. 誰要看它的輸出？
5. 上線後誰維護？
6. 出事時查不查得到？

如果這六題答不出來，通常代表專案還沒準備好驗收。

現在不能講太滿的地方

這份主題頁是從數發部正式手冊、AI 公務人才 Beta 指引與課綱，以及 AIEC 官方評測資料整理出的實務方向。正式手冊是供機關參考運用的指南，不是新的採購法規；Beta 人才指引不能寫成已定案制度；AIEC 模型基準也不是通案合規認證或固定採購門檻。2024 年的 AI 產品與系統評測參考指引頁仍是一筆草案預告，AIEC 已實際運作不代表可以反推該草案已成為強制規則。

還要繼續追的是：

• 公務 AI 應用規劃導入能力認證何時正式完成。
• 這套能力分類是否會被各機關放進派訓、任用、採購或專案管理流程。
• 政府 AI 委外案未來是否會明確要求特定 AI 能力、證照或驗收文件。
• AI 風險分類框架、AIEC 評測、資安與個資規範，會怎麼接到各機關的實際採購與驗收。