Chi affitta l’intelligenza e chi se la porta dentro: la divisione che ridisegnerà le aziende

Il frame che organizza le decisioni infrastrutturali del 2026 è semplice: affittare intelligenza o possederla. Da un lato le aziende che dipendono dai grandi provider cloud per ogni inferenza, ogni chiamata API, ogni risposta dei propri sistemi AI. Dall’altro quelle che stanno riportando i modelli dentro i propri datacenter o direttamente sui margini della rete. La distinzione sembra tecnica. Non lo è.

Per cinque anni il cloud-first ha dominato il dibattito sull’AI aziendale per ragioni comprensibili: accesso immediato ai modelli più potenti, zero investimento iniziale in hardware, scalabilità elastica per i picchi di calcolo. Tutto vero fino al 2024, quando i carichi di lavoro AI sono passati dalla sperimentazione alla produzione e le bollette cloud hanno cominciato a pesare nei bilanci. Il costo per milione di token, in un’organizzazione che usa l’AI in modo intensivo su processi core, non è una voce marginale.

Affittare intelligenza o possederla: un’analisi di costo che cambia tutto

L’analisi del costo totale di possesso mette in crisi il presupposto che il cloud sia sempre più conveniente. Secondo i dati raccolti da Lenovo nel confronto TCO 2026, il costo per milione di token su infrastruttura on-premise può essere fino a 18 volte inferiore rispetto alle API dei grandi provider di modelli-come-servizio, nei carichi di lavoro ad alta frequenza d’uso. Il breakeven rispetto all’investimento in hardware si raggiunge in meno di quattro mesi per chi gestisce workload intensivi.

Questi numeri non valgono per tutti. Un’azienda che usa l’AI sporadicamente, per task non critici, non ha motivo di investire in GPU proprie. Ma l’economia si ribalta non appena l’AI diventa infrastruttura di processo piuttosto che strumento occasionale. Quattro mesi di breakeven significano che già nel quinto mese si spende meno dell’alternativa cloud. Su tre anni, il risparmio complessivo è strutturale.

Il mercato si sta già muovendo in questa direzione. IDC stima che entro il 2027 il 75% delle grandi organizzazioni adotterà architetture ibride, con una distribuzione tri-partita bilanciata tra cloud pubblico, cloud privato o on-premise, e dispositivi edge. Il 2026 segna la transizione da un modello a gravità cloud verso una distribuzione del carico di lavoro AI pensata in base alla natura del singolo workload. Chi fa questa transizione in ordine mantiene il controllo dell’architettura. Chi la subisce insegue i costi.

La distinzione per tipo di carico di lavoro è netta. L’addestramento di modelli di grandi dimensioni e i picchi compute rimangono terreno cloud per ragioni strutturali: la richiesta di calcolo è discontinua, l’elasticità del cloud ha senso, comprare GPU ferme nove mesi su dodici per coprire i picchi è inefficiente. L’inferenza in produzione su dati operativi interni, invece, cambia la matematica. Qui il volume è costante, il dato è sensibile, la latenza conta.

I dati operativi restano in sede: dove devono stare anche i modelli

I settori regolamentati hanno capito prima degli altri che mandare dati su API cloud è un problema di governance, non solo di costo. Banche, ospedali, studi legali: i dati operativi non possono lasciare il perimetro aziendale senza generare rischi di conformità che nessun accordo contrattuale con un provider cloud elimina davvero. GDPR, direttive settoriali, audit interni: il dato che esce è un dato esposto. Questo ha spinto molte organizzazioni a riconsiderare l’ipotesi on-premise non come un passo indietro tecnologico, ma come scelta di sovranità.

C’è però un secondo problema, meno discusso ma altrettanto rilevante: il lock-in da modello. Chi costruisce applicazioni business sopra le API di un grande provider cloud dipende dal comportamento specifico di quella versione del modello. Gli aggiornamenti unilaterali dei modelli, frequenti e spesso non comunicati con anticipo sufficiente, cambiano il comportamento dell’applicazione senza preavviso. Un sistema di classificazione documenti calibrato su GPT-4o di marzo si comporta in modo diverso con GPT-4o di settembre. La dipendenza dall’API diventa dipendenza dal capriccio del fornitore.

Nutanix definisce l’infrastruttura on-premise moderna come “la colonna vertebrale dell’AI aziendale privata”. La formula è di marketing, ma il concetto regge: controllare il modello significa controllare il comportamento dell’applicazione nel tempo. Un modello fisso in sede non cambia comportamento a meno che sia l’azienda a sceglierlo. Questo è un vantaggio di stabilità che vale in tutti i settori, non solo in quelli regolamentati.

L’edge introduce una terza dimensione. Per le PMI manifatturiere e le aziende di logistica, la latenza e la connettività variabile rendono l’AI su cloud strutturalmente inadeguata per certi processi. Un sistema di ispezione visiva su linea di produzione che dipende da una chiamata API a duecento millisecondi di latenza, con una connessione che può degradare, non è un’infrastruttura affidabile. L’inferenza locale su dispositivi edge non è una soluzione di ripiego: è la scelta corretta per i workload che richiedono risposta in tempo reale su dati locali. Su questo tema Tom’s Hardware ha analizzato in dettaglio il vantaggio del pensiero locale.

Le aziende che avevano frenato sulla spesa AI nel 2025, dopo aver visto i costi cloud lievitare, stanno ora ripensando l’architettura invece di tagliare i progetti. La distinzione tra workload cloud-native e workload on-premise si consolida come prassi di ingegneria infrastrutturale: si usano entrambi i modelli, si sceglie caso per caso in base a latenza, volume, sensibilità del dato, stabilità richiesta.

Il mercato sta leggendo questa transizione come la divisione strutturale del decennio per il software aziendale: da un lato chi affitta intelligenza ai grandi provider, dall’altro chi la possiede e la gestisce. La tesi è che questa divisione produrrà una differenza competitiva reale nel medio termine, perché i costi e la controllabilità dell’AI aziendale sono variabili strategiche, non tecniche.

La scelta fatta oggi è difficilmente reversibile nel breve termine. Costruire stack applicativi sopra le API di un singolo provider significa incassare la dipendenza da quel provider per anni: i contratti di servizio, le integrazioni, la formazione interna si stratificano sopra l’architettura iniziale. Cambiare idea a diciotto mesi dall’avvio di un progetto enterprise comporta costi di migrazione e riscrittura che molte organizzazioni non possono permettersi. Il vendor lock-in nell’AI aziendale è più profondo del lock-in cloud tradizionale, perché tocca il comportamento delle applicazioni, non solo il posto dove girano.

La scelta sbagliata oggi produce un costo strutturale che durerà anni. Un’organizzazione che scopre a ventiquattro mesi dall’avvio che il modello cloud non soddisfa i requisiti di latenza per il suo caso d’uso principale, o che i costi API hanno superato qualsiasi proiezione iniziale, non può semplicemente “migrare on-premise” in qualche settimana. Ha dati, processi e integrazioni costruiti su una premessa sbagliata.

L’architettura AI non è una questione che si delega interamente al team IT. La decisione su dove stanno i modelli, chi li controlla, quanto costano a regime e come evolvono nel tempo è una decisione di business con implicazioni pluriennali. Chi la tratta come un dettaglio tecnico scoprirà che ha comunque scelto: ha scelto di affittare, con tutto quello che questo comporta.