L’adozione dell’AI generativa impone scelte infrastrutturali che guardino oltre il prezzo della potenza di calcolo: oggi sono il Total Cost of Ownership (TCO), il valore di business e la sovranità dei dati a guidare la decisione tra AI “pubblica” e “privata”.

AI “pubblica” e AI “privata”

Quando le organizzazioni grandi e medie hanno cominciato ad adottare soluzioni basate su AI generativa, è stato naturale affidarsi all’“AI pubblica”, quella basata su infrastrutture di cloud pubblico e su servizi AI forniti dai grandi operatori globali. Erano gli unici ad offrire a clienti non specialisti infrastrutture e servizi adeguati ad addestrare e far funzionare i Large Language Model (LLM), modelli su cui l’AI generativa si basa.

Oggi per diversi casi d’uso di intelligenza artificiale sono maturate soluzioni di “AI privata”: quelle in cui i modelli, i dati e spesso anche l’infrastruttura restano sotto il controllo diretto dell’organizzazione che li usa, o di un suo fornitore di fiducia, magari locale, con maggiore possibilità di personalizzazione, isolamento e controllo dei costi nel tempo.

La domanda chiave diventa allora: come scegliere tra AI pubblica e privata? In quali casi il costo totale di una è migliore di quello dell’altra, se consideriamo l’intero ciclo di vita della soluzione e non solo il prezzo di listino delle GPU o delle chiamate API?

Perché con l’AI i modelli di TCO vanno aggiornati

Quando si parla di TCO (Total Cost of Ownership) si intende il costo complessivo di una soluzione lungo tutto il suo ciclo di vita: progettazione, realizzazione, esercizio, manutenzione, aggiornamenti, dismissione. Il RoI (Return on Investment) misura invece il ritorno economico rispetto all’investimento effettuato, spesso su un orizzonte di alcuni anni. Per le soluzioni di AI, alcuni dei fattori che li compongono sono nuovi o vanno gestiti in maniera diversa. Ecco i principali, identificati con l’aiuto di diversi operatori del mercato:

Giulio Lovisi, Head of Solution Hub di Deda Next, osserva innanzitutto che nel confronto tra AI privata e AI pubblica è profondamente diversa la struttura stessa dei costi: i costi dell’AI privata sono prevalentemente investimenti in conto capitale (in breve CapEx, da “Capital Expenditure”), in particolare l’acquisto di GPU e hardware, che vengono poi ammortizzati. I costi dell’AI pubblica sono invece soprattutto spese correnti (OpEx, da “Operational Expenditure”), basati su abbonamenti e consumi. “Con un’infrastruttura AI privata il TCO risulta più chiaro e definibile a priori, ma molto più articolato e soprattutto richiede una gestione attiva,” osserva Lovisi, che aggiunge come nell’AI pubblica siano spesso difficili da stimare a priori non solo i costi di utilizzo ma anche i costi legati al trasferimento di dati da un fornitore all’altro.

Matteo Neuroni, CEO di SYS-DAT Group, ricorda che la scelta non è “cloud o privata?” ma “comprendere quale architettura, o combinazione di architetture, possa massimizzare il ritorno sull’investimento e ottimizzare il Total Cost of Ownership in funzione degli specifici obiettivi di business”. In altre parole, il confronto non è più tra due blocchi monolitici, ma tra configurazioni ibride che combinano componenti pubbliche, private e distribuite.

Un punto chiave, come osservano Antonio Talia, Chief Analyst Officer, e Aaron Smith, Senior Analyst di CONTEXT, è che “l’efficienza è diventata una moneta di scambio”: con normative europee più stringenti sull’efficienza energetica, la performance-per-watt non è più solo un parametro tecnico ma un fattore che incide direttamente sul TCO e soprattutto sul rischio di sanzioni. Secondo CONTEXT “per le grandi imprese europee il TCO alla fine premia l’infrastruttura privata”, proprio perché permette di ottimizzare hardware e consumi in modo mirato.

Avvalora questa prospettiva Joerg Weishaupt, fondatore e CEO/CTO di Malogica, secondo il quale “in tutta Europa l’efficienza energetica dell’AI non è una considerazione al contorno, è il cuore della questione”. Al cuore dell’offerta di Malogica ci sono gli ASIC (processori ottimizzati per un’applicazione specifica, in questo caso l’inferenza). Secondo Weishaupt questi erogano un multiplo delle inferenze per watt rispetto a una GPU generica. In Italia in particolare, dove i prezzi dell’energia sono tra i più cari dell’Unione, su un periodo di ammortamento di 3-5 anni il consumo in watt per token si traduce direttamente in euro per token. Per questo, conclude Weishaupt, “siamo convinti che i ‘server edge accelerati’ [descritti meglio più oltre da CONTEXT] costituiscano la risposta strutturalmente più indicata per le organizzazioni europee che vogliono combinare sovranità, costi prevedibili e un’impronta fisica ridotta.”

Con l’AI, alcuni costi importanti si nascondono

Sergio Ajani, Services & Solutions Design Director di Innovaway conferma: “Il punto non è ‘quanto costa il cloud vs il ferro’, ma quali voci di costo si vedono e quali si nascondono nei diversi modelli.” Vanno considerati l’integrazione con i sistemi legacy, la gestione delle identità e degli accessi, la latenza delle API quando i modelli sono ospitati lontano dai dati, e i costi di adeguamento delle applicazioni esistenti per sfruttare l’AI. In molti casi, questi costi di integrazione e di esercizio possono superare il costo “puro” dell’infrastruttura.

Un esempio molto specifico ma indicativo di costi di gestione difficili da identificare e che non si trovano nei listini è quello degli aggiornamenti ai driver software delle GPU, i software che permettono al sistema operativo di interagirvi. Per nodi con numerose GPU, questo aggiornamento diventa un’attività di manutenzione vera e propria, che richiede competenze verticali molto specifiche, e quindi costose, soprattutto per pianificarlo in modo da evitare interruzioni del servizio.

Per Daniele Cremonini, Head of Strategic Growth – Space, Defense & AI/HPC solutions di E4 Computer Engineering, “occorre aggiungere al TCO la voce del costo della dipendenza: non si tratta solo di rischio contrattuale, ma di costi concreti che emergono quando dati, modelli e pipeline vivono in ambienti terzi: rialzi tariffari, vincoli tecnici, limiti di compliance e perdita di leva negoziale. Questo costo della dipendenza va quantificato e monitorato come una voce ricorrente del TCO.”

L’errore strutturale come costo ricorrente

