如果企业正在把大模型或 AI 智能体接入 SAP,真正需要关注的不是“第三方工具是不是从此不能用”,而是 SAP 正在重新划定核心 ERP 数据和业务流程的 API 使用边界:企业应通过已发布 API、产品文档、SAP 认可架构、数据服务或特定服务路径来访问这些能力。[1][
7][
10]
这会直接影响 AI PoC、数据平台、RPA、iPaaS、ETL,以及企业自己搭建的自动化流程。过去一些“能调通就先跑”的集成方式,在新政策下可能要先回答一个问题:这个接口和这种调用方式,是否在 SAP 支持和认可的范围内?[1][
13]
新政策真正改变了什么
SAP 新政策把 API 使用边界写得更明确。CIO 引述 SAP 的说法称,只有列在 SAP Business Accelerator Hub 或相应产品文档中的接口,才被视为已发布 API。[7] The Register 也报道称,新政策要求用户只能在
SAP-endorsed architectures, data services, or service-specific pathways2][
10]
这意味着,企业不能再默认“只要技术上能调用的 SAP 接口,就适合长期依赖”。政策文件列出的 API 控制项包括功能和技术用量限制、配额、弃用时间表、数据进入和流出配额、批量抽取或复制的限制与前提,以及其他安全或技术要求。[9]
SAPinsider 也指出,未文档化 API 在 SAP 生态中仍被广泛使用,但政策更新后,这类接口会落在支持边界之外,从而增加长期集成和运营风险。[1]
换句话说,这不是单独针对 AI 的一个条款,而是更大的 ERP 集成治理问题:哪些 API 是已发布的,哪些使用方式受支持,哪些数据抽取或复制需要满足前提,以及哪些自动化必须走 SAP 认可路径。[7][
9][
13]
为什么第三方 AI Agent 特别敏感
最受关注的是 AI 相关条款。多家报道引述政策称,除非通过 SAP 认可架构、数据服务或明确指定路径,SAP 禁止 API 被用于同半自主或生成式 AI 系统互动或集成;受影响的是那些会规划、选择或执行一连串 API 调用的系统。[5][
10]
这正是 agentic AI 与传统系统集成的差别。传统集成通常是预先定义好的流程:系统按照固定规则调用某个 API,完成单一任务。AI agent 则可能根据目标动态决定下一步,例如先查供应商,再查库存,再生成采购建议,最后提交审批或更新记录。
只要一个 agent 会自行选择并串联多个 SAP API 调用,就可能落入政策描述的多步 API 编排范围。实际是否合规,还要看所用 API、系统架构、数据服务,以及是否属于 SAP 认可方式。[5][
10]
同一组限制还涵盖 scraping、harvesting,以及系统性或大规模数据抽取与复制。[5][
10] 因此,受影响的不只是会写入 SAP 的 AI agent;如果企业大量读取 SAP 数据来支撑外部 AI 平台、湖仓、数据管道或编排层,也需要重新审查。[
9][
13]
对客户创新:PoC 还能做,但会更像正式项目
对创新团队、系统集成商和独立软件供应商来说,最大变化是实验前多了一道治理关口。过去第三方 AI agent 可能较快接入 ERP,用来测试自动对账、采购辅助、库存分析或客服流程自动化;新政策下,团队需要先确认:API 是否列在 SAP Business Accelerator Hub 或产品文档内,架构是否属于 SAP 认可路径,用量是否触发配额或批量抽取限制,agent 是否会自行规划多步 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 平台、agent 编排层或第三方自动化系统,就需要特别检查数据进入和流出配额、批量抽取或复制前提、已发布 API 范围,以及是否必须走 SAP 认可路径。[7][
9][
10]
这类限制有助于把性能、安全、审计和治理控制集中起来;代价是跨平台 AI 架构的自主性可能下降,尤其是那些需要大量读写 SAP 交易数据的用例。[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 件事
-
盘点所有 SAP 集成。 把每个接口标记为已发布 API、产品文档内 API、未文档化接口、批量抽取、实时读写、RPA、iPaaS 或外部 workflow/agent 调用。[
1][
7][
13]
-
重点检查 AI 用例。 凡是由模型或 agent 自行规划、选择或执行多个 SAP API 调用的流程,都应先做政策风险评估。[
5][
10]
-
审查数据抽取与复制。 大规模 extraction、replication、scraping 或 harvesting 已被纳入限制范围;现有 data lake、lakehouse、BI、AI 训练或同步架构,都应重新确认配额、前提和允许路径。[
5][
9][
10]
-
要求 SAP 或实施伙伴提供书面确认。 对 agentic AI、自动交易更新、跨系统编排、批量数据导出等高风险场景,不应只依赖口头理解;DSAG 对不确定性的批评,正好说明书面边界的重要性。[
2]
-
保留架构选择权。 即使最终采用 SAP 认可路径,也应尽量把 AI 编排、数据治理、权限、审计日志和业务规则设计成可替换模块,避免所有创新逻辑被锁死在单一路径内。
结论
SAP 2026 API 新政策的真正影响,不是“AI 不能用 SAP”,而是第三方 AI agent 不能再假设可以自由编排 SAP API。它提高了安全、性能和治理门槛,同时也带来更高合规成本、更慢实验速度,以及更明显的供应商锁定风险。[10][
13]
短期内,企业最务实的做法是:盘点现有集成,界定 AI agent 风险,确认 SAP 认可路径,并在新架构中有意识地保留跨平台选择权。




