SAP 2026 API 新政策如何限制第三方 AI Agent 存取 ERP 數據

這代表企業不能再假設任何可呼叫的 SAP 接口都適合長期使用。政策文件列出的 API controls 包括功能與技術用量限制、配額、棄用時間表、data ingress／egress 配額、批量抽取或複製的限制與前提，以及其他安全或技術要求。^[9] SAPinsider 亦指出，未文件化 API 雖然仍被廣泛使用，但更新後會落在支援邊界之外，增加長期整合和營運風險。^[1]

換句話說，這不是單一 AI 條款，而是一個更大的 ERP 整合治理問題：哪些 API 是已發布、哪些用法受支援、哪些抽取或複製需要前提，以及哪些自動化必須走 SAP 認可路徑。^[7][9][13]

為甚麼第三方 AI agent 特別敏感

最受關注的是 AI 條款。多個報道引述政策指，除非經 SAP 認可架構、數據服務或明確指定路徑，SAP 禁止 API 用於同半自主或生成式 AI 系統互動或整合；受影響的是那些會規劃、選擇或執行一連串 API calls 的系統。^[5][10]

這正是 agentic AI 與傳統整合的差別。傳統整合通常是預先定義好的流程：一個系統按固定規則呼叫某個 API，完成單一任務。AI agent 則可能根據目標即時決定下一步，例如先查供應商，再查庫存，再生成採購建議，最後提交審批或更新紀錄。只要 agent 會自行選擇並串連多個 SAP API calls，就可能落入政策描述的多步 API 編排範圍；實際是否合規，要視乎所用 API、架構、數據服務和 SAP 認可方式而定。^[5][10]

同一組限制亦涵蓋 scraping、harvesting，以及系統性或大規模數據抽取與複製。^[5][10] 因此，受影響的不只是會寫入 SAP 的 agent；大量讀取 SAP 數據去支援外部 AI 平台、lakehouse 或 orchestration layer 的設計，也需要重新審查。^[9][13]

對客戶創新：PoC 不一定停止，但會更正式

對創新團隊、SI 和 ISV 來說，最大變化是實驗前多了一道治理閘門。以前第三方 AI agent 可能較快接入 ERP，測試自動對賬、採購輔助、庫存分析或客服流程自動化；新政策下，團隊要先確認 API 是否列在 SAP Business Accelerator Hub 或產品文件內、架構是否屬於 SAP 認可路徑、用量是否觸發配額或批量抽取限制，以及 agent 會否自行規劃多步 API calls。^[5][7][9]

這不等於 AI PoC 不能做，但會令 PoC 更像正式整合項目：要有 API 盤點、權限設計、用量估算、數據流向審核和合規確認。ERP Today 指出，這項政策把原本偏技術的整合問題，推高成更廣泛的 ERP 架構問題，因為現有整合可能依賴未正式文件化的接口，而新興 AI 應用又需要受控地接觸企業數據和交易流程。^[13]

不確定性本身亦會拖慢創新。The Register 報道指，德語區 SAP 用戶組 DSAG 批評政策帶來不確定性；同一報道亦提到，批評者認為 SAP 認可接口清單未必管理完善或更新及時。^[2]

對數據控制：問題不只是哪個系統擁有數據

這場爭議的焦點，不只是客戶數據所有權，而是客戶能否用自己選擇的 AI 平台、data stack 和自動化工具，直接、即時、連續地存取 SAP 數據與交易流程。The Register 將問題描述為第三方 AI 工具可能被排除於客戶 SAP 數據之外；ERP Today 則把它放在 ERP 整合路線、數據複製與 AI 存取的架構層面討論。^[10][13]

如果企業想把 SAP 數據同步到外部 lakehouse、AI 平台、agent orchestration layer 或第三方自動化系統，就要特別檢查 data ingress／egress 配額、批量抽取或複製前提、已發布 API 範圍，以及是否必須走 SAP 認可路徑。^[7][9][10]

這類限制有助把效能、安全、審計和治理控制集中化；代價是跨平台 AI 架構的自主性可能下降，尤其是需要大量讀寫 SAP 交易數據的 use case。^[9][13]

對供應商鎖定：風險上升，但不是必然結局

鎖定風險來自一個實際問題：如果第三方 AI agent 不能自由同 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 件事

1. 盤點所有 SAP 整合。 把每個接口標記為已發布 API、產品文件內 API、未文件化接口、批量抽取、即時讀寫、RPA、iPaaS 或外部 workflow／agent 調用。^[1][7][13]

2. 特別檢查 AI use case。 凡是由模型或 agent 自行規劃、選擇或執行多個 SAP API calls 的流程，都應先做政策風險評估。^[5][10]

3. 審核數據抽取與複製。 大規模 extraction、replication、scraping 或 harvesting 已被放入限制範圍；現有 data lake、lakehouse、BI、AI 訓練或同步架構都應重新確認配額、前提和允許路徑。^[5][9][10]

4. 要求 SAP 或實施伙伴提供書面確認。 對 agentic AI、自動交易更新、跨系統 orchestration、批量數據導出等高風險場景，不應只靠口頭理解；DSAG 對不確定性的批評，正好說明書面邊界的重要性。^[2]

5. 保留架構選擇權。 即使最終採用 SAP 認可路徑，也應盡量把 AI 編排、數據治理、權限、審計日誌和業務規則設計成可替換模組，避免所有創新邏輯被鎖死在單一路徑之內。

結論

SAP 2026 API 新政策的真正影響，不是 AI 不能用 SAP，而是第三方 AI agent 不能再假設可以自由編排 SAP API。它提高了安全、效能和治理門檻，同時亦帶來更高合規成本、更慢實驗速度，以及更明顯的供應商鎖定風險。^[10][13] 短期內，最務實做法是盤點整合、界定 AI agent 風險、確認 SAP 認可路徑，並在新架構入面刻意保留跨平台選擇權。