2026 年 4 月,SAP 更新 API 政策後,企業最需要釐清的不是「第三方工具是不是都不能連 SAP」,而是:SAP 正把核心 ERP 資料與流程的 API 使用,限定在已發布 API、產品文件、SAP 認可架構、資料服務或指定服務路徑之內。[1][
7][
10]
對正在把 AI 代理接入 SAP 的企業來說,這會直接改變概念驗證(PoC)、資料平台、RPA、iPaaS、ETL 與自建自動化流程的設計方式。[1][
13]
新政策的核心:不是不能連,而是不能「隨便連」
CIO 引述 SAP 說法指出,只有列在 SAP Business Accelerator Hub 或相應產品文件中的介面,才被視為已發布 API。[7] The Register 也報導,新政策要求使用者只能在 SAP-endorsed architectures, data services, or service-specific pathways 的限制內使用 API。[
2][
10]
這代表企業不能再假設「只要技術上呼叫得到」的 SAP 介面,就適合作為長期整合基礎。政策文件列出的 API controls 包括功能與技術用量限制、配額、棄用時程、資料進出配額、批量抽取或複製的限制與前提,以及其他安全或技術要求。[9]
SAPinsider 也指出,未文件化 API 雖然仍被廣泛使用,但在更新後會落在支援邊界之外,增加長期整合與營運風險。[1]
換句話說,這不是單一的 AI 條款,而是一個更大的 ERP 整合治理問題:哪些 API 算已發布、哪些用法受支援、哪些資料抽取或複製需要前提,以及哪些自動化必須走 SAP 認可路徑。[7][
9][
13]
為什麼 AI 代理特別敏感
最受關注的是 AI 條款。多個報導引述政策指出,除非透過 SAP 認可架構、資料服務或明確指定路徑,SAP 禁止 API 用於與半自主或生成式 AI 系統互動或整合;受影響的是那些會規劃、選擇或執行一連串 API 呼叫的系統。[5][
10]
這正是「代理式 AI」與傳統整合的差別。傳統整合通常是預先定義好的流程:某個系統依固定規則呼叫某個 API,完成單一任務。AI 代理則可能根據目標即時決定下一步,例如先查供應商,再查庫存,再產生採購建議,最後提交審批或更新紀錄。
只要 AI 代理會自行選擇並串連多個 SAP API 呼叫,就可能落入政策描述的多步 API 編排範圍;實際是否合規,仍要視所用 API、架構、資料服務與 SAP 認可方式而定。[5][
10]
同一組限制也涵蓋 scraping、harvesting,以及系統性或大規模資料抽取與複製。[5][
10] 因此,受影響的不只是會寫入 SAP 的 AI 代理;若企業大量讀取 SAP 資料來支援外部 AI 平台、lakehouse 或 orchestration layer,也需要重新審查架構。[
9][
13]
對客戶創新:PoC 不會消失,但會更像正式專案
對創新團隊、系統整合商(SI)與獨立軟體供應商(ISV)來說,最大變化是實驗前多了一道治理門檻。過去第三方 AI 代理可能較快接入 ERP,測試自動對帳、採購輔助、庫存分析或客服流程自動化;新政策下,團隊要先確認幾件事:
- API 是否列在 SAP Business Accelerator Hub 或產品文件內;
- 架構是否屬於 SAP 認可路徑;
- 用量是否觸發配額、資料進出或批量抽取限制;
- AI 代理是否會自行規劃並執行多步 API 呼叫。[
5][
7][
9]
這不等於 AI PoC 不能做,但會讓 PoC 更接近正式整合專案:需要 API 盤點、權限設計、用量估算、資料流向審核與合規確認。
ERP Today 指出,這項政策把原本偏技術的整合問題,推高成更廣泛的 ERP 架構問題,因為現有整合可能依賴未正式文件化的介面,而新興 AI 應用又需要受控地接觸企業資料與交易流程。[13]
不確定性本身也可能拖慢創新。The Register 報導,德語區 SAP 使用者組織 DSAG 批評政策帶來不確定性;同一報導也提到,批評者認為 SAP 認可介面清單未必管理完善或更新及時。[2]
對資料控制:焦點不只是「資料歸誰」
這場爭議的焦點,不只是客戶資料所有權,而是客戶能否用自己選擇的 AI 平台、資料堆疊與自動化工具,直接、即時、連續地存取 SAP 資料與交易流程。
The Register 將問題描述為第三方 AI 工具可能被排除於客戶 SAP 資料之外;ERP Today 則把它放在 ERP 整合路線、資料複製與 AI 存取的架構層面討論。[10][
13]
如果企業想把 SAP 資料同步到外部 lakehouse、AI 平台、AI 代理編排層或第三方自動化系統,就要特別檢查資料進出配額、批量抽取或複製前提、已發布 API 範圍,以及是否必須走 SAP 認可路徑。[7][
9][
10]
這類限制有助於把效能、安全、稽核與治理控制集中化;代價是跨平台 AI 架構的自主性可能下降,尤其是需要大量讀寫 SAP 交易資料的使用情境。[9][
13]
對供應商鎖定:風險上升,但不是必然結局
供應商鎖定風險來自一個實際問題:如果第三方 AI 代理不能自由與 SAP API 互動,客戶就更可能依賴 SAP 認可架構、官方資料服務或 SAP 明確允許的整合方式。The Register 已將這條 AI clause 描述為引發 lock-in concern,因為它可能讓部分第三方 AI 工具無法接觸客戶的 SAP 資料。[10]
DSAG 的反應顯示,客戶社群關心的不只是技術細節。E3 Magazine 報導,DSAG 認為 SAP 對未文件化用途、系統性大量資料抽取,以及第三方自主生成式 AI 系統互動的嚴格限制不可接受。[11]
不過,鎖定不是政策的唯一可能結果。真正影響取決於 SAP 後續能否清楚定義認可路徑、維持 API 清單完整且及時更新、提供可稽核的例外或批准流程,並允許第三方供應商在清楚規則下繼續創新。批評者已指出認可清單管理與更新速度可能不足,這正是企業在採購與架構決策時需要追問的地方。[2][
7]
企業現在應該做的 5 件事
-
盤點所有 SAP 整合。 把每個介面標記為已發布 API、產品文件內 API、未文件化介面、批量抽取、即時讀寫、RPA、iPaaS,或外部 workflow/AI 代理呼叫。[
1][
7][
13]
-
特別檢查 AI 使用情境。 凡是由模型或 AI 代理自行規劃、選擇或執行多個 SAP API 呼叫的流程,都應先做政策風險評估。[
5][
10]
-
審核資料抽取與複製。 大規模 extraction、replication、scraping 或 harvesting 已被放入限制範圍;現有 data lake、lakehouse、BI、AI 訓練或資料同步架構,都應重新確認配額、前提與允許路徑。[
5][
9][
10]
-
要求 SAP 或實施夥伴提供書面確認。 對代理式 AI、自動交易更新、跨系統編排、批量資料匯出等高風險場景,不應只靠口頭理解;DSAG 對不確定性的批評,正好說明書面邊界的重要性。[
2]
-
保留架構選擇權。 即使最終採用 SAP 認可路徑,也應盡量把 AI 編排、資料治理、權限、稽核日誌與業務規則設計成可替換模組,避免所有創新邏輯被鎖死在單一路徑之內。
結論
SAP 2026 API 新政策的真正影響,不是 AI 不能用 SAP,而是第三方 AI 代理不能再假設可以自由編排 SAP API。它提高了安全、效能與治理門檻,同時也帶來更高合規成本、更慢實驗速度,以及更明顯的供應商鎖定風險。[10][
13]
短期內,企業最務實的做法是盤點整合、界定 AI 代理風險、確認 SAP 認可路徑,並在新架構中刻意保留跨平台選擇權。




