先定義驗收的對象，不要只驗收模型
AI 專案的驗收範圍通常比傳統軟體更容易失焦。很多團隊一開始只問模型準不準，但企業真正使用時，還會受到資料品質、檢索邏輯、權限控管、介面流程、系統延遲、例外處理與維運方式影響。如果最後才一起檢查，問題會混在一起，很難判斷是需求錯、資料錯、提示錯、模型錯，還是整合方式錯。
我們通常建議把驗收對象拆成幾層：業務情境是否定義清楚，資料來源是否可靠且可追溯，AI 回答是否符合企業規範，系統整合是否能接上 LINE、ERP、CRM 或內部入口，最後才是上線後的監控與改善機制。這樣做的好處是每一層都有自己的責任邊界，也比較能讓業務、IT、資安與工程團隊在同一張圖上討論。
階段式驗收不是把專案切成更多會議，而是把風險放到最早能被驗證的位置。例如 RAG 企業助理若回答不穩定，可能不是模型能力不足，而是文件版本混亂、切段策略不適合、權限沒有帶入查詢，或使用者問題本身需要流程狀態。這些問題若在架構驗收或資料驗收就被攔下，後面的模型微調與介面開發才不會浪費。
把專案拆成可判斷的驗收閘門
好的階段式驗收，會為每個階段設定明確的通過條件、觀察資料與決策人。常見順序可以是需求與情境驗收、資料與權限驗收、原型驗收、整合驗收、試營運驗收、正式上線驗收。每一關不一定都要很重，但必須回答一個問題：現在是否有足夠證據進入下一階段。
- 需求與情境驗收：確認主要使用者、任務邊界、不可回答範圍、人工接手條件，以及哪些流程真的需要 AI 參與。
- 資料與權限驗收：確認文件、資料庫、API、知識庫的來源、更新方式、敏感資料處理、存取權限與稽核需求。
- 原型驗收：用小範圍樣本驗證回答風格、檢索品質、工具呼叫邏輯與使用者互動，不急著追求完整功能。
- 整合驗收：檢查 AI 服務與 LINE、ERP、CRM、IoT 平台、雲端服務或內部系統之間的資料流、錯誤處理與權限傳遞。
- 試營運驗收：讓真實使用者在受控範圍內操作，觀察誤用、例外問題、回覆延遲、人工覆核負擔與維運成本。
每一關都應該保留退回條件。若資料驗收沒有通過，就不要急著進入模型調整；若試營運發現使用者其實需要的是流程自動化，而不是問答助理，就應該調整產品形態。階段式驗收的價值，在於讓專案可以有紀律地轉向，而不是一路完成原本假設。
接受 AI 的不確定性，但不要放棄工程標準
AI 系統不會像傳統規則引擎一樣每次輸出完全相同，因此驗收方式也不能只靠固定輸入對固定輸出。比較務實的做法，是建立代表性測試集，包含常見問題、邊界問題、惡意或誤導問題、權限不足情境、資料不存在情境，以及需要轉人工的情境。測試結果可以用人工評分、檢索來源檢查、規則檢查與自動化測試一起看，而不是只看單一分數。
工程團隊需要把可控與不可控分開處理。模型生成內容有變動性，但資料來源、提示版本、檢索參數、工具呼叫、API timeout、錯誤訊息、紀錄格式、權限判斷與部署流程都應該可追蹤。若一次失敗無法重現，就很難改善；若系統不知道回答引用了哪些文件，也很難讓使用者信任。
驗收標準也要包含負面能力。企業 AI 不只要會回答，還要知道何時不能回答、何時要說資料不足、何時要要求使用者補充資訊、何時必須轉給人工或建立工單。很多專案在展示時看起來流暢，但一遇到過期文件、跨部門權限、客訴語氣或 ERP 狀態不一致，就會暴露風險。這些不是上線後再處理的小問題，而是應該在驗收集中被刻意測到。
用試營運驗收營運能力，而不只是功能清單
正式上線前的試營運，重點不是再做一次功能測試，而是確認組織是否準備好使用與維護這套 AI 系統。需要看的是使用者是否知道怎麼問、管理者是否能判斷成效、IT 是否能監控成本與錯誤、資安是否能追查資料流、業務單位是否能處理 AI 無法完成的案件。若這些角色沒有被放進驗收流程，系統即使功能完成，也可能很快變成沒人敢用或沒人維護的工具。
試營運期間應該保留足夠的紀錄，但也要控制個資與敏感資訊。常見做法包括記錄問題類型、是否命中正確資料、是否需要人工接手、使用者是否重問、哪些流程卡住，以及哪些回答需要調整。這些紀錄不只是 debug 用，也會決定下一版要優先改善資料、流程、介面還是模型策略。
最後的正式驗收，應該是一個營運決策，而不是單純簽收。團隊要一起確認上線範圍、已知限制、回滾方案、監控項目、維護責任、資料更新流程與後續迭代節奏。AI 專案很少在第一版就完全定型；成熟的做法，是讓第一版足夠可靠地承接明確場景，並建立可以持續改善的工程與營運機制。這也是整合團隊能發揮價值的地方：把模型、資料、流程與既有系統一起驗收，而不是只交付一個聊天介面。