Il costo nascosto della nuvola

Capitolo 5 — Il costo nascosto della nuvola

La narrativa dominante degli ultimi cinque anni dice che la nuvola è economica, scalabile e semplice. Per molti carichi di lavoro è perfettamente vero. Per i RAG aziendali, sempre più spesso, non lo è. E il momento in cui te ne accorgi è solitamente la fine del primo trimestre, quando arriva la fattura.

Prendiamo la voce più sottovalutata del conto: le API dei modelli di visione. Quando un'azienda ingerisce il proprio archivio fotografico in un RAG moderno, ogni foto deve essere "descritta" da un modello multimodale che ne estrae contenuto, oggetti, contesto, eventuali testi sovraimpressi, umore, composizione. Un grande provider europeo di modelli — ancora senza nomi — offriva, nel 2025, un eccellente modello della famiglia Qwen da 32 miliardi di parametri, a un prezzo per immagine interessante. Il problema, scoperto solo sul campo e dopo mesi di produzione: sotto carico, il provider troncava le risposte. Non sempre, non in modo prevedibile, non quando c'era il team di testing davanti: casualmente. Una foto su dieci, a volte una su cinque, tornava con un JSON tagliato a metà, parsato male, con metadati parziali o nulli. I tempi schizzavano da dieci secondi a duecento secondi per immagine, senza pattern. La bolletta del retry — perché i retry si pagano, ogni chiamata, anche quella che il server tronca — era più alta del previsto. Il database era disomogeneo: alcune foto ricchissime di metadati, altre monche. E il team non riusciva a riprodurre il problema in ambienti di test, perché in test il carico era basso e tutto funzionava.

La soluzione è arrivata in tre pezzi: un prompt più compatto (risposte più brevi si troncano meno), una logica di retry intelligente (se la risposta impiega più di cinquanta secondi e torna vuota, riprova subito) e — quando il volume lo giustifica — la possibilità di saltare del tutto il cloud e far girare il modello di visione su una GPU locale, più lenta ma deterministica. L'architettura giusta, da questa esperienza, non è "cloud sempre" né "locale sempre". È "scegli per ogni chiamata, in base a cosa serve in quel momento".

Poi c'è il capitolo delle query. Ogni ricerca utente, in un RAG cloud-nativo classico, scatena una cascata di chiamate API a pagamento. Una per l'embedding della domanda. Una per la classificazione intenzionale (di che tipo è la domanda?). Una per il reranking dei documenti. Una per la generazione della risposta finale. Ciascuna costa una frazione di centesimo. Per un servizio interno con cinquanta utenti e diecimila query al giorno — che non sono poche ma nemmeno un numero enorme per un'azienda media — il conto mensile arriva a cifre che farebbero storcere il naso anche a un CFO indulgente. E la crescita è lineare: raddoppi gli utenti, raddoppi il conto. Non ci sono economie di scala nei token consumati, non per te.

C'è anche un problema che nel 2025 era sottotraccia e che nel 2026 è diventato centrale: ogni singola query manda pezzi di documenti aziendali — a volte riservati, a volte coperti da NDA, a volte soggetti a normative di settore — ai server di un fornitore esterno, in giurisdizioni che non sempre coincidono con la tua, con policy sulla conservazione dei log non sempre cristalline. Più di un'azienda europea, negli ultimi diciotto mesi, ha scoperto solo durante un audit — di solito indotto da un cliente preoccupato o da una verifica ISO — che i propri contratti, listini e specifiche tecniche erano stati processati (e potenzialmente loggati per fini di "miglioramento del servizio") da infrastrutture fuori UE. La sorpresa, di solito, è costata più del risparmio sull'hardware locale che si era voluto evitare.

L'alternativa non è il dogma opposto. "Cloud no, locale sì" è sbagliato quanto "cloud sì sempre". L'alternativa è un'architettura che ti permetta di scegliere, per ogni singolo pezzo della pipeline — embedding, classificazione, reranking, visione, generazione finale —, se usare un modello cloud o uno locale, e di cambiare idea in un giorno, non in un trimestre. Questo richiede un disegno in cui i fornitori siano intercambiabili, dove nessun pezzo sia inchiodato al nome di un'azienda specifica, dove il passaggio da Regolo a Ollama (o viceversa) sia una riga di configurazione, non una riscrittura. E questo, fino a poco tempo fa, era raro. I framework popolari, nonostante la facciata di "provider-agnostic", erano in realtà molto sposati con qualcuno.