SAPContractChange

SAP API Policy v4/2026: impatti

Perché due pagine di policy possono ridisegnare i confini dell’AI enterprise*

A fine aprile 2026 SAP ha pubblicato, con relativa discrezione sull’Help Portal, un documento di due pagine destinato a far discutere: la SAP API Policy v4/2026a. Tre sezioni, linguaggio legale asciutto, impatto potenzialmente enorme su chiunque abbia mai integrato un sistema non-SAP o stia costruendo scenari AI su dati ERP. 

La motivazione dichiarata è la tutela di “solution health and security” di fronte all’esplosione delle chiamate API da sistemi esterni, comprese le architetture AI. Motivazione legittima. Ma il testo della policy, a parere di molti, va molto oltre la gestione del traffico e questo è il punto che ha generato reazioni a catena tra clienti, partner, analisti e studi legali internazionali. 

SAP gestisce i dati che alimentano il 90% delle supply chain mondiali. Quando ridefinisce le regole di accesso a quei dati, non si tratta di aggiornare il manuale d’uso: si tratta di ridisegnare i confini di un ecosistema che vale miliardi. 

 

Cosa dice esattamente la policy? 

Il testo ufficiale è disponibile sull’SAP Help Portal. Consiglio a tutti gli interessati di leggerlo senza intermediari. Per comodità e contesto, a seguire ne riassumo e cito alcune parti.  

La sezione 1 introduce una classificazione netta in tre categorie: 

  • API pubblicate (Published APIs): quelle documentate nel SAP Business Accelerator Hub o nella documentazione di prodotto specifica. Sono le uniche consentite per l’uso previsto (“Documented Use”), che include integrazione, estensioni, sincronizzazione dati, scambio dati, trigger di eventi e scenari di business analoghi. 
  • API non pubblicate (Non-Published APIs): la Sezione 1.2 è esplicita: “Customer and third-party applications must not access, invoke, or interact in any manner with APIs that are not Published APIs.” Eccezioni limitate: API ABAP sviluppate su misura in ambienti private cloud e on-premise, se espressamente autorizzate dalla documentazione SAP. Tutto il resto (incluse API interne, private, o legate a client riservati SAP come i namespace S/4HANA) è fuori perimetro. E la policy avverte: queste interfacce possono essere modificate o rimosse senza preavviso. 
  • API esplicitamente vietate: quelle classificate come “Confidential and Proprietary” o bloccate da SAP Note specifiche. Caso emblematico citato dagli analisti: ODP-RFC per strumenti di terze parti. 

Il punto critico per molte organizzazioni è che RFC calls, BAPI e altre route tradizionali, da decenni backbone dei flussi dati SAP, rientrano presumibilmente nella categoria delle API non pubblicate. Ma passiamo alla sezione 2 dove parliamo di controlli. 

  • Specific API Controls (2.1) sono i controlli tecnici documentati per ogni API: rate limit, quote, deprecation schedule, limiti per bulk extraction, requisiti di sicurezza. Nulla di particolarmente nuovo, ma ora formalizzato in modo vincolante. Da sapere ma nulla di più. 
  • General API Controls (2.2) sono “il problema”. La Sezione 2.2.1 vieta l’uso delle API per: analisi competitiva, funzioni non previste dalla Documented Use (salvo autorizzazione SAP), e qualsiasi attività che crei rischi per performance, stabilità o sicurezza del sistema

La Sezione 2.2.2 il cuore della controversia. 

Recita testualmente: 

Except through and within the limits of SAP-endorsed architectures, data services, or service-specific pathways expressly identified and intended for such purposes, SAP prohibits API use for: (a) interaction or integration with (semi-)autonomous or generative AI systems that plan, select, or execute sequences of API calls, and (b) scraping, harvesting, or systematic and/or large-scale data extraction or replication. 

In italiano “semplificato”: se il tuo AI agent interroga SAP in autonomia (pianificando, selezionando o eseguendo sequenze di chiamate API) stai violando la policy, a meno che non passi per architetture espressamente approvate da SAP come Joule (l’AI di SAP), BTP e SAP Business AI Platform. 

SAP si riserva il diritto di monitorare l’uso delle API e di adottare “reasonable enforcement actions” in caso di non conformità. Le misure previste sono: throttling, sospensione o terminazione dell’accesso. Ed è esplicitamente vietato aggirare i controlli attraverso “intermediary services, custom code or developments, proxies, gateways, impersonation techniques, or similar mechanisms. 

L’unica tutela esplicitamente garantita è quella verso gli obblighi di legge: la policy non limita le obbligazioni di SAP relative a data export o data egress richiesti da norme specifiche (portabilità dei dati, switching, conservazione legale). 

Le reazioni 

Da qualche mese molti si sono espressi. 

La Deutschsprachige SAP-Anwendergruppe (DSAG) ha pubblicato una nota ufficiale il 29 aprile 2026, dura nei toni e precisa nei contenuti identificando tre richieste specifiche: definizioni chiare e documentazione completa delle API coinvolte, garanzie contrattuali esplicite, e tempi di transizione realistici per chi dipende da API non documentate. 

Forrester ha sintetizzato il quadro senza mezzi termini: “Three weeks ago, the SAP API Policy v.4.2026a looked like a legal document with no enforcement infrastructure. After Sapphire 2026, it looks like a strategy with a product line attached.“. L’enforcement tecnico inizia il 9 giugno 2026, con una security patch che blocca ODP via RFC calls non conformi. 

 

