Costi AI aziendali: cosa insegnano Uber, DGX Spark e i modelli locali

La tesi in una frase

Molte aziende stanno sovrapagando l'AI perché trattano ogni attività come se richiedesse il modello più intelligente sul mercato. Nei prossimi 12-24 mesi la competenza importante non sarà solo saper usare ChatGPT, Claude o Gemini, ma saper decidere quale modello usare, dove eseguirlo, con quali limiti di costo e con quale misurazione del ritorno.

Il passaggio sarà questo: prima le aziende hanno chiesto 'possiamo usare l'AI?'. Poi chiederanno 'quanto ci costa usarla davvero?'. Infine arriveranno alla domanda matura: 'qual è il modello abbastanza buono per questo processo specifico?'. È lì che diventano interessanti modelli locali, modelli open source, hardware dedicato e architetture ibride.

Cosa è successo a Uber e perché interessa anche alle PMI

Il caso Uber è utile perché rende visibile un problema che molte aziende stanno ancora sottovalutando. TechCrunch, riprendendo Bloomberg e The Information, riporta che Uber ha messo un cap mensile di 1.500 dollari per dipendente e per tool agentico come Claude Code o Cursor. La spesa può essere superata con autorizzazione, ma il messaggio è chiaro: l'uso dell'AI non può crescere senza controllo.

La parte più interessante non è il numero in sé. Per una grande azienda tecnologica 1.500 dollari al mese per persona possono anche essere giustificati se producono abbastanza valore. Il punto è che Uber aveva incoraggiato l'uso massiccio degli strumenti AI e, secondo quanto riportato, aveva già consumato il budget annuale in quattro mesi. Questa è la dinamica tipica della prima fase di adozione: si misura l'utilizzo, non il risultato.

Per una PMI italiana il rischio è lo stesso, solo su scala più piccola. Prima si comprano licenze per tutti. Poi ogni reparto sperimenta. Poi emergono abbonamenti duplicati, workflow non misurati, output mai usati, strumenti pagati perché 'non si sa mai'. Dopo qualche mese l'imprenditore o il CFO chiede: quante ore abbiamo risparmiato? Quanti errori abbiamo ridotto? Quanti preventivi in più abbiamo mandato? Se la risposta non esiste, l'AI viene percepita come costo, non come capacità aziendale.

Il problema non è il costo dell'AI, è il costo non misurato

Dire che l'AI costa troppo è una semplificazione. L'AI costa troppo quando viene usata senza collegarla a un processo, a una baseline e a un output economico. Se un team di sviluppo spende 1.500 euro al mese in strumenti agentici ma riduce del 30% il tempo su bug fix, refactor e test, quella spesa può essere ottima. Se lo stesso importo produce solo più chat, più bozze e più esperimenti non adottati, è spreco.

La differenza sta nella misurazione. Prima di introdurre l'AI su un processo bisogna conoscere almeno tre numeri: quanto tempo costa oggi quel processo, quante volte avviene ogni mese, quale livello di qualità serve per considerare l'output utilizzabile. Senza questi numeri ogni discussione sul ROI diventa opinione.

Questo è il motivo per cui la prossima categoria di consulenza AI non sarà solo 'formazione su ChatGPT'. Sarà AI cost audit: mappare dove l'azienda sta usando AI, quanto spende, quali workflow producono valore, quali vanno chiusi, quali possono essere spostati su modelli più economici.

L'errore più comune: usare sempre il modello migliore

Molte aziende assumono implicitamente che il modello più potente produca sempre più valore. È falso. Il modello migliore produce più valore solo quando il task richiede davvero capacità superiori: ragionamento complesso, coding difficile, strategia, analisi con molte variabili, agenti che devono pianificare su più step.

Per molti processi aziendali quotidiani non serve il modello più intelligente del pianeta. Serve un modello abbastanza buono, stabile, economico, privato e facile da integrare. La differenza è enorme. Un modello frontier usato per classificare ticket semplici può essere tecnicamente eccellente e economicamente sbagliato. Un modello locale più piccolo che raggiunge il 90-95% di accuratezza a una frazione del costo può essere la scelta migliore.

• Classificazione documenti: serve coerenza di etichette, non creatività.
• Estrazione dati da fatture e contratti: serve precisione su campi definiti, non ragionamento strategico.
• Routing ticket customer care: serve capire categoria, priorità e reparto.
• Sintesi di report ricorrenti: serve uno schema stabile e verificabile.
• Bozze email operative: serve aderire al tono e al contesto, non vincere un benchmark.
• Arricchimento CRM: serve completare campi e generare note sintetiche.

L'esempio dei 3.000 documenti

Immaginiamo un workflow di estrazione dati su circa 3.000 documenti. Si caricano i file, il modello legge ogni documento, estrae campi strutturati, segnala anomalie e produce un CSV controllabile. Con un modello frontier di ultima generazione il risultato può essere molto buono. Ma se il costo stimato è circa 3.000 euro, la domanda corretta non è: il modello riesce a farlo? La domanda corretta è: vale 3.000 euro?

