AI 上線後怎麼持續評測？漂移、事件、成本與人工負荷
上線前測試只能證明某個版本在某組案例與環境下的表現。正式資料、使用者、流量、模型、提示、知識庫與供應商都會改變，因此驗收通過不是永久有效。持續評測的目的不是把所有對話永久保存，而是用最小必要資料及早發現品質、風險、成本與人工負荷偏離批准範圍。
先固定可追溯的正式基準
把已批准版本的系統邊界、測試集、門檻與逐題結果保存成基準。每次模型、提示、檢索、工具或政策變更，都要有版本與變更理由；依影響決定跑完整回歸、特定風險集或快速冒煙測試。NIST AI RMF Measure 指出 AI 應在部署前測試，也要在運行期間定期測試與監控，量測結果再回到管理決策。
用AI 系統清冊記錄 owner、依賴與下次複查日，並將離線回歸連到AI 評測指標資料庫中的任務、依據、安全、營運、成本與人工面向。不要因能監控幾十個數字，就讓每個數字都成為沒有 owner 的告警。
線上監控分成四層
第一層是服務：可用性、錯誤、P50/P95/P99 延遲、限流、重試與降級。第二層是品質：抽樣任務成功、依據忠實、無答案、修正與轉人工。第三層是風險：未授權工具、敏感資料、禁止內容、權限拒絕與停止。第四層是價值：合格成果、採用、人工分鐘、返工與每件完整成本。
HTTP 200 不等於工作成功，token 用量也不等於價值。每個指標要有分母、時間窗、分群、資料延遲、門檻、owner 與調查步驟。高風險事件可即時告警；低風險品質則可用代表性抽樣與週期評測，避免過度蒐集內容。
漂移要連到真實失敗與重測
輸入長度、主題或語言改變只是訊號，不一定等於品質變差。把分布變化和人工修正、零結果、重大錯誤、申訴與業務成果相連，才能判斷是否需要重測。已知模型或資料變更可做回放測試；未知變化則由線上抽樣、事件與使用者回報補進測試集。
NIST 的 TEVV 資料強調指標與方法必須依應用情境而定，準確、穩健、偏誤、安全與透明各自需要不同量測。不要用單一「漂移分數」自動決定停機；應事先定義查核、限縮、回復與批准層級。
事件、近失事件與人工負荷都是資料
收集真正造成或差點造成影響的事件，記錄系統版本、輸入類型、來源、工具、人工控制是否攔截與受影響範圍。近失事件可揭露控制剛好攔住的弱點。使用AI 事件紀錄模板讓事故改善能回到測試案例、權限、提示或流程，而非只歸咎使用者。
人工複核時間、錯誤採納、轉人工等待與工作品質也要持續追蹤。若修正率下降但漏掉重大錯誤，不能宣稱品質改善；若成本下降卻讓使用者承擔更多查錯，也不是完整效益。
設計停止、降級與週期複查
對未授權動作、機密洩漏、重大錯誤、預算爆量與依賴故障設定停止或降級條件，定期演練轉人工、規則流程、替代供應商與資料回復。保存必要追蹤但限制內容、存取與期間，尤其不能為了除錯無限期保留敏感原文。
最後以固定週期由業務、技術、資安、資料與適用的法務角色檢視：指標是否仍代表用途、門檻是否需有證據地調整、已知限制是否改變，以及系統是否仍值得運行。這才是從一次驗收走向可治理的正式服務。