Ogni poche settimane, ormai, la scena si ripete con la precisione di una liturgia: un grande laboratorio annuncia un nuovo modello linguistico, le slide mostrano grafici con barre appena più lunghe di quelle della generazione precedente, e quasi tutta la stampa — generalista e non — trasforma quel mezzo punto percentuale in più su un benchmark accademico in un titolo a nove colonne. Poi arrivano gli analisti finanziari, poi i consulenti, poi i decisori aziendali che chiedono ai propri CIO: «dobbiamo passare al nuovo modello?». La risposta onesta, quasi mai pronunciata, è che nessuno lo sa davvero, perché gli strumenti con cui misuriamo questi modelli non sono stati pensati per rispondere alle domande del business.

Questo articolo racconta un percorso diverso: perché i benchmark tradizionali non bastano più, come si costruisce una valutazione business-oriented e che cosa succede quando si smette di guardare i decimi di punto e si iniziano a guardare scenari operativi, provenienza dei dati, costi e possibilità di dispiegamento in Private AI. Anticipiamo la conclusione: per la stragrande maggioranza dei compiti aziendali quotidiani, modelli da circa 30 miliardi di parametri bastano e avanzano; i giganti di frontiera servono solo per compiti particolari, in domini della conoscenza particolarmente profondi. E questo cambia tutto: nei budget, nella sicurezza, nella sovranità dei dati.

La liturgia dei decimi di punto

Ogni volta che esce un modello nuovo, la prima cosa che si guarda sono i benchmark: un +0,8 su una leaderboard, un +1,2 su un’altra, un Elo che sale di qualche punto su LMArena. Valori di pochi punti decimali in più che creano aspettative spesso eccessive, perché vengono letti come salti di qualità mentre sono, nel migliore dei casi, miglioramenti marginali su misure sempre meno significative.

I limiti strutturali di questa liturgia sono noti a chi la studia, ma raramente arrivano al grande pubblico:

• Saturazione: benchmark storici come MMLU sono ormai oltre il 90% per i modelli di frontiera; quando tutti prendono nove e mezzo, il voto non discrimina più.
• Contaminazione: i dataset di test finiscono, direttamente o indirettamente, nei dati di addestramento; il modello non sta ragionando, sta ricordando.
• Specificità: un benchmark di coding non dice nulla sulla capacità di leggere un contratto o gestire una conversazione.
• Bias: molti benchmark sono anglocentrici e raccontano poco di come un modello si comporterà con l’italiano giuridico di una delibera o di un capitolato.

Che cosa significa, per il direttore operations di una media impresa italiana, un +1,2% su un benchmark di matematica competitiva? Nulla, se non viene tradotto in ciò che quel modello dovrà fare il lunedì mattina: leggere documenti, eseguire procedure, rispondere a clienti. Un decimo di punto su una leaderboard non è un punto di margine operativo.

Costi in crescita e il rischio bolla

C’è una seconda dinamica, meno visibile ma più conseguente: i costi dei modelli crescono a ogni nuova uscita. Crescono i costi di addestramento — calcolo, energia, data center — e crescono le ambizioni finanziarie di chi li produce. I modelli di frontiera hanno l’esigenza strutturale di giustificare valutazioni e round di finanziamento sempre più grandi: ogni annuncio di prodotto è anche, e talvolta soprattutto, un messaggio agli investitori.

Già nel giugno 2024 Jim Covello, Head of Global Equity Research di Goldman Sachs, si chiedeva se la spesa in AI generativa non fosse «troppa, per troppo poco beneficio»^[1]. Nel 2025 il progetto NANDA del MIT ha stimato che il 95% dei progetti pilota di AI generativa nelle imprese non produce ritorni misurabili sul conto economico^[2]. E Daron Acemoglu, Institute Professor al MIT, ha argomentato che l’impatto macroeconomico dell’AI sarà, nel breve periodo, molto più modesto di quanto la narrativa suggerisca^[3].