Fabio Santini, SVP Europe di Expert.ai, sottolinea un aspetto nuovo e squisitamente specifico dei servizi AI: “Nell’AI generativa l’errore non è un’anomalia, è una proprietà intrinseca della tecnologia … il TCO dovrebbe incorporare il costo ricorrente di un errore che non si elimina ma si gestisce.” Questo errore strutturale impone di considerare nel TCO non solo l’infrastruttura e le licenze, ma anche i costi continui di monitoraggio, revisione umana, correzione e contenimento della propagazione degli errori nei processi aziendali. In un sistema tradizionale, i bug si correggono e diventano sempre più rari, il costo di correzione tende a diminuire nel tempo; “in un sistema di AI generativa, invece, l’errore è probabilistico e non scompare mai del tutto: “il sistema produce output diversi a parità di input, e quando sbaglia lo fa in modo spesso indistinguibile dalla risposta corretta”.

Un aspetto oneroso di questo errore strutturale, segnala Santini, è la propagazione silenziosa: un’informazione errata può essere incorporata in documenti, decisioni e processi per settimane o mesi prima di essere rilevata, amplificando il danno. Per questo il TCO deve includere non solo il costo della correzione, ma anche i molti costi indiretti e associati.

Serve quindi:

• Introdurre KPI specifici, come la percentuale di output che richiedono intervento umano, il tempo medio di intervento su un output, la percentuale di regressione (aumento degli errori) dopo un aggiornamento del modello o del servizio AI
• prevedere processi e persone dedicate alla verifica degli output, alla gestione dei casi limite, alla revisione dei prompt e dei modelli.

Obsolescenza rapida dei modelli

I modelli di AI generativa evolvono rapidamente: nuove versioni migliorano qualità e costi per token, ma richiedono test, validazioni e talvolta adattamenti delle applicazioni. Questo introduce una forma di obsolescenza programmata che va considerata nel TCO: non basta comprare o affittare hardware, bisogna prevedere cicli di aggiornamento dei modelli e delle pipeline.

Per l’AI privata, evidenzia in particolare Santini (Expert.ai), l’obsolescenza rapida impone cicli di aggiornamento più frequenti anche per lo hardware: il modello di ammortamento tradizionale su 3–5 anni va integrato con scenari di refresh semestrali o annuali per i modelli LLM. Questo influisce su test, validazioni e costi di integrazione, che vanno modellati nel TCO.

I costi di certificazione della conformità alle norme (“compliance”)

Uwe Geier, Senior Director Cloud Solutions di IONOS, segnala un altro elemento spesso sottovalutato del TCO: il costo delle certificazioni infrastrutturali. Audit e attestazioni di conformità possono comportare oneri significativi per chi ha in carico la proprietà delle soluzioni, indicativamente dell’ordine di decine o centinaia di migliaia di euro all’anno. Quando si confronta il TCO di una soluzione AI pubblica con quello di una privata occorre tenerne conto, perché nel cloud pubblico questi costi si possono almeno ridurre, grazie alle certificazioni del provider.

E il RoI? Con l’AI contano ancora di più valore intangibile e orizzonte temporale

Fabio Santini (Expert.ai) segnala che l’AI può generare ritorni difficili da misurare con metriche tradizionali perché agisce su concetti, sfumature ed emozioni. Un assistente virtuale più efficace può migliorare la soddisfazione del cliente, ridurre l’abbandono o aumentare le vendite indirettamente, ma questi effetti emergono su orizzonti temporali lunghi e con metriche non sempre standardizzate. Per questo, i modelli di RoI devono includere indicatori qualitativi e sperimentazioni controllate (per esempio A/B test) per misurare l’impatto reale dell’AI sui processi e sui risultati di business.

Cloud pubblico o AI privata? Voci di costo e condizioni di convenienza

Una volta aggiornato il modo di calcolare TCO e RoI, si può tornare alla domanda iniziale: quando conviene l’AI pubblica e quando quella privata?

Cloud pubblico — vantaggi e limiti

Adriano Ceccherini, Chief Business Officer di SAP Italia, evidenzia l’utilità di modelli contrattuali OpEx omnicomprensivi che includano LLM, sicurezza, infrastruttura e operation in un unico costo che dipenda dal carico previsto, totalmente trasparente e prevedibile. Modelli contrattuali simili nascono per il cloud pubblico. SAP, sottolinea Ceccherini, è tra i fornitori in grado di proporli anche per un ambiente privato o ibrido, offrendo quindi una flessibilità analoga a quella del cloud pubblico.

Giulio Lovisi (Deda Next) segnala come costi dell’AI pubblica (OpEx e costi variabili): abbonamenti e tariffe per chiamate ai modelli; costi di estrazione e trasferimento dati in uscita (egress); costi variabili legati al volume d’uso e alla sua fluttuazione e, qualitativi ma importanti, le conseguenze di leve negoziali limitate con fornitori grandi o grandissimi, che possono rendere meno prevedibili i costi nel tempo.

Mario Cubello, Business Line Manager di S2E – Solutions to Enterprises, sottolinea che “le infrastrutture pubbliche sono impareggiabili per la rapidità di attivazione e la flessibilità, e naturalmente minimizzano le spese in conto capitale (CapEx)”, ma segnala costi difficili da stimare come, di nuovo, gli egress fee e gli effetti non voluti del data gravity. L’espressione “data gravity” descrive la tendenza dei dati ad “attirare” vicino a sé, sulla stessa piattaforma cloud, applicazioni e servizi, perché scambiare dati tra piattaforme diverse è più costoso e complesso.

Il cloud pubblico è quindi ideale per:

• sperimentazioni rapide;
• progetti pilota;
• workload con picchi imprevedibili;
• organizzazioni che non vogliono o non possono investire in infrastrutture proprie,

mentre può diventare costoso nel lungo periodo se i volumi di dati e di chiamate ai modelli crescono in modo stabile e se i dati devono essere spostati frequentemente tra ambienti diversi.

Marco Ballan, Direttore Infrastrutture di IBM Italia, oltre a confermare molte valutazioni espresse da altri operatori, segnala che l’AI pubblica, come in generale le soluzioni SaaS in cloud pubblico, è particolarmente adatta alle situazioni nelle quali chi userà i servizi vuole limitare il proprio impegno di risorse diretto (investimenti in competenze e persone, oltre che in capitale) e poter ingrandire o rimpicciolire le infrastrutture che usa al variare dei fabbisogni. Il vincolo corrispondente, sottolinea, è che le soluzioni AI pubbliche, progettate per servire in maniera omogenea tanti clienti diversi, lasciano in generale meno spazi di personalizzazione per ciascuno. La forte prevalenza di spese correnti (OpEx) può essere un altro vincolo per operatori con budget prevalentemente in conto capitale, come in Italia, ad esempio, le pubbliche amministrazioni.

Il cloud pubblico per gestire l’”attrito” nella catena di fornitura

