On-premise, cloud o API: dove far girare l'AI aziendale

Dopo la scelta del modello arriva la domanda gemella, dove farlo girare, e la risposta disegna l'assetto con cui l'azienda conviverà per anni: i costi che diventeranno struttura, le competenze da assumere, i vincoli che ogni nuovo caso d'uso erediterà. Le opzioni sul tavolo sono tre, e prima dei criteri conviene chiamarle con precisione, perché nei comitati si confondono spesso. L'API gestita: il modello vive dal provider, l'azienda consuma capacità a richiesta. Il cloud dedicato: il modello, aperto o licenziato, gira su infrastruttura noleggiata dall'azienda presso un hyperscaler, dentro un perimetro che l'azienda controlla. L'on-premise: hardware proprio, nel proprio data center, sotto la propria responsabilità fisica.

La tentazione di trattarla come scelta di campo va disinnescata subito, come per i modelli: la domanda giusta è per caso d'uso, e l'assetto di arrivo delle organizzazioni mature è quasi sempre ibrido.

Il vincolo comanda, il resto negozia

Il criterio che decide per primo, quando c'è, è il vincolo non negoziabile sui dati. Esistono informazioni che per norma di settore, per clausola di committenza o per natura (si pensi a certi dati sanitari, giudiziari, di difesa) non possono attraversare confini definiti, e lì la discussione si accorcia: si sceglie tra cloud dedicato con garanzie di residenza contrattualmente solide, formule di cloud sovrano dove il settore le richiede, oppure on-premise quando nemmeno il perimetro noleggiato basta. Il lavoro serio, in questi casi, sta nel distinguere i vincoli veri da quelli presunti, perché "i nostri dati non possono stare nel cloud" è una frase che negli assessment si rivela, una volta su due, una policy mai scritta che qualcuno ricorda male.

Dove il vincolo assoluto non c'è, entrano i criteri negoziabili, e il primo è il profilo di carico. L'API brilla con volumi variabili o imprevedibili, perché trasforma tutto in costo marginale; l'infrastruttura propria, noleggiata o comprata, inizia a ripagarsi con carichi alti e costanti, quando le GPU lavorano invece di aspettare. La latenza aggiunge il suo peso nei casi d'uso in linea con l'operatività (un sistema che risponde all'operatore in tempo reale tollera male i viaggi di rete), la personalizzazione profonda il suo, perché fine-tuning estesi e controllo di versione totale chiedono un'infrastruttura che si comanda.

I costi che le slide non mostrano

Il confronto economico tra le tre vie soffre di una distorsione sistematica: si confrontano i prezzi visibili, il costo per token contro il canone delle GPU, e si omettono le voci che decidono il totale. Per il cloud dedicato e l'on-premise le voci omesse sono le persone (ingegneri capaci di servire modelli con affidabilità di produzione, la figura più contesa del mercato), l'utilizzo reale dell'hardware (una GPU pagata e ferma è il costo più puro che esista), l'aggiornamento (i modelli migliorano a ritmo tale che l'infrastruttura dimensionata oggi può servire un modello obsoleto tra diciotto mesi). Per l'API la voce omessa è speculare, la crescita: il costo marginale che rendeva facile partire scala linearmente con il successo, e i casi d'uso ad alto volume vanno rifatti di conto ogni pochi mesi.

La conseguenza pratica è che il punto di pareggio esiste, si sposta nel tempo, e va calcolato sui volumi propri con tutte le voci dentro. Nei conti che rivediamo, l'errore più frequente resta sottostimare le persone e sovrastimare l'utilizzo.

L'ibrido come punto di arrivo, l'astrazione come premessa

Messi in fila i criteri, l'architettura verso cui convergono le organizzazioni mature è a strati: API gestite per la lunga coda di casi d'uso a volume contenuto e per ciò che chiede capacità di frontiera, un perimetro dedicato (cloud o, più di rado, on-premise) per i carichi costanti e per i dati che non viaggiano, e una regola scritta che assegna ogni nuovo caso d'uso allo strato giusto in base a vincoli, volumi e latenza, invece che alle preferenze del team che lo propone.

La premessa tecnica che rende l'ibrido governabile, e che va decisa all'inizio quando costa poco, è lo strato di astrazione: le applicazioni parlano con un'interfaccia interna, mai direttamente con il singolo provider o il singolo cluster, così che spostare un carico da uno strato all'altro sia una configurazione e non una riscrittura. È la stessa assicurazione contro il lock-in di cui parliamo a proposito dei modelli, applicata all'infrastruttura, e vale anche come posizione negoziale: si ottengono condizioni migliori da chiunque quando andarsene è tecnicamente facile.

La scelta dell'assetto, in sintesi, è un esercizio di vincoli prima che di preferenze, e il modo più rapido per sbagliarla è farla per imitazione, copiando l'architettura di un'azienda con vincoli diversi dai propri. Se state disegnando la vostra, o ridiscutendo quella ereditata, il punto di partenza è l'inventario di vincoli, volumi e competenze reali: calendly.com/fabiolalli/zerofive, oppure hello@zerofive.ai. E per il prossimo comitato, una domanda di controllo che non richiede slide: dei vincoli che oggi vi tengono lontani dal cloud, o dentro, quanti esistono per iscritto?