Siamo di fronte a una bolla? Non spetta a questo articolo dirlo, e la storia della tecnologia insegna che le bolle finanziarie possono convivere con innovazioni reali — la ferrovia resta anche quando chi l’ha finanziata fallisce. Ma quando la narrativa precede i ricavi, la prudenza è d’obbligo: un’impresa sana non costruisce il proprio bilancio AI sull’ipotesi che i prezzi dei modelli di frontiera scenderanno per generosità altrui. Li misura, li confronta e decide. Torneremo su questo punto nelle conclusioni, perché il rapporto tra costi, debito e concorrenza è oggi il vero nodo strategico del settore.

Il marketing delle prodezze: vulnerabilità e fughe dalla sandbox

Ultimamente i modelli di frontiera — ma non solo — hanno cominciato a produrre un genere nuovo di iniziative di marketing: il modello che «ha trovato vulnerabilità di cybersecurity che nessuno aveva mai scoperto», il modello che «è fuggito dalla sandbox e ha bucato un altro sito». Storie affascinanti, costruite per essere raccontate. E proprio qui sta il problema.

Chi lavora nell’ingegneria della sicurezza lo sa: da una sandbox fatta bene non si scappa, perché non esiste nulla da cui scappare. Un ambiente isolato correttamente — namespace del kernel, seccomp, capability ridotte all’osso, nessuna credenziale montata, rete segregata, filesystem effimero — non offre appigli: non c’è una rete verso cui uscire, non ci sono privilegi da “escalare”, non c’è un host da raggiungere. E un modello linguistico, per sua natura, produce testo: sono gli strumenti che gli mettiamo in mano ad agire sul mondo.

Se un agente «esce», le ipotesi sul tavolo sono due, e nessuna delle due è un prodigio: o l’isolamento era configurato male — errore umano di engineering, non intelligenza emergente — oppure il perimetro era volutamente permissivo, e allora si tratta di una demo, non di una scoperta. Allo stesso modo, un modello che individua bug nel codice che gli viene sottoposto è uno strumento prezioso di analisi assistita; raccontarlo come un hacker autonomo che «buca siti» è un’altra cosa.

Il grande pubblico non ha gli strumenti per operare queste distinzioni, e il risultato è una doppia distorsione: aspettative irrazionali da un lato, paure irrazionali dall’altro, con decisioni di procurement e di policy prese sull’onda di boutade. Il rischio non è il modello che evade dalla sandbox: è il racconto che evade dai dati.

Il mercato opaco dei benchmark: mode, autodichiarazioni e confronti mancati

C’è un terzo problema, forse il più grave, ed è strutturale: il mercato della misurazione è opaco. Di benchmark ne esistono a centinaia, ma sono i vendor a scegliere quali pubblicare. Ogni provider decide autonomamente su quali test misurare il proprio modello, con quali versioni e con quali metriche, e naturalmente pubblica i numeri che lo favoriscono. Il risultato è un patchwork di fonti in cui costruire un confronto omogeneo è quasi impossibile.

A questo si aggiunge la moda del momento: in questo periodo l’applicazione trainante dell’AI è il coding, e infatti i benchmark di coding — SWE-bench e le sue evoluzioni, LiveCodeBench — vengono diffusi e aggiornati con regolarità, mentre quelli utili al RAG, all’instruction following o alla conversazione multilingue restano indietro, quando non vengono abbandonati. Nei fatti, non sappiamo se i nuovi modelli si stanno specializzando su alcuni ambiti abbandonando gli altri: un modello può essere fortissimo sul codice e inaffidabile nel recupero documentale o nella chat, e i numeri pubblicati semplicemente non ce lo dicono, perché quei numeri nessuno li misura più.

E non basta: non esiste un’organizzazione super partes che valuti gli LLM con una metodologia uniforme su tutti i modelli e tutti i test. Gran parte dei valori in circolazione sono autodichiarazioni dei produttori, e la tentazione che qualche vendor possa «vendersi» valori non veritieri — versioni ad hoc del test, prompt ottimizzati, selezione dei run migliori — è tutt’altro che teorica. Infine, i modelli chiusi non sempre accettano il confronto con quelli aperti: meglio non comparire nella stessa classifica, se il confronto rischia di essere scomodo. I benchmark, nati come strumenti scientifici, sono diventati meccanismi di marketing, e districarsi è sempre più difficile. Un benchmark scelto da chi vende il modello non è una misura: è una brochure.

