Perché due pagine di policy possono ridisegnare i confini dell’AI enterprise*
In questo articolo approfondiamo la SAP API Policy v4/2026, il documento che ridefinisce le regole di accesso alle API SAP e solleva interrogativi importanti per chi sta costruendo scenari AI su dati ERP. Dalla classificazione delle API alle implicazioni per i sistemi agentici, fino alle FAQ pubblicate da SAP e al nodo contrattuale: cosa cambia, per chi e in che misura.
At the end of April 2026, SAP published, with relative discretion on the Help Portal, a two-page document destined to cause discussion: the SAP API Policy v4/2026a. Three sections, dry legal language, potentially huge impact on anyone who has ever integrated a non-SAP system or is building AI scenarios on ERP data.
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.
The official text is available on the SAP Help Portal. I advise everyone interested to read it without intermediaries. For convenience and context, below I summarize and quote some parts of it.
Section 1 introduces a clear classification into three categories:
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. Le FAQ ridimensionano il timore, e ne parliamo tra poco. Prima, la sezione 2, quella dei controlli.
It reads verbatim:
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, e lo fa fuori dai percorsi approvati, stai violando la policy. Quei percorsi sono le 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).
Dopo la pubblicazione della policy, SAP ha rilasciato delle FAQ per rispondere ai dubbi più frequenti. Quanto segue si basa sulla versione 1.3 (giugno 2026).
Il criterio di compliance che emerge è semplice: conta l’interfaccia SAP usata e il pattern di accesso, non la piattaforma da cui parte la chiamata.
Restano consentiti namespace Z, Custom ABAP, OData services, CDS views e RFC modules sviluppati dal cliente. È un chiarimento importante per chi, leggendo la Sezione 1.2, temeva che l’intero mondo RFC/ABAP fosse fuori perimetro.
Con delle condizioni: il codice custom non deve creare carico eccessivo o rischi di sicurezza sul sistema, non deve interagire con componenti SAP etichettati come interni, privati o riservati, e non deve diventare un canale per estrazioni massive di dati o per agenti AI non approvati.
SAP Integration Suite è raccomandata ma non obbligatoria. Middleware e iPaaS di terze parti sono allineati alla policy, se consumano API pubblicate nel rispetto dei controlli generali.
Sì, ODP-RFC è un pattern di integrazione esplicitamente vietato. Le FAQ lo indicano come interfaccia di estrazione legacy, non approvata per strumenti non SAP, e richiamano la SAP Note 3255746: qualsiasi uso da parte di applicazioni di clienti o terze parti verso sistemi ABAP che contengono PI_BASIS, SAP BW o SAP BW/4HANA, on-premise o in private cloud, è vietato.
Chi lo usa tramite piattaforme di terze parti è invitato a contattare il proprio account executive SAP per concordare un percorso di migrazione. Le alternative indicate per i grandi volumi sono SAP Business Data Cloud, SLT, ODP-OData e analytical CDS views con servizi OData V4.
Le integrazioni esistenti che usano API non documentate non vengono invalidate retroattivamente come atto di enforcement. Per la gran parte dei casi la situazione è invariata: restano “a proprio rischio“, cioè possono continuare a funzionare, ma senza le garanzie di stabilità o supporto di SAP.
Se SAP individua un’interfaccia o un pattern che presenta un rischio di sicurezza per la piattaforma o per i dati, promette preavviso e supporto nella migrazione prima di intervenire.
La policy vieta i pattern di accesso agentivo non governato: un agente che pianifica ed esegue da solo sequenze di chiamate API, collegato alle API SAP senza passare da un percorso approvato.
Non vieta l’AI agentica in sé: il problema, secondo SAP, è che un singolo prompt può generare migliaia di chiamate, con rischi per stabilità, sicurezza e integrità dei dati. L’automazione deterministica con sequenze predefinite di chiamate API (RPA) non rientra in questa restrizione, pur restando soggetta al resto della policy.
In conclusion percorsi approvati per gli agenti di terze parti sono:
Un’avvertenza: nelle FAQ l’Agent Gateway destinato alle piattaforme di terze parti è descritto al futuro. Conviene verificarne la disponibilità prima di pianificare.
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. Riguarda chiunque abbia licenziato un’applicazione SAP, comprese le applicazioni dei partner.
Tra aprile e luglio 2026 molti si sono espressi.
Mapping 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.
Sui tempi di transizione la risposta di SAP resta generica: nessun periodo di grazia o scadenza formale, solo l’impegno a non bloccare o limitare un’integrazione esistente senza un contatto preventivo. Le garanzie contrattuali restano aperte: le FAQ stesse precisano di non far parte di alcun contratto.
Nelle settimane successive DSAG ha incontrato SAP, e parte delle sue osservazioni è confluita nelle FAQ aggiornate presentate a Sapphire, fine maggio 2026. Il presidente Jens Hungershausen ha però continuato a chiedere, anche in giugno e luglio, condizioni chiare, affidabili e contrattualmente solide, senza zone grigie per processi end-to-end, soluzioni di partner e scenari AI: un segnale che, dal lato DSAG, il nodo contrattuale non è considerato chiuso.
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.“. Il passaggio dalla carta all’operatività è arrivato il 9 giugno 2026, con una security patch che blocca ODP via RFC calls non conformi.
The answer is "it depends". Le FAQ dicono che la policy da sola non modifica le concessioni di licenza né i diritti funzionali, e che l’approccio di SAP privilegia monitoraggio e dialogo rispetto alle penali. Precisano però anche di non essere vincolanti: in caso di conflitto prevalgono il contratto applicabile e la Documentation. Da sole, quindi, non risolvono la questione contrattuale.
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”.
ATTENZIONE! Questo articolo è redatto da Jary Busato, SAM/ITAM Consultant in WEGG, e poi ampliato dalla redazione 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 settembre 2026.
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2025 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Azienda Certificata ISO 9001:2015 – ITA / ISO 9001:2015 – EN