Il nodo contrattuale: la policy è davvero vincolante? 

La risposta è “dipende”. 

  • Per i contratti cloud (RISE, S/4HANA Cloud, BTP): un Cloud Service Agreement SAP è composto da Order Form, Supplemental Terms and Conditions, Support Schedule, SLA, DPA e General Terms and Conditions. Se le GTC prevedono che SAP possa aggiornare la Documentation unilateralmente (come accade in molti contratti cloud moderni) la policy potrebbe essere già contrattualmente operativa. Per i nuovi contratti e i rinnovi, è quasi certamente così. 
  • Per i contratti on-premise / licenza perpetua: la struttura è diversa (Order Form + Software Use Rights + GTC for Software and Support). Il legame con la Documentation pubblicata sull’Help Portal è meno diretto e più contestabile. Qui i clienti potrebbero avere argomenti contrattuali solidi. 
  • Per RISE with SAP / Private Cloud: la policy è esplicitamente applicabile. Il contratto RISE incorpora Supplemental Terms che richiamano la Documentation. 

Nota: quanto sopra è la mia interpretazione sulla base dei molti contratti visionati nel mio lavoro. Tuttavia, consiglio un parere legale sull’argomento, specialmente nei casi “grigi”. 
 
*Articolo a firma di Jary Busato, SAM/ITAM Consultant in WEGG – The Impact Factory 
 
ATTENZIONE! Questo articolo è redatto da Jary Busato a scopo informativo e di condivisione. Le analisi e i commenti espressi rappresentano il punto di vista dell’autore e non costituiscono parere legale o consulenza contrattuale. I contenuti si basano su fonti pubblicamente disponibili, citate a fine articolo. SAP SE e i prodotti menzionati sono marchi registrati dei rispettivi proprietari. L’autore non ha affiliazioni commerciali con SAP SE né con i vendor citati. I contenuti sono aggiornati a giugno 2026. 

 

Fonti e/o articoli interessanti sull’argomento 

  • SAP API Policy v4/2026a — testo ufficiale (SAP Help Portal, aprile 2026) 
  • DSAG Pressemitteilung, 29 aprile 2026 
  • CIO.com — “SAP’s new API policy restricts AI access, draws customer criticism”, Manfred Bremmer, 4 maggio 2026 
  • SAPinsider — “SAP’s New API Policy Redefines Access in the AI Era”, Adam Pitman, 28 aprile 2026 
  • The Register — “AI clause in new SAP API policy provokes lock-in concern”, 29 aprile 2026 
  • Hunton Andrews Kurth LLP — “SAP’s New API Policy Raises New Compliance and Continuity Risks”, 26 maggio 2026 
  • Forrester — “SAP Is Attempting To Become The Gatekeeper Of Enterprise AI — CIOs Should Push Back”, maggio 2026 
  • Forrester — “SAP Sapphire 2026: The Autonomous Enterprise Is Credible, But It Comes With Concentration Risk”, maggio 2026 
  • diginomica — “SAP Sapphire 2026 — SAP CTO Philipp Herzig on SAP’s API policy changes”, giugno 2026 
  • Simplifier AG — “SAP API Policy: Facts, risks and recommendations for your AI strategy”, 2026 
  • AI Magazine — “Can AI agents still access SAP data under new API rules?”, 2026 
  • cio.inc — “Explained: Why SAP Rewrote Its Third-Party API Policy”, 2026 
  • blog.zeis.de — “A Clearer View of Your SAP Integrations Under the New API Policy”, giugno 2026 
  • SAP Community — thread “Impacts of SAP API Policy v4/2026 on existing customer integrations”, 2026 

Approfondimenti

Chi è coinvolto e in che misura 

La policy si applica a tutte le soluzioni SAP cloud e on-premise, inclusi S/4HANA Private Cloud (RISE) e tutte le line-of-business solution. 

  • Clienti con integrazioni legacy: chiunque abbia costruito connessioni negli anni scorsi su API non documentate (RFC, BAPI, route non standard) si trova tecnicamente fuori perimetro. La SAP Community ha già registrato numerose domande su architetture esistenti: CDS OData service custom, estensioni BTP, scenari di estrazione dati. La risposta di SAP è che le integrazioni esistenti non sono immediatamente colpite, ma la situazione cambia al rinnovo contrattuale. 
  • Partner e ISV: l’impatto è potenzialmente più severo. Molti add-on dipendono da API non standard per accedere a dati che le interfacce pubblicate non espongono. Migrare a Published API può richiedere riscritture significative o comportare perdita di funzionalità se le API equivalenti non esistono. 
  • Aziende con strategie di AI agentica: questo è il fronte più caldo. Strumenti come Agentforce (Salesforce), Copilot (Microsoft), ServiceNow, Workday Illuminate, Celonis… ovvero tutti sistemi che per loro natura “pianificano, selezionano ed eseguono sequenze di API calls”, se non instradati attraverso percorsi SAP-endorsed, sembrerebbero rientrare nella casistica della Sezione 2.2.2. 
02-s pattern02

Vorresti approfondire il tema dell’accesso indiretto in SAP?

CONTATTACI PER APPROFONDIRE!