Perché serve una valutazione business-oriented

Come creare, allora, un sistema di valutazione che sia onesto e funzionale al business? La domanda ci ha guidato per mesi, e la risposta che ci siamo dati poggia su alcuni principi non negoziabili:

• Misurare ciò che il business usa davvero, non ciò che fa notizia: le aziende chiedono all’AI di leggere documenti, eseguire procedure e conversare, non di risolvere problemi di matematica competitiva.
• Confrontare su gruppi di valori: i modelli vanno valutati non genericamente su «il benchmark» di turno, ma su insiemi di misure legati alle operazioni in cui saranno effettivamente coinvolti.
• Valorizzare anche i modelli meno famosi: molti modelli open-weight non hanno uffici marketing, ma hanno numeri eccellenti; un indice onesto deve saperli vedere.
• Dichiarare la provenienza di ogni dato: live, vendor-reported o stimato — perché un numero senza fonte è un’opinione travestita da fatto.
• Nessuna scatola nera: pesi e soglie espliciti, documentati e modificabili da chi li usa.
• Il costo è parte della qualità, così come la possibilità di dispiegare il modello in Private AI: un indice che ignora il dispiegamento ignora metà della decisione.
• Riproducibilità: dati pubblici, codice aperto, risultati ricalcolabili da chiunque.

Su questi principi abbiamo costruito un benchmark composito: 25 modelli, tre scenari operativi che coprono ciò che le organizzazioni chiedono ogni giorno all’intelligenza artificiale, e una politica dei dati che dice esplicitamente da dove viene ogni numero.

Il framework: tre scenari operativi

Il cuore del framework è una scomposizione semplice: le aziende oggi usano i modelli linguistici sostanzialmente in tre modi, che chiamiamo scenari operativi. Ogni scenario pesa un terzo dell’indice finale (33,3%), perché nessuna delle tre funzioni è, in astratto, più importante delle altre: lo sono tutte, in misura diversa a seconda dell’organizzazione.

RAG & Documenti: il modello come lettore

Il primo scenario misura la capacità del modello di comprendere, recuperare e sintetizzare informazioni da contesti documentali lunghi e complessi. È il caso d’uso forse più diffuso: knowledge base aziendali, analisi contrattuale e legale, ricerca nella documentazione tecnica, sintesi di report multipli, compliance e audit documentale. Qui il modello lavora come un lettore infaticabile che deve trovare l’ago nel pagliaio e restituirlo con contesto.

Agentic AI: il modello come esecutore

Il secondo scenario misura la capacità di pianificare ed eseguire compiti complessi in più passi, usando strumenti esterni, API e ambienti computazionali: automazione di workflow, sviluppo software assistito, analisi dati con esecuzione di codice, orchestrazione multi-agente. Qui il modello non legge: agisce, e ogni azione sbagliata ha un costo reale.

Assistenza & Chat: il modello come conversatore

Il terzo scenario misura la qualità dell’interazione conversazionale e la capacità di ragionare su problemi specialistici: coerenza nei dialoghi a più turni, conoscenza, capacità multilingue. Customer service, assistenti virtuali interni, supporto tecnico, chatbot per aziende che operano su più mercati. Qui il modello è il volto dell’organizzazione verso persone in carne e ossa.

La scomposizione non è un vezzo accademico: un modello può essere eccellente in uno scenario e mediocre in un altro. Misurare gli scenari separatamente è già, di per sé, una forma di onestà.

I benchmark scelti, uno per uno

