C’è un momento, nella storia del computing, che si ripete sempre uguale a sé stesso. Prima tutto è centralizzato, cloud, costoso, presidiato da pochi. Poi arriva un salto tecnologico che permette di fare in locale ciò che prima richiedeva un mainframe, e il pendolo torna indietro. Negli anni Settanta il calcolo viveva nei centri di elaborazione dati delle grandi aziende. Con il PC, l’intelligenza si è spostata sulla scrivania. Con il cloud, buona parte era tornata a vivere altrove, in data center che non vediamo e non controlliamo. Oggi si sta pensando, nelle PA locali e nel post PNRR, a un ritorno “on premise” per motivi di costi e sovranità del dato.
Oggi, con l’intelligenza artificiale generativa, il pendolo sta per fare un altro giro completo, e i numeri che lo raccontano sono più chiari di quanto si possa immaginare.
Uno studio pubblicato a novembre 2025 da Stanford University e Together AI ha misurato, con un metodo tutt’altro che aneddotico, quanta parte del traffico AI conversazionale potrebbe essere gestita da modelli locali invece che da modelli frontier in cloud. Il risultato: l’88,7% delle query di chat e reasoning single-turn può essere risolto correttamente da modelli piccoli, eseguiti su hardware di fascia consumer, con un’accuratezza comparabile a quella dei modelli di frontiera.
Un secondo lavoro, firmato Nvidia insieme al Georgia Institute of Technology, arriva a una conclusione quasi identica per gli agenti AI: tra l’80% e il 90% degli step di un loop agentico può restare in locale su modelli da 3 a 9 miliardi di parametri, più veloci, più economici e più privati di un modello frontier richiamato in cloud. Novanta e dieci, dunque, non è uno slogan. È l’ordine di grandezza che due gruppi di ricerca indipendenti, con metodologie diverse, misurano sulla stessa frontiera.
Indice degli argomenti:
Il pendolo del computing torna verso il locale
Per capire perché questo dato conta, serve fare un passo indietro. Negli ultimi tre anni abbiamo costruito un’infrastruttura AI quasi interamente centralizzata: ogni prompt, dalla mail che riscriviamo al codice che debugghiamo, viaggia verso un data center, passa attraverso un modello enorme allenato su scala planetaria, e torna indietro. Ha senso, se l’unico modo per ottenere una risposta intelligente è chiamare un modello da centinaia di miliardi di parametri. Ma è un’architettura che nasconde uno spreco strutturale: usiamo un modello capace di ragionare su fisica avanzata per riformulare una mail, la Formula 1 per consegnare una pizza.
Quello che è cambiato tra il 2023 e il 2025 è la capacità dei modelli piccoli.
Cos’è, davvero, l’intelligent routing
Il termine suona tecnico ma il concetto è semplice: l‘intelligent routing è il meccanismo, oggi in gran parte manuale, con cui decidiamo quale modello merita un determinato task. Quando apriamo la chat di un assistente AI e le chiediamo di riassumere un’email, stiamo usando un fucile a pompa per spegnere una candela: il modello frontier in cloud viene mobilitato per un compito che un modello locale da pochi miliardi di parametri gestirebbe altrettanto bene, a costo quasi zero e senza far uscire una riga di testo dal nostro dispositivo.
Oggi questa decisione, quale task mandare a quale modello, è delegata quasi interamente a noi umani, e la prendiamo per abitudine più che per calcolo: apriamo sempre la stessa app, chiamiamo sempre lo stesso modello, indipendentemente dalla complessità reale della richiesta. È come se, prima di ogni telefonata, dovessimo scegliere manualmente se serve un centralinista, un tecnico specializzato o il direttore generale. Nessuna azienda funziona così: esiste uno smistamento, un centralino, un livello di triage che instrada la richiesta verso chi è davvero necessario. Nell’AI, quel centralino ancora non esiste in forma matura. Il routing tra modelli locali e frontier è, in sostanza, il tentativo di costruirlo.
I numeri del 90 e 10
Vale la pena essere precisi, perché il dato del 90/10 è reale ma non va sovraesteso. Lo studio Stanford IPW lavora su query single-turn di chat e reasoning: la copertura locale supera il 90% sui compiti creativi, come scrittura e arti, ma scende al 68% sui domini tecnici, come architettura e ingegneria. Sui task di reasoning puro il miglior modello locale copre l’88,9% delle query di chat generica ma solo il 64,9% di quelle di reasoning strutturato, un divario di 24 punti percentuali che dice qualcosa di importante: il locale funziona meglio dove il compito è ripetitivo o conversazionale, meno dove serve ragionamento originale su più passaggi.
Il lavoro Nvidia, sul fronte degli agenti, conferma la stessa geometria da un’altra angolazione: l’80-90% degli step di un loop agentico, quali il parsing di un input, la chiamata a uno strumento, la formattazione di un output strutturato, non richiede affatto un modello generalista di frontiera. Servono affidabilità, velocità e aderenza a un formato, non brillantezza. Un modello da 7 miliardi di parametri costa da 10 a 30 volte meno, in latenza, energia e calcolo, di un modello da 70-175 miliardi. Il restante 10-20% degli step, quelli che richiedono comprensione ampia, contesto lunghissimo o ragionamento davvero nuovo, resta terreno dei modelli frontier.
Due studi, due metodologie, due popolazioni di task diverse, la stessa proporzione. Non è una coincidenza statistica isolata: è la fotografia di un’architettura che si sta ridisegnando attorno a un principio semplice: usare l’intelligenza minima sufficiente, non quella massima disponibile.
Privacy: dove va, davvero, il nostro prompt
Ogni volta che scriviamo un prompt a un modello in cloud, quel testo lascia il nostro dispositivo, attraversa una rete, viene elaborato su un server che non controlliamo, secondo termini di servizio che quasi nessuno legge fino in fondo. Per una domanda generica non cambia molto. Ma il 90% del nostro utilizzo quotidiano dell’AI non è fatto solo di domande generiche: contiene bozze di contratti, dati clinici, strategie aziendali riservate, informazioni su persone terze che non hanno acconsentito a nulla.
Con un modello locale, la domanda “dove va il mio prompt” ha una risposta univoca: da nessuna parte, resta sul dispositivo. Non ci sono termini di servizio di terzi da interpretare, non c’è incertezza sull’uso dei dati per addestramento futuro, non c’è un log su un server altrui che potrebbe essere oggetto di una richiesta legale, di una violazione, di un cambio di policy aziendale deciso altrove.
Il routing intelligente, in questa prospettiva, non è solo un’ottimizzazione di costo: è uno strumento di minimizzazione dei dati by design. Se il 90% dei task può restare in locale, il 90% dei dati sensibili non deve mai porsi il problema di attraversare un confine giurisdizionale o contrattuale. Solo il 10% residuo, quello che davvero richiede la potenza di un modello frontier, comporta una scelta consapevole su cosa condividere e con chi.
Cybersicurezza: meno superficie, ma un nuovo punto critico
Lo stesso ragionamento vale, con qualche complicazione in più, sul fronte della sicurezza informatica. Meno dati in transito significa meno superficie d’attacco: meno chiamate API, meno chiavi da custodire e ruotare, meno fornitori terzi nella catena di responsabilità, meno endpoint che un attaccante può tentare di compromettere per intercettare traffico. Un’architettura che tiene il 90% dell’elaborazione dentro il perimetro dell’organizzazione riduce, per definizione, il numero di punti in cui qualcosa può andare storto fuori dal proprio controllo.
Ma sarebbe ingenuo raccontarla solo come una vittoria. Il router stesso, il livello che decide quale task va in locale e quale invece merita l’escalation al cloud, diventa un componente critico e, per certi versi, più delicato dei singoli modelli che orchestra. Un router compromesso, o semplicemente mal configurato, è un canale di esfiltrazione perfetto: instrada verso l’esterno esattamente i dati più sensibili, quelli che un attaccante cercherebbe, mascherando l’operazione da normale traffico di servizio.
Più il routing diventa automatico e invisibile, più la sua integrità va trattata come si tratta quella di un firewall o di un sistema di autenticazione, non come un dettaglio implementativo. Delegare la decisione “cosa esce e cosa resta dentro” a un algoritmo significa spostare lì anche la responsabilità della sua verificabilità.
“Sufficientemente buono” batte “il più potente disponibile”
Il secondo cambio di paradigma riguarda di quali modelli locali stiamo parlando. Non serve l’ultimo modello uscito, e spesso non serve nemmeno un modello proprietario. La famiglia di modelli open, o open-weight, quali Gemma, Qwen, Mistral, Phi, GPT-OSS, sta chiudendo il divario con i modelli di frontiera proprio sui task ripetitivi e strutturati che compongono la maggioranza del nostro utilizzo reale. Il migliore modello locale nello studio Stanford, un modello open da 120 miliardi di parametri attivi ma eseguibile su hardware consumer di fascia alta, risponde correttamente a quasi tre quarti delle query testate da solo, e la copertura sale ulteriormente combinando più modelli locali specializzati in un piccolo ensemble.
Questo capovolge un’assunzione diffusa: non è vero che dobbiamo rincorrere sempre l’ultimo modello frontier per ottenere valore dall’AI. Per la maggior parte dei task quotidiani, un modello open di generazione precedente, eseguito localmente, è sufficiente, ed è anche misurabilmente più economico. Il risparmio non è aneddotico: il routing ibrido locale-cloud taglia energia, calcolo e costo dal 60 all’80% rispetto a un’infrastruttura interamente cloud, secondo lo studio Stanford, mentre la letteratura sul routing tra modelli in generale, includendo qui anche configurazioni cloud-cloud tra modelli economici e modelli di punta, riporta riduzioni di spesa nell’ordine del 40-85% a seconda della composizione del traffico.
Il dato più interessante, per chi deve progettare questi sistemi, è un altro: la ricerca Stanford mostra che il routing non deve essere perfetto per generare valore. Un router accurato all’80%, quindi tutt’altro che infallibile, cattura comunque circa l’80% dei benefici teorici di un router perfetto. È una soglia di ingegneria molto più raggiungibile di quanto sembri, e apre la porta a una domanda che oggi ha ancora poche risposte strutturate: chi costruirà, e chi venderà, questo livello di smistamento?
Il mercato che ancora non esiste: chi decide cosa va dove
Oggi la scelta del modello è, nella stragrande maggioranza dei casi, delegata all’abitudine umana. Apriamo l’app che conosciamo, digitiamo, otteniamo una risposta, senza mai chiederci se quel particolare compito avesse davvero bisogno della potenza che abbiamo appena mobilitato. È un’inefficienza silenziosa, che pesa in costi, in energia e, come visto, in esposizione di dati non necessaria.
La direzione più probabile, nei prossimi anni, è che questa decisione smetta di essere umana e diventi infrastrutturale: un livello di routing integrato di default nei framework agentici e negli assistenti personali, che valuta ogni richiesta e decide, in millisecondi, se può restare sul dispositivo o merita l’escalation verso un modello frontier a pagamento.
Alcuni analisti di settore prevedono che, nel 2026 e 2027, i framework per agenti AI inizieranno a includere un router locale come componente predefinito, relegando la chiamata al cloud a un’opzione configurabile piuttosto che al motore principale del sistema.
Questo sposta il baricentro del valore. Se oggi il valore percepito sta nel modello, quale intelligenza artificiale usiamo, domani una quota crescente di valore starà nel router, chi decide bene quando serve quale intelligenza. È un mercato ancora acerbo: non esistono ancora benchmark condivisi per valutare la qualità di un router, non esistono standard su cosa un router debba loggare o dimostrare in caso di controllo, non esiste un consenso su chi debba possedere quella logica, se il produttore del modello, il produttore del dispositivo, o un livello terzo indipendente. Chi arriverà a definire questi standard per primo avrà un vantaggio competitivo importante, perché controllare il router significa controllare due leve contemporaneamente: dove vanno i dati e dove va la spesa.
Ed è qui che serve una lettura critica, non solo entusiasta. Un router non è mai neutro. La logica che decide “questo task è abbastanza semplice per il locale” incorpora scelte di valore, quanto rischio accettare, quanto costo ottimizzare, quanto privilegiare la latenza sulla qualità, che oggi facciamo implicitamente e domani faranno, per noi, sistemi progettati da qualcun altro. Vale per il routing AI quello che vale per qualunque algoritmo di raccomandazione o di prioritizzazione: chi lo progetta definisce, di fatto, cosa viene trattato come semplice e cosa come eccezionale.
Cosa cambia, concretamente, per chi lavora oggi con l’AI
Per chi si occupa di trasformazione digitale, pubblica o privata che sia, questo scenario suggerisce alcune direzioni pratiche, non teoriche.
- Mappare i task ricorrenti per sensibilità del dato e complessità reale, invece di trattare ogni richiesta AI come equivalente: non tutto merita un modello frontier, e non tutto può permettersi un modello locale.
- Valutare fin da ora soluzioni ibride, dove i task standard restano su modelli open eseguiti in locale o su infrastruttura controllata, e solo i task complessi vengono instradati verso un modello frontier a chiamata.
- Trattare il livello di routing, quando verrà adottato, con lo stesso rigore di sicurezza riservato a un firewall: verificabilità, log, responsabilità chiare su chi ha accesso a quella logica di smistamento.
Una prospettiva più ampia
Il paragone con il passaggio dal mainframe al PC non è solo un’analogia evocativa. Anche allora, il cambiamento non fu “il mainframe scompare”: fu “il mainframe smette di essere il default per tutto” e diventa lo strumento per i carichi che davvero lo richiedono. Con l’AI sta accadendo la stessa cosa, più in fretta. Il modello frontier in cloud non sparirà, e non deve sparire: resta insostituibile per il ragionamento più complesso, per il contesto più ampio, per i compiti davvero nuovi. Ma smetterà, gradualmente, di essere la risposta di default a ogni singolo prompt.
La competenza che conterà, nei prossimi anni, non sarà tanto “saper usare l’intelligenza artificiale”, quanto sapere quanta intelligenza artificiale serve, per quale compito, e a quale prezzo, in termini di costo, di energia e di dati esposti. Se l’intelligenza sta diventando abbondante, questo non vuol dire che dobbiamo sprecarla: dobbiamo capire quanta intelligenza allocare per ogni task e dove metterla (locale o cloud).
È una competenza che oggi non insegniamo quasi a nessuno, e che nel giro di pochi anni diventerà silenziosamente infrastrutturale, incorporata in un router che nessuno vedrà mai, ma che deciderà, per ognuno di noi, cosa resta a casa e cosa esce.


Partecipa alla community