由 Tse、Esposito、Mizuno、Goh 共同撰寫。本章揭露 AI 專案失敗的「最笨原因」：再頂尖的 AI 模型，若無法接到既有系統，就毫無用處。解方是建立 **AIOps（AI operations，AI 維運）**團隊。

一個常見的悲傷故事#

企業與一家有潛力的技術廠商合作，投入時間、金錢與人力，**概念驗證（proof of concept, PoC）**大獲成功，展示 AI 將如何改善業務。然後——一切戛然而止，PoC 被封存，團隊挫敗。

為什麼？因為要把 AI 模型整合進公司整體技術架構極其困難。企業把所有時間與資源投在 AI 模型上，卻沒思考如何讓模型真的能與既有系統一起運作。

AIOps 是什麼？#

AIOps 涵蓋建置、整合、測試、發布、部署與管理整套系統，把 AI 模型的結果轉化為終端使用者所需的洞察。最基本層次上，AIOps 同時需要：

• 對的硬體與軟體
• 對的團隊：能把 AI 整合到現有公司流程與系統的開發者與工程師

AIOps 演化自 DevOps（軟體開發與營運的整合實踐），是把 AI 引擎的工作轉化為真正商業產出、達到大規模可靠運行的關鍵。

從正確的環境開始#

在許多 AI 驅動的企業中，只有一小部分程式碼真正在做 AI 的事——AI 模型只是更大系統中的一小塊，使用者如何與其互動和模型本身一樣重要。要釋放 AI 價值，必須從設計良好的**生產環境（production environment）**開始。

好的生產環境須符合三項標準：

1. 可靠性（Dependability）#

當前 AI 技術充滿技術問題：

• 餵入錯誤或變形資料，AI 系統會停擺
• 處理大量資料時速度必然下降，輕則拖慢系統、重則癱瘓

避免資料瓶頸是建立可靠環境的關鍵。

• 設計周全的處理與儲存架構可解決吞吐量與延遲問題
• 良好的 AIOps 團隊會主動設想環境如何避免崩潰，並準備好應變計畫

2. 彈性（Flexibility）#

業務目標與背後的流程持續變動，但系統層級必須像時鐘般精準：資料匯入要按規則定期執行、報表機制要持續更新、避免使用過期資料。

把架構拆成可管理的「樂高積木」——可以後續新增、替換或移除——能讓系統在不影響運行效率的前提下快速重組與同步資料。

3. 可擴充與可延展（Scalability and Extendibility）#

當業務擴張時，基礎建設裡的「水管」也得跟著調整。不同 IT 系統的效能、可擴充性與延展性各異，跨系統時往往出問題。

成功關鍵在於團隊能否一邊維持「business as usual」、一邊嵌入升級的 AI 模型——透過持續調整、修補、測試，讓新舊系統達成平衡。

自建還是外包？#

最重要的決策：AIOps 團隊要自建還是外包。

選項一：自己做（Do It Yourself）#

優勢：

• 對整套設置擁有完全控制權
• 省去與外部供應商的合約與管理麻煩
• 大企業可垂直整合 AIOps；中小企業可擴充 IT 團隊能力

代價：

• 行政與組織負擔不容小覷
• 需在內部培養 AIOps 專業
• 前期經濟衝擊大——儲存硬體、伺服器這類會折舊的資產需大量現金；即使用雲端，「試錯」設定活動也會推高安裝成本

選項二：即插即用（Plug and Play）#

優勢：

• 與 AIOps 廠商合作，快速取得穩固的生產環境與可靠團隊
• 釋放企業原本要投入自建的龐大資源

代價：

• 失去對專屬系統的所有權與 AIOps 運作的完整話語權
• 是「財務限制」與「取得穩固 AI 架構」之間的折衷——不像自建那樣量身打造，但足以推動企業數位化

結語#

對任何想善用 AI 紅利的企業來說，真正關鍵的不是 AI 模型本身，而是「由 AI 驅動、能把公司從現在帶到未來的那台運轉良好的機器」。

一次性的專案與漂亮的願景做不到。AIOps 不是事後補上的，而是競爭上的必需。