Una premessa di trasparenza: la selezione è cambiata nel tempo, e vale la pena spiegare perché. I benchmark scelti nelle prime versioni — RULER, MMLU-Pro, NeedleBench, GAIA, BFCL e altri — erano ampiamente citati nei report dei vendor, ma con l’uscita dei modelli più recenti la loro copertura sulle leaderboard indipendenti è diventata frammentaria: molti valori non venivano più pubblicati o erano disponibili solo per un sottoinsieme di modelli. Abbiamo quindi dovuto rivedere la lista, scegliendo benchmark più recenti e meglio coperti, in particolare orientati a coding, agenti e reasoning. È una scelta dettata dalla realtà dei dati disponibili, non dalla preferenza: e questo, come visto in precedenza, è esso stesso un sintomo del problema.

Per RAG & Documenti

• Humanity’s Last Exam: domande ai confini della conoscenza umana, curate e validate da esperti di dominio. Misura conoscenza specialistica avanzata e ragionamento: per questo lo abbiamo spostato in questo scenario, dove la comprensione profonda dei documenti conta più della velocità di recupero.
• MMMU-Pro: evoluzione rafforzata del benchmark multidisciplinare multimodale, con dieci opzioni di risposta e filtri contro le scorciatoie. Discrimina ancora, dove i predecessori sono saturi.
• MRCR-v2-8-needle: la versione moderna del «needle-in-haystack»: otto informazioni nascoste in contesti lunghissimi, da ritrovare e distinguere senza confonderle. È la prova più vicina al lavoro quotidiano su fascicoli e documentazione tecnica.
• IFEval (Google): instruction following con vincoli verificabili — «rispondi in meno di 200 parole», «usa solo elenchi puntati», «includi queste parole chiave». Sembra banale; non lo è, ed è esattamente ciò che serve perché un report generato sia utilizzabile senza rilavorazioni.
• LiveBench: un benchmark «vivo», con domande rinnovate periodicamente proprio per sfuggire alla contaminazione dei dati di addestramento. Una risposta concreta al problema dei dataset memorizzati.

Per Agentic AI

• SWE-bench Pro: risoluzione di issue reali su repository reali, in una versione rafforzata e meno contaminata dell’originale. È oggi il riferimento per il coding agentico.
• Terminal-Bench 2.1: misura la capacità di operare in ambienti reali — shell, git, python — eseguendo comandi e portando a termine workflow agentici. È la prova del nove: non basta pianificare, bisogna eseguire.
• MCP-Atlas: valuta la capacità di orchestrare strumenti esposti tramite Model Context Protocol su compiti reali a più passi: è il banco di prova dell’integrazione con i sistemi aziendali.
• OSWorld-Verified: agenti che operano su sistemi operativi veri — file, applicazioni, browser — con verifica dello stato finale. La differenza tra «dire» e «fare».

Per Assistenza & Chat

• GPQA Diamond: domande scientifiche di livello dottorale, progettate per resistere alla ricerca su Google. Misura il ragionamento specialistico che serve nel supporto tecnico avanzato.
• LiveCodeBench: coding su problemi raccolti in continuazione dalle competizioni, con finestre temporali che riducono il rischio di contaminazione.
• AutomationBench: misura la capacità di automatizzare compiti lavorativi reali end-to-end, il banco di prova più vicino all’ufficio e più lontano dalla gara di matematica.
• LMArena: classifica Elo costruita su preferenze umane reali. È il giudizio del pubblico, con i suoi pregi e i suoi bias, ma resta un segnale difficile da falsificare.

Resta nel foglio dati, ma fuori dall’indice composito, BrowseComp, che misura la capacità di ricerca web ostinata: utile, ma troppo legato a funzionalità di browsing che non tutti i modelli espongono in modo comparabile. E anche con la nuova selezione la copertura non è completa: nessuna entità indipendente esegue tutti i benchmark su tutti i modelli principali. Il che ci porta al capitolo successivo.

La politica dei dati: live, vendor-reported e family-min

Se i dati mancano, la domanda diventa: come si riempiono le celle vuote senza barare? Ci siamo dati una politica esplicita, con una catena di priorità documentata nel foglio Excel, dove il colore della cella dichiara la provenienza del numero:

Tabella 1 — La catena di priorità nel popolamento dei dati. Il colore della cella dichiara sempre la provenienza del numero.