CONTEXT segnala un nuovo o rinnovato “attrito lungo la catena di fornitura”, che sta rallentando il passaggio all’AI privata: molte aziende italiane piazzano ordini duplicati per assicurarsi componenti, creando scarsità artificiale; già ad aprile 2026 diversi produttori hardware risultano saturi di ordini per tutto l’anno per storage ad alta capacità. Molte organizzazioni si trovano quindi costrette a trattenere in cloud i carichi di lavoro fino alla consegna dello hardware di loro proprietà: “La transizione all’AI privata è oggi ostacolata da una domanda fantasma e da ritardi nelle forniture; il cloud resta la sala d’attesa per chi vuole rimanere AI-ready” osserva Antonio Talia.

Questa dinamica ha due effetti pratici sul TCO: da un lato spinge a sostenere costi ricorrenti in cloud per periodi più lunghi del previsto; dall’altro introduce incertezza nella pianificazione degli investimenti in conto capitale (CapEx) per infrastrutture private.

Un ulteriore elemento di rischio sui costi dell’AI pubblica: “oggi il cloud pubblico offre costi di ingresso inferiori, ma ci aspettiamo che i provider aumentino presto i prezzi per trasferire gli incrementi dei costi hardware che per ora stanno assorbendo”, avverte Aaron Smith di CONTEXT. Gli aumenti vertiginosi di componenti come la RAM (fino a +350%) e i sovrapprezzi su tutti gli altri componenti hardware, quando verranno trasferiti ai clienti, renderanno il modello OpEx molto più oneroso nel medio periodo.

AI privata — vantaggi e oneri

Giulio Lovisi (Deda Next) evidenzia tra i costi più significativi dell’AI privata: costi hardware (GPU, storage ad alta capacità); ammortamento dell’investimento; costi energetici e di raffreddamento; costi di esercizio (“operation”); licenze software e manutenzione; costi di adeguamento degli ambienti fisici (colocation, sicurezza fisica).

Lorenzo Beliusse, Marketing Director di Reti, sottolinea in particolare voci di spesa corrente (OpEx) non nuove ma particolarmente rilevanti per i servizi AI: il consumo energetico, che in Italia è particolarmente costoso e va pianificato e gestito attentamente, la manutenzione dello hardware acquisito inizialmente, le licenze dei software di orchestrazione e gli aggiornamenti dei driver, e i costi dei servizi di alta disponibilità e disaster recovery.

Entrambi evidenziano in particolare i costi per formare e trattenere personale specializzato, con competenze altamente richieste dal mercato.

Joerg Weishaupt, di Malogica, segnala che soluzioni hardware alternative possono ridurre anche i costi di inferenza, oltre ai consumi di energia: “Le nostre soluzioni hardware e software integrate e preconfigurate, basate su schede acceleratrici custom (ASIC) specializzate per l’inferenza, permettono risparmi dell’ordine del 70-80% rispetto a una soluzione confrontabile basata su GPU, per carichi di inferenza elevati e continui.“ In una soluzione di AI privata, l’organizzazione può quindi scegliere hardware ottimizzato, modelli specifici e configurazioni commisurate ai propri carichi di lavoro, ottenendo risparmi significativi quando l’uso è intenso e continuativo.

Questo presuppone naturalmente la volontà e la possibilità di sostenere una spesa in conto capitale relativamente grande all’inizio, da ammortare negli anni successivi.

Sul tema dello hardware di proprietà Giulio Lovisi (Deda Next) osserva poi che, a inizio 2026, i costi di acquisizione delle GPU risultano relativamente convenienti perché la domanda per infrastrutture AI private è ancora contenuta; ciò rende l’investimento CapEx più appetibile per chi può pianificare ammortamenti su 3–5 anni. Tuttavia, questo vantaggio richiede una gestione attiva per evitare obsolescenza e sprechi.

Conformità e sovranità

Secondo Marco Ballan (IBM), le soluzioni private hanno caratteristiche quasi speculari a quelle delle soluzioni pubbliche: prevalenza degli investimenti in conto capitale e in competenze e personale, rigidità dei volumi di infrastruttura e flessibilità di personalizzazione, oltre a minori costi di trasferimento dei dati e maggior controllo su di essi, che facilita audit e verifiche di conformità.

Lorenzo Beliusse (Reti), ricorda che per settori regolamentati l’AI privata mitiga in modo significativo i rischi di lock-in e sanzioni: in ambiti come sanità, finanza, pubblica amministrazione, la localizzazione dei dati, il controllo sui log e la possibilità di dimostrare come vengono trattate le informazioni sono elementi essenziali. Una soluzione privata o sovrana può facilitare audit, certificazioni e adeguamento normativo.

Insomma: come sintetizza ancora Antonio Talia di CONTEXT, “il cloud vince la sprint per l’accesso immediato, ma l’infrastruttura privata vince la maratona: far scalare nel tempo una AI sostenibile, sovrana e conveniente”. Per scegliere la strategia ottimale è quindi essenziale valutare orizzonte temporale, volumi e vincoli normativi.

Il modello ibrido come punto di equilibrio

Edward Abbiati, CMO di Aruba Enterprise, affronta il tema da un’altra prospettiva, distanziandosi da quella sui modelli economici e il TCO: “nelle conversazioni che stiamo avendo, il focus si è spostato altrove: non è tanto una questione di costo, ma di quale AI usare, e per quali task”. Il punto centrale, in altre parole, riguarda “governance, compliance e modalità di utilizzo: come e dove l’AI viene impiegata, per quali dati, con quale livello di controllo e in che perimetri tecnologici e regolatori.” Questa capacità di mantenere controllo, governance e coerenza “si esplicita maggiormente in contesti di AI privata, poiché in termini di costi questa offre una maggior prevedibilità e un maggiore controllo nel tempo.”

L’obiettivo di Aruba è allora “mettere i clienti nelle condizioni di decidere in autonomia cosa utilizzare in AI privata e cosa in AI pubblica”. “Questo significa”, spiega Abbiati, “poter decidere, caso per caso e task per task, dove ha senso utilizzare infrastrutture private e dove invece sfruttare servizi pubblici, senza perdere visibilità e governo complessivo dell’ecosistema AI”. Conclude con un esempio: “l’elaborazione di dati sanitari o segreti industriali richiederà più AI privata, mentre materiali pubblici di marketing o la classificazione di documenti pubblici potranno usare AI pubblica.”

Adriano Ceccherini (SAP) osserva: “Noi non contrapponiamo cloud privato e cloud pubblico: li consideriamo complementari. Il cloud pubblico è ideale per le organizzazioni che cercano velocità, standardizzazione e scalabilità immediata. Cloud privato e ambienti sovrani sono invece la scelta naturale per imprese con processi altamente personalizzati, forti requisiti regolatori o esigenze di controllo più stringenti”.

