AI 系統上線交接清單:從 PoC 到生產環境必須驗收的 12 個項目

交接那天,對方的 PM 問了一個問題,把整個會議室問安靜了:「如果模型答錯,把客戶的額度改錯了,我們怎麼把它改回來?」

沒有人答得出來。系統已經跑了三週,沒有回滾機制,沒有操作日誌,連誰有權限改那張表都說不清楚。Demo 那天這些問題根本不存在,因為 Demo 不會真的動到生產資料。等它動到了,才發現最該驗收的東西,全被跳過了。

所謂 AI 上線交接清單,是一份在系統從 PoC 進入生產環境前,逐項驗收權限、回滾、監控、成本與責任歸屬的檢核表——它確認的不是「它會不會動」,而是「它壞掉的時候,誰接得住」。

PoC 只需要在一條乾淨的示範路徑上跑通;生產環境要面對真實權限、真實流量、真實的錯帳與真實的預算。這兩者中間有一道溝,而多數團隊是在上線後才發現自己沒搭橋。

這份 AI 上線交接清單要驗收什麼

我們把 FDE 交付時實際在用的 12 項,整理成下面這張表。前八項讓系統活著,後四項讓它被用起來。每一項沒有綠燈,就不算交付完成。

項目	驗收要問的問題	通過標準
1. 權限邊界	模型與 Agent 能讀哪些資料、能執行哪些寫入?	最小權限、service account 獨立、寫入白名單
2. 資料權限繼承	RAG 檢索有沒有沿用使用者原本的存取權限?	文件級/列級權限過濾,不越權讀取
3. 回滾機制	AI 觸發的每個寫入,能不能還原?	可回滾,或高風險動作先過人工關卡
4. 版本管理	prompt、模型、索引能不能指定回退版本?	三者皆版本化,可一鍵回退上一版
5. 監控告警	延遲、錯誤、工具調用失敗,誰會知道?	指標上儀表板,超標時有人的手機會響
6. 可觀測性	一則回應能不能追出用了哪份文件、哪個 prompt?	每次回應可追溯、可重現
7. 成本上限	失控的 Agent 迴圈會不會燒穿預算?	日/月上限、單人速率限制、熔斷機制
8. 評測基準	「多好才算通過」有沒有數字?	離線評測集 + 上線後線上抽檢門檻
9. 失敗降級	LLM 或向量庫掛了,使用者看到什麼?	有 fallback:轉人工、快取或明確錯誤
10. 資安合規	PII、稽核軌跡、供應商資料條款理清了嗎?	遮蔽 + 稽核日誌 + 合約條款存檔
11. Runbook	值班的人半夜被叫醒,照著能修嗎?	可執行文件,不是口頭交接
12. 採用負責人	使用率誰在盯?目標多少?	指定 owner、明確門檻、每週追蹤

這四項幾乎每次都被跳過,而且每一項都能單獨把一個專案拖下水。

權限。很多團隊上線時,直接給 AI 一個「什麼都能讀」的帳號,因為這樣最快跑通。問題是,RAG 一旦繞過原本的資料權限,基層員工就能透過問答,問出董事會的薪酬表。要驗收的是:模型的資料存取,是不是還遵守使用者本來就有的權限邊界。

回滾。Demo 只讀不寫,所以沒人想過回滾。但生產環境的 AI 會改工單狀態、會寄信、會更新 CRM。我們的預設做法是:高風險寫入一律 human-in-the-loop,直到線上錯誤率連續兩週低於門檻,才逐步放開自動化。

監控。我們接手過一個案子,上線三個月後才發現幻覺率一直穩定在 8%——因為根本沒人在看。你至少要盯延遲、工具調用失敗率、和抽樣的答案品質,而且要具體到「誰的手機會在半夜響」。沒有這一句,監控就只是擺設。

成本上限。一個沒有上限的 Agent 迴圈,可以在一個週末燒掉一整季的預算。日上限、單一使用者速率限制、失控時的熔斷,這三道閘門缺一不可。

真正的交接,不是把帳號密碼和一份簡報丟進 email。而是對方的值班工程師照著 runbook,就能在半夜把系統救回來;是採用率有人盯、有門檻、有 owner。這也是為什麼清單的最後一項是「採用負責人」——沒人負責採用率,再漂亮的系統都會躺在那裡,使用率停在個位數。

我們在做 FDE 前線部署時,把這 12 項當成上線的驗收門檻,工程師進場陪跑到每一項都亮綠燈才收工。因為 Demo 很美不算數。上線、有人在用、壞掉時有人接得住,才算數。