Il family-min fallback merita una spiegazione. La tentazione, di fronte a un dato mancante, sarebbe lasciare zero: ma un modello forte nel coding e mai testato sul RAG non ha «zero in RAG», ha semplicemente un dato assente, e lo zero falserebbe la media composita verso il basso. Prendiamo allora il valore più basso tra i modelli dello stesso vendor e della stessa famiglia — per esempio, per Qwen3.8-flash il minimo tra Qwen3.8 27B e Qwen3.6 27B — perché modelli con nomi simili e dello stesso produttore tendono a condividere architettura e capacità. È una scelta deliberatamente conservativa: il minimo di famiglia evita di sovrastimare chi non si è sottoposto al test. Con due eccezioni dichiarate: Claude Opus 5 è escluso dal family-min e mantiene gli zeri dove il dato manca, e i modelli con famiglia di un solo membro non possono beneficiarne.

Nel foglio Dashboard una colonna Provenienza riassume per ogni modello la fonte dominante — Live, Vendor-reported, Family-min, Not found o Misto — così che chi legge la classifica veda subito quanta parte di quel punteggio è misurata e quanta è stimata. I costi vengono da OpenRouter, i benchmark live da llm-stats.com, e una cache SQLite memorizza i dati grezzi — non i valori family-min — così che le stime vengano ricalcolate automaticamente a ogni aggiornamento. La trasparenza non è un optional del metodo: è il metodo.

La logica dei pesi

I pesi sono calibrati su tre criteri: l’importanza business di ogni capacità, la difficoltà di saturazione — i benchmark più difficili pesano di più perché discriminano ancora — e la ridondanza informativa, per evitare di contare due volte la stessa capacità. I pesi correnti sono espliciti, documentati e modificabili nel foglio Dati Benchmark dello strumento: la struttura assegna pesi uniformi all’interno degli scenari RAG e Chat, dove nessun benchmark è dominante e la ridondanza è minima, e premia nello scenario Agentic le capacità davvero discriminanti — pianificazione ed esecuzione reale — perché un agente che pianifica bene ma sbaglia l’esecuzione è inutile, e viceversa. Chi non condivide le nostre ponderazioni può cambiarle e ricalcolare: è esattamente il punto dell’apertura.

Dai punteggi alle fasce: come nasce l’indice generale

Il calcolo è volutamente semplice, perché la trasparenza non tollera alchimie. Per ogni scenario, il punteggio è la somma pesata dei benchmark che lo compongono:

Score_scenario = Σ (benchmark_i × peso_i)

L’indice generale è la media aritmetica dei tre scenari:

Overall = (Score_RAG + Score_Agentic + Score_Chat) / 3

Ma un numero grezzo, diciamo 77,5, soffre di tre difetti: è astratto — che cosa significa 77,5? — non è azionabile — che decisione prendo? — e non è comunicabile — come lo spiego a un CFO? Per questo l’indice (0-100) viene mappato su sei fasce di competenza professionale, con doppia nomenclatura consulenziale e aziendale:

Tabella 2 — Le sei fasce di competenza professionale. La Fascia F5 è lo sweet spot del rapporto costo-efficacia.

Dire a un amministratore delegato «questo modello ha totalizzato 68,3» non produce decisioni; dirgli «questo modello è un Associate Partner a un quindicesimo del costo di un altro Associate Partner», sì. La nomenclatura professionale non è un trucco retorico: è un ponte tra la misura tecnica e il linguaggio con cui le organizzazioni ragionano su ruoli, responsabilità e costo del lavoro.

Oltre la qualità: costo e Private AI

La Dashboard non si ferma alla qualità: per ogni modello riporta il costo in input e in output per milione di token e il tipo — CLOSED, PROP o OPEN. Non è un dettaglio tecnico: solo i modelli open-weight possono essere dispiegati in Private AI, su infrastruttura propria o dedicata. Un indice che ignora il dispiegamento ignora metà della decisione d’acquisto.

Tabella 3 — Qualità, costo e dispiegabilità a confronto (dati agosto 2026, soggetti a variazione: rilanciare lo script per valori aggiornati).