In molti scenari, spiega Ceccherini, la soluzione più razionale è quindi un modello ibrido in cui:

• il training di grandi modelli o l’uso di modelli generalisti avviene su cloud pubblico;
• l’inferenza su dati sensibili o su carichi stabili avviene su infrastrutture private o in colocation;
• i dati più critici restano in ambienti controllati, mentre copie parziali o anonimizzate vengono usate in cloud pubblico per casi d’uso specifici.

Per Marco Ballan (IBM) le soluzioni in cloud ibrido si rivelano spesso buoni compromessi tra AI privata e AI pubblica per molte esigenze specifiche, in particolare per portare i servizi di inferenza dove si trova la versione originale dei dati anziché far uso di repliche dei dati dove si fanno le inferenze, come – secondo Ballan – altri operatori fanno. “Con le nostre soluzioni possiamo lasciare il dato dov’è, esportandone una versione anonimizzata solo quando sia necessario accedere a servizi cloud pubblici”. Questa capacità è particolarmente preziosa per settori fortemente regolamentati come sanità, servizi finanziari e, di nuovo, la pubblica amministrazione.

AI distribuita, networking e TCO

Finora abbiamo considerato soprattutto dove risiedono i modelli e chi gestisce l’infrastruttura. Ma un altro fattore chiave del TCO è dove risiedono i dati – dal punto di vista della geografia e della latenza, ma anche nel senso di quale tipo di hardware li gestisce – e come vengono collegati ai modelli.

Data locality e interconnessione

Equinix è un “colocator” globale: un’azienda specializzata nella gestione di infrastrutture fisiche dove ospitare con la massima efficienza e sicurezza infrastrutture e applicazioni digitali dei propri clienti (che restano responsabili di gestire i livelli hardware e software superiori). In questo ruolo non si occupa direttamente di sviluppare o gestire soluzioni AI, ma ha tra i suoi fattori differenzianti la capacità di ottimizzare costi e sicurezza della trasmissione dei dati tra sedi anche remote, un fattore chiave per qualsiasi soluzione AI. Da questa sua prospettiva complementare, sottolinea che “le domande più complesse sul TCO e sul RoI dell’AI non riguardano più i modelli. Riguardano l’infrastruttura: dove vengono eseguiti i workload di AI…”. Le reti tradizionali, sottolinea Equinix, non sono progettate per i nuovi pattern di traffico generati dall’AI distribuita: la rapida crescita dei volumi di dati e la frammentazione dei workload aumentano la pressione su latenza, throughput e resilienza. Per questo, secondo Equinix, molte organizzazioni stanno riprogettando le proprie reti in chiave decentralizzata, adottando connettività privata ad alte prestazioni e architetture multicloud ibride per ottimizzare costi e performance.

Per soddisfare questa nuova classe di esigenze di connettività, la società propone l’Equinix Distributed AI Hub, che connette dataset e modelli mantenendo i dataset “autorevoli” in ambienti controllati. L’idea è che i dati autorevoli, cioè le copie di riferimento, restino in un ambiente stabile e sicuro, mentre copie temporanee o versioni derivate vengono spostate vicino alle risorse di calcolo solo quando serve.

Colocation e riduzione dei costi di egress

Replicare copie temporanee vicino alle risorse di calcolo e mantenere i dataset “autorevoli” in storage privato, spiega Equinix, aiuta a ridurre costi di egress e rischi di lock-in richiamati da numerosi operatori. In una configurazione di colocation, l’organizzazione può ospitare la propria infrastruttura in data centre terzi, ma connessi direttamente ai cloud pubblici e ad altri partner, riducendo la latenza e i costi di trasferimento dati. Questo approccio di AI distribuita permette di scegliere di volta in volta dove eseguire i carichi di lavoro, senza spostare permanentemente tutti i dati in un solo ambiente.

Scalare verso il basso: l’AI per le PMI e i server edge accelerati

CONTEXT definisce i “server edge accelerati” come una soluzione intermedia tra hardware da ufficio e quello per grandi data centre: si tratta di server compatti, dotati di acceleratori (GPU o NPU), pensati per essere collocati vicino al punto di generazione dei dati (come stabilimenti, punti vendita, uffici locali) e per eseguire inferenza localmente, riducendo latenza e traffico verso il cloud. Questa architettura riduce i costi di egress e può migliorare il TCO per carichi distribuiti. Secondo Aaron Smith “I server edge accelerati … rappresentano la soluzione ‘AI-on-site’ per molte PMI”.

Nel tessuto industriale italiano, dominato da PMI specializzate, sottolinea Antonio Talia, i server edge accelerati rappresentano una soluzione pratica e sostenibile: consentono di partire in piccolo con inferenza locale, mantenere la sovranità dei dati (un tema delicato, visti i casi giudiziari internazionali) e gestire meglio i vincoli energetici imposti dalle nuove direttive UE. “Per le PMI italiane l’edge è la soluzione: costi contenuti, sovranità dei dati e compliance energetica”, conclude Antonio Talia.

Joerg Weishaupt, CEO di Malogica che produce proprio server edge accelerati, conferma: “quando si spinge lo sguardo al di là delle CPU per valutare server accelerati di altro genere, il conto economico di una soluzione di inferenza edge cambia drasticamente. Con schede di accelerazione basate su ASIC, un solo appliance capace di far girare un LLM open source da 20-30 miliardi di parametri a velocità da produzione sta nello chassis di un desktop e consuma molto meno di un server basato su GPU. Per una PMI come quelle italiane, cambia tutto il contesto della decisione sull’AI: l’inferenza privata non è più un progetto in conto capitale con investimenti di decine di migliaia di euro, ma l’acquisto di un appliance paragonabile con una workstation di fascia alta.”

Un’altra peculiarità italiana, che è CONTEXT a evidenziare soprattutto nelle PMI ma anche nelle imprese più grandi: mentre in alcuni contesti esteri si sta puntando con forza su offerte tipo “GPU-as-a-Service”, per accedere allo hardware più recente e potente “on demand”, molte aziende italiane preferiscono rinnovare l’infrastruttura legacy o acquistare estensioni di garanzia su hardware che già posseggono, per ridurre l’impatto dei costi elevati dei componenti. Questa strategia riduce il rischio immediato di spesa straordinaria ma può rallentare l’adozione di soluzioni iperscalabili, spingendo invece verso approcci graduali e locali come quello edge.

Anche Mario Cubello (S2E) conferma che architetture private ben progettate possono scalare verso le PMI, permettendo soluzioni “desktop in sala CED” per inferenza locale a basso consumo, preziose per piccole organizzazioni che già avvertano esigenze di servizi AI e di sovranità. Non è quindi necessario pensare alla AI privata solo come a grandi cluster di GPU: esistono configurazioni compatte, ottimizzate per modelli più piccoli o specializzati, che possono essere economicamente sostenibili anche per organizzazioni di dimensioni medie. Per questo il gruppo S2E ha lanciato Galene AI, una piattaforma di AI privata chiavi in mano pensata per offrire sovranità e controllo sui dati, con architetture scalabili anche verso il basso per servire organizzazioni medie e piccole.

