SAP为自主AI划界及影响
2026年4月末，SAP悄然发布了其API政策4/2026版本（Section 2.2.2），这被视为今年最具影响力的企业AI治理文件。该条款明确禁止通过非SAP认可的架构使用API与半自主或生成式AI系统进行交互，尤其针对能够自主规划、选择和执行API调用序列的“附加AI”。此举不仅重塑了企业AI代理的架构边界，更在客户社区引发关于锁定、合规与开放性的激烈讨论。本文深度剖析政策细则、五大解读、与微软/赛富时等竞品的对比，以及客户和合作伙伴必须立即采取的行动。
Section 2.2.2 真实含义：禁止计划、选择或执行API调用序列的AI
条款直白禁止通过SAP认可的架构、数据服务或特定服务路径之外的任何方式，将API用于与半自主或生成式AI系统的交互或集成。同时明确禁止数据抓取、大规模提取。唯有SAP商务加速器中心或产品文档中列出的已发布API方可使用，且必须用于其记录的目的。任何代理性使用都必须经由SAP认可的路径。政策保留限流、暂停甚至终止访问的执行权利，并禁止通过代理、中间服务、自定义代码或模拟身份进行规避。
社区五大解读：从技术封闭到商业锁定的多棱镜
- 技术封闭：社区维护者Marian Zeis指出，SAP行动缓慢，导致实际项目依赖未记录的API，新政策使这种依赖非法。
- 商业路径控制：架构师Jorge Ocampos直言，SAP并非反对Claude/GPT，而是控制代理接触SAP数据的路径——必须是BTP、Joule、AI Core等，并消耗AI单元（消费计价模型）。
- 锁定担忧：德语SAP用户组DSAG公开要求合同明确性、过渡时间表和公平使用阈值，保护现有集成。
- 区分“附加AI”与“分离AI”：附加AI（attached AI）规划、选择并执行对生产系统的API调用，被政策锁定；分离AI（detached AI）仅辅助理解、生成代码、搜索文档，不触发生成交易，不受影响。这是最核心的概念框架。
- 程序模糊：政策未列出“SAP认可的架构”具体清单，造成合规迷雾。实践者不知道哪些路径被认可，这恰是合同纠纷的温床。
“附加AI” vs “分离AI”：区分决定合规风险
分离AI（如Copilot辅助ABAP开发）完全安全；附加AI（如LangGraph代理读取S/4HANA采购订单、规划执行发邮件并写入更新）必须通过SAP认可的路径（Joule、MCP网关、BTP、BDC）才能合规。大多数恐慌源于误将分离AI纳入政策范围。
与竞品对比：SAP的独立路径选择vs微软的网关、赛富时的结果管控
- 微软：通过Azure AI Gateway、Agent 365、Agents SDK框架无关地管控身份、可观测性和令牌速率，明确支持OpenAI、Anthropic、LangChain等任意框架。
- 赛富时：通过Einstein信任层和每次对话定价，主要限制自动化决策的法律效果。唯一例外是去年收紧Slack数据条款，限制外部AI工具索引。
- ServiceNow：在2025年12月版本中增加A2A v0.3互操作性，并内置递归循环保护。
- Oracle：资源绑定，默认每个租户最多2个代理，工具数上限。
- HubSpot：按结果付费（每次解决对话约50美分）。
- Zoho：MCP服务器明确模型无关。
所有对手都选择了不同的控制点，SAP是唯一在此规模下选择架构限制的玩家。微软、ServiceNow和超大规模云商未来两个季度将在CIO对话中积极利用这一差异。
SAP认可路径清单：BTP、Joule、MCP网关、BDC为核心
虽然没有枚举白名单，但SAP架构中心、AI黄金路径和产品文档给出了稳定库存：已发布API（SAP商务加速器中心+产品API）、代理运行时栈（AI Core、GenAI Hub、Joule Studio、SAP Build）、执行边界（MCP网关在集成套件内，强制工具白名单、每个工具授权、人工干预）、集成与事件（集成套件、Event Mesh、IAS App2App令牌）、数据（Business Data Cloud、HDC向量引擎、知识图谱）、互操作性与A2A协议。旧的模式：“代理→调用API→SAP”；新模式：“代理→经过治理的SAP路径→调用已发布API、事件、数据产品→SAP”。更多中介、更多日志、更多SAP架构，几乎必然更多SAP支出。
三种客户情境及其合规行动
- SAP原生代理（Joule、采购代理、争议解决代理）：最低风险，需要运营性工作：跟踪消耗、记录审批、要求SAP提供透明定价。
- 合作伙伴/ISV构建在SAP技术上：必须证明架构合规——盘点每个API/端点/事件，映射到文档用途，明确分类是否包含附加AI，指明认可路径，定义写操作审批阈值，捕获审计痕迹。灰色设计需书面确认。
- 基于非SAP技术运行AI代理：最高风险。安全模式是将推理与执行分离：外部代理（Bedrock/Vertex/Copilot Studio/LangGraph）通过BDC、Datasphere或HDC向量引擎接地数据，而执行由SAP控制的服务完成。使用A2A到Joule作为行动，而不是直接API编排。必须使用IAS App2App令牌，不得使用共享账户。实现人工干预门控（财务、HR、采购、供应商主数据、定价、支付、库存、生产）。停止使用未记录API。注意，该政策与SAP数字访问许可关联：每个自动创建的发票文档都需支付数字访问费用。
政策耐久性：精神持久但条文脆弱，预计未来数月内将澄清
反抓取、限流、反规避、使用已发布API完成其目的——这些都是合理的。但原文本中的强架构限制面临真实阻力：企业架构正走向开放多代理网格（基于MCP和A2A），且SAP无法可靠区分代理流量与人类流量。CEO Christian Klein在投资者电话中已软化态度，称政策主要涉及SAP的领域知识而非客户数据。DSAG也正式表达了矛盾。预测未来几个月内，SAP将发布澄清材料（FAQ、v5政策），明确三点：现有合作伙伴方案和客户集成获“祖父条款保护”；定义“SAP认可架构”为维护的版本列表并附弃用时间线；软化为公平使用限流加反规避条款。若不及时澄清，微软、ServiceNow、Salesforce和超大规模云商将利用“开放替代方案”进行竞争伤害。
SAP的边界争夺：下一步必须用价值证明必要性
政策在技术上有道理、商业上自私、战略上脆弱。SAP需要做三件事：公布清晰、维护的认可代理架构白名单；通过A2A、BDC Connect和MCP网关认证非SAP运行时的代理模式，使客户不必将所有代理放入BTP即可合规；使认可路径真正有价值而非只是强制。BDC Connect零拷贝共享（Databricks、Snowflake、Fabric、GCP）是读取侧的良好范例；写入侧，Joule和MCP网关必须成为从任何地方执行SAP交易的最佳方式，不仅是唯一合规方式。SAP已经画了栅栏，现在必须赢得它。接下来的两个政策修订将说明公司是否理解这一点。