La tabella dice più di molte analisi: tre modelli nella stessa fascia professionale, con costi che differiscono di un ordine di grandezza, e solo due su tre dispiegabili dentro il perimetro aziendale. Ma avere i numeri non basta: bisogna sapere che cosa farne. È qui che entra in gioco l’economia — e una teoria del 1956 che sembra scritta apposta per gli LLM.

Lo sweet spot dei 30 miliardi di parametri

La conclusione empirica del lavoro è netta: modelli da circa 30 miliardi di parametri svolgono egregiamente le funzioni quotidiane d’azienda, offrendo grandi prestazioni a una frazione del costo. Nei nostri dati, modelli open-weight tra i 27 e i 70 miliardi di parametri raggiungono la Fascia F5 — Associate Partner, autonomia stimata 85-95% — a un costo da 10 a 50 volte inferiore a quello dei modelli di frontiera. I quali restano necessari, ma per quello che sono: strumenti per compiti particolari ed esigenze su ambiti particolarmente profondi dei domini della conoscenza — ricerca di frontiera, ragionamento matematico avanzato, scenari ad altissimo rischio.

I tre modelli della tabella precedente lo mostrano con chiarezza: tutti e tre in Fascia F5, con indici di 81,1, 77,6 e 68,3. Se il requisito operativo è F5, il vantaggio tecnico del primo sul terzo esiste ma va misurato contro il costo. Quanto vale, in euro, quel punto di capacità in più? Per rispondere serve uno strumento decisionale, e lo andiamo a prendere in prestito dall’economia del benessere.

Infine su una scala da 0 a 100, il valore 81,1 e il valore 68,3 differiscono di 13 punti, comincia a diventare poco significativo.

Il Second Best: dal benchmark alla decisione economica

Nel 1956 due economisti, Richard Lipsey e Kelvin Lancaster, pubblicarono su The Review of Economic Studies un articolo che rivoluzionò l’economia del benessere: The General Theory of Second Best^[4]. Il teorema afferma qualcosa di profondamente controintuitivo: se una delle condizioni ottimali non può essere soddisfatta, non è detto che convenga soddisfare tutte le altre. In altre parole, quando esiste un vincolo — un monopolio, un’imposta, un budget finito — il second best non è una versione «quasi» del first best: è una soluzione completamente diversa, che può richiedere di rinunciare deliberatamente all’eccellenza tecnica.

Nel nostro caso il vincolo non è tecnologico, è economico: nessuna azienda ha budget infinito. Il first best tecnico esiste — è il modello con l’indice più alto — ma il suo costo marginale può essere proibitivo. La domanda giusta non è «qual è il modello migliore?», ma «quale combinazione di modello, costo e rischio massimizza il valore sotto il vincolo di budget?»

Il caso: 5 milioni di token al giorno

Prendiamo un’azienda di 2.000 dipendenti con 500 utenti attivi al giorno e 10.000 token di consumo medio a testa: 5 milioni di token al giorno, più 15 milioni di input, con un carico tipico — chat, RAG su documenti interni, report — senza coding agentico intensivo. Per esempio mettiamo sul banco, tre modelli tutti in Fascia F5: Claude Opus 4.8 (indice 81,1) via API, GLM-5.2 (77,6) via API, e Qwen 3.8-27B (68,3) self-hosted su una GPU workstation. I numeri sul campo:

Tabella 4 — Tre modelli F5 a confronto su 5 milioni di token/giorno. L’output effettivo sconta errori, rigenerazioni e fallimenti in proporzione all’indice di capacità.

Il modello C perde quasi il 16% di output utile rispetto ad A: non è trascurabile, ma va messo in relazione con il costo — 3,60 dollari per milione di token effettivo contro 40. Il cuore della teoria di Lipsey e Lancaster è però l’analisi marginale: non si confrontano i totali, si chiede quanto costa il passaggio da un livello all’altro. Il salto da C a B costa 48,53 dollari per ogni milione di token aggiuntivi generati correttamente; il salto da B ad A ne costa 727,58. Per compiti aziendali standard, quest’ultima soglia è semplicemente fuori gioco: A è la scelta giusta solo quando il valore di un singolo token è astronomico — una clausola contrattuale, una diagnosi — dove un errore costa più di 700 dollari per milione di token.