Le decisioni dei fornitori di piattaforme che permettono ai loro clienti di scegliere AI pubblica o privata

Molti fornitori di piattaforme collaborative europee adottano oggi un approccio agnostico rispetto ai modelli AI, lasciando al cliente la scelta del modello più adatto in funzione di esigenze operative e valutazioni di rischio. Come spiega Birgit Becker, Co Owner, EGroupware, “Quando abbiamo integrato l’AI abbiamo deciso di prevedere una configurazione dove ciascun cliente possa decidere da solo cosa usare secondo le proprie esigenze e le proprie valutazioni dei rischi”. In pratica, EGroupware offre configurazioni che permettono al cliente di scegliere tra modelli locali e servizi cloud, mentre i suoi sviluppatori usano modelli locali per test.

Anche Nextcloud adotta la stessa logica: la sua suite include un AI Assistant indipendente dalle soluzioni, che consente agli utenti di scegliere tra diversi LLM e di decidere se eseguire l’elaborazione su infrastrutture proprie o tramite partner cloud.

Questo approccio aumenta la flessibilità operativa e la sovranità dei dati, perché lascia il controllo della scelta del modello a ciascuna organizzazione, riducendo il rischio di lock-in e facilitando strategie ibride (modelli locali per dati sensibili, modelli pubblici per sperimentazione).

Casi d’uso per AI privata e pubblica

Per rendere operative queste considerazioni, è utile guardare ad alcuni casi d’uso tipici e alle relative soglie quantitative.

Inferenza continua e uso intensivo

Marco Ballan (IBM), Sergio Ajani (Innovaway), Joerg Weishaupt (Malogica) e molti altri operatori concordano che per inferenza continua l’on-premise o il noleggio di hardware possono risultare più economici nel medio termine. Se un modello viene utilizzato in modo costante, per esempio per analizzare flussi di documenti, conversazioni o log, il costo per chiamata in cloud pubblico può diventare significativo. In questi casi, investire in hardware dedicato o in soluzioni di noleggio operativo può ridurre il TCO, soprattutto se l’infrastruttura viene sfruttata appieno.

Secondo Giulio Lovisi (Deda Next), per rendere competitiva l’AI su infrastruttura privata rispetto all’AI pubblica, è proprio il livello di saturazione dell’infrastruttura il fattore critico: occorre raggiungere una saturazione operativa dell’ordine del 70–80% per poter mirare a costi competitivi. Inoltre, il periodo di ammortamento considerato deve essere sufficientemente esteso — tipicamente 3–5 anni — perché l’investimento CapEx si traduca in vantaggio economico rispetto a un modello OpEx. Questa soglia di saturazione rende evidente perché molte organizzazioni scelgono inizialmente il cloud pubblico per sperimentare e poi valutano il passaggio al privato solo quando i volumi d’uso diventano stabili e prevedibili.

Ancor più positivi Lorenzo Beliusse (Reti) che prospetta un punto di pareggio già intorno al 60-70% di saturazione costante dei server, e Sergio Ajani (Innovaway), secondo il quale per carichi di lavoro ad alta frequenza e bassa variabilità il pareggio può arrivare rapidamente; in queste condizioni “il punto di pareggio … si attesta su una soglia sorprendentemente bassa: appena 5 o 6 ore di utilizzo al giorno.” In pratica, se un modello viene interrogato in modo continuativo per molte ore al giorno, il costo unitario per inferenza su infrastruttura dedicata può diventare inferiore a quello del cloud pubblico, soprattutto se si considerano nel TCO anche egress, integrazione e margini del provider.

Modelli custom e dati proprietari

Un altro caso d’uso significativo per l’AI privata, prosegue Ajani, si presenta quando si sviluppano modelli custom addestrati su dati proprietari. In queste situazioni il controllo del modello diventa un asset strategico: il TCO deve includere costi di protezione della proprietà intellettuale (sicurezza, segregazione dei dati, audit), costi di gestione delle licenze e potenziali ricavi o risparmi derivanti dalla riutilizzabilità del modello. Per questi casi, l’AI privata tutela l’investimento e riduce il rischio di dispersione di dati verso ambienti condivisi.

Concorda ed espande Daniele Cremonini (E4 Computer Engineering): l’AI privata smette di essere solo un costo da giustificare quando diventa leva di controllo: non si compra soltanto capacità di calcolo, ma si costruisce un asset governabile e scalabile che incorpora il know-how aziendale. Per carichi stabili, modelli personalizzati e dati riservati, l’investimento iniziale può quindi tradursi in un RoI superiore non solo per risparmi diretti, ma per il valore strategico dell’autonomia operativa: “la sovranità industriale non significa chiusura o autarchia. Significa poter scegliere, cambiare, integrare e soprattutto governare.”

Addestramento e formazione su grande scala

Marco Ballan (IBM), Mario Cubello (S2E) e Matteo Neuroni (SYS-DAT) ricordano che, se si può spostare con vantaggio l’inferenza vicino ai dati, l’addestramento su larga scala spesso richiede costi e capacità di calcolo tali che resta dominio dei grandi Cloud Service Provider globali (“hyperscaler”) o dei loro equivalenti regionali con infrastrutture che permettono forte scalabilità in tempi brevi con potenze elevate, distribuite in tutte le regioni dove il cliente opera. Addestrare un grande modello richiede infatti risorse di calcolo concentrate e per periodi limitati, che il cloud pubblico può fornire in modo flessibile. Una volta addestrato o adattato il modello, però, può essere conveniente eseguirlo su infrastrutture private, soprattutto se i dati sono sensibili o se l’uso è continuativo.

Sperimentazione e picchi

Anche Uwe Geier, di IONOS, che fornisce anche proprio servizi cloud pubblici, sottolinea che il cloud pubblico è ideale per workload variabili e sperimentali grazie al modello pay-per-use e all’assenza di CapEx iniziale. Per progetti pilota, proof of concept o casi d’uso in cui non è ancora chiaro il volume di utilizzo, permette di iniziare rapidamente, misurare i risultati e poi decidere se consolidare la soluzione su infrastrutture private o ibride.

Framework operativo per valutare e gestire TCO e RoI

Ecco uno schema riassuntivo fatto di passi concreti per valutare quando usare AI pubblica e quando AI privata in ciascun contesto specifico.

1. Mappare il ciclo di vita del workload

