先分清楚三種工具在解什麼問題
流程自動化、RPA 與 AI 常被放在同一個討論裡，但它們處理的是不同層級的問題。流程自動化比較像把既有業務規則系統化，透過 API、事件、排程、表單與簽核，把工作從一個系統可靠地送到另一個系統。它適合規則清楚、資料結構穩定、系統之間可以整合的情境，例如訂單成立後建立出貨任務、表單核准後同步到 ERP、客服單關閉後更新 CRM 狀態。
RPA 則比較像替人操作畫面。當某個老系統沒有 API、匯出格式受限、只能用瀏覽器或桌面程式操作時，RPA 可以模擬點擊、輸入、複製、貼上與下載。它的價值在於用較低侵入性的方式跨過系統限制，但代價是對畫面變更、網路延遲、登入狀態與例外視窗比較敏感。RPA 可以很有用，但不應被誤認為長期整合架構的核心。
AI 適合處理判斷、理解、摘要、分類、搜尋與自然語言互動，特別是輸入資料不固定、需要看上下文、或規則難以完整列舉的工作。例如客服信件分類、合約條款摘要、內部知識庫問答、維修紀錄歸納、從非結構化文字抽取欄位。AI 的風險也不同：它需要資料治理、權限控管、評估集、人工覆核機制，以及對錯誤輸出的處理設計。
選型時先看流程穩定性與系統邊界
工程上最實用的判斷方式，是先把流程拆成輸入、規則、系統動作、例外與產出。若輸入格式固定、規則明確、後端系統有 API，通常應優先做流程自動化。這種方式可觀測性較好，錯誤容易重試，權限與資料流也比較清楚。若流程橫跨多個系統，但其中只有少數步驟卡在沒有 API 的舊系統，RPA 可以作為局部橋接，而不是把整條流程都做成畫面操作。
若流程的困難點在於人需要閱讀、判斷或整理大量文字，AI 才是主要候選。常見例子是採購信件需要判斷品項與交期、客服對話需要辨識意圖、工程報修描述需要轉成結構化工單。這時候不要只做一個聊天介面，而應該設計 AI 輸出如何進入既有流程：哪些欄位可自動填入，哪些需要人工確認，錯誤如何回報，後續系統如何追蹤。
- 規則穩定且系統可整合：優先選流程自動化，讓 API、工作流與資料表成為主要控制點。
- 規則穩定但系統封閉：可用 RPA 補上缺口，同時評估未來是否能改成 API 或資料庫層級整合。
- 輸入不固定且需要理解語意：考慮 AI，但要把人工覆核、信心不足時的處理路徑一起設計。
- 流程常變且責任邊界不清：先整理流程與資料責任，不要急著導入工具，否則自動化只會放大混亂。
不要只看建置速度，也要看維運成本
很多自動化專案初期看起來都能快速展示成果，但真正的成本通常出現在維運。流程自動化的建置可能需要較多系統理解與 API 串接，但一旦資料契約清楚，監控、版本控管、測試與回復會比較可管理。RPA 的初期門檻通常較低，尤其面對舊系統時很有吸引力；但只要畫面欄位調整、瀏覽器政策改變、驗證流程更新，就可能造成機器人失敗。
AI 的維運成本則不是單純的伺服器與模型費用。企業需要維護知識來源、文件版本、權限同步、提示詞與評估案例。若 AI 產出的結果會觸發後續系統動作，就必須定義可接受的自動化範圍。例如 AI 可以先草擬回覆、分類工單或建議下一步，但付款、合約變更、客戶承諾與庫存調整等高風險動作，通常需要更嚴格的審核與紀錄。
一個成熟的做法，是把自動化分成低風險與高風險步驟。低風險步驟可以自動執行，例如資料同步、通知、建立草稿、補齊欄位。高風險步驟則保留人工核准，讓系統提供上下文、差異比較與建議。這樣可以讓效率逐步提升，也避免一開始就把責任交給難以解釋的黑盒。
實務上常是混合架構，而不是三選一
企業現場很少只有一種技術能完整解決問題。比較合理的架構通常是流程引擎負責狀態與責任歸屬，API 負責主要資料交換，RPA 處理少數無法整合的舊系統步驟，AI 負責理解非結構化資訊或協助人員決策。這樣每個工具都待在自己擅長的位置，也比較容易除錯。
例如客戶來信進入共用信箱後，AI 可以判斷意圖、摘要需求、抽取公司名稱與產品資訊；流程自動化可以建立客服單、指派負責團隊、同步 CRM；若某個舊 ERP 只能由網頁後台查詢訂單狀態，RPA 可以在受控範圍內查詢並回填結果。最後由客服人員確認回覆內容。這不是把人排除在流程之外，而是把人放在需要判斷與承擔責任的位置。
我們通常建議先選一條高頻、邊界清楚、資料可取得的流程做試點。不要一開始就追求全公司自動化，而是先建立可觀測的流程紀錄、錯誤處理、權限模型與人工覆核方式。當第一條流程跑穩，再把同樣的模式複製到採購、客服、財務、維修或業務支援等相鄰流程。真正可靠的自動化，不是工具堆得多，而是每個步驟的責任、資料與例外都被設計清楚。