Giro di vite di SAP sull’utilizzo delle API per agenti AI: clienti e partner in subbuglio

Per decenni SAP ha rappresentato il sistema nervoso centrale delle più grandi organizzazioni mondiali, gestendo processi critici che vanno dalla supply chain alla contabilità. Tuttavia, la recente pubblicazione delle nuove linee guida relative alle API ha innescato un acceso dibattito acceso che tocca i nervi scoperti della sovranità dei dati e della libertà di innovazione. Un cambio di paradigma che, sotto l’egida della sicurezza e della stabilità, sembra voler tracciare un confine netto tra ciò che è permesso e ciò che è proibito nel nascente ecosistema degli agenti AI.

Al centro di questa controversia c’è un documento di policy aggiornato il mese scorso, nel quale SAP stabilisce un divieto esplicito all’utilizzo delle proprie API per interagire con sistemi AI semi-autonomi o generativi che non rientrino nelle architetture ufficialmente approvate dal fornitore. Questa mossa non colpisce soltanto i partner di terze parti, ma si ripercuote direttamente sui clienti finali, limitando la loro capacità di orchestrare flussi di lavoro complessi attraverso strumenti AI esterni.

La clausola parla chiaro: l’estrazione sistematica di dati, lo scraping su larga scala e, soprattutto, l’esecuzione di sequenze di chiamate API pianificate da agenti autonomi sono ora attività considerate fuori norma, a meno che non passino attraverso i canali “endorsed” da SAP stessa.

Per un CTO o un responsabile dell’innovazione, questo scenario somiglia pericolosamente a un tentativo di blindare il patrimonio informativo aziendale dentro un recinto proprietario. Sebbene la proprietà dei dati rimanga formalmente in capo al cliente, l’accesso a quegli stessi dati viene mediato da regole che SAP può modificare o revocare a propria discrezione.

Marian Zeis, consulente indipendente di grande esperienza nel mondo tedesco, ha sollevato una questione tecnica non trascurabile, ovvero la cronica lentezza di SAP nel documentare e aggiornare le proprie interfacce ufficiali. Nella pratica quotidiana, gli sviluppatori sono spesso costretti a fare affidamento su API non documentate per far funzionare le personalizzazioni richieste dal business. Rendere obbligatorio l’uso esclusivo delle API documentate significa dare al vendor il potere assoluto di governare, monitorare e, se necessario, soffocare qualsiasi sviluppo che non sia in linea con la propria roadmap commerciale.

Dal punto di vista della dirigenza SAP, la narrazione è diametralmente opposta. Il CEO Christian Klein ha infatti cercato di rassicurare gli investitori e il mercato, affermando che la piattaforma rimarrà aperta e che nessuno dovrà pagare per accedere ai propri dati. La giustificazione ufficiale poggia su due pilastri come la stabilità del sistema e la protezione della proprietà intellettuale.

Un argomento che in effetti ha una sua logica ferrea, visto che quando un agente AI inizia a generare milioni di chiamate API per estrarre pattern o automatizzare processi, il rischio di degradare le prestazioni dell’intero sistema ERP è concreto. Throttling e controllo degli accessi diventano, in questa ottica, strumenti di difesa necessari per evitare che l’entusiasmo per l’IA si traduca in un disservizio per le operazioni core dell’azienda.

Esiste anche una componente di sicurezza informatica che non può essere ignorata. Esperti come Alisdair Bach sottolineano come nell’attuale panorama delle minacce i sistemi aziendali siano costantemente messi alla prova da agenti automatizzati, capaci di individuare punti di accesso deboli molto più velocemente di quanto potrebbe fare un essere umano.

In un simile contesto, permettere schemi di integrazione troppo permissivi o poco controllati significa esporre il fianco a violazioni di dati potenzialmente catastrofiche. Il confine tra protezione legittima e protezionismo commerciale è però estremamente sottile. La critica mossa dalla DSAG, l’influente gruppo degli utenti SAP di lingua tedesca, evidenzia proprio questa ambiguità. Se ogni modulo funzionale interno a SAP è tecnicamente un’API, l’incertezza su quali di esse siano utilizzabili senza ritorsioni legali o tecniche rischia di paralizzare l’innovazione.

D’altronde, non scopriamo certo oggi che l’incertezza è la vera nemica del progresso tecnologico. Se le aziende non hanno la certezza che i propri investimenti in soluzioni AI di terze parti rimarranno compatibili con il nucleo SAP, preferiranno probabilmente attendere o adottare esclusivamente le soluzioni proposte dal vendor, anche se meno performanti o più costose.

Questo meccanismo di “lock-in” tecnologico è precisamente ciò che spaventa il mercato. Jens Hungershausen, alla guida della DSAG, teme proprio che la mancanza di chiarezza normativa scoraggi l’adozione di nuove tecnologie e impedisca alle imprese di sperimentare in un momento storico in cui la velocità di adattamento è tutto. Il rischio insomma è che le aziende europee, già impegnate in una difficile rincorsa tecnologica, si trovino con le mani legate da policy contrattuali eccessivamente rigide.

Riconoscimento editoriale Kittyfly Shutterstock

Il documento di SAP parla anche di limitazioni ai “service-specific pathways”, un termine che lascia ampio spazio all’interpretazione ma che sembra suggerire una preferenza strutturale per lo stack tecnologico interno, come la SAP Business Technology Platform (BTP). Chi decide di percorrere strade diverse, magari integrando modelli linguistici di grandi dimensioni ospitati su altri cloud o sviluppando agenti proprietari per la gestione della logistica, si trova ora a camminare su un terreno minato. La possibilità che SAP revochi la “white-listing” di determinate interfacce crea infatti una spada di Damocle sopra ogni progetto di integrazione custom.

Nel frattempo, la risposta ufficiale dell’azienda continua a battere sul tasto dell’equità d’uso e degli standard industriali del cloud. SAP sostiene che queste modifiche siano necessarie per supportare un accesso basato sull’automazione che sia sostenibile nel tempo. Eppure, il sospetto che si tratti di una manovra per proteggere il “know-how di dominio” citato da Klein rimane forte.

SAP è infatti consapevole di possedere il contesto dei dati aziendali, ovvero l’asset più prezioso dell’era moderna. Un modello AI è potente solo se ha accesso a dati di qualità e i dati di qualità risiedono quasi sempre nei database SAP. Impedire a terzi di accedervi liberamente attraverso agenti intelligenti significa mantenere il controllo sulla catena del valore dell’intelligenza artificiale applicata al business.

Mentre altre realtà del settore SaaS sembrano muoversi verso una maggiore apertura per scongiurare l’obsolescenza, SAP sceglie quindi la strada della regolamentazione interna ferrea. La partita tra la necessità di proteggere la stabilità dei sistemi e il desiderio delle aziende di sfruttare l’AI in modo agnostico rispetto al fornitore è appena iniziata, e la sensazione è che le sue conseguenze si faranno sentire ben oltre i confini del mondo SAP.

(Immagine in apertura: Shutterstock)