Come suggerisce Sergio Ajani (Innovaway), è essenziale definire durata, tendenze di sviluppo previste e modello operativo prima di costruire modelli di costo. Un workload sperimentale di pochi mesi ha esigenze diverse da un servizio core destinato a durare anni. Questa mappatura include:

• durata prevista del progetto;
• volumi stimati di richieste ai modelli;
• sensibilità dei dati trattati;
• requisiti di disponibilità e latenza.

2. Quantificare costi ricorrenti non tradizionali

Occorre includere nel TCO, in particolare:

• monitoraggio degli errori e revisione degli output (Expert.ai);
• audit e certificazioni richieste da normative o standard di settore (IONOS);
• costi energetici e di raffreddamento per infrastrutture proprie (Reti);
• costi di egress e di interconnessione tra ambienti diversi (Equinix).

Queste voci possono incidere in modo significativo sul costo complessivo, soprattutto nel medio-lungo periodo.

3. Stimare il rischio di propagazione degli errori

Misurare gli impatti downstream e definire metriche di qualità dell’output è fondamentale, come sottolinea Expert.ai. Un errore in un modello di AI generativa può propagarsi in documenti, decisioni o comunicazioni verso clienti e partner, magari per settimane o mesi prima che si riesca a scoprirlo. Serve quindi:

• definire soglie di accettabilità degli errori;
• implementare controlli umani nei punti critici;
• prevedere processi di rollback e correzione
• valutare anche i costi indiretti di ripristino delle situazioni corrette, e di mantenimento e ricostruzione della fiducia,

con strumenti descritti meglio nella scheda dedicata all’offerta di Expert.ai.

4. Valutare interoperabilità e lock-in

Daniele Cremonini (E4 Computer Engineering) sottolinea che l’interoperabilità è una condizione di sovranità: costruire sistemi aperti e modulari riduce le dipendenze. Questo significa:

• preferire standard aperti per API e formati dati;
• evitare soluzioni che vincolano a un solo provider per modelli, dati e infrastruttura;
• progettare fin dall’inizio la possibilità di spostare workload tra ambienti diversi.

L’interoperabilità, sottolinea Cremonini, non è un dettaglio architetturale: è una condizione di sovranità. Costruire sistemi aperti, modulari e basati su standard riduce le dipendenze, facilita la mobilità dei workload e preserva la capacità dell’impresa di scegliere e cambiare fornitori senza perdere il controllo sul proprio know-how.

Anche Marco Ballan (IBM) sottolinea l’importanza di soluzioni basate su standard aperti e componenti open source, per ridurre dipendenze da fornitori specifici e in generale mantenersi flessibili rispetto a cambiamenti di scenario in un mondo in rapida evoluzione tecnologica ed economica – evidenziando poi queste caratteristiche nell’offerta di IBM stessa.

5. Scegliere mix ibrido e punti di collocazione

Usare cloud service provider globali o altri con infrastrutture pubbliche di grande potenza per training e picchi; ricorrere a colocation o cloud privato per inferenza stabile e dati sensibili (Equinix; SAP). Questo permette di combinare flessibilità e controllo. La scelta del mix dipende da:

• profilo di utilizzo (forti variazioni o uso uniforme);
• sensibilità dei dati;
• requisiti di latenza;
• vincoli normativi.

Raccomandazioni operative

In sintesi, alcune raccomandazioni pratiche per chi deve decidere oggi tra AI pubblica e privata:

Guardare oltre i listini per scegliere. Come segnalano molti operatori, in particolare Sergio Ajani (Innovaway), è necessario considerare competenze, integrazione e time-to-value, oltre ai costi di infrastruttura.

Misurare il costo dell’errore. Implementare metriche, audit trail e processi di rollback (Expert.ai) per gestire l’errore strutturale dell’AI generativa.

Valutare opzioni di noleggio hardware. Innovaway e Malogica indicano il noleggio operativo come leva per abbassare la soglia di ingresso alla AI privata, soprattutto per inferenza continua.

Sfruttare hub distribuiti e colocation. Ridurre egress e migliorare latenza (Deda Next, Equinix IBM e molti altri) può avere un impatto rilevante sul TCO, soprattutto quando i dati sono distribuiti tra più ambienti.

Adottare contratti OpEx trasparenti. Quando possibile, allineare costi e valore con modelli OpEx che siano comprensivi non solo dell’infrastruttura, ma anche di modelli AI, sicurezza e operation (SAP).

Valutare la rete come componente strategica del TCO dell’AI. Oltre a stimare egress e storage, includere nella valutazione i costi di connettività privata, le funzionalità di interconnessione e la capacità di orchestrare copie temporanee dei dataset vicino dove si fanno i calcoli (Equinix).

La scelta tra AI “pubblica” e “privata” non è più una contrapposizione ideologica, quindi ma una valutazione operativa basata su TCO e RoI aggiornati alla realtà dell’AI generativa. Come proponeva all’inizio di questo articolo Matteo Neuroni di SYS-DAT Group, la vera domanda è quale combinazione di architetture permetta di massimizzare il ritorno e minimizzare i rischi, in funzione degli obiettivi specifici di ogni organizzazione. In molti casi, la risposta sarà un ecosistema ibrido e distribuito, in cui cloud pubblico, AI privata e colocation convivono, con i diversi dati e modelli collocati dove ha più senso economico, tecnico e normativo.

Le proposte di alcuni operatori del mercato

Deda Next

Questo fornitore di software e servizi rivolti soprattutto alla pubblica amministrazione fa parte del gruppo Dedagroup e collabora con le sue consociate (tra cui Deda Ai) per offrire soluzioni che spaziano dal SaaS su Microsoft Azure, del quale Deda Next è partner (ad esempio Civilia Next, suite applicativa per amministrazioni comunali) fino a installazioni on-premise e in ambienti sovrani come Polo Strategico Nazionale (PSN), dove sono disponibili molte delle sue soluzioni.

Per l’AI, Deda Next utilizza oggi servizi OpenAI tramite Microsoft. Per favorire portabilità e ridurre il rischio di lock-in, sta introducendo agenti AI agnostici rispetto ai modelli. Usa inoltre modelli ML tradizionali: la consociata Deda Ai fornisce modelli per casi concreti (come manutenzione predittiva, catalogazione della posta), utili quando i requisiti computazionali sono più contenuti.

Per soddisfare le esigenze di sovranità della pubblica amministrazione, Deda Next partecipa a vari progetti di infrastruttura sovrana. Tra questi, Giulio Lovisi ha evidenziato in particolare:

Talia (spin-off dell’Istituto di Linguistica Computazionale del CNR): questa piattaforma semantica potenzia l’estrazione di conoscenza dai testi in lingua italiana, migliorando accuratezza e valore operativo.

