Durante SAP Sapphire a Madrid, abbiamo incontrato Philipp Herzig, Chief Technology Officer e Chief AI Officer di SAP, che ha fornito spunti diretti e di ampio respiro sull’evoluzione della piattaforma SAP, sul ruolo dell’intelligenza artificiale generativa e sulla trasformazione dei sistemi aziendali. Il suo messaggio è chiaro: “L’AI è pronta. Le aziende devono mettersi nelle condizioni di utilizzarla davvero”.
E per utilizzarla devono necessariamente effettuare la transizione dal cloud, operazione la cui complessità dipende dal grado di personalizzazione effettuato sulle versioni on premise.
SAP conta oggi quasi 10.000 clienti su RISE with SAP, un dato che mostra un’accelerazione netta nella transizione verso il cloud. Tuttavia, rimane una grande base installata su sistemi on-premise — da S/4HANA a versioni più datate come ECC — ancora in fase decisionale. Il termine della manutenzione nel 2028 rappresenta una spinta concreta, ma secondo Herzig l’elemento realmente trasformativo è la pressione tecnologica: chi resta indietro non può accedere alle innovazioni, a partire dall’AI. “È come voler usare Apple Intelligence su un iPhone 12”, osserva. “Semplicemente non si può. Le aziende devono aggiornare i sistemi per accedere alle nuove capacità”.
Molti clienti esitano perché i loro sistemi SAP sono cresciuti in modo disordinato, spesso personalizzati pesantemente da system integrator che hanno sviluppato codice custom anche laddove esistevano soluzioni standard. “Abbiamo lasciato troppa libertà in passato”, ammette Herzig. “Tutti potevano modificare tutto, anche le funzioni private”.
Questo porta oggi a una sfida complessa, che Herzig paragona a un “three-way merge”: SAP evolve, il cliente evolve, ma riconciliare le due linee di sviluppo è difficile e costoso. È come tornare a fare sport dopo anni di inattività: doloroso all’inizio, ma inevitabile per stare al passo.
Joule for Consultants: la bussola per orientarsi nella complessità
Proprio per affrontare questa complessità, SAP ha sviluppato Joule for Consultants, lo strumento pensato per i team IT e gli architetti di processo. A differenza di Joule for Developers, focalizzato sulla riscrittura del codice, Joule Consultant guida la mappatura della trasformazione aziendale: analizza i sistemi esistenti, confronta i processi reali con le best practice SAP, misura le deviazioni e suggerisce i passi per allinearsi al nuovo standard.
È uno strumento consulenziale, che permette di affrontare il passaggio da moduli obsoleti a soluzioni moderne, aiutando a riformulare architetture e configurazioni. In aziende complesse, con centinaia di sistemi, Joule for Consultants rappresenta il “navigatore intelligente” in grado di trasformare una migrazione in una roadmap strutturata.
Per quanto riguarda il codice legacy, SAP adotta una strategia mista. Prima si classificano le personalizzazioni: ciò che può essere eliminato, ciò che va riscritto e ciò che è già conforme. Poi si applicano strumenti a regole statiche che analizzano le chiamate, i moduli e le funzioni obsolete.
Quando le regole non bastano, entra in gioco l’intelligenza artificiale. SAP ha sviluppato un LLM proprietario per il linguaggio ABAP, capace di interpretare e riscrivere codice legacy in modo conforme al modello clean core. È l’unione tra regole deterministiche e AI generativa che permette di affrontare anche i casi più sfumati, riducendo gli errori e aumentando la produttività.
Una delle principali forze che spinge oggi le aziende a modernizzare è l’AI stessa. Joule, la piattaforma AI di SAP, non è solo una promessa: è già operativa in realtà come Standard Chartered Bank, che gestisce 2 trilioni di dollari al mese su SAP in cloud, con AI embedded e aggiornamenti continui ogni sei settimane. “È il nostro cliente modello”, racconta Herzig. “Molti lo guardano per capire come replicarne l’approccio”. L’interesse per l’AI non è più teorico: è operativo, pragmatico e guidato dal ritorno sull’investimento.
Il focus si è poi spostato sull’utilizzo di soluzioni esterne a SAP, come gli LLM.
Nel mondo SAP, i modelli linguistici non sono una scelta ideologica. Herzig li definisce “commodity”, come i dischi rigidi o i server. La differenza sta in come vengono gestiti e integrati, non in chi li produce. SAP esegue LLM sia commerciali sia open source nei propri data center, assicurando controllo, sicurezza e compliance.
Il cliente non sa (e non deve sapere) quale modello viene usato: sa solo che funziona, rispetta le policy e produce valore. SAP si assume la responsabilità dell’intera catena, compreso il comportamento del modello. Come nel cloud, dove non si sa quando viene sostituito un disco fisico, ma si sa che il servizio rimane stabile e performante.
Il valore per il business derivante dall’uso di modelli esterni deriva dalla qualità dell’integrazione nella piattaforma. Herzig insiste sul fatto che il prompting non è una banalità tecnica. È una disciplina progettuale che in SAP viene trattata con la stessa serietà del coding. Il lavoro sui prompt inizia con l’identificazione del caso d’uso, passa per il benchmarking su più modelli (GPT, Claude, Gemini, LLaMA), include red teaming e controlli di sicurezza, e si chiude con l’ottimizzazione guidata dal Prompt Optimizer.
Ogni prompt è parte di una pipeline complessa che integra knowledge graph, policy aziendali, metadati e sicurezza. È questo approccio che consente a SAP di trasformare l’AI da tecnologia a servizio aziendale affidabile. Herzig ironizza: “SAP non è solo un wrapper su un database, e Joule non è un wrapper su GPT. C’è molto di più dietro”.
E utilizzare il modello più appropriato per ciascun task aumenta la qualità e riduce i costi.
Secondo Herzig, gli Small Language Models (SLM) rappresentano la direzione giusta per rendere l’AI più efficiente, personalizzata e sostenibile. Gli LLM generalisti risolvono il problema del “cold start”, ma sono costosi e poco adatti a scenari ripetitivi.
La strategia di SAP è progressiva: si parte da un LLM, si osservano i dati d’uso, si ottimizzano i prompt e si addestra un modello più piccolo specializzato sul cliente. A quel punto, la richiesta viene instradata automaticamente verso il modello SLM, più veloce ed economico.
Questo passaggio è già oggi gestito da Joule Orchestrator, ma l’obiettivo futuro è che sia l’AI stessa a decidere, in tempo reale, quale modello usare in base al carico, al contesto e alla complessità della richiesta. Joule Orchestrator è la componente che coordina dinamicamente l’intero ecosistema AI di SAP. Decide quale modello usare (LLM, SLM, modelli SAP o open source), in base a criteri come accuratezza, latenza, costo, livello di fiducia e compliance normativa. Joule Orchestrator è modulare, scalabile, invisibile all’utente finale e governato da SAP. Non si limita a eseguire, ma interpreta e ottimizza ogni richiesta, assicurando che il cliente riceva sempre il miglior equilibrio tra performance, affidabilità e costi.
Lavora in stretta sinergia con il Prompt Optimizer, soluzione sviluppata in collaborazione con Not Diamond, che adatta i prompt ai modelli e ottimizza le prestazioni. Oggi il passaggio da un modello all’altro è ancora manuale, ma SAP sta lavorando per renderlo completamente automatizzato. L’obiettivo è che l’AI non solo risponda, ma decida autonomamente come rispondere, con quale modello, in quale momento.
Con Jonathan Von Rueden, Head of AI Frontrunner Innovation di SAP, abbiamo parlato di intelligenza artificiale applicata ai contesti enterprise e soprattutto delle scelte progettuali e operative per garantire un uso sicuro, verificabile e responsabile degli agenti AI.
Uno dei primi temi affrontati è stato l’utilizzo di Perplexity. Von Rueden ha spiegato che SAP utilizza attualmente l’API di completamento conversazionale offerta da Perplexity nella sua versione Enterprise Pro, e lo fa principalmente per le attività di web research. “Per noi è fondamentale che il 100% dei fatti riportati siano accompagnati da fonti”, ha detto. “Nel business non puoi permetterti di essere indirizzato verso una risposta senza sapere da dove viene. Perplexity restituisce fonti per ogni passaggio”. Questo, ha aggiunto, li rende più affidabili rispetto ad altri fornitori, che magari offrono sintesi accurate ma prive di riferimenti chiari.
Per garantire la privacy, SAP utilizza un contratto che assicura che nessun dato venga memorizzato. Tuttavia, ha ricordato Von Rueden, oggi Perplexity opera con server solo negli Stati Uniti. “In futuro, è previsto che aprano data center anche in altre regioni”, ha anticipato, “ma per ora i clienti devono essere consapevoli che l’esecuzione avviene negli USA”.
L’interazione tra SAP e Perplexity non avviene attraverso un passaggio diretto di dati, ma mediante una serie di agenti che costruiscono una domanda contestualizzata. A monte c’è il knowledge graph SAP, che consente di collegare entità complesse: ordini di vendita, articoli, impianti, paesi d’origine. “Una volta che il grafo ha costruito la relazione dinamica, creiamo le chiamate API per estrarre i dati dal sistema S/4HANA e li integriamo nel prompt che viene poi mandato a Perplexity”. Non si tratta quindi di inviare metadati o numeri, ma di domande costruite a partire da dati transazionali interni.
Questo lavoro è orchestrato da più agenti: un agente pianificatore, che costruisce la sequenza di ragionamento; un modulo che interroga il knowledge graph; un validatore, che controlla la coerenza dei dati; infine un agente per la web research, che traduce il tutto in un prompt per Perplexity.
In termini di licensing, Von Rueden ha spiegato che l’utilizzo di Perplexity è incluso nella metrica a unità su cui si basa l’offerta AI di SAP. “Ogni azienda acquista un certo numero di unità, che poi vengono consumate dai diversi utenti in base all’uso effettivo, anche attraverso Joule”. Ha poi ricordato che i costi sono in costante discesa: “Negli ultimi due anni e mezzo abbiamo assistito a un calo del 180% o più. Tutti puntano sul fatto che continuerà”.
La scelta di Perplexity, ha detto, si basa anche su un aspetto tecnico: la quantità e profondità delle fonti che riesce a indicizzare. “Il CEO di Perplexity me l’ha mostrato dal vivo: nel browser stava consultando più di 500 fonti in tempo reale. E tutte accessibili una per una”. Altri vendor, secondo Von Rueden, non hanno la stessa cura nell’esposizione del ragionamento.
WalkMe, quando una digital adoption platform diventa strumento di automazione e integrazione fra applicazioni
Dalla web research si passa a WalkMe, l’altro tassello chiave nel disegno di SAP. Acquisita un anno fa, WalkMe è una piattaforma di digital adoption che guida l’utente all’interno delle interfacce. “Il principio è semplice: sei in una pagina, e WalkMe ti indica dove cliccare, cosa fare, ti accompagna”. Questo strumento è già integrato nativamente in molte soluzioni cloud SAP.
La novità è però l’integrazione tra WalkMe e Joule. “Lo avete visto durante il keynote: in basso c’era questa Action Bar AI. È WalkMe in combinazione con Joule”. Si tratta di un plugin, sempre attivo nel browser, che può anche essere installato come app client sul desktop. L’utente può definire azioni personalizzate, come: “Quando vedo un caso chiuso, per favore, riassumilo in questo template email e preparalo per il mio supervisore”. Non serve IT: è l’utente stesso a costruirsi il proprio assistente.
“È molto potente perché permette a ognuno di essere creativo. Non è un reparto centrale a decidere tutto, ma ogni persona può costruire il proprio prompt e migliorare il proprio flusso di lavoro”. Joule può quindi essere attivato in modalità always-on, oppure essere chiamato nel momento del bisogno: “Se hai bisogno di più contesto, puoi passare a Joule e approfondire da lì”.
Tempi diversi nell’adozione dell’AI
Secondo Von Rueden, le aziende si muovono in modo disomogeneo nell’adottare l’AI per il business. Alcune, come DHL, sono rapidissime. In settori come il marketing o il customer care, dove l’errore ha un impatto limitato, gli agenti sono già in uso per comporre e-mail, fare ricerca di mercato, sintetizzare ticket. In ambiti più sensibili come finanza, supply chain o HR, si lavora più lentamente.
“In SuccessFactors, ad esempio, bisogna essere molto cauti con i dati personali. Un agente che seleziona CV automaticamente non passerebbe la nostra revisione etica. Abbiamo sia una commissione esterna sia una review interna, e ogni agente deve passarle entrambe”.
Von Rueden ha poi chiarito che SAP distingue tra agenti attivati dall’utente e agenti attivati dal sistema. I secondi, quelli che operano in background o su eventi automatici, sono fortemente limitati. “Possono solo portare un processo in stato di bozza, mai completarlo. Un essere umano deve sempre intervenire prima di finalizzare”.
“Prendiamo il caso di una disputa su una fattura sbagliata”, spiega. “Il cliente scrive di notte, e Joule potrebbe teoricamente processare la richiesta subito. Ma noi preferiamo che sia l’utente a dire: aiutami a risolvere questa disputa. Così può vedere come l’agente ragiona, cosa propone, costruire fiducia. Dopo 50 o 100 volte, saprà quando può fidarsi a delegare completamente. Ma è l’utente a decidere”.
Infine, ammette che sarà difficile controllare come i clienti useranno agenti custom costruiti con Agent Studio. “Possiamo mettere vincoli nei contratti, ma non possiamo controllare tutto. Come con ogni software. Il nostro dovere è informare, formare e fare in modo che gli strumenti siano progettati per guidare verso un uso corretto”.
Agenti che parlano con il mondo
Dal punto di vista architetturale, SAP ha costruito una struttura di dialogo tra agenti che ricorda un protocollo di messaggistica interna. “In pratica, abbiamo già un nostro protocollo simile a MCP, con funzioni di dialogo impacchettate in scenari. MCP sta per diventare lo standard, e ci stiamo muovendo anche noi in quella direzione”. L’obiettivo è duplice: rendere gli skill SAP esponibili tramite sintassi MCP e consentire ai clienti di esporre i propri servizi come agenti MCP, interagendo con Joule e con altri agenti esterni.
“Abbiamo già oltre 1.600 skill in linguaggio naturale. Ci basterà adattarne la sintassi a MCP. L’AI può occuparsi della traduzione”, spiega Von Rueden.
SAP sta lavorando con l’Integration Suite di BTP per “wrappare” le API esistenti con specifiche MCP, rendendole accessibili ad altri agenti e abilitare i clienti a ospitare propri server MCP, per rendere “scopribili” i loro servizi da altri agenti AI.
“Finalmente sembra esserci uno standard condiviso. È un bene per tutto l’ecosistema”, commenta Von Rueden. MCP apre la strada a un’AI distribuita, in cui Joule non è solo un assistente interno, ma un interlocutore in un mondo di agenti connessi.
