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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

鎖定風險來自一個實際問題：如果第三方 AI agent 不能自由同 SAP API 互動，客戶就更可能依賴 SAP 認可架構、官方數據服務或 SAP 明確容許的整合方式。The Register 已把這條 AI clause 描述為引發 lock-in concern，因為它可能令部分第三方 AI 工具無法接觸客戶的 SAP 數據。

DSAG 的反應顯示，客戶社群關心的不只是技術細節。E3 Magazine 報道指，DSAG 認為 SAP 對未文件化用途、系統性大量數據抽取，以及第三方自主生成式 AI 系統互動的嚴格限制不可接受。

不過，鎖定不是政策的唯一可能結果。真正影響取決於 SAP 之後能否清楚定義認可路徑、保持 API 清單完整和及時更新、提供可審計的例外或批准流程，並容許第三方供應商在清晰規則下繼續創新。批評者已指出認可清單管理和更新速度可能不足，這正是企業採購和架構決策需要追問的地方。

企業現在應該做的 5 件事

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

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

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

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

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

結論

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