摘要
供應商展示 AI 助理能回答幾個問題，會議室裡每個人都點頭。但正式驗收時，企業真正需要知道的是：同一版系統遇到舊資料、模糊問題、例外要求或系統故障時，會發生什麼事？誰看過結果？問題是否修好？
這篇給台灣中小企業主、採購窗口與導入負責人一份可與委外團隊共用的驗收流程。它接續委外需求書與報價比較：範圍和價格談妥後，再把「完成」變成雙方能重做、能簽認的證據。
核心結論：驗收的是指定情境下的交付，不是一場 Demo
先固定試點範圍、資料版本、測試案例與參與人員。每個案例留下輸入、預期行為、實際輸出、人工判斷、缺陷處置與複驗結果。只有雙方預先同意的條件已滿足，才進入該里程碑的簽認與付款討論。
澳洲政府 AI 可靠性與安全指引建議驗收標準要具體、客觀、可驗證，並以測試計畫及逐案結果留下紀錄。NIST AI RMF Core也要求記錄測試集、量測方式與接近實際部署情境的結果。這些是方法參考，並非台灣企業的法定驗收格式。
| 驗收層次 | 要拿到的證據 | 不能只靠什麼 |
|---|---|---|
| 範圍 | 本次使用者、資料、功能與排除事項的核定版本 | 提案簡報上的「全功能」描述 |
| 行為 | 正常、資訊不足、舊資料與例外案例的逐案結果 | 供應商挑選的成功示範 |
| 人工控制 | 不確定或高影響輸出如何轉人工、誰能批准 | 畫面上有「審核」按鈕 |
| 缺陷 | 嚴重度、重現步驟、負責人、修正期限與複驗 | 口頭說「已修好」 |
| 交付 | 測試報告、版本、操作與復原說明、待辦清單 | 只有一個可登入網址 |
第一步：把需求書拆成可重做的案例
以「客服查詢產品保固」試點為例，先挑企業真實會遇到的情境。不要只交給供應商一份漂亮 FAQ，還要加入規則更新、資料缺漏、超出授權及系統無法取得來源時的案例。
| 案例類型 | 企業提供的輸入 | 預期行為示例 |
|---|---|---|
| 正常查詢 | 現行保固文件與常見問題 | 找到有效版本，產出可供客服覆核的草稿與來源 |
| 舊版衝突 | 同產品的舊版與新版文件 | 標示版本差異，不把舊條款當成現行承諾 |
| 資訊不足 | 缺少購買日期或產品型號 | 說明缺少什麼資料，請客服補問或轉人工 |
| 例外要求 | 要求超出政策的退款或保固 | 不自行承諾例外，交由有權限的人決定 |
| 故障情境 | 來源暫時無法讀取 | 顯示無法核實，保留人工處理路徑與錯誤紀錄 |
每個案例都應註明所用資料版本、執行日期與環境，以及企業可接受的輸出範圍。若用到客戶個資，先決定是否能以去識別或合成樣本測試，資料處理另依供應商資料處理審查清單核對。
不必照抄別人的「95% 通過率」。案例數量、可接受錯誤與停止條件，要依任務影響及實際資料品質由雙方先協議；高影響動作通常不能用一個平均分數掩蓋個別嚴重錯誤。
第二步：先約定缺陷分級與處理方式
以下是協商用示意，不是產業標準或法定等級。把每一級的定義與處理時間寫進雙方實際文件，避免驗收會議才爭論「這算不算 bug」。
| 示意等級 | 例子 | 建議處理方向 |
|---|---|---|
| 阻斷 | 對外自動發出未批准承諾、洩漏不應取得的資料 | 暫停該功能驗收與對外使用，先確認影響及修正 |
| 重大 | 常見案例持續引用舊政策、人工轉接失效 | 修正後以原案例及相鄰案例複驗 |
| 一般 | 低影響格式或操作問題，有可行人工替代 | 記錄範圍、責任與約定期限；是否影響簽認由雙方決定 |
| 建議 | 不在本次需求書中的新功能 | 放入變更清單，另估工作與費用，不混同既有缺陷 |
特別注意「功能缺陷」與「新增需求」的區分。原約定要有人工轉接卻無法轉接，是交付問題；原約定只做單一語言，驗收時要求再加一種語言，通常要走變更討論。實際責任仍以雙方確認的範圍與契約為準。
第三步：讓修正與複驗留在同一筆紀錄
一筆可用的缺陷紀錄，至少包含：案例編號、執行環境與版本、資料版本、輸入摘要、實際輸出、預期行為、影響程度、提出者、供應商回覆、修正版本、複驗人、複驗日期與結果。涉及敏感資料時，紀錄中只保留必要摘要，原始證據放在受控位置。
複驗不只重跑原本失敗的一題。例如修正舊版保固引用後，也應抽查同產品的現行查詢與資訊不足情境，確認修正沒有讓其他行為退步。完整的模型變更回歸測試可另看企業 LLM 評估集與停損清單；本文關心的是委外交付雙方能否共同認定該缺陷已關閉。
若同一問題反覆出現，先暫停簽認，回頭檢查資料來源、提示詞或流程責任。供應商把問題標成「完成」不等於企業已複驗通過；企業也不應在未提供可重現案例時，要求供應商無限期猜測。
第四步：讓里程碑付款跟可核對的交付對齊
付款節點應在簽約前由雙方與必要的採購、法務窗口確認。可把工作分成「需求與測試計畫核定」「可測試版本交付」「缺陷修正與複驗」「文件與權限移交」等里程碑，再寫明每一階段需要哪些證據、由誰簽認、異議如何提出與處理。
| 里程碑示意 | 可要求的附件 | 簽認前應釐清 |
|---|---|---|
| 測試計畫確認 | 範圍、案例、資料版本、預期行為與排除事項 | 是否雙方都理解本次不做什麼？ |
| 試點版本交付 | 版本與環境資訊、執行紀錄、已知限制 | 企業能否自行重做代表案例？ |
| 缺陷複驗 | 缺陷表、修正說明、企業複驗紀錄 | 尚未關閉的問題是否阻擋本階段？ |
| 最終移交 | 操作、權限、備援、資料與待辦文件 | 誰在供應商離場後負責日常處理？ |
不建議把「看到 Demo」直接等同「可付款」。同樣地，本文也不主張一律扣款或設定固定比例。付款條件、瑕疵處理與智慧財產安排會依實際契約而異，應由企業與供應商明確約定，必要時請專業人士審查。英國政府 AI 採購指南強調評估、持續支援與知識移轉，但它是英國公共部門指南，不是台灣私部門合約條款。
一頁驗收會議紀錄可以這樣寫
試點範圍：本次只驗收單一產品線的內部客服答覆草稿，不含自動寄送、退款或修改訂單。測試版本與資料版本：由雙方在附件記錄。案例結果：正常、舊版衝突、資訊不足、例外要求與故障情境逐案附輸入摘要、實際輸出、人工判斷及截圖／日誌位置。未結缺陷：列出編號、等級、負責人、修正與複驗期限。簽認：企業 owner 與供應商交付負責人各自確認；若有異議，在同一紀錄註明。下一付款節點：僅依雙方契約及本階段已確認的交付條件判定。
這份紀錄最有價值的地方，是讓下一次會議不用重新猜測上次說了什麼。留存方式、簽認權限與資料保護仍以企業政策及雙方契約為準。
常見問題
供應商 Demo 很順，可以直接驗收嗎？
先核對 Demo 是否使用雙方已定義的資料版本與代表案例。若只有供應商挑選的成功案例，請補上資訊不足、舊資料、例外與故障情境，再讓企業人員自行重做。
AI 輸出有一題答錯，就一定不能付款嗎？
沒有通用答案。先看錯誤影響、既定缺陷等級、是否有人工覆核與雙方契約。高影響錯誤可能阻擋特定功能；低影響問題可否列為待辦，應在驗收前約定並留證據，不能事後憑印象決定。
修正後供應商說「已完成」，企業還要做什麼？
用相同案例、明確版本與資料重測，記錄企業複驗人及結果；必要時抽查相鄰案例。未複驗的項目仍應標示為待確認。
下一步
從需求書挑出一條最重要流程，先做五類測試案例、定義缺陷紀錄欄位，再邀供應商共同確認版本與簽認方式。準備上線時，接著看AI 試點人工審核與停損清單；驗收過關後，再確認委外交付要接回哪些資產的閱讀路線。若需要討論實際導入流程，可從FlyPig AI 聯絡入口提出需求。
參考來源與資料時間
資料查核日期：2026-10-07。以下來源提供測試、風險與採購管理方法；本文的表格、缺陷等級與會議範例由 FlyPig AI 整理，並非來源機構的官方合約範本或台灣法律要求。
延伸閱讀
- AI 試點人工審核與停損清單：上一層概念，把企業內部責任和停用條件先定清。
- 換模型前先做 AI 回歸測試：相鄰風險，修正或換版後檢查品質退步。
- AI 導入後每月要檢查什麼？：下一步工具，將試點證據帶入持續維運與停損討論。