Se una persona interna può fare lo stesso lavoro a un costo inferiore, il workflow non ha ROI. Se un modello locale o più piccolo può ottenere il 95% dell'accuratezza al 5-10% del costo, il modello frontier è probabilmente sovradimensionato. Se invece quei 3.000 documenti generano un output che evita settimane di lavoro qualificato, riduce errori legali o sblocca una decisione commerciale importante, allora anche 3.000 euro possono essere pochi.

Il punto è sempre lo stesso: il costo dell'AI va confrontato con il costo del processo attuale, non con l'entusiasmo per la tecnologia.

Perché DGX Spark è rilevante

NVIDIA DGX Spark è interessante non perché ogni PMI debba comprarlo domani, ma perché segnala una direzione. NVIDIA descrive DGX Spark come un computer AI desktop basato su superchip GB10 Grace Blackwell, con fino a 1 petaFLOP di performance AI FP4, 128 GB di memoria unificata e supporto a modelli fino a 200 miliardi di parametri su singola macchina. La documentazione NVIDIA parla anche di fine-tuning locale di modelli fino a 70 miliardi di parametri e, in configurazione dual-Spark, supporto a modelli fino a 405 miliardi di parametri.

Fino a poco tempo fa l'AI locale era spesso una scelta da smanettoni o da team di ricerca: poca VRAM, setup fragile, performance imprevedibili, tooling meno maturo. Hardware come DGX Spark indica che il mercato sta andando verso macchine dedicate per sviluppo, test, inferenza e personalizzazione locale. Non sostituiscono il cloud per tutto. Rendono però credibile un'architettura in cui alcuni carichi vengono eseguiti internamente.

Per le aziende europee questo conta anche per privacy, governance e controllo dei dati. Se un workflow tratta documenti legali, dati sanitari, informazioni finanziarie, dati clienti o know-how industriale, mandare tutto a un provider esterno può essere impossibile o almeno delicato. Una parte dell'AI tornerà vicino ai dati non per nostalgia dell'on-premise, ma perché alcuni processi sono troppo sensibili o troppo frequenti per dipendere sempre dal cloud.

Cloud AI vs AI locale: è la domanda sbagliata

La contrapposizione 'cloud contro on-premise' attira click, ma porta fuori strada. Il futuro più probabile non è tutto locale e non è tutto cloud. È ibrido. I modelli frontier resteranno fondamentali per i task difficili. OpenAI, Anthropic, Google e gli altri continueranno a spingere la frontiera. La domanda è se ogni azienda debba usare quella frontiera per ogni attività.

Per la maggior parte delle aziende la risposta è no. Un'architettura intelligente separa i task per criticità, costo e sensibilità del dato. I task ripetitivi e ad alto volume vanno su modelli economici, spesso locali o open source. I task complessi, a basso volume e ad alto valore vanno sui modelli migliori disponibili. È la stessa logica con cui nel cloud non si usa la macchina più potente per ogni servizio.

La strategia ibrida: tre livelli di modelli

Una stack AI sostenibile per una PMI o mid-market può essere pensata su tre livelli. Non è una teoria astratta: è il modo più semplice per evitare che ogni workflow finisca sul modello più costoso solo perché è il default.

• Livello 1 - Modelli piccoli e locali: classificazione, tagging, estrazione campi semplici, anonimizzazione, routing, pre-processing. Obiettivo: costo bassissimo e privacy alta.
• Livello 2 - Modelli cloud economici o open source serviti internamente: sintesi, normalizzazione documenti, RAG su knowledge base, bozze standard, analisi ricorrenti. Obiettivo: buon compromesso fra qualità e costo.
• Livello 3 - Modelli frontier: coding complesso, strategia, analisi ambigue, agenti multi-step, decision support ad alto valore. Obiettivo: massima qualità dove il valore giustifica il costo.

Dove i modelli locali hanno senso oggi

I modelli locali o open source sono già interessanti quando il task è ripetitivo, lo schema di output è chiaro e l'azienda può validare la qualità su un set di test reale. Non serve credere che un modello locale batta sempre Claude, GPT o Gemini. Serve sapere quando è abbastanza buono per il lavoro.

Esempi concreti: classificare ticket in 20 categorie, estrarre dati da documenti standardizzati, generare tag per contenuti interni, sintetizzare note operative, controllare se un documento contiene informazioni sensibili, trasformare email in record CRM, fare deduplica e normalizzazione di anagrafiche. Sono task in cui il valore non deriva dalla genialità del modello, ma dalla ripetibilità.

Dove i modelli frontier restano indispensabili

Il messaggio non deve diventare ideologico. I modelli frontier restano superiori quando il task richiede ragionamento profondo, gestione di contesto ambiguo, capacità agentiche avanzate o produzione di codice complesso. Usarli meno non significa usarli peggio. Significa preservarli per i casi in cui spostano davvero il risultato.

In pratica: coding su codebase grandi, analisi strategica, troubleshooting tecnico complesso, revisione contratti con clausole non standard, simulazione di scenari, progettazione di workflow agentici, ricerca con fonti multiple e sintesi di decisioni manageriali. Qui il costo del modello è spesso secondario rispetto al costo di una risposta sbagliata o mediocre.

