先用一句白話問
為什麼 AI demo 在會議裡看起來很有用，但幾週後卻沒有真正進入日常工作？
簡短答案是：demo 證明 AI 可以產出東西，但沒有證明這個產出真的能接進公司原本的工作方式。
這個差別很重要。
一個有用的 AI 試點，不只是測試工具，而是對一段真實工作做小幅改變：誰收到需求、要查哪些資料、誰審核答案、結果要送到哪裡，以及團隊怎麼知道這件事真的改善了。
研究給我們的提醒
近年的企業 AI 研究大致指向同一個方向。
MIT NANDA 關於 “GenAI Divide” 的報告指出，很多試點沒有產生可衡量回報；少數成功案例通常會把 AI 對準具體流程與商業成果。
來源：MIT NANDA / State of AI in Business 2025
McKinsey 的 State of AI 研究也提到，AI 高績效企業更常重新設計工作流，也更常定義 AI 輸出什麼時候需要人工驗證。
來源：McKinsey State of AI
Deloitte 的 GenAI 研究則持續提醒，治理、風險、資料品質與人員問題，仍然是企業擴大導入 AI 的主要阻礙。
來源：Deloitte State of Generative AI
翻成白話就是：AI 導入常常不是敗在技術，而是敗在它沒有變成一段可管理的工作。
很常見的企業場景
公司請廠商或內部團隊展示 AI 可以做什麼。
Demo 很漂亮：
- AI 可以摘要文件。
- AI 可以草擬客服回覆。
- AI 可以從公司文件回答問題。
- AI 可以從 email 抽出重點。
大家都看得到潛力。
但會議結束後，真正困難的問題才出現：
- 哪個團隊每天會使用？
- 第一個處理的工作類別是什麼？
- AI 可以相信哪些資料來源？
- 結果送到客戶前，誰要審核？
- AI 不確定時要怎麼辦？
- 誰負責更新資料來源？
- 哪個指標能證明試點成功？
如果這些問題沒有答案，試點通常只會停留在 demo，而不會變成工作流。
五個常見失敗原因
1. 從工具開始，而不是從痛的工作開始
「我們應該用 AI」不是一段工作流。
「客服團隊每週花 12 小時回答重複的配送政策問題」才是一個工作流問題。
第二種說法比較容易評估，因為它有真實任務、真實處理量、真實成本，也有 AI 可能介入的位置。
2. 沒有設計人工審核點
很多公司會卡在兩個極端。
一邊希望 AI 立刻全自動。另一邊擔心 AI 出錯。兩種反應都可以理解，但都不是設計。
比較好的試點會這樣定義：
- AI 可以先草擬答案。
- AI 必須附上政策來源。
- 退款、合約條款、敏感客訴由人審核。
- 低風險重複問題，在品質證明後可以降低審核強度。
信任是這樣建立的。
3. 知識來源太亂
如果政策、SOP、價格規則或內部知識過期、分散、互相矛盾，AI 就很難穩定回答。
這不代表公司必須等資料完美才能開始。
意思是：第一個試點要選擇資料來源相對足夠的流程。如果資料來源太弱，第一個專案也許應該是整理來源，而不是自動化。
4. 沒有 business owner
AI 試點需要有人對這段流程負責。
這個人不一定要懂技術，但要能回答：
- 這個答案能不能接受？
- 哪些例外情況很重要？
- 誰每週檢查品質？
- 什麼時候可以擴大？
- 什麼時候應該停止？
沒有 owner，試點就很容易變成沒有人維護的 demo。
5. 沒有衡量成功
如果團隊說不清楚要改善什麼，就無法判斷試點是否成功。
有用的指標通常很簡單：
- 節省多少時間
- 首次回覆速度
- 人工分流是否減少
- 回答是否更一致
- 升級處理是否更準確
- 重複問題是否下降
- 團隊是否真的採用
不同工作流需要不同指標。重點是，試點開始前就要先定義。
更好的第一個試點選擇方式
先選一段工作流，問六個問題：
- 這段工作發生頻率夠高嗎？
- 它有明顯成本、延遲、品質問題或客戶痛點嗎？
- 它有 AI 可以辨識的模式嗎？
- 它有足夠可信的資料來源嗎？
- 重要輸出可以由人審核嗎？
- 有人會對這段流程負責嗎？
如果大多數答案是肯定的，這段流程可能適合做 AI 試點。
如果大多數答案是否定的，AI 以後仍可能有用，但它大概不是第一個該做的地方。
例子：客服信箱
比較弱的試點想法：
「我們來加一個 AI chatbot。」
比較強的工作流說法：
「我們的客服信箱收到很多配送、退貨與庫存問題。希望 AI 先分類請求、從核准政策中找依據、草擬回覆，並把退款或客訴案件交給真人審核。」
後者比較容易設計，也比較容易衡量。
團隊可以追蹤首次回覆時間、人工分流時間、草稿品質、升級準確度，以及客服人員是否真的使用 AI 建議。
主管在批准試點前可以問什麼
在投入 AI 試點前，主管可以問：
- 我們到底要改哪一段工作流？
- AI 要準備、判斷或建議什麼？
- 人在哪裡審核？
- AI 會使用哪些資料來源？
- 上線後誰負責這段流程？
- 哪個指標能說明這件事成功？
這些問題很簡單，但可以避免很多浪費。
Glasrocks 的看法
AI 試點在 demo 之後失敗，通常是因為它沒有接進真正的營運工作流。
解法不是做更大的 demo。
解法是把工作流變得更小、更清楚、更安全、更可衡量。
這也是為什麼 Glasrocks Method 從工作流適配度開始，而不是從工具選型開始。先選一段工作，診斷它是否準備好，設計人工審核，再決定要不要實作。