先把 PoC 的問題縮成一句能測試的話
例如「用 AI 提升行政效率」太廣；可以改成「把已授權的詢價訊息整理成草稿，保留缺漏欄位與來源，由行政確認後使用」。這個範圍還沒有包含報價核准、正式發送或訂單寫入，就不要在驗收時默默加進去。
澳洲 Digital Transformation Agency 的 AI 概念驗證到擴大應用指引可作為階段規劃參考。下方表格是 AgentJE 整理的工作範本，實際條件應由業務與技術負責人共同確認。
試點到正式使用
- 確認測試範圍輸入、輸出、排除項目與負責人
- 驗證工作結果正常、缺漏、例外及人工修正成本
- 確認上線條件權限、監控、備援、交接與維護
試點通過後仍要完成上線準備，不能只用展示影片代替驗收。
準備測試資料時，保留沒有拿來調整過的題目
若開發時一直用同一批漂亮範例，最後再拿它們驗收，很難知道換成真實資料會怎樣。準備資料時可分出供討論和調整的樣本，以及留到正式確認時使用的樣本；兩者都要有來源、預期結果及必要的去識別化處理。
Microsoft 的 AI 工作負載測試指引區分模型評估與整個系統的測試。這也提醒我們：文字答得對，仍可能送錯對象、寫錯系統或沒有遵守權限。驗收需要檢查整段流程。
用這張表整理第一批驗收情境
| 情境 | 預期行為 | 應留下的依據 |
|---|---|---|
| 資料完整 | 欄位與核准來源一致 | 輸入、輸出與比對結果 |
| 欄位缺漏 | 標記待確認，不自行補造 | 缺漏清單與接手人 |
| 規則互相衝突 | 依已確認版本處理，或停止等待確認 | 來源版本與處理原因 |
| 使用者沒有權限 | 不取用、不顯示未授權資料 | 測試角色與查詢結果 |
| 外部服務失敗 | 清楚標示未完成，避免重複執行 | 錯誤紀錄與重試結果 |
| 需要人工核准 | 核准前不發送或寫入正式結果 | 核准人、狀態與實際執行紀錄 |
表中沒有設定一個通用通過率。重要的是先說清楚「一題」算什麼、欄位或整筆如何計算、抽樣範圍，以及哪些錯誤不能被平均分數掩蓋。例如不應洩漏的資料，即使其他問題答得很好，仍應阻止擴大使用並先修正。
除了準確度，再看人要花多少時間修
記錄從收到資料到可使用輸出的時間，包含人工核對、修改與例外處理。若 AI 草稿很快，但同仁需要花更久重查，就還沒有證明整體工作改善。可同時保留完成量、失敗量、修正時間與使用者回饋，與原流程比較。
需要估算投資效益時，另看 AI 導入 ROI 與工作指標。本篇著重「這次交付是否符合約定」，不把試點樣本結果當成未來所有工作的保證。
正式使用前，確認接手者做得出來
- 使用者、資料及串接權限由誰核准，是否以實際角色測過。
- 失敗與待核准狀態在哪裡查看，誰接通知。
- 如何停止流程、恢復人工作業，或撤回尚未核准的工作。
- 文件與規則更新後，由誰重新測試。
- 哪些維護包含在交付內，新增功能如何另行確認。
依測試紀錄完成判定
- 核對約定條件逐項查看結果與尚未完成的準備
- 記錄判定理由通過、修正重測或暫停擴大
- 指定下一步由誰處理、何時確認、需要重測什麼
每個結果都留下原因與負責人，避免用「再調一下」無限延長試點。
開案前就能填的驗收範本
試點名稱／流程負責人：
本次要驗證的能力與排除項目：
輸入、輸出與核准來源：
測試樣本與預期答案由誰提供：
測試角色與權限：
正常、缺漏、衝突、失敗與人工核准情境：
通過條件、計算方式與不可接受錯誤：
人工核對及修正時間如何記錄：
問題修正與重測的負責人：
上線、暫停或擴大由誰決定：
操作、停用、維護的交付文件：若團隊不熟悉測試與查證，可以把這份表當作 企業 AI 內訓 的實作題目；若要委託試點開發，則帶著它確認 顧問、系統與驗收交付。兩者的工作內容需要各自說清楚。
常見問題
AI 試點 PoC 通過，代表可以直接正式上線嗎？
不一定。PoC 可能只驗證一項能力；正式上線還要確認權限、錯誤處理、監控、人工接手、操作交接與維護。兩個階段應分開列條件。
AI 導入驗收應該設定幾成正確率？
沒有適用所有任務的門檻。先約定測試集、計算單位、可容忍錯誤與不可發生的錯誤，再依用途決定通過條件，不能只引用沒有前提的百分比。
驗收可以只讓 AI 自己評分嗎？
不宜只依賴模型自評。應搭配可比對的正確依據、程式檢查及業務人員覆核；涉及權限、對外承諾和實際執行結果時，還要直接檢查系統紀錄。
資料查核：2026 年 11 月 5 日。驗收情境與表格為示例，實際條件由雙方約定，未宣稱客戶成果。