2026 年 4 月,SAP 更新 API Policy 后,第三方 AI Agent 能否直接操作 SAP API,已经不只是“接口能不能连上”的技术问题,而是企业架构、合同权利、数据治理和风险责任的问题。[5][
6][
10] SAP 的 API Policy 说明,该政策用于界定 API availability、API limits,并建立控制措施,以保障 solution health 和 security、促进公平访问并防止 API 滥用。[
9]
最受关注的是 AI 条款。外部分析和媒体均指出,API Policy v4/2026 第 2.2.2 节针对会自行计划、选择或执行一连串 API calls 的半自主/生成式 AI 系统;除非通过 SAP 认可架构、数据服务或指定服务路径,这类 API 互动或集成会被禁止。[6][
8][
10]
一句话答案:SAP 管得最严的是“执行型 AI Agent”
这项政策不等于 SAP 全面禁止企业使用 AI。更准确的理解是:SAP 收紧的是 AI Agent 把 SAP API 当作可自由编排的操作层,尤其是 AI 能自行决定下一步调用哪个 API、跨多个 SAP API 完成任务,或把结果写回企业核心系统的设计。[6][
8][
10]
如果一个工具只是基于已导出的数据做摘要、预测或建议,最后仍由员工在 SAP 内确认并执行,通常不会触及最敏感的 agentic AI 模式。相反,如果 AI 会自动查库存、修改订单、创建采购单、审批流程、更新主数据,或把多个 SAP 动作串成端到端工作流,风险就会显著上升,因为这接近政策所描述的多步 API 编排与业务状态变更。[6][
8][
10]
新政策划出的四条实务边界
1. 第三方 AI Agent 需要走 SAP 认可路径
科技媒体 The Register 概括新条款时指出,SAP 禁止在其认可架构之外,用 API 与外部 AI 系统集成,因此引发第三方 AI 工具被排除在客户 SAP 数据之外的担忧。[10] Fivetran 也指出,政策明确点名会自行计划、选择或执行 API call 序列的半自主/生成式 AI 系统。[
8]
换句话说,技术上能接入 API,不再等于政策上可以任意接入。企业若要让第三方 Agent 操作 SAP,关键会变成:该方案是否属于 SAP-endorsed architecture、data service,或 service-specific pathway。[10]
2. Published、documented APIs 成为基本要求
SAPInsider 指出,这次更新把系统访问收紧到 published、documented APIs;未文档化 API 会落在支持边界之外,令长期集成和运营风险上升。[5] SAP API Policy 也说明,Published APIs 包括在 SAP Business Accelerator Hub,或在产品特定文档中识别的 API。[
9]
对长期依赖自定义集成、旧接口或未正式文档化 API 的企业来说,这意味着现有连接方式需要重新盘点。即使某些集成今天还能运行,未来在支持、合规和升级上的不确定性也会更高。[5][
9]
3. 大规模抽取与复制数据同样受限
新条款不只针对 AI Agent 编排 API。Fivetran 和 The Register 均指出,政策也涵盖 scraping、harvesting,以及系统性或大规模数据抽取或复制;除非通过 SAP 控制或认可的架构与路径,这类做法可能受限。[8][
10]
因此,企业若计划把 SAP 数据大量复制到外部 data lake、warehouse 或非 SAP AI 平台,不能只从吞吐量、成本和模型效果评估,还要检查 API policy、合同权利、API limits、审计要求和认可路径。[8][
9][
10]
4. SAP 自家 AI 生态会成为更自然的选项
SAP 官方文档显示,企业可在 SAP BTP 上构建 AI agents,并与 Joule 及 SAP BTP 底层 AI infrastructure 集成;SAP Cloud SDK for AI 也可通过 LangChain 等 adapter 连接常见 Agent framework。[1] SAP 还把 SAP Knowledge Graph 定位为支持 Joule 及其他 AI、包括 AI agents 的能力,通过 SAP 应用中的业务语境提升 AI 回答的准确度和相关性。[
4]
这不代表所有第三方方案都不可行。但在政策边界变窄后,官方或认可路径会更容易被企业架构、法务与风险团队接受。[1][
4][
10]
哪些 AI 项目最受影响?
| 使用场景 | 受影响程度 | 原因 |
|---|---|---|
| 用已授权抽取的数据做 BI、报表或离线分析 | 较低至中等 | 如果 AI 不直接编排 SAP API,较少触及 agentic AI 条款;但大规模抽取或复制仍要检查政策边界。[ |
| Chatbot 只提供建议,由人工在 SAP 执行 | 较低 | 政策核心针对会计划、选择或执行 API call 序列的 AI 系统;纯建议型流程与直接操作型 Agent 不同。[ |
| AI 自动查库存、改订单、开采购单、审批或更新主数据 | 高 | 这类流程通常涉及多步 API call、写回和业务状态变更,正接近政策最关注的 agentic AI 模式。[ |
| 把 SAP 数据大量复制到外部平台供 AI 使用 | 高 | 政策同时点名 scraping、harvesting、系统性或大规模数据抽取与复制。[ |
| 依赖未文档化 API 的旧连接器或自定义集成 | 中至高 | SAPInsider 指出未文档化 API 已落在支持边界之外;SAP Policy 也把 Published APIs 定义为 API Hub 或产品文档中识别的 API。[ |
对创新的影响:PoC 不能只看技术可行性
从平台治理角度看,SAP 有理由限制外部 Agent 无限制、大规模调用核心 ERP API,尤其是涉及写入、交易流程和系统性能的场景;SAP API Policy 也明示其控制目的包括保障 solution health、security、促进公平访问并防止滥用。[9]
但对开发团队而言,AI proof of concept 的前置成本会提高。过去一个实验可能只需取得 API 权限、建立 connector、测试流程;现在如果 AI 会自行决定下一步并跨 API 执行任务,就要先确认是否属于 SAP 认可架构、数据服务或指定服务路径。[8][
10]
结果不是创新停止,而是创新更需要前置治理。自建 Agent、合作伙伴产品或第三方 AI 平台,即使技术上能连到 SAP API,也需要更早进行合同审查、架构审查和数据治理审查。[5][
8][
10]
对数据控制的影响:能取数,不等于能实时操作
这次政策主要处理 API 可用性、API 限制及控制措施,并不是一份完整的数据所有权声明。[9] 但在 agentic AI 场景下,控制权不只关乎能否下载报表,也关乎谁可以实时读取、写入、排序和执行 API calls,并改变 SAP 系统内的业务状态。[
6][
8][
10]
外部分析把这件事形容为企业数据集成的重新盘点:企业不只要问能否取用 SAP 数据,还要问能否让自己选择的 AI Agent 直接对这些数据采取行动。[6]
也需要公平指出,Kai Waehner 的外部分析引述 SAP CEO Christian Klein 的澄清称,政策意图是保护 SAP domain know-how 和避免 performance degradation,而不是阻止客户取用自己的数据。[6] 对企业来说,重点仍是把这类解读落实到合同、API policy、认可架构清单和每个 use case 的明确许可上。[
6][
9][
12]
对 vendor lock-in 的影响:锁定可能出现在流程编排层
Vendor lock-in 不一定表现为数据完全不能导出。在 AI Agent 时代,锁定更可能出现在流程编排层:如果最安全、争议最少、最容易合规的 AI 自动化路线,是把 Agent 放在 SAP BTP、Joule、AI Core 或 Knowledge Graph 相关路径内,企业的长期 AI 架构自然会更依赖 SAP 生态。[1][
4][
10]
The Register 明确指出,新 AI 条款引发 lock-in concern,因为第三方 AI 工具可能更难直接接触客户的 SAP 数据与流程。[10] Fivetran 也认为,这项政策提高了企业 AI strategy 的风险和取舍,特别是当企业希望让 AI agents 存取 ERP 数据时。[
8]
企业现在应做的五件事
- 把 AI use case 拆细。 先分清是 read-only、write-back、人工确认,还是 AI 自行多步执行;政策风险通常在后两者急升。[
6][
8][
10]
- 要求 SAP 或系统集成商确认认可路径。 问清每个场景是否可通过 SAP-endorsed architecture、data service、service-specific pathway,或 SAP BTP/Joule 相关架构落地。[
1][
10]
- 检查 API 是否 published 和 documented。 若现有集成依赖未文档化 API,要预留重构和支持风险;SAPInsider 已指出这类集成的长期运营风险正在上升。[
5][
9]
- 把数据权利写入合同与治理文件。 尤其要厘清第三方 AI 使用、数据抽取与复制、API limits、审计、incident responsibility,以及 AI 写回 SAP 时的责任边界。[
8][
9][
10]
- 持续跟踪 SAP FAQ 和政策更新。 SAP 的 FAQ 文件说明,它会回答 API Policy 常见问题,且可能不时更新;企业不应只依赖一次性的口头解读。[
12]
结论
SAP 新 API 政策的核心信号是:第三方 AI Agent 不能再默认自己可以自由编排 SAP API。对只做报表、离线分析或人工确认的 AI 工具,影响可能有限;但对想用 AI 直接操作 SAP 核心流程、写回 ERP 或大规模复制数据的企业,这是一项架构、合同和数据治理层面的重大检查点。[8][
10]
如果企业已经押注 SAP BTP、Joule 和 SAP AI Core,政策可能让官方路线更清晰。[1][
4] 相反,如果企业希望建立横跨 ERP、CRM、供应链和数据平台的开放式 AI Agent layer,就应在投入开发前,先确认 SAP 认可架构、API 使用权和数据抽取边界,避免把创新项目建在日后不能合规运行的集成方式上。[
5][
10]