E il volume cambia tutto: C ha un costo quasi fisso che si diluisce, B ha un costo puramente variabile. Il punto di pareggio è a circa 1,67 milioni di token al giorno: sotto, conviene B; sopra, conviene C, e a 5 milioni siamo ben oltre la soglia. Infine il rischio: A e B sono noleggi, i cui prezzi sono variabili controllate dal vendor; C è un asset, il cui costo è prevedibile. Su tre anni, il costo atteso di B — tenendo conto di possibili aumenti di prezzo o dismissioni — è stimato in circa 62.000 dollari, contro circa 11.600 di C, rivendita della GPU inclusa.

La mappa decisionale che ne emerge è semplice: A è il first best tecnico ma economicamente irrilevante per i carichi standard; B è il Second Best nel senso di Lipsey e Lancaster, da usare sotto la soglia di volume o per i compiti dove il degrado di C è inaccettabile; C è il best economico e il best dal punto di vista del rischio oltre la soglia. E se domani il volume raddoppia, o esce un modello nuovo, la mappa si ridisegna: ma il framework resta valido, perché il Second Best non è una scelta — è un modo di pensare. Il benchmark, in definitiva, serve esattamente a questo: separare la capacità sufficiente dalla capacità superflua.

Private AI: la strada per sicurezza e budget

C’è un’ultima implicazione, la più importante. I modelli diventano sempre più piccoli e sempre più competitivi: la densità di intelligenza per parametro cresce a ogni generazione, e ciò che ieri richiedeva un data center oggi gira su una workstation ben dimensionata. Per l’uso quotidiano del business, la strada è quindi sempre più la Private AI: il modello dentro il perimetro, i dati che non escono, i costi che diventano prevedibili.

Le ragioni sono due, e si rinforzano a vicenda. La prima è la sicurezza: nessun dato aziendale verso terze parti, nessun rischio che i propri documenti alimentino l’addestramento altrui, superficie di esposizione ridotta, piena aderenza a GDPR, NIS2 e ai requisiti di documentazione dell’AI Act^[5]. La seconda, e per molti decisori decisiva, è il budget: il costo per token diventa costo hardware ammortizzato, svincolato dalle politiche di pricing di un fornitore che domani potrebbe aumentare i prezzi del 30%. La Private AI non è una scelta nostalgica né difensiva: è una scelta di governance, di bilancio e di sovranità.

Altre considerazioni di business

Uno strumento di misura serio produce benefici che vanno oltre la scelta del modello. Ne elenchiamo quattro, perché spesso sono quelli che convincono il consiglio di amministrazione.

Vendor lock-in e potere negoziale

Chi si lega a un solo provider espone l’azienda ad aumenti unilaterali, cambi di policy, indisponibilità del servizio. Confrontare modelli open e closed su dati oggettivi abilita strategie multi-vendor e rovescia il tavolo negoziale: quando sai che un modello open da 27B vale la stessa fascia del tuo fornitore a una frazione del prezzo, la trattativa non è più sullo sconto, ma sulla sopravvivenza del contratto.

Compliance, audit e documentazione

L’AI Act richiede di documentare capacità e limiti dei sistemi impiegati, specie negli usi ad alto rischio. Un benchmark riproducibile, con la provenienza dichiarata di ogni dato, fornisce esattamente questo: una motivazione oggettiva e archiviabile della scelta, utile in audit e in sede di valutazione del rischio.

Routing: il modello giusto per il compito giusto

L’architettura matura non usa un modello, ma un mix: i compiti semplici a modelli piccoli, quelli complessi ai 27-70B, solo il 5% circa di compiti critici ai frontier. Nei nostri scenari il risparmio complessivo si colloca tra il 70 e l’85%. La domanda non è «quale modello compriamo», ma «quale portafoglio di modelli governiamo».

Una roadmap graduale

