很多公司談 AI 導入，重心都放在「怎麼上線」，卻很少談「上線之後呢」。專案結案、慶功照拍完，AI Agent 開始跑，接下來三個月、半年會發生什麼事，往往才是決定這個流程能不能長期用下去的關鍵。答案很直接：上線後要有一位明確的負責人，建立例外狀況的通報與人工確認機制，並固定週期檢視規則是否需要更新，這個流程才不會慢慢停擺。
為什麼「上線＝結束」是最常見的誤解？
四步工法裡，「上線運行」是最後一步，但很多團隊把它理解成終點，而不是開始。上線那一刻，AI Agent 處理的是「當時萃取出來的規則」，而業務不會靜止：客戶問法會變、單據格式會改、公司政策會調整。規則沒人維護，AI Agent 就會用過時的邏輯繼續執行，直到有人發現「早該用新規則處理，系統還在照舊做」。另一個常見狀況是上線初期主管盯著看，一兩個月後注意力轉到下一個專案，這個流程就進入沒人管的狀態——不是做錯事才被發現，而是根本沒人在看。
誰該當這個流程的負責人？
負責人不必是 IT 人員，但一定要熟悉這項業務，例如原本就在做這件事的資深同仁，或該部門主管。負責人的工作有三項：
- 定期看例外案例：AI Agent 判斷不了、轉交人工的案子，要確認轉交理由合理，不是規則寫得不夠清楚。
- 收集規則異動的訊號：業務端有新的例外或判斷標準，第一個知道的通常是負責人，不是 IT。
- 決定要不要調整規則：發現該改了，負責人要能拍板，或知道找誰拍板，不是丟著等別人發現。
一開始沒指定這個角色，等於預設「大家都要負責」，實務上通常等於沒人負責。導入前就該把負責人寫進上線計畫，跟決定導入哪個流程一樣重要。
例外狀況要怎麼處理，才不會變成黑洞？
沒有一套規則能涵蓋所有情況，AI Agent 一定會遇到判斷不了、或風險較高的案子。這些例外不該硬塞進既有規則勉強處理，也不該被系統直接吃掉、沒人知道發生過。比較務實的分流方式：
- 規則覆蓋不到的低風險案子：AI Agent 標記「無法判斷」，轉交負責人處理並記錄下來，作為未來規則更新的素材。
- 金額大、影響範圍廣的案子：即使 AI Agent 判斷得出結果，也應設計成「AI 先初判，人工確認後才執行」，而非全自動放行。
- 反覆出現的例外：同一類例外一再發生，代表不是個案，而是規則有缺口，該提報為更新候選，而非每次都當特例處理。
關鍵是「轉交人工」跟「規則不完整」要分開看待，前者是正常設計，後者是需要修正的訊號。沒有區分的話，例外會一直靠人工救火，AI Agent 實際處理比例越來越低，導入效益也跟著被稀釋。
規則多久該更新一次？由誰提出？
規則更新不需要天天做，但也不能等出問題才想起來。務實做法是設定固定週期，例如每月或每季，由負責人整理累積的例外案例，判斷是否需要調整。更新來源通常有三種：公司政策或產品調整這類業務本身的變化，負責人通常最早知道，應主動提出；同一類例外重複出現三次以上的案例累積，值得評估是否調整規則；以及法規、稅務規定等外部環境的改變，建議跟業務合規同仁一起檢視。規則更新後，記得同步更新對應的 SOP 文件，讓「AI 能執行的 SOP」跟實際運行的規則保持一致，否則下次要調整或交接時會找不到最新版本。
怎麼判斷這個流程值不值得繼續投資？
上線前設定的量測基準，上線後也要持續追蹤，幾個實際可用的檢查點：自動處理比例是否隨時間穩定或上升，持續下滑代表規則老化的速度比更新快；例外處理耗時是否比導入前更短，沒有的話代表可能只是換一種方式做同樣的事；錯誤率與返工次數是否在可接受範圍，並隨規則調整逐漸下降。
如果這些指標持續變差，且已投入資源調整規則仍未改善，代表這個流程可能不如當初評估的適合自動化，需要回到「精簡流程」那一步重新檢視，而不是持續加規則硬撐。反過來說，指標穩定甚至變好，正是向公司內部證明成效、爭取下一個流程資源的最好材料。
小結：把「上線」放進維運計畫裡
AI Agent 上線那天不是專案終點，而是維運的起點。指定一位懂業務的負責人、把例外狀況設計成清楚的分流機制、固定週期檢視規則是否需要更新，並持續追蹤量測基準，這個流程才會隨業務一起成長，而不是停在上線那一刻，慢慢變得不合用。導入前，不妨把這些維運機制一併寫進計畫，跟挑選流程、寫規則一樣當成必要項目，而不是上線後才臨時想辦法。