Istella e LLM nativo italiano: Deda partecipa a Istella, società specializzata nell’analisi di dati e nello sviluppo di modelli di intelligenza artificiale generativa, offrendo modelli linguistici avanzati, tra cui LLM e SLM.

Intacture: Deada fa parte di Intacture, un’infrastruttura digitale strategica per il futuro del paese e un data center unico nel suo genere: realizzato all’interno di una miniera attiva, progettato per garantire sicurezza, sostenibilità e capacità computazionale avanzata nell’era dell’intelligenza artificiale.

E4 Computer Engineering

E4 Computer Engineering è un fornitore di soluzioni hardware e software ad alte prestazioni, con competenze specifiche in ambiti mission-critical come spazio, difesa e AI/HPC. L’azienda progetta infrastrutture e sistemi pensati per carichi intensivi e per scenari in cui interoperabilità, resilienza e controllo operativo sono requisiti fondamentali.

L’esperienza concreta di E4 con i suoi clienti conferma: l’AI non è più una promessa da laboratorio, ma una leva concreta di competitività: secondo Daniele Cremonini, le imprese che integrano l’AI su scala operativa migliorano produttività, velocità decisionale e capacità di innovare, mentre chi resta spettatore rischia di perdere vantaggio competitivo. Per E4, questo rende cruciale mantenere controllo su dati, modelli e pipeline nei punti che definiscono il know-how aziendale, perché è lì che si gioca la sovranità industriale.

La strategia che E4 Computer Engineering prospetta sulla base di questa esperienza è quella ibrida e pragmatica che emerge da molte voci in tutta questa pagina: usare il cloud per sperimentare e per assorbire picchi, ma mantenere on-premise o in colocation presso un operatore di fiducia le componenti che contengono il valore distintivo dell’impresa (dati critici, pipeline di addestramento, logica di business). È così che l’AI privata smette di essere solo un costo da giustificare e diventa una leva di controllo e autonomia operativa.

Anche la prospettiva di E4 converge quindi con il messaggio strategico dell’intero articolo: la scelta tra AI pubblica e privata va valutata non solo sui numeri del TCO, ma anche sulla capacità dell’organizzazione di governare i propri asset digitali e trasformare l’AI in vantaggio competitivo sostenibile.

Expert.ai

Expert.ai è un’azienda specializzata in soluzioni di Natural Language Understanding e intelligenza artificiale applicata al trattamento del linguaggio; fornisce piattaforme e servizi per automatizzare l’estrazione di conoscenza da testi e per integrare capacità semantiche nei processi aziendali. Fabio Santini, SVP Europe, ha contribuito a questo articolo sottolineando in particolare la necessità di aggiornare i modelli di valutazione economica (TCO e RoI) alla luce delle caratteristiche probabilistiche e dinamiche dell’AI generativa, che introducono una fonte di errore strutturale.

Per gestire operativamente questo errore, Expert.ai propone tre leve pratiche da includere nella stima del TCO e soprattutto nella sua gestione nel tempo:

Metriche di qualità e monitoraggio continuo, veri e propri KPI operativi specifici per i sistemi generativi, come ad esempio:

• percentuale degli output che richiedono intervento umano;
• percentuale di output con errori rilevanti;
• tempo medio di rilevazione e correzione;
• tasso di regressione dopo aggiornamenti.

Questi indicatori devono essere monitorati in modo continuativo e i loro costi vanno stimati e contabilizzati come ricorrenti (strumentazione, storage dei log, dashboarding, analisi).

Human-in-the-loop e processi di validazione. Occorre integrare punti di controllo manuale per output critici, flussi di escalation e procedure di rollback:

• stabilire chi verifica, con quali criteri e con quali SLA;
• dimensionare il personale di verifica e i relativi costi;
• prevedere training periodici per i revisori.

L’adozione di processi simili riduce la probabilità di propagazione silenziosa e genera dati utili per il miglioramento dei modelli.

Audit trail e tracciabilità come requisito operativo. È necessario:

• implementare log strutturati che registrino prompt, versioni dei modelli, output, decisioni automatiche e interventi umani;
• conservare metadati di contesto per ogni transazione;
• predisporre strumenti per analisi post-errore e per rispondere a richieste di audit o verifiche regolamentari.

La progettazione e la gestione di questa tracciabilità comportano costi (storage, retention policy, strumenti di ricerca e governance) che vanno inclusi nel TCO.

Questa impostazione trasforma la gestione dell’errore da costo imprevisto a processo governato: gestire i costi di metriche, persone e tracciabilità permette di ridurre il rischio di danni che possono ripercuotersi a lungo, e aiuta a collegare più chiaramente gli investimenti AI a indicatori di valore misurabili nel tempo.

IBM

Questo operatore tra i fondatori dell’informatica business per organizzazioni grandi e piccole ha una prospettiva particolarmente rilevante sul tema di questo articolo perché evolve da decenni un’offerta che oggi prevede

da una parte soluzioni per il cloud ibrido e servizi per gestirle, che quindi comprendono sia hardware e software da acquisire e collocare on premise o presso operatori di fiducia, sia soluzioni SaaS multitenant, nel cloud pubblico di IBM stessa e in quelli di operatori terzi,

dall’altra, fin da molti anni prima dello sviluppo dell’AI generativa, soluzioni di intelligenza artificiale disponibili su tutte le forme del cloud ibrido, compresa l’AI privata.

Per quanto riguarda le soluzioni per il cloud, una peculiarità delle componenti hardware alla loro base è che usano anche processori Power con architettura RISC, un tipo di architetture logiche semplificate rispetto a quelle dei processori più comuni. I processori RISC raggiungono prestazioni superiori a parità di costo e consumo di energia in situazioni di alta saturazione delle risorse di calcolo, come quelle di molti servizi AI. Il software che utilizzano, basato sulla piattaforma di gestione infrastrutture Openshift di Red Hat, grande azienda di soluzioni open source che IBM aveva acquisito nel 2019, espone API standard di mercato e quindi aiuta a gestire queste soluzioni in ambienti multicloud e ibridi.

Le soluzioni di intelligenza artificiale IBM, sotto il marchio watsonx, coprono sia scenari di inferenza “tradizionali”, sia servizi di AI generativa, sia servizi basati su agenti AI, tutti disponibili on premise, come servizi PaaS in cloud privato o SaaS in cloud pubblico, di IBM e di altri.

Innovaway

Innovaway è una società specializzata in servizi ICT e soluzioni tecnologiche avanzate per imprese e pubbliche amministrazioni con oltre 25 anni di esperienza e più di 800 professionisti in diverse sedi italiane ed estere. L’azienda offre un portafoglio completo che copre l’intero ciclo di vita dei servizi digitali, dalla progettazione alla gestione end-to-end di infrastrutture, piattaforme e processi, agendo come unico punto di contatto per i propri clienti.

