AI 與 SaaS 如何競爭？IBM 與 Palo Alto 執行長談平台整併，銀行系統為何不同
AI 與 SaaS 的競爭會走向全面取代嗎？從 IBM 與 Palo Alto 執行長訪談，看平台整併、代理記憶與換平台成本，以及銀行交易可靠性的差別。
AI 與 SaaS，也就是透過網路提供的軟體服務，正在競爭企業的工作入口。但一個新介面做得出來，與一套關鍵系統可以被替換，中間仍有很長一段距離。
IBM 執行長 Arvind Krishna 與 Palo Alto Networks 執行長 Nikesh Arora，在 2026 年 10 月 22 日上架的 All-In 訪談中，預期企業軟體將出現更多整併。
Arora 認為，代理累積的記憶、背景與系統連接，可能讓使用者更難搬到另一個平台。這讓競爭從單一模型，延伸到整段工作所在的環境。
Krishna 則提醒，互動功能與銀行交易、財務結帳所需的可靠性，有不同替代難度。把兩種價值混在一起，很容易把產品預測讀成全面淘汰的消息。
因此，訪談裡的整併看法，需要放回供應商的商業立場理解。它沒有證明所有 SaaS 都會消失，也沒有提供每一類系統的替換時程。
對使用企業工具的讀者，較實用的問題是：AI 改善了哪個工作步驟，原有系統承擔的資料與交易責任，又會由誰接手。
AI 與 SaaS 的競爭，為何超過一個聊天介面？
企業工具的價值同時包含互動方式與背後持續運作的資料、流程及責任。因此，看到模型做出可操作的畫面，還需要辨認它接上了哪些系統。
在訪談後半段，兩位執行長從垂直整合談到應用軟體。垂直整合是指一個供應商掌握服務所需的多個層次，讓不同部分可以一起設計與提供。
Krishna 以 IBM 大型主機的歷史說明，供應商可以選擇哪些能力自行掌握，哪些向外部購買。這是他的產業經驗與商業判斷，並不表示每一家軟體公司都適合包辦所有設備與服務。
但對應到今天的代理，畫面只是使用者看見的一層。模型還需要背景資料、過去的工作紀錄，以及能連到訂單、文件或其他系統的工具，才有機會把任務做完。
做出介面，與接管系統有什麼差別？
以一個假設的請款介面為例，AI 可以快速產生填寫表單、整理附件的畫面。但團隊仍要確認請款資料存在哪裡、誰可核准，以及哪些結果才算正式入帳。
如果新介面仍把資料送進既有系統，原系統就持續承擔記錄與處理的角色。使用者入口改變，與底層服務被替換，是兩種不同的變化。
因此，「AI 能寫軟體」不能直接推成「企業不必買任何軟體」。企業付出的費用可能包含持續維護、系統整合與故障處理，生成一個新功能只對應其中一部分。
兩位執行長預期的整併，較接近平台把更多工作收進同一個環境。這些依賴累積後，便會影響使用者換平台的難度。
代理的記憶與背景，如何提高換平台成本？
當代理已連上工具並累積工作背景，搬家就需要處理模型之外的資料與設定。因此，換到回答更好的模型，未必等於整段工作可以立刻搬過去。
Arora 在 32 分 54 秒後談到，代理的推理、記憶與背景逐漸綁在一起。他預期，當平台擁有更多使用者脈絡，轉移任務就會變得麻煩，進而形成商業上的防守優勢。
這裡的背景，可以是公司規則或當前專案資料；記憶則是讓代理之後能再使用的過去資訊。它們與模型的通用能力不同，內容可能只對某個人或團隊有用。
假設一個代理已知道報表欄位定義、團隊慣用格式，以及例外應找哪位同事。若改用另一個服務時，這些內容不能一起帶走，新工具就需要重新取得同樣的工作背景。
搬得走資料，是否就能接著工作？
資料匯出只是其中一步。因為另一個平台還需要理解資料如何使用，以及原來的工具連接與工作安排能否重建。只保留對話文字，可能仍缺少讓任務繼續執行的設定。
所以，換平台成本可以從實際任務來看。團隊可挑一項已熟悉的工作，確認更換模型後，哪些背景能沿用、哪些需要重設，而不只比較兩個模型當下的回答品質。
Arora 的說法仍是對競爭方向的預測。但這項預測不證明資料搬遷永遠不可能，也沒有排除開放介面或共用背景方法能降低摩擦。
不同工具共用工作背景，已是產品發展的一個方向。
延伸閱讀：Notion 讓 AI 代理共用記憶：ChatGPT、Claude 如何接上同一份工作背景？
降低工具拼接成本是平台的吸引力，但集中程度也會改變選擇空間。
平台整併能省下什麼，又會留下哪些依賴？
整合平台可能減少重複串接，企業仍需要核對哪些功能真的互通。工具列在同一個選單裡，與它們能一起完成工作，並不是相同程度的整合。
Arora 在訪談裡以資安產品為例，主張客戶不應自行拼接許多不同方案。他把平台整合視為供應商應承擔的工作，這也符合 Palo Alto Networks 經營多項資安服務的商業立場。
Krishna 則預期，企業可能把一部分分散的軟體需求，交給較少的平台與 AI 功能。他對整併速度沒有給出確定結論，甚至提到可能是數月，也可能是數年。
因此，訪談可以支持兩位高階主管正在思考整併，無法支持「所有企業已大幅淘汰既有工具」的結論。因為實際採購還會受到原有流程、資料與遷移成本影響。
整合也可以是管理不同平台
IBM 在 10 月 27 日公布的 watsonx Orchestrate 更新，提出集中管理來自不同環境的代理，保留既有框架與雲端選擇。
這項產品方向顯示，整合未必要求所有工作都搬到同一家服務。因為公司也可以把可見性與管理方式集中，讓底下不同系統繼續存在。產品實際能涵蓋多少範圍，仍須對照支援的功能與環境。
若團隊要比較這類方案，可以先找出原本最費力的接點。例如，同一筆資料是否要人工重輸，或工作失敗後是否要到多個後台找原因，才知道整合改善了哪一段。
跨平台管理的功能與限制，可以延伸閱讀本站對官方更新的整理。
延伸閱讀：IBM watsonx Orchestrate 擴展 AI 代理管理：跨平台盤點、權限與測試怎麼做？
即使介面與流程接得更順，底層交易正確性也不能省略。
銀行交易與財務結帳，為何難用新介面替代？
關鍵系統需要在中斷、並行操作與失敗時維持資料正確，這超過生成畫面的要求。這也是 Krishna 在訪談結尾，替全面取代的預測加上限制的原因。
他在38 分 50 秒後區分軟體的互動價值，以及銀行資料查詢、財務結帳等高度重視可靠性的工作。他認為，後者較難輕易交由 AI 生成的軟體取代。
這個區分可以用一筆假設的轉帳理解。使用者看到完成訊息之前，系統需要處理扣款與入款是否一致，以及中途失敗時應留下哪一種狀態。畫面能顯示成功，並不足以證明帳務正確。
若兩項操作只完成一半，之後由誰發現、如何恢復，也屬於服務必須處理的工作。因此，可靠性包含正常操作以外的條件，不能只用一次順利示範判斷。
資料庫保障，與模型回答的品質不同
Microsoft 的資料交易文件說明了原子性：交易中的變更應全部成功，或全部不成立。文件也討論同時寫入資料可能產生的衝突，以及已提交變更的保存。
這裡引用的是 Azure Databricks 對自身系統的說明，用來理解交易保障的種類，不代表所有銀行都使用這個產品。但不同系統的具體保證與限制，也需要分別確認。
這些保障處理的是資料狀態。模型能否正確理解指令，則屬於另一個需要檢查的部分。把較會解題的模型接上資料庫，並不自動完成整套交易服務的驗證。
因此，Krishna 的區分有助於讀者理解替換難度，卻無法證明 AI 永遠不能協助開發關鍵系統。開發方式改變之後，原本需要滿足的可靠性條件仍然存在。
企業評估新 AI 工具，應先確認什麼？
先界定替換的是介面、工作流程還是記錄系統，才能安排相應的驗證。因此，這個區分也能讓採購討論更具體，避免拿不同層次的產品直接相比。
若只改寫查詢介面，重點可能是使用者能否更容易找到正確資訊。若工具會更新資料，則還要理解哪些變更被保存，以及失敗或重複執行時會發生什麼事。
若連正式記錄系統也要更換，資料移轉與既有工作的連續性，就會成為專案的一部分。這些條件需要實際安排，無法只靠模型能力測驗回答。
團隊也可先用一條工作流程比較新舊方案。除了操作是否方便，也記下仍要人工補做的步驟，及資料能否帶往其他工具，才容易看見整合的收益與代價。
這樣的比較不預設平台愈少愈好。某些工作適合集中，另一些工作可能仍需要專門系統。能把功能改善與責任交接說清楚，才看得出整併是否真的讓工作更簡單。
AI 與 SaaS 常見問題
這場訪談是否宣布 SaaS 將全面消失？
沒有。兩位執行長提出整併與競爭的預期，Krishna 也明確區分不同軟體的替代難度。
代理累積記憶後，就無法換平台嗎？
搬遷可能需要處理資料、工具與設定，難度依實際服務而變。訪談沒有證明轉移永遠不可能。
AI 產生的程式可以用在關鍵系統嗎？
開發方式與系統是否符合要求，是兩項不同判斷。關鍵服務仍需要驗證資料正確性、失敗處理與持續運作條件。
先看軟體承擔什麼，再判斷 AI 改變了多少
這場訪談讓平台整併的討論多了一項區分：容易改變的互動方式，與需要持續承擔責任的系統能力，不能只用同一個展示效果衡量。
對使用企業工具的讀者，先釐清工作資料、流程與記錄由誰負責，比先猜哪家公司會消失更有幫助。免費訂閱 AI 郵報，持續閱讀 AI 如何改變企業軟體與實際工作。
