年度簡報送印前一週，資訊長停在其中一頁，確認標題沒有問題。

AI Change Impact Assistant
Status: PoC Success
Expected Benefit: Reduce manual impact analysis
Next Phase: Production Integration

專案經理說，PoC 還有三週才結束，但這一頁得先放進年度成果。法務、資安和平台團隊都已看過方向；如果年底才寫「進行中」，看起來反而像沒有交代。

於是「PoC Success」先被寫上去。剩下三週，只是把成功的細節補齊。

這個 Agent 的工作很清楚：每次系統變更前，讀取 CI/CD、服務目錄與相依關係，列出可能受影響的服務，讓 Change Manager 少花時間逐一追查。

中期檢查那天，技術結果其實不差。測試過的 12 個 Change 裡，Agent 判斷正確率是 84%，誤報率 11%，沒有漏掉 Critical 影響。工程師花了一下午調整輸出，最後把結果整理成一張很像可以上線的表。

但 Change Manager 沒有先看正確率。他指著另一欄問：「這五個 Change 的相依資料為什麼是空的？」

資料工程師回答，那些服務的擁有者沒有持續更新服務目錄。這次 PoC 是人工補齊資料才跑得動；若要進 Production，得把資料同步自動化，或安排人每週維護。

接著有人把實際工作量攤開。高風險 Change 一個月大約 14 件；即使每件都能省下 20 分鐘，也只有 4.7 小時。維護資料、處理例外、串接入口，保守估計每月要 12 到 16 小時。

會議室安靜了一下。

然後產品負責人說：「這些都是 Phase 2 可以改善的地方。」

資料缺口，Phase 2 做自動同步。使用量太低，Phase 2 擴大到一般 Change。誤報偏高，Phase 2 再優化模型。入口還沒整合，Phase 2 接進變更管理系統。

每一項都合理。也因此，沒有任何一項會讓這個 PoC 停下來。

當 PoC 只能導向繼續

這不是技術失敗，也不是誰刻意粉飾結果。專案一開始就把它放進年度 AI 成果，團隊自然會把注意力放在「如何證明它值得下一階段」，而不是「什麼結果會讓我們不再投入」。

PoC 原本應該用來降低不確定性。它可以證明模型能否判斷、資料是否可取得、工作量是否足以支撐維護成本，也可以證明答案是否定的。

若一個 PoC 無論跑出什麼結果，都只會轉成下一輪改善項目，它就沒有真正測試投資選項；它只是替既定計畫累積更多待辦事項。

Day 9 談過 Demo 成功不等於能營運。這裡的問題不同：即使技術上已經能營運，組織是否允許它得到「不值得做」這個結論？

那張 Project Charter 裡原本列了成功條件：正確率至少 80%、回覆在十秒內、沒有重大資安問題、使用者願意給正面回饋。它沒有列停止條件。

於是 84% 的正確率足以讓簡報說成功；但每月只有 14 件高風險 Change、維護成本高於節省工時，卻沒有地方可以被判成失敗。

在開始前，先寫下可以停在哪裡

這類 PoC 不需要更完整的成功指標，而需要一條真的能停止投資的 Kill Criteria。它不能是「如果模型完全無法運作就停止」這種不會發生的條件；它要針對這次投資最不確定、也最影響價值的假設。

這個案子後來補進 Charter 的句子很短：

若八週內驗證後的每月適用工作量低於 30 件，
則不進入 Production 投資。

30 不是神奇數字。它只是把原本模糊的討論變成一個可由工作量、節省時間與維護成本共同檢查的門檻。重點是：在 PoC 開始前，所有人都承認這個結果有可能出現，也承認出現後要停。

後來，年度簡報那頁被換掉了。

AI Change Impact Assistant
Status: PoC Completed
Decision: No Production Investment

沒有 Phase 2，也沒有「失敗」兩個字。旁邊只留下一句原因：已驗證的工作量不足以支撐資料維護與整合成本。

下一季原本預留給這個案子的預算，空了出來。投資組合少了一個需要持續解釋的 Production 計畫，也多了一個可以拿去測試下一個問題的位置。