Dove l’AI si rompe davvero (e i benchmark non lo dicono)
Chi mette in produzione carichi AI scopre in fretta che la distanza tra la demo su una singola GPU e un servizio con SLA è enorme. Sul campo, i punti di rottura non sono quasi mai quelli che compaiono nei benchmark pubblicati dai vendor. Il primo è la VRAM: un modello che “entra” in 24 GB durante un test a batch singolo esplode quando arrivano richieste concorrenti, perché la KV-cache cresce con il contesto e con il numero di sessioni. Il risultato non è un rallentamento graduale, ma OOM secchi e worker che muoiono. La lezione è dimensionare sulla concorrenza reale, non sul peso del checkpoint.
Il secondo collo di bottiglia è lo storage per i modelli. Nessuno racconta che scaricare, versionare e caricare pesi da decine o centinaia di GB mette sotto stress la pipeline: cold start di diversi minuti, saturazione dei link verso il registry, autoscaling che non scala perché il tempo di provisioning di un pod GPU è dominato dal pull del modello. Qui servono cache locali sui nodi, storage NVMe veloce e una strategia di pre-warm, altrimenti l’elasticità promessa dal cloud diventa teoria.
Il terzo è il costo cloud fuori controllo. Le istanze GPU a consumo si pagano per ogni ora, anche quando la GPU è ferma ad aspettare I/O. Ho visto conti tripicare per workload lasciati “acceso per comodità” nei fine settimana e per inference verso API esterne fatturate a token, dove un retrieval mal progettato che inietta contesto ridondante moltiplica la spesa senza migliorare la risposta. Senza FinOps e budget alert, la bolletta arriva prima del valore di business.
Sovranità del dato contro comodità delle API: il trade-off reale
Il negoziato più concreto con i clienti riguarda sempre la scelta tra modello on-prem (o su cloud sovrano UE) e le API dei provider USA. Da un lato performance immediate, modelli allo stato dell’arte e zero gestione infrastrutturale; dall’altro il vincolo dell’AI Act, la classificazione del rischio, la data residency e il fatto che i dati sensibili non possono uscire dalla UE.
La soluzione che finisce per convincere quasi sempre è ibrida e guidata dalla classificazione del dato:
- Dati regolati o sensibili (sanitari, giudiziari, segreti industriali): inference on-prem o su cloud sovrano, con modelli open-weight di taglia gestibile, gateway che impedisce l’uscita del payload verso l’esterno e log completo per l’auditabilità richiesta dall’AI Act.
- Dati pubblici o non critici (bozze, contenuti già divulgati, task generici): API esterne accettabili, ma con anonimizzazione a monte e clausole contrattuali sul non-training.
Il compromesso vero è ammettere che un 8B on-prem ben istruito con RAG sui dati aziendali batte spesso un modello enorme via API che non conosce il dominio. La qualità percepita dipende più dal contesto recuperato che dal numero di parametri: questo sposta l’ago verso la sovranità senza sacrificare i risultati.
Quando dico “partiamo” e quando dico “aspetta”
Quando un CIO o un CISO chiede “dobbiamo metterci l’AI”, la mia prima risposta non è tecnologica ma metodologica: si parte dagli use case. Non da “vogliamo l’AI”, ma da un problema misurabile, con un baseline e una metrica di successo. È questo che separa un progetto da una spesa di posizionamento.
Dico di partire subito quando esiste un caso a volume alto, ripetitivo e con dato interno già strutturato: classificazione di ticket, ricerca semantica su documentazione tecnica, assistenza di primo livello su knowledge base. Motivazione tecnica: qui il RAG su modelli medi rende risultati solidi, l’infrastruttura è dimensionabile, il ROI è misurabile in ore-uomo risparmiate e il rischio AI Act è basso perché il dato resta dentro il perimetro.
Freno quando la richiesta è generativa “aperta” su processi critici senza un dato ripulito alle spalle, o quando si vuole comprare cluster GPU on-prem “perché servirà”. Motivazione tecnica precisa: senza dataset governato il RAG allucina, la validazione umana annulla il risparmio, e una GPU acquistata per un carico non ancora definito è capitale immobilizzato che invecchia in fretta, mentre un affitto orario o un endpoint sovrano coprono lo stesso bisogno con costi variabili. Prima si valida su infrastruttura elastica, poi — solo con numeri di utilizzo alla mano — si valuta l’on-prem.
Il verdetto: muoversi ora, ma con disciplina
Il verdetto è 1: conviene muoversi. Non perché l’hype lo imponga, ma perché lo stack per fare AI in casa in modo sovrano è oggi maturo: modelli open-weight validi, runtime di inference efficienti, quantizzazione che riduce le richieste di VRAM, cloud UE su cui appoggiarsi. Chi aspetta perde competenza operativa, e la competenza — non la GPU — è la parte che non si compra a consumo.
Muoversi però significa partire da use case circoscritti, misurare i costi reali con logica FinOps, tenere il dato sensibile dentro il perimetro per l’AI Act e trattare l’infrastruttura GPU come una scelta di scala, non di apertura del progetto. L’AI in produzione premia chi la tratta come un sistema da esercire con SLA, budget e auditabilità, non come una demo da mettere online. Il conto della luce, alla fine, lo paga solo chi non ha fatto i conti prima.