Le fasce suggeriscono anche un percorso: si parte con un proof of concept su compiti da F2-F3 con budget minimi, si espande a RAG e chat con modelli F4-F5, si arriva all’agentic con un mix F5+F6. Ogni fase si finanzia con i risparmi della precedente: l’adozione dell’AI smette di essere un salto di fede e diventa un piano industriale.

Conclusioni: misurare per decidere

Torniamo alla liturgia iniziale. Non possiamo impedire ai laboratori di celebrare i propri decimi di punto, né ai marketing department di raccontare fughe dalla sandbox che una sandbox ben fatta non consente, né ai vendor di pubblicare solo i benchmark che li favoriscono. Possiamo però smettere di prendere decisioni sulla base di quella liturgia. Dobbiamo smettere di comprare modelli e iniziare a comprare capacità misurate: capacità di leggere i nostri documenti, eseguire le nostre procedure, parlare con i nostri clienti — al costo giusto, nel perimetro giusto.

Tre evidenze finali. La prima: i modelli hanno caratteristiche profondamente diverse, e l’omologazione delle classifiche è un’illusione — esistono specialisti e generalisti, modelli forti nel coding e deboli nel RAG, e solo una misura per scenari la vede. La seconda: i costi stanno diventando il vero collo di bottiglia della diffusione dell’AI, non la capacità tecnica; trovare modelli che ottimizzino costi e prestazioni è ormai la condizione perché l’AI esca dai piloti ed entri nei processi. La terza è un nodo strategico che riguarda l’intero settore: le aziende fortemente indebitate che producono modelli di frontiera non possono ridurre di molto i prezzi, perché devono dimostrare agli investitori che l’investimento rende; ma se non li riducono, favoriscono inevitabilmente i concorrenti — i modelli aperti, i piccoli, i self-hosted. È una trappola da cui si esce solo con volumi enormi o con costi di produzione che crollano: e nel frattempo, per le imprese che usano l’AI, la convenienza dei modelli «abbastanza bravi» al prezzo giusto non fa che crescere.

Gli strumenti per decidere esistono, e li abbiamo voluti aperti: un framework documentato, uno script che chiunque può eseguire, pesi, soglie e fonti che chiunque può contestare e migliorare. L’invito è a usarli: rilanciare il benchmark ogni trimestre, validarlo sui propri casi d’uso, adattare i pesi alle proprie priorità, portarlo in sala negoziale con i fornitori. Perché la maturità digitale di un’organizzazione non si misura dal modello che acquista, ma dalla capacità di misurare ciò che acquista. Il resto è marketing — e il marketing, come abbiamo visto, non scappa dalle sandbox: ci entra da solo, se glielo permettiamo.

Il link al repository github è: https://github.com/intelligentiae/llm-business-benchmark

il modello è aperto a suggerimenti, miglioramenti e correzioni ed è auspicata la condivisione.

Riferimenti e fonti

Benchmark

• Humanity’s Last Exam
• MMMU-Pro
• IFEval — Google Research
• LiveBench
• SWE-bench Pro
• Terminal-Bench 2.1
• OSWorld-Verified
• GPQA Diamond
• LiveCodeBench
• LMArena

Fonti dati e strumenti

• llm-stats.com — benchmark live
• OpenRouter — prezzi dei modelli
• Artificial Analysis
• LM Council

^[1] Goldman Sachs, «Gen AI: Too Much Spend, Too Little Benefit?», Top of Mind, 25 giugno 2024; intervista a Jim Covello, Head of Global Equity Research.

^[2] MIT Project NANDA, «The GenAI Divide: State of AI in Business 2025», luglio 2025: il 95% dei progetti pilota di AI generativa non produce ritorni misurabili sul conto economico.

^[3] Daron Acemoglu, Institute Professor al Massachusetts Institute of Technology, «The Simple Macroeconomics of AI», Economic Policy, 39(119), 2024.

^[4] R. G. Lipsey e K. J. Lancaster, «The General Theory of Second Best», The Review of Economic Studies, 24(1), 1956, pp. 11-32.

^[5] Regolamento (UE) 2024/1689 del Parlamento europeo e del Consiglio, che stabilisce regole armonizzate in materia di intelligenza artificiale (AI Act).