La privacy sarà un acceleratore dell'AI locale

In Europa, e ancora di più in settori regolati, la privacy non è un dettaglio. Molte aziende non possono mandare liberamente a un provider esterno documenti clienti, dati sanitari, pratiche legali, dati finanziari, offerte commerciali o informazioni industriali. Anche quando è possibile farlo con contratti enterprise e DPA corretti, serve comunque governance: chi può caricare cosa, con quale modello, in quale ambiente, con quali log.

L'AI locale non elimina automaticamente GDPR, sicurezza e compliance. Ma offre una leva in più: alcuni dati possono restare dentro il perimetro aziendale, alcuni workflow possono essere auditati meglio, alcune elaborazioni possono avvenire vicino ai sistemi sorgente. Per aziende tedesche, italiane, sanitarie, legali, finanziarie e manifatturiere questo può diventare un vantaggio concreto.

Come fare un AI cost audit in azienda

Un AI cost audit non parte dagli strumenti. Parte dai processi. L'obiettivo è capire dove l'AI sta creando valore, dove sta solo consumando budget e dove conviene cambiare modello o architettura.

• 1. Inventario: elenca tutti gli strumenti AI usati dal team, inclusi abbonamenti personali rimborsati e API nascoste nei workflow.
• 2. Mappa processi: collega ogni strumento a un processo reale, non a una generica voce 'produttività'.
• 3. Misura baseline: ore spese prima dell'AI, volume mensile, costo orario del team, tasso di errore.
• 4. Misura utilizzo: costo per reparto, persona, workflow, modello e output generato.
• 5. Calcola valore: ore risparmiate, output aggiuntivo, errori evitati, velocità di risposta migliorata.
• 6. Segmenta modelli: decidi quali workflow richiedono frontier model, quali possono usare modelli economici, quali possono andare locali.
• 7. Imposta guardrail: budget mensili, dashboard, soglie di alert, autorizzazioni per superare i limiti.

Cosa dovrebbe fare una PMI italiana nei prossimi 90 giorni

La risposta non è comprare hardware AI subito. Per la maggior parte delle PMI sarebbe prematuro. La risposta è costruire disciplina. Prima si misura, poi si ottimizza, poi eventualmente si decide se ha senso una componente locale.

• Settimana 1-2: scegli 3 processi AI già usati o candidati e misura il costo attuale senza AI.
• Settimana 3-4: testa il workflow con un modello frontier e definisci una baseline di qualità.
• Settimana 5-6: prova un modello più economico o locale sugli stessi input e confronta costo, qualità e tempo di revisione.
• Settimana 7-8: scegli il modello più economico che supera la soglia di qualità richiesta.
• Settimana 9-12: metti il workflow in produzione con dashboard di costo, owner interno e revisione mensile.

La vera opportunità: AI cost optimization

La prima ondata dell'AI aziendale è stata venduta come trasformazione. La seconda sarà venduta come efficienza. Ma la terza, quella più matura, sarà ottimizzazione: stesso risultato o risultato migliore, con costo unitario più basso, più privacy e più controllo.

È esattamente quello che è successo con il cloud. Prima tutti hanno migrato. Poi le fatture sono esplose. Poi sono nati FinOps, tagging, reserved instances, autoscaling, cost dashboards, architetture più sobrie. Con l'AI succederà qualcosa di simile, ma più velocemente, perché il costo non è solo infrastruttura: è token, contesto, agenti, tool, chiamate API, revisione umana e rischio sui dati.

Le aziende vincenti non saranno quelle che 'usano più AI'. Saranno quelle che sapranno usare l'AI giusta nel punto giusto del processo.

Tre chiarimenti utili

No: DGX Spark non significa che tutte le aziende debbano spostare l'AI on-premise. Significa che l'inferenza e lo sviluppo locale diventano più realistici per team con volumi, privacy o sperimentazione tecnica sufficienti.

No: il caso Uber non dimostra che l'AI non produce ROI. Dimostra che l'adozione senza misurazione e senza limiti di costo può bruciare budget prima che l'azienda sappia attribuire il valore prodotto.

Sì: una PMI può iniziare senza hardware dedicato. Il primo passo è misurare processi, scegliere casi d'uso ad alto volume, testare modelli diversi e usare il modello meno costoso che raggiunge la qualità necessaria.

In sintesi

Il punto non è scegliere una religione tra cloud e on-premise. Il punto è smettere di usare il modello più costoso come default universale. Uber mostra il problema della spesa AI non governata. DGX Spark mostra che l'hardware per AI locale sta diventando più serio. In mezzo c'è la decisione che ogni azienda dovrà prendere: quale modello serve davvero per questo processo?

Per le PMI italiane questa è una buona notizia. Non serve inseguire ogni novità. Serve costruire una matrice semplice: valore del processo, volume, sensibilità dei dati, qualità richiesta, costo per esecuzione. Da lì si decide se usare un modello frontier, un modello economico, un workflow locale o nessuna AI.

La prossima fase non premierà chi fa più esperimenti. Premierà chi misura, taglia gli sprechi e mette l'AI dove il ritorno è dimostrabile.