Nel contesto dei servizi AI, Innovaway ha sviluppato un approccio distintivo basato sul framework Agentic Augmented Intelligence (A2I), che integra l’AI nei servizi IT “trasformando queste tecnologie da semplice supporto decisionale a leva operativa concreta”. Secondo Sergio Ajani, questo modello si fonda sull’utilizzo di agenti autonomi in grado di intervenire in logica “self-healing”, risolvendo incidenti, prevenendo guasti e garantendo continuità operativa nel rispetto di regole e processi aziendali. A2I agisce come un orchestratore operativo avanzato, agnostico rispetto all’infrastruttura sottostante, e quindi supporta la piena operatività sia in modalità on-premise che in ambienti di cloud privato, oltre a integrarsi nativamente con i principali provider di cloud pubblico.

Il framework, approfondisce Ajani, gestisce in modo “deterministico e industriale” la relazione tra le diverse tipologie di AI, bilanciando sicurezza, potenza computazionale e scalabilità. La componente di AI pubblica viene impiegata per accedere ai Large Language Model più raffinati e potenti del mercato, sfruttando la loro capacità di integrare vasti dataset esterni globali e di scalare istantaneamente per gestire carichi di lavoro complessi. Al contrario, l’AI privata viene dedicata all’elaborazione dei dati core aziendali in ambienti protetti, dove operano agenti dedicati ai task più critici.

Come esempio concreto di questa sinergia, Innovaway propone quello dell’Intelligence Documentale. In questo contesto, il framework A2I utilizza l’AI privata per processare documenti o dati interni sensibili, all’interno del perimetro sicuro dell’organizzazione, assicurando la totale sovranità del dato. Simultaneamente, il sistema accede all’AI pubblica per correlare le evidenze interne con milioni di fonti esterne, come trend di mercato globali o aggiornamenti normativi in tempo reale. Questo modello ibrido consente di beneficiare dei modelli più evoluti e performanti disponibili su scala mondiale, mantenendo al contempo la massima riservatezza sulla proprietà intellettuale e riducendo i tempi di esecuzione dei processi di business.

IONOS

IONOS è un provider cloud europeo con infrastrutture ospitate in data centre tedeschi ed europei, focalizzato su soluzioni sovrane e certificate per clienti regolamentati, anche in alternativa a quelle dei grandissimi operatori globali di diritto extraeuropeo. Offre sia cloud pubblico sia cloud privato e una piattaforma gestita per applicazioni AI, con attenzione a conformità, controllo dei dati e opzioni open-source.

Tra i principali componenti dell’offerta IONOS che aiutano a costruire e gestire servizi AI sia sul public cloud IONOS, sia in ambienti cloud privati sovrani, con particolare attenzione a integrazione rapida, gestione dei dati e requisiti di sovranità e compliance, Uwe Geier evidenzia:

AI Model Hub: una piattaforma completamente gestita che ospita modelli open-source e fornisce un’API compatibile OpenAI per facilitare l’avvio delle attività.

Valore operativo: permette di integrare modelli per generare testi e immagini direttamente nelle applicazioni con un impegno iniziale limitato e senza dover gestire l’infrastruttura sottostante.

Capacità di estrazione dati e RAG (vision-language e OCR): modelli e tool per convertire documenti complessi (fatture, moduli, archivi) in formati strutturati (Markdown, LaTeX, JSON) e per alimentare pipeline di Retrieval-Augmented Generation.

Valore operativo: facilita la digitalizzazione di archivi aziendali e la costruzione di knowledge base contestualizzate sui dati proprietari.

Private Cloud flessibile: IONOS propone un cloud privato basato su VMware con opzioni operative flessibili (aggiunta/rimozione server, cancellazione giornaliera) e isolamento fisico per workload sensibili.

Valore operativo: consente di bilanciare controllo, sovranità e flessibilità operativa per carichi di lavoro che richiedono certificazioni o isolamento.

Malogica Solutions

Malogica Solutions, attiva in tutta Europa dalla sede centrale di Madera, in Portogallo, propone soluzioni software di livello enterprise, server per HPC e AI, ed energia rinnovabile. Malogica Systems, il braccio AI/HPC, progetta e assembla appliance (cioè macchine configurate in modo da poter stare in ambienti di lavoro standard e non in data centre e di ufficio standard, senza accorgimenti particolari, configurazione e manutenzione da parte di chi le usa) specializzate per l’inferenza AI, costruite intorno a schede acceleratrici progettate su misura per l’inferenza. (Queste macchine si basano infatti su chip ASIC, progettati specificamente per l’inferenza AI. Le GPU, invece, si sono dimostrate efficaci per l’AI ma sono nate per applicazioni di calcolo generico, in particolare per la manipolazione e resa di immagini.)

Questa pila hardware-software integrata, con LLM open source ottimizzati per funzionare su hardware diverso dalle GPU, si rivolge alle organizzazioni in tutta Europa che preferiscono i costi prevedibili delle soluzioni on premise, l’efficienza energetica e la sovranità sui dati rispetto alla flessibilità dei servizi cloud pubblici.

SAP

Questo fornitore di software tra i principali al mondo offre soluzioni AI integrate per le applicazioni enterprise, disponibili sia su ambienti private cloud, sia public cloud in collaborazione con molti hyperscaler. L’approccio di SAP punta a collegare l’AI ai processi core aziendali, consentendo scalabilità, tutela del dato e libertà architetturale.

Adriano Ceccherini evidenzia tre componenti distintive nell’offerta SAP per i servizi AI:

Modello OpEx integrato: SAP propone un modello contrattuale OpEx in cui una singola fee adattabile include applicazione AI di business, LLM, layer di sicurezza, infrastruttura ed esercizio (operation).

Valore operativo: semplifica la previsione dei costi e allinea il pricing al valore operativo effettivamente erogato, facilitando l’adozione di soluzioni in produzione oltre che sperimentali.

Servizi AI di tre tipologie: SAP fornisce servizi AI in tre ambiti: agenti e orchestrazione, interfacce conversazionali integrate, e AI inserita nei processi di business (es. Joule, Joule Agents, AI Foundation).

Valore operativo: gli agenti AI automatizzano attività ripetitive e orchestrano processi complessi tra funzioni diverse – ad esempio finanza, gestione delle risorse umane, supply chain e procurement – riducendo tempi operativi, errori manuali e colli di bottiglia.

Opzioni sovrane e private: SAP mette a disposizione percorsi dedicati per esigenze di sovranità e compliance, tra cui SAP S/4HANA Cloud Private Edition, i percorsi RISE with SAP e le architetture EU AI Cloud per esigenze di sovranità e conformità alle norme.

Valore operativo: maggior controllo su dati e processi, che rende SAP adatto anche a settori regolamentati che richiedono garanzie di conformità e localizzazione.