Sovranità dell’AI: quando un governo può spegnere un modello

Venerdì 12 giugno 2026, ore 17:21 a New York. Anthropic riceve una lettera dal governo degli Stati Uniti e nel giro di poche ore disattiva i suoi due modelli più potenti, Fable 5 e Mythos 5, per l’intera base clienti, ovunque nel mondo. La motivazione, dichiarata nel comunicato ufficiale dell’azienda, è un export control per ragioni di sicurezza nazionale che vieta l’accesso a qualunque cittadino straniero, dentro e fuori dagli Stati Uniti, compresi i dipendenti stranieri della stessa Anthropic.

Screenshot

Non discuto qui chi abbia ragione. Mi interessa una cosa più semplice, e più scomoda, che fino a quella sera in molti trattavano come un dettaglio tecnico: l’accesso ai modelli di frontiera è un permesso, e un permesso lo concede qualcuno che può anche ritirarlo.

Un export control ha messo offline un modello di frontiera

La direttiva è arrivata venerdì pomeriggio, alle 17:21 ora della costa Est. Secondo NBC News a firmarla è stato il Segretario al Commercio Howard Lutnick, con i funzionari del Bureau of Industry and Security, l’ufficio che negli Stati Uniti gestisce le restrizioni all’export. È lo stesso strumento con cui negli anni Novanta Washington trattava la crittografia come un’arma da guerra, soggetta alle regole sull’export militare. Anthropic ha scelto di spegnere i modelli per tutti, perché applicare il divieto ai soli stranieri avrebbe comunque tagliato fuori una parte enorme di utenti, inclusi i suoi stessi dipendenti non statunitensi.

L’azienda si adegua, ma dichiara di non essere d’accordo. Sostiene che la vulnerabilità contestata sia minore, che la prova ricevuta sia finora soltanto verbale, e che la stessa capacità sia già reperibile in altri modelli pubblici, incluso GPT-5.5 di OpenAI, e usata ogni giorno da chi i sistemi li difende. È, per quanto se ne sa, la prima volta che un’azienda AI di primo piano mette offline un modello già distribuito al pubblico per effetto di un intervento federale.

Il contesto pesa più della singola lettera. A febbraio l’amministrazione aveva provato a escludere i prodotti Anthropic dalle agenzie federali, l’azienda aveva fatto causa e un giudice le aveva dato ragione. La settimana scorsa è emerso che la National Security Agency stava usando Mythos per operazioni cyber offensive. E il 2 giugno è stato firmato un ordine esecutivo sull’AI che, tra le altre cose, prevede un meccanismo per dare al governo accesso anticipato, su base volontaria, ai modelli più potenti. Lo stesso modello che lo Stato vuole usare per la propria sicurezza è anche quello che lo Stato può decidere di spegnere, per la stessa ragione.

Permesso, non proprietà

Quando paghi l’abbonamento a un modello hai l’impressione di possederne l’uso. L’accesso non è un bene che possiedi, è un permesso che ti concedono, condizionato, che vive su infrastruttura di qualcun altro e sotto la legge di qualcun altro.

In Pelle Digitale ho provato a raccontare come il digitale sia diventato una seconda pelle, qualcosa che indossiamo senza più accorgercene finché funziona. La dipendenza più profonda è quella invisibile. La vedi solo il giorno in cui qualcuno la stacca, e venerdì centinaia di milioni di persone hanno visto la propria.

Il controllo dell’AI è verticale

Girano decine di schemi dello stack dell’AI. Alcuni lo disegnano come un mercato, con applicazioni e modelli e dati e infrastruttura, altri come un’architettura tecnica a livelli, altri ancora come una pila di governance che sale dalla sicurezza fino al consiglio di amministrazione. Linguaggi diversi per lo stesso oggetto.

Quasi nessuno mette in evidenza la dimensione che venerdì è diventata lampante. Il controllo è verticale. C’è una pila che parte dal silicio e arriva alla governance, con in mezzo il cloud, i pesi del modello, il runtime di inferenza, l’orchestrazione, le applicazioni. Puoi avere model card, audit trail e comitati etici impeccabili in cima, e perdere comunque l’accesso al modello perché una lettera, in un’altra capitale, ha deciso così. Una policy perfetta vale poco se il fondo della pila vive sotto la giurisdizione di un altro Stato.

Dove può intervenire davvero un’azienda privata?

Qui la domanda si fa concreta, e la risposta cambia da livello a livello.

Sul silicio un’azienda privata non interviene. Non progetta i chip, non controlla i grandi produttori, e l’export sui semiconduttori è una leva che si muove tra governi. È il piano geopolitico del controllo, quello su cui un’impresa, per quanto grande, resta sostanzialmente spettatrice.

Dal cloud in su la situazione si ribalta. L’infrastruttura puoi sceglierla, on-premise oppure su un cloud sovrano in giurisdizione europea. Il runtime di inferenza gira su software aperto, dentro il tuo perimetro. Per orchestrazione e agenti esistono standard aperti come MCP. Le applicazioni le disegni o le ospiti tu, e la governance, in cima, è per definizione tua.

In mezzo c’è il livello che decide tutto, il modello e i suoi pesi. Con pesi aperti, scaricati e ospitati sulla tua infrastruttura, il modello è tuo e nessuno te lo spegne da remoto. Con un’API proprietaria, per quanto eccellente, dipendi dalla continuità di servizio di chi te la fornisce, ed è esattamente lì che venerdì è caduta la direttiva.

Controllare l’intera pila, dal chip all’applicazione, è impraticabile per quasi qualunque organizzazione, e costoso anche solo provarci. La scelta sensata non sta nel possedere tutto, ma nel decidere, livello per livello, cosa tenere dentro il perimetro e cosa affittare sapendo bene che cosa si sta affittando.

Il metodo viene prima della tecnologia

Decidere quali livelli controllare è prima di tutto un esercizio di metodo: mappare le dipendenze reali, valutare la maturità dell’organizzazione, architettare quali strati portare in casa e con quale priorità, mettere governance e conformità, con l’AI Act in testa, dentro il progetto dall’inizio e non come timbro finale. È il lavoro che con ZeroFive provo a fare con un framework a cinque fasi, che parte dall’allineamento strategico e dalla valutazione della maturità, passa per l’architettura delle priorità e l’attivazione della governance, e arriva alla misurazione del valore nel tempo, con un’idea fissa, portare metodo dove l’industria porta hype.

Il metodo dice quali livelli pesano per te. Poi serve la tecnologia per tenerli davvero in mano, e sul livello che fa da bivio, il modello e il runtime, la risposta tecnica ha un nome preciso, l’open source. LocalAI è un motore di inferenza aperto, compatibile con le API di OpenAI e indipendente dal modello, pensato per far girare modelli a pesi aperti dentro il perimetro dell’azienda, senza che il dato esca e senza che l’accesso dipenda da una decisione presa da un’altra parte. È il progetto su cui lavoro, e lo cito per quello che è in questo discorso, un modo concreto per riportare il modello dalla parte di chi lo usa. Vale anche per chi si occupa di AI generativa in azienda: la scelta della pila viene prima della scelta del fornitore.

La direttiva del 12 giugno rientrerà quasi certamente, Anthropic stessa la legge come un malinteso, e l’accesso a Fable e Mythos tornerà. La lezione però resta anche dopo. Per chi costruisce in Europa la prossima domanda da portare in consiglio di amministrazione non riguarda quale modello sia il più bravo, ma quanta parte del proprio stack continuerebbe a funzionare il mattino dopo una lettera. Voi quanta parte ne avete?


Fonte primaria: Statement on the US government directive to suspend access to Fable 5 and Mythos 5, Anthropic, 12 giugno 2026. Ricostruzione del meccanismo governativo: NBC News. Contesto regolatorio: ordine esecutivo del 2 giugno 2026.

I decreti attuativi sull’IA e la responsabilità che resta umana

Il 10 giugno 2026 il Consiglio dei Ministri ha approvato in esame preliminare due decreti attuativi della legge 132/2025 sull’intelligenza artificiale. Sono il primo quadro nazionale organico in materia, costruito per dare attuazione all’AI Act dentro l’ordinamento italiano. I testi non sono ancora definitivi, davanti c’è l’iter delle Commissioni parlamentari, della Conferenza delle Regioni e delle Authority competenti, e qualche pezzo cambierà.

Li ho letti per intero, e al netto della retorica da comunicato c’è una direzione che riconosco e condivido. In un anno in cui tutti corrono sull’adozione dell’IA, queste norme spostano in silenzio il baricentro, ridefiniscono cosa diventa difficile e quindi prezioso: tenere una persona competente dentro la decisione, e tenere il dato sotto controllo. Non è un freno all’innovazione, è il posto dove inizia la difendibilità.

Dentro i decreti attuativi resta una persona che decide

Il filo che attraversa entrambi i testi è uno solo. L’IA può assistere, analizzare, prevedere, ma la decisione resta umana e imputabile a qualcuno che ne risponde. Sul lavoro la regola diventa esplicita: le scelte che riguardano assunzione, sanzione disciplinare o licenziamento non possono essere prese unicamente sulla base di un trattamento automatizzato, e un licenziamento deciso solo da un algoritmo è nullo. Il lavoratore ha diritto, su richiesta e con l’intervento di una persona fisica, a una motivazione intelligibile di ciò che lo riguarda.

La stessa logica torna nella giustizia, dove la formazione dei magistrati serve a garantire che l’IA non sostituisca lo ius dicere, e nella sanità, dove l’uso clinico degli strumenti entra obbligatoriamente nei programmi di Educazione Continua in Medicina. Cambia il settore, resta identico il principio. La sorveglianza umana diventa la condizione perché la tecnologia entri davvero, e smette di essere una casella da spuntare a posteriori.

Questa è la parte che mi tocca più da vicino. In Pelle Digitale avevo provato a raccontare la frontiera sottile tra noi e le macchine come una membrana, qualcosa che ci protegge mentre ci mette in contatto. È la traduzione in diritto di quella membrana: l’algoritmo propone, la persona resta responsabile.

E i dati dove restano?

Sul fronte dei dati il secondo dei decreti attuativi, quello sulle attività di polizia, è il banco di prova più delicato, e la scelta è leggibile. Niente sorveglianza biometrica generalizzata, niente banche dati costruite raccogliendo immagini a strascico dal web. L’identificazione biometrica in tempo reale resta ammessa solo in casi tassativi, con autorizzazione dell’autorità giudiziaria, delimitata nel tempo e nello spazio, per un periodo che non supera i quindici giorni salvo proroga motivata.

Il riconoscimento facciale a posteriori può attivarsi solo dopo un reato, sulla base di elementi verificabili, con i dati conservati in locale per sette giorni e log non modificabili per cinque anni. Nessuna decisione che danneggia una persona può fondarsi soltanto sull’output del sistema. Il comunicato lo sintetizza con un’immagine, «nessun Grande Fratello», e qui la formula coincide con la sostanza: dato conservato in locale e verificabile.

C’è chi legge questo stesso impianto con più diffidenza, e non ha torto a porsi il problema. Su Agenda Digitale è uscita una lettura più critica del decreto sulla polizia, che nelle garanzie formali vede il rischio di una normalizzazione progressiva della sorveglianza. È un’obiezione seria, da tenere accanto al testo. Le regole sui dati valgono quanto la loro applicazione concreta.

Alfabetizzazione critica, non addestramento

Il blocco sulla formazione è quello che rischiamo di sottovalutare, ed è la condizione abilitante di tutto il resto. I decreti non parlano di corsi sull’uso degli strumenti. Parlano di capacità di leggere gli output, riconoscere i bias, capire i limiti, mantenere una sorveglianza vera su sistemi che spesso restano opachi anche a chi li adopera. È la differenza tra usare uno strumento e governarlo.

La cosa entra ovunque, dalla scuola con cento milioni destinati alla formazione dei docenti, all’università, alla pubblica amministrazione, fino agli ordini professionali che dovranno adeguare i regolamenti in sei mesi e all’equo compenso ricalibrato sul livello di rischio del sistema impiegato. Per chi come me passa buona parte dell’anno dentro le aziende a lavorare su adozione e governance dell’IA, è la conferma di una cosa semplice: la competenza è il presupposto della trasformazione.

Un miliardo per l’ecosistema nazionale

Accanto alle regole il pacchetto porta una scommessa industriale, ed è la metà che spesso sfugge nel dibattito. L’articolo 23 della legge 132 destina fino a un miliardo di euro del Fondo di sostegno al venture capital allo sviluppo dell’ecosistema nazionale dell’IA. Secondo il comunicato il mercato italiano ha toccato 1,8 miliardi nel 2025, con una crescita del cinquanta per cento sull’anno prima, e CDP Venture Capital ha già allocato oltre trecento milioni su più di centocinquanta startup. Il comunicato cita anche oltre mille occupati altamente qualificati nelle imprese già sostenute e più di cinquecento milioni di nuovi investimenti previsti nel prossimo triennio.

Le filiere indicate come prioritarie dicono la direzione: robotica umanoide e guida autonoma, quantum e fotonica per il calcolo ad alte prestazioni, IA verticale e deep tech. Dal 2026 si aggiunge un polo dedicato a intelligenza artificiale e cybersicurezza. La parola che ricorre, sotto traccia, è sovranità. Costruire capacità qui, su infrastruttura europea, con il dato che non deve attraversare l’oceano per essere elaborato.

La difendibilità si sposta sul controllo

Qui le due cose, le regole e la scommessa industriale, si chiudono in un cerchio che mi riguarda da vicino. Se la decisione resta umana e il dato resta a terra e tracciato, se la formazione diventa un requisito, allora il vantaggio competitivo smette di essere soltanto la velocità. In una conferenza di pochi giorni fa avevo provato a dirlo così, veloci lo saranno tutti, difendibili pochi. Due decreti attuativi che mettono al centro controllo e responsabilità, senza cercarlo, raccontano la stessa cosa.

È il terreno su cui lavoro ogni giorno, su due piani che si tengono insieme. C’è il metodo, il lavoro con le aziende attraverso ZeroFive, per portare l’IA dentro i processi restando dentro le regole, con governance e formazione che diventano competenza reale e non slide. E c’è la tecnologia, LocalAI, dove l’inferenza gira on-premise e il dato non esce dall’azienda, anche negli ambienti più regolati. Li cito per una ragione precisa, e non per piazzare un’inserzione: sono nati prima di questo decreto, rispondendo alla stessa domanda che il decreto adesso mette nero su bianco.

Resta l’incognita di sempre, e vale la pena tenerla aperta. Una regola che impone la sorveglianza umana vale quanto la serietà con cui la si esercita, e un’infrastruttura sovrana conta solo se qualcuno la sceglie davvero. La forma definitiva dei testi arriverà tra qualche mese. La domanda vera viene dopo: quante aziende vivranno questo perimetro come un adempimento da subire, e quante come il punto da cui ricostruire un vantaggio?


Fonte: Comunicato stampa del Consiglio dei Ministri n. 177, 10 giugno 2026.

Mistral vs Llama vs Qwen vs DeepSeek: quale per l’azienda

Tre anni fa, “modello open-source” significava roba di nicchia per ricercatori. Llama 1 di Meta aveva 65 miliardi di parametri, performance discrete sui benchmark, e una licenza che non ti permetteva di usarlo commercialmente. Il resto era praticamente esercizio accademico. Nel maggio 2026 il panorama è cambiato in modo radicale. Quattro famiglie di modelli open-weight competono testa a testa con i top di gamma proprietari (Claude Opus, GPT-5, Gemini Pro) su task specifici, e per le aziende italiane che vogliono fare AI privata sono diventate la scelta di default invece dell’eccezione.

Ho ricevuto la stessa domanda due volte questa settimana, una da un CTO di un’azienda manifatturiera lombarda e una da un’innovation manager di una banca italiana di medie dimensioni: “Tutti dicono Llama, ma davvero è la scelta giusta per noi?”. La risposta breve è “dipende”, e in questo articolo provo a sciogliere quel dipende.

I quattro modelli che vale la pena considerare seriamente oggi sono: Llama di Meta (americano, ampia diffusione, ecosistema enorme), Mistral di Mistral AI (francese, alleato europeo, focus enterprise), Qwen di Alibaba (cinese, performance al top sui benchmark, costi infrastrutturali bassi), DeepSeek (cinese, reasoning forte, prezzi aggressivi). Provo a confrontarli sui cinque criteri che contano davvero per chi deve prendere una decisione enterprise.

La lingua italiana, prima di tutto

Per le aziende italiane c’è un problema spesso sottovalutato: la qualità della lingua italiana del modello. I benchmark internazionali sono quasi tutti in inglese, e un modello che fa 92 su MMLU in inglese può fare 78 in italiano. Per chi costruisce un agente AI interno che parla con i propri dipendenti, questa differenza si sente nella qualità delle risposte.

I quattro modelli si comportano in modo abbastanza diverso su italiano. Mistral, essendo francese, ha l’italiano nel core training data fin dalle prime versioni, e produce un italiano molto naturale, con sfumature idiomatiche credibili. Llama 3.3 ha migliorato significativamente l’italiano rispetto a Llama 2, ma resta sotto Mistral nelle situazioni complesse (contratti legali, terminologia tecnica specifica). Qwen 4 fa un italiano sorprendentemente buono nelle versioni recenti, soprattutto sui task strutturati, anche se ogni tanto introduce piccoli calchi grammaticali dal cinese che un madrelingua riconosce. DeepSeek è il più debole sull’italiano della categoria, va bene per task tecnici e codice ma spesso suona “tradotto” sul conversazionale.

La mia regola pratica: se l’agente AI deve parlare con i vostri dipendenti italiani in modo fluido, Mistral o Llama. Se l’agente fa task back-end strutturati (estrazione dati, classificazione, codice), Qwen o DeepSeek vanno benissimo. Se siete bilingue inglese-italiano in azienda, qualsiasi dei quattro va bene.

Qualità delle risposte sui task aziendali tipici

I benchmark accademici (MMLU, GSM8K, HumanEval) sono utili come riferimento generale, ma non vi dicono se un modello vi serve in produzione. Per chi vuole capire cosa scegliere per la propria azienda, vale la pena testare quattro categorie di task che tornano spesso.

Sintesi e analisi documentale. Tutti e quattro i modelli, nelle loro versioni 70B+, fanno bene questo task. Mistral Large 3 e Llama 3.3 70B sono praticamente equivalenti sui documenti aziendali italiani. Qwen 4 70B è leggermente più conciso, può andare bene o male a seconda dello stile che cercate. DeepSeek V3 fa molto bene su documenti tecnici e meno bene su prosa argomentativa.

Estrazione strutturata. Quando dovete estrarre dati strutturati da testo libero (campi di un contratto, voci di una fattura, entità da una mail), i modelli si differenziano per affidabilità. Qwen 4 e DeepSeek vincono qui, perché hanno una propensione al rigore strutturale che è perfetta per output JSON, function calling, schema fissi. Llama e Mistral fanno discretamente, ma con tasso di hallucination sui campi vuoti più alto.

Generazione di codice. Categoria dove DeepSeek brilla con il suo modello specializzato Coder, che compete direttamente con Claude Sonnet sui task di programmazione. Qwen 4 Coder è il secondo. Mistral Codestral è solido. Llama 3.3 fa il codice meno bene degli altri tre.

Conversazione lunga e ragionamento. Per agenti AI con conversazioni multi-turno complesse, ricerca multi-step, ragionamento articolato, i modelli reasoning sono la categoria giusta. DeepSeek R2 è il leader open-weight della categoria, eccellente su reasoning matematico e logico. Qwen 4 con thinking mode è il secondo. Mistral e Llama nelle versioni standard sono più orientati al chat istantaneo, meno al reasoning profondo.

Hardware necessario e costi infrastrutturali

I quattro modelli pesano in modo diverso sulla vostra infrastruttura. È un fattore che le aziende spesso valutano in secondo piano e che diventa importante quando si passa dalla demo alla produzione su volumi reali.

Llama 3.3 70B in Q4 quantizzato pesa circa 40 GB di RAM/VRAM. Gira bene su Mac Studio M4 Max 128 GB (30-45 tok/s), su server con 2x RTX 4090 (50-70 tok/s), su singola H100 (90-120 tok/s).

Mistral Large 3 (123 miliardi parametri) è significativamente più pesante. Richiede 70+ GB di memoria, quindi Mac Studio 128 GB o server NVIDIA con almeno 80 GB di VRAM (H100, due 5090 in tandem). Performance: 15-25 tok/s sul Mac, 60-90 tok/s su H100.

Qwen 4 32B-A3B è la sorpresa positiva. È un modello MoE (Mixture of Experts) da 32 miliardi totali con solo 3 miliardi attivi per token. Pesa circa 18 GB ma è veloce come un modello da 7B in inferenza. Sul Mac Mini M4 Pro 48 GB arriva a 50-70 tok/s con qualità di output che compete con modelli 70B densi. È il modello più “efficiente per dollaro” che ho visto nel 2026.

DeepSeek V3 è grande (671B parametri totali, 37B attivi MoE), richiede infrastruttura server seria. Non gira su consumer Mac. Per molte PMI italiane è sovradimensionato.

Calcolando il costo infrastrutturale per servire 100 utenti aziendali simultaneamente in produzione:

  • Qwen 4 32B-A3B: 2.000-4.000 euro hardware
  • Llama 3.3 70B: 5.000-10.000 euro hardware
  • Mistral Large 3: 15.000-30.000 euro hardware
  • DeepSeek V3 full: 40.000+ euro hardware

Licensing e implicazioni geopolitiche

Per le aziende italiane, soprattutto quelle che lavorano con PA o settori regolati, la provenienza geografica del modello inizia a contare.

Llama ha una licenza commerciale aperta che permette praticamente qualsiasi uso (con il limite delle aziende con oltre 700 milioni di utenti attivi, che è un caso che riguarda Meta stessa, non voi). È un modello americano, sviluppato da Meta, distribuito sotto Llama Community License.

Mistral è francese, distribuito sotto Apache 2.0 per le versioni open-weight (Mistral 7B, Mixtral, alcune varianti). Le versioni più recenti come Mistral Large 3 sono proprietarie con API a pagamento ma con opzione enterprise on-premise. Per le aziende italiane che vogliono restare nel perimetro europeo, Mistral è la scelta naturale dal punto di vista geopolitico.

Qwen è di Alibaba, distribuito sotto Apache 2.0 (le versioni più recenti) o Tongyi Qianwen License (alcune varianti). I modelli sono completamente utilizzabili commercialmente. La provenienza cinese può essere un problema per aziende che lavorano con PA, difesa, settori sensibili. Per la maggior parte delle aziende manifatturiere o servizi italiane non c’è alcun problema operativo, ma è un fattore che alcuni board considerano.

DeepSeek è cinese (Hangzhou), distribuito sotto MIT license (più permissiva di Apache 2.0 in alcuni dettagli). Stesse considerazioni geopolitiche di Qwen.

La domanda non è “il modello cinese può rubare i miei dati”: tutti i modelli open-weight girano sul vostro hardware, quindi i dati non escono di un millimetro. La domanda è di posizionamento aziendale: alcune RFP italiane di settore difesa o PA cominciano a escludere esplicitamente componenti software cinesi.

Aggiornamenti e supporto della community

Un fattore spesso sottostimato: come evolve il modello nei prossimi anni? Acquistare hardware oggi per girarci sopra un modello che non viene più aggiornato è un investimento dimezzato.

Llama ha rilasciato versioni nuove ogni 6-9 mesi (Llama 1, 2, 3, 3.1, 3.2, 3.3, e Llama 4 è atteso entro fine 2026). Meta investe tantissimo nell’ecosistema, e la community Hugging Face ha le fine-tunate Llama più estese al mondo. Roadmap solida.

Mistral rilascia con cadenza simile, ma sta progressivamente spostando i modelli più nuovi su licenze proprietarie con accesso commerciale a pagamento. Per chi vuole stare sull’open-weight puro, Mistral si è un po’ rallentato come strategia. L’azienda è solida però (round di finanziamento da 2 miliardi nel 2024), quindi non c’è rischio sostenibilità.

Qwen è quello che evolve più velocemente. Alibaba sta investendo aggressivamente, e Qwen rilascia nuove versioni ogni 2-3 mesi. La velocità di iterazione è impressionante.

DeepSeek ha sorpreso tutti nel 2025 con la versione R1 che competeva con OpenAI o1 su benchmark di reasoning. Sta continuando a rilasciare aggiornamenti, anche se la sostenibilità a lungo termine del progetto è meno chiara di Meta o Alibaba.

La scelta concreta per tre profili aziendali italiani

Provo a tradurre i criteri sopra in tre raccomandazioni operative.

Per la PMI italiana media (50-300 dipendenti, AI per processi interni, no settori sensibili): Qwen 4 32B-A3B è la scelta di default oggi. Costa poco in hardware, gira veloce su un Mac Studio o un workstation modesto, l’italiano è buono per la maggior parte dei task aziendali, ha aggiornamenti frequenti. Se l’agente AI fa molto codice o estrazione strutturata, valutate anche DeepSeek Coder come modello specializzato accanto a Qwen.

Per l’azienda media-grande con focus su lingua italiana e mercati europei (settore retail, media, hospitality, servizi B2C): Mistral Large 3 è la scelta giusta. Italiano impeccabile, posizionamento europeo, supporto enterprise dedicato. Costa di più in hardware (15-30k euro per servire bene 100+ utenti) ma per chi ha quel budget vale.

Per banche, sanità, PA, difesa, manifattura strategica (settori regolati con sensibilità geopolitica): Llama 3.3 70B o Mistral Large 3. Llama per costo infrastrutturale più contenuto e ecosistema ampio, Mistral per posizionamento europeo. Evitate Qwen e DeepSeek se la vostra controparte ha sensibilità sul tema “componenti cinesi”.

Il valore di poter cambiare modello senza riscrivere

Una considerazione che vale per tutti i profili sopra: i quattro modelli open-weight evolvono velocemente, e il modello migliore di oggi probabilmente non sarà quello di fra dodici mesi. Llama 4 è atteso a fine 2026, Mistral sta preparando le sue prossime versioni, Qwen e DeepSeek rilasciano ogni pochi mesi.

Le aziende che costruiscono il proprio stack AI con un layer di astrazione (un orchestratore che espone API compatibili OpenAI come LocalAI.io, di cui sono cofondatore) riescono a cambiare il modello sotto senza ritoccare le applicazioni. Le aziende che si legano a un modello specifico in modo profondo (prompt engineerizzati su quirk specifici di Mistral, function calling con sintassi proprietaria di Qwen, fine-tuning legato a Llama 3.3) si ritrovano a fare la migrazione manuale ogni volta che esce un modello migliore. La differenza, su tre anni, vale settimane di lavoro di sviluppo.

LocalAI è progettato esattamente per questo: gestisce in parallelo Llama, Mistral, Qwen, DeepSeek e tutti i loro fine-tuned, espone un unico endpoint compatibile OpenAI, permette di fare A/B testing fra modelli, di routare task diversi a modelli diversi (Qwen per estrazione strutturata, Mistral per conversazione italiana, DeepSeek per codice), di aggiornare il modello sotto senza che le applicazioni se ne accorgano. È il single point of integration che rende la vostra architettura AI flessibile invece di rigida.

Per chi vuole capire come si imposta lo stack completo dal modello al deployment, ho scritto una guida hardware completa e una guida economica al TCO recente. Per chi sta facendo la decisione operativa su quale modello partire, c’è la pagina Advisory con i formati di lavoro che propongo.

La domanda da farsi oggi non è “qual è il modello migliore”. È: con quale modello vogliamo iniziare adesso, sapendo che fra sei mesi forse cambieremo? E quanto è facile per noi cambiarlo quando arriverà il momento?

TCO LLM on-premise vs cloud: il calcolo a tre anni

Un CFO italiano mi ha fatto una settimana fa la domanda che ricevo più spesso quando parliamo di AI privata: “Se chiamo Claude o GPT pago a token, è chiaro. Se mi metto un’infrastruttura in casa, in quanto tempo mi rientrano i soldi rispetto al cloud?”. È la domanda giusta, perché senza un calcolo TCO LLM on-premise solido nessun investimento in AI privata regge davanti al comitato finanziario.

In questo articolo provo a smontare il calcolo del TCO (Total Cost of Ownership) di un LLM on-premise su un orizzonte di tre anni, mettendolo a confronto con le API cloud dei grandi provider. Lavoro su numeri reali di maggio 2026, su tre scenari aziendali tipici italiani, e provo a includere anche le voci nascoste che troppi business case lasciano fuori. L’obiettivo qui non è dimostrare che l’on-premise vince sempre. Provo a dare uno strumento per decidere caso per caso.

La trappola del prezzo a token

Il prezzo per milione di token delle API cloud è sceso vertiginosamente negli ultimi 24 mesi. Per dare un’idea: GPT-5.4 a maggio 2026 sta a 2,50 dollari per milione di token in input e 15 dollari in output. Claude Sonnet 4.6 a 3 e 15 dollari. Gemini 3 Flash a 0,50 e 3 dollari. DeepSeek V3 a 0,27 e 1,10 dollari. Sembrano cifre piccole. Sono il motivo per cui i CFO mostrano scetticismo verso l’on-premise: “Ma quanto vuoi che mi costino qualche centinaio di milioni di token al mese?”.

Il problema è che “qualche centinaio di milioni di token al mese” non è la realtà di una azienda che usa l’AI sul serio. La realtà è che, quando un sistema AI entra dentro i processi e gli utenti se ne accorgono, il consumo esplode. Un agente AI che fa RAG su documenti aziendali per 100 dipendenti può facilmente bruciare 500 milioni di token al mese fra input e output, una volta che gli utenti hanno preso confidenza con lo strumento. A questi volumi, i conti cambiano.

Vediamo un esempio. Azienda media italiana, 200 dipendenti, agente AI interno per assistenza alla documentazione tecnica e supporto commerciale. Volume tipico: 1 miliardo di token input + 200 milioni di token output al mese (lo skew input/output è alto perché il RAG ricarica documenti pesanti per ogni query). Con Claude Sonnet 4.6: 3.000 + 3.000 = 6.000 dollari al mese, 72.000 dollari l’anno. Con GPT-5.4: 2.500 + 3.000 = 5.500 dollari al mese, 66.000 dollari l’anno. Con Gemini 3 Flash come scelta low-cost: 500 + 600 = 1.100 dollari al mese, 13.200 dollari l’anno.

La forbice è larga, e dipende molto dal modello scelto. Tenete in mente questi numeri perché ci tornerò.

Il vero conto dell’on-premise

Per il setup on-premise, scomponiamo i costi in cinque voci. Le considero su un orizzonte di 36 mesi, che è il periodo di ammortamento tipico dell’hardware AI in Italia.

Hardware. Per servire 200 dipendenti con un modello Llama 3.3 70B in produzione, lo scenario realistico è un server con 2x RTX 5090 o singola H100, oppure un Mac Studio M4 Max 128 GB. Costo hardware: 8.000-15.000 euro per il Mac Studio, 25.000-40.000 euro per il server NVIDIA. Su 36 mesi di ammortamento, parliamo di 220-1.100 euro al mese.

Hosting e infrastruttura. L’hardware deve stare da qualche parte. Se è on-premise puro, c’è il costo del rack, del condizionamento, del power supply ridondato, della connettività enterprise. Stima realistica: 200-500 euro al mese. Se è in colocation italiana (per chi non ha sala server propria), 400-800 euro al mese. Se è su cloud privato italiano (Aruba, Seeweb, una delle nascenti soluzioni PSN), 600-1.200 euro al mese.

Elettricità. Una RTX 5090 sotto carico costante consuma 575W. Una H100 consuma 700W. Un Mac Studio M4 Max si ferma a 130W. Calcolando bolletta italiana media a 0,28 euro/kWh, un sistema NVIDIA sotto carico 16 ore al giorno costa 80-110 euro al mese. Un Mac Studio sotto stesso carico, 18 euro al mese. Su tre anni la differenza è di 2.000-3.000 euro.

Operations. Qui è dove il TCO si rompe per molte aziende. Un sistema AI on-premise richiede manutenzione continua: aggiornamenti dei modelli quando ne escono di migliori, monitoring delle performance, gestione dei picchi di carico, backup, sicurezza, integrazione con i sistemi aziendali. Per una PMI, parliamo di 0,3-0,5 FTE dedicati (dove FTE è equivalente a tempo pieno), che in Italia significano 18.000-35.000 euro l’anno solo di personale interno. In alternativa, contratto di managed service con un fornitore specializzato: 1.500-3.000 euro al mese.

Software e licenze. Lo stack open-source (Ollama, LocalAI, Qdrant, n8n) è gratuito. Però spesso servono componenti commerciali per features enterprise: monitoring tipo Datadog o New Relic, SSO con Okta o equivalenti, vector database managed per il RAG se non volete gestirlo voi. Stima media: 500-1.500 euro al mese.

Sommando tutto su 36 mesi, abbiamo questa fascia di costo TCO totale per il setup on-premise descritto sopra: dai 60.000 euro (scenario Mac Studio, ops interno minimo, no managed service) ai 200.000 euro (scenario server NVIDIA, ops managed, full stack enterprise) su 3 anni.

Tre scenari aziendali a confronto

Provo a costruire tre scenari realistici e a fare il calcolo TCO completo cloud-vs-onprem.

Scenario A – Studio professionale, 30 utenti, uso moderato.

Volume mensile stimato: 100 milioni di token input + 20 milioni di token output. Cloud con Claude Sonnet: 600 dollari/mese = 21.600 dollari su 3 anni. Cloud con GPT-5.4: 550 dollari/mese = 19.800 dollari. Cloud con Gemini 3 Flash: 110 dollari/mese = 3.960 dollari.

On-premise: Mac Mini M4 Pro 48 GB. Hardware 1.800 euro, hosting on-site 100 euro/mese, elettricità 8 euro/mese, ops 0,1 FTE = 6.000 euro/anno. Totale su 3 anni: 1.800 + 3.600 + 290 + 18.000 = 23.690 euro.

Verdetto: per uno studio piccolo che usa modelli economici (Gemini Flash, GPT-4o mini), il cloud resta più conveniente. Per chi vuole modelli di fascia alta (Claude Sonnet, GPT-5.4) e tiene ai dati sensibili, l’on-premise comincia a tornare. La discriminante qui non è solo il costo. Ci sta dentro la sensibilità dei dati gestiti, che pesa in modo diverso a seconda del settore.

Scenario B – Azienda media manifatturiera, 200 utenti, uso intensivo.

Volume mensile: 1 miliardo input + 200 milioni output. Cloud Claude Sonnet: 6.000 dollari/mese = 216.000 dollari su 3 anni. Cloud GPT-5.4: 5.500 dollari/mese = 198.000 dollari. Cloud Gemini Flash: 1.100 dollari/mese = 39.600 dollari.

On-premise: Mac Studio M4 Max 128 GB + cloud privato italiano. Hardware 4.500 euro, hosting cloud privato 800 euro/mese, elettricità inclusa nel cloud, ops 0,4 FTE = 24.000 euro/anno, software 1.000 euro/mese. Totale su 3 anni: 4.500 + 28.800 + 72.000 + 36.000 = 141.300 euro.

Verdetto: rispetto al cloud Claude Sonnet o GPT-5.4 (200k+ dollari su 3 anni), l’on-premise vince con margine ampio. Rispetto al cloud Gemini Flash low-cost, il cloud resta più economico se non avete vincoli di sovranità del dato. Per una manifattura italiana, dove la proprietà intellettuale dei processi è asset strategico, on-premise è la scelta da fare anche se costa qualche migliaio di euro in più.

Scenario C – Azienda servizi finanziari, 100 utenti, alta sensibilità.

Volume mensile: 500 milioni input + 100 milioni output. Cloud Claude Sonnet: 3.000 dollari/mese = 108.000 dollari su 3 anni. Però realisticamente, per una banca o assicurazione italiana, il cloud americano è impraticabile per ragioni di compliance.

On-premise: server NVIDIA con 2x RTX 5090 in colocation italiana. Hardware 30.000 euro, hosting colocation 700 euro/mese, elettricità 100 euro/mese, ops 0,5 FTE + managed service support = 50.000 euro/anno, software enterprise (SSO, audit, monitoring) 2.000 euro/mese. Totale su 3 anni: 30.000 + 25.200 + 3.600 + 150.000 + 72.000 = 280.800 euro.

Verdetto: il TCO è significativamente più alto del cloud equivalente in token, ma la domanda da farsi qui cambia. Diventa “qual è l’alternativa accettabile”. Per finanza e sanità italiana, l’on-premise non è una scelta di ottimizzazione costi, è un vincolo strutturale. Una volta accettato il vincolo, il calcolo diventa quanto investire bene per minimizzare i rischi.

Le voci che nessuno mette nel business case

Tre cose escono spesso fuori solo quando il progetto è già partito e si rivelano problemi.

La variabilità del prezzo cloud. I prezzi delle API LLM sono scesi tantissimo nel 2024 e 2025, ma non c’è nessuna garanzia che continuino a scendere allo stesso ritmo. Anzi, alcuni modelli premium (GPT-5.5 Pro a 30 dollari input e 180 output) suggeriscono che la forbice fra modelli economici e modelli avanzati si sta allargando. Un business plan a 3 anni costruito su prezzi attuali può essere completamente fuori bersaglio fra 18 mesi.

Il rate limiting. I provider cloud applicano limiti alle chiamate per evitare picchi. Sotto carico, una vostra applicazione AI potrebbe non riuscire a servire gli utenti, oppure dover pagare premium per priority access. È un costo che non c’è nel listino e si manifesta nei momenti peggiori. Su on-premise, il limite è solo l’hardware vostro.

La migrazione obbligata. I provider cloud deprecano modelli ogni 12-18 mesi. Un’applicazione costruita su GPT-4 nel 2024 oggi gira su GPT-5.4 con prompt diversi, comportamenti diversi, output marginalmente diversi. Ogni migrazione costa giorni o settimane di lavoro di prompt engineering e regression testing, che nei business case non finiscono. On-premise, voi decidete quando aggiornare e a quale modello.

Quando l’on-premise vince con margine

Riassumendo i tre scenari con un’occhiata pragmatica al TCO su 36 mesi:

Per uso moderato e modelli economici (Gemini Flash, DeepSeek): cloud resta più conveniente, soprattutto se non avete vincoli di compliance. La differenza è di qualche migliaio di euro.

Per uso intensivo e modelli di fascia alta (Claude Sonnet, GPT-5.4): on-premise comincia a vincere già al primo anno, e a 36 mesi la differenza può essere di 100-150k euro a favore del setup interno.

Per settori regolati (finanza, sanità, PA, manifattura strategica): la conversazione si sposta dal TCO assoluto al perimetro architetturale praticabile. Il cloud americano per certi tipi di dato è fuori discussione, e il costo dell’on-premise è il prezzo della compliance.

Lo strumento che amplifica il ROI dell’on-premise

C’è una variabile che cambia tutto il calcolo TCO, e ha a che fare con quanto efficiente è lo stack software che gestisce l’infrastruttura. Su questo ho investito personalmente come cofondatore di LocalAI.io. LocalAI è il gateway open-source che permette di gestire modelli multipli sullo stesso hardware, con API compatibile OpenAI, di cambiare modello sotto senza ritoccare le applicazioni, di orchestrare RAG e agenti, di fare A/B testing e monitoring.

L’effetto pratico sul TCO è significativo. Un’azienda che adotta LocalAI invece di gestire i singoli modelli individualmente tipicamente riduce di 0,2-0,3 FTE il fabbisogno di ops, che su 36 mesi significa 18-32k euro di risparmio. E soprattutto, riduce il costo della migrazione fra modelli a zero: quando esce un Llama 4 o un Qwen 5 migliore di quello che state usando, lo cambiate dalla console di LocalAI, le applicazioni sopra continuano a funzionare.

Per chi vuole approfondire il calcolo applicato al proprio caso specifico, ho scritto la settimana scorsa una guida hardware completa che entra nei dettagli per scenario, e una guida ai 10 motivi strategici per portare l’AI privata al tavolo del board. Per una conversazione specifica sul vostro contesto, c’è la pagina Advisory.

Il TCO è uno strumento di decisione, non una formula magica. Le aziende che scelgono on-premise non lo fanno per risparmiare qualche migliaio di euro al mese, lo fanno per avere il controllo strutturale di un’asset che sta diventando strategico per il loro business. Le aziende che restano sul cloud lo fanno perché la flessibilità conta più del controllo. Entrambe le scelte sono legittime, ed entrambe meritano di essere fatte con i numeri davanti, non con le sensazioni.

La domanda da portarsi nel comitato finanziario dei prossimi mesi è semplice. Quanto consumeranno realisticamente i nostri agenti AI fra 24 mesi, quando saranno integrati nei processi e gli utenti li useranno davvero? E a quel volume, qual è il TCO più basso dove la nostra compliance e la nostra sovranità del dato restano garantite?

Hardware per LLM locale 2026: Mac, NVIDIA, costi reali

Tre anni fa, “far girare un LLM in locale” significava possedere una workstation con due NVIDIA H100, sapere cosa fosse vLLM, e accettare che il tutto sarebbe stato comunque più lento e meno preciso di una qualsiasi chiamata API a GPT-4. Era un esercizio da ricercatori, da appassionati, da aziende con budget infrastrutturali serissimi.

Nel 2026 il quadro è cambiato. Un Mac Mini M4 Pro da 1.799 euro fa girare Llama 3.3 70B a quantizzazione aggressiva, a 5-10 tokens al secondo, sufficiente per la quasi totalità dei task aziendali batch. Un Mac Studio M4 Max a 4.000 euro arriva a 30-45 tok/s sui modelli da 70B. Una workstation NVIDIA con RTX 5090 supera i 100 tok/s. E sotto, una nuova categoria di mini PC ottimizzati per AI sta emergendo come alternativa serissima, con NVIDIA DGX Spark, AMD Strix Halo, Framework Desktop.

Da quando ho cofondato LocalAI.io mi capita ogni settimana di rispondere alla stessa domanda da CTO italiani: “Quale hardware per LLM locale mi serve per cominciare?”. La risposta dipende da tre variabili che vanno tenute insieme, e che voglio provare a smontare in questo articolo: che modelli volete far girare, quanti utenti simultanei dovete servire, quanto budget e quanto tempo siete disposti a investire nell’ops.

Cosa determina davvero la velocità di un LLM in locale

C’è una metrica che vale più di tutte le altre quando si parla di inferenza LLM: la banda di memoria. Non la potenza di calcolo, non i TFLOPS, non i CUDA cores. È la banda con cui il chip riesce a leggere i pesi del modello dalla memoria, perché generare un token nuovo richiede di leggere TUTTI i pesi del modello, ogni volta. Un modello da 70 miliardi di parametri quantizzato a 4 bit pesa 35-40 GB, e ogni token generato è una passata completa di quei 40 GB.

Su questo dato si gioca la partita fra Apple Silicon e NVIDIA. Una RTX 4090 ha 1.008 GB/s di banda di memoria. Un M4 Max arriva a 546 GB/s, un M4 Pro a 273 GB/s, un M4 base a 120 GB/s. Significa che, modello per modello, NVIDIA è 2-3 volte più veloce di Apple Silicon top di gamma sui token al secondo. Però Apple Silicon ha un asso che NVIDIA non ha: la memoria unificata. Un Mac Studio M4 Max con 128 GB di RAM unificata fa girare modelli che non entrano in nessuna GPU consumer NVIDIA, neanche la 5090 da 32 GB. Per le aziende che vogliono lavorare con modelli da 70B in alto, Apple resta spesso l’unica opzione consumer.

Una nota di realismo importante. Apple sta arrivando con M5 Max e M5 Ultra previsti per fine 2026 con banda di memoria che dovrebbe superare 1 TB/s e tensor core FP8 nativi nel Neural Engine. Se le anticipazioni reggono, il gap di throughput per token con NVIDIA H100 si chiuderà quasi del tutto sull’inferenza, e l’asso della memoria unificata resterà comunque sul tavolo.

Quattro fasce hardware e cosa ci fate dentro

Provo a mappare quattro fasce di setup, dalla più accessibile alla più seria, con i numeri reali di throughput misurati con LLMCheck e altre fonti pubbliche aggiornate a maggio 2026.

Fascia 1: laptop e Mac Mini base, sotto i 1.000 euro. Un MacBook Air M2/M3 con 16 GB, un Mac Mini M4 base 16 GB, un mini PC NUC con CPU recente e 32 GB RAM. Modelli che ci girano bene: Phi-5 Mini, Llama 3.2 3B, Qwen 2.5 7B in quantizzazione Q4. Velocità tipica 40-80 tok/s sui modelli piccoli. Adatto a sperimentare, fare RAG su piccoli corpus documentali, sviluppare prototipi. Non adatto a produzione aziendale seria, non adatto a servire più utenti simultanei.

Fascia 2: workstation singolo utente, 1.500-3.000 euro. Mac Mini M4 Pro 24 GB o 48 GB. PC desktop con RTX 4070/4080. Modelli che girano: Llama 3.3 14B, Mistral Small, Qwen 4 32B-A3B (modello MoE con 3B parametri attivi, eccellente rapporto qualità/velocità sul Mac), Gemma 4 26B. Velocità tipica 25-55 tok/s sui modelli 14-32B. Adatto a uno sviluppatore singolo, a piccolo team che condivide, a applicazioni interne con pochi utenti. Il Mac Mini M4 Pro 48 GB a 1.799 euro è il punto di equilibrio prezzo-prestazioni che consiglio più spesso oggi a chi inizia.

Fascia 3: workstation potente, 4.000-7.000 euro. Mac Studio M4 Max con 64 GB o 128 GB. PC desktop con RTX 4090 o 5090 (32 GB VRAM). Modelli che girano: Llama 3.3 70B Q4 a 30-45 tok/s sul Mac Studio, Qwen 4 70B, DeepSeek R2 in versione compressa. Adatto a produzione interna seria su 10-50 utenti, a serving di applicazioni RAG complesse, a fine-tuning leggero. È la fascia dove Apple Silicon vince per memoria, NVIDIA vince per pura velocità, e la scelta dipende molto dal vostro mix specifico di modelli e workload.

Fascia 4: server-class, 15.000 euro in su. Mac Studio M3 Ultra con 256 GB (per workload memoria-bound). Server NVIDIA con due o quattro RTX 5090 in parallelo, oppure singola H100 da 80 GB. Apple offre DGX Spark, NVIDIA i sistemi DGX. Adatto a piccole-medie aziende che vogliono servire il proprio strato AI internamente a centinaia di utenti, a fine-tuning serio, a training di modelli specializzati piccoli. È la zona dove il ragionamento smette di essere consumer-DIY e diventa decisione infrastrutturale aziendale, con tutto quello che comporta in termini di networking, raffreddamento, alimentazione, backup.

Una scelta concreta per ogni profilo aziendale

Vorrei provare a passare dalle tabelle astratte a tre scenari aziendali che ho visto in concreto negli ultimi mesi, e dire cosa consiglierei in ciascuno.

Studio professionale, 10-30 dipendenti, vuole fare AI privata per RAG su documenti interni. Mac Mini M4 Pro 48 GB, modello Llama 3.3 14B o Qwen 4 32B-A3B. Costo totale 1.800 euro una tantum più il tempo di setup. Stack: Ollama come motore di inferenza, LocalAI come gateway compatibile OpenAI, un vector database come Qdrant in Docker per il RAG. Tempo medio di setup completo: una giornata di lavoro per uno sviluppatore che sa cosa fa. Sufficiente per 5-15 utenti simultanei con interazioni occasionali, non per una chat sempre attiva di 30 persone.

Azienda manifatturiera, 100-300 dipendenti, vuole un agente AI interno con accesso a documenti tecnici e gestionale. Mac Studio M4 Max 128 GB, modello Llama 3.3 70B Q4. Costo totale 4.000-5.000 euro hardware. Setup più articolato: LocalAI per orchestrare modelli multipli (uno per chat conversazionale, uno specializzato sui documenti tecnici), Qdrant o Weaviate per la memoria vettoriale, n8n o Make per le integrazioni con i sistemi aziendali. Tempo di setup completo realistico: una settimana di lavoro di un team da 2 persone. Capacità: 30-50 utenti simultanei.

Azienda servizi finanziari medio-piccola, 50-150 dipendenti, vuole un sistema AI con vincoli GDPR strettissimi. Qui non è solo hardware, è architettura completa. Server con 2x RTX 5090 o singola H100 in colocation italiana, modello Qwen 4 70B o Mistral Large, stack di sicurezza completo con SSO, audit log, segmentazione di rete. Costo hardware 20-30k euro, costo annuale di hosting e operations 30-50k. Setup: 4-6 settimane di lavoro di un team specializzato, magari con il supporto di chi conosce il dominio (qui entra il valore dell’advisory). Capacità: 100-300 utenti simultanei con alto livello di compliance.

Il problema dei costi nascosti

Le aziende che valutano l’AI privata guardando solo al costo dell’hardware sbagliano la metà del calcolo. L’altra metà sono tre voci che spesso non finiscono nei business case ma esistono comunque.

La prima è l’elettricità. Una RTX 5090 sotto carico consuma 575 watt. Un Mac Studio M4 Max si ferma a 130 watt. Su un anno di utilizzo continuativo, parliamo di una differenza di 1.500-2.000 euro l’anno solo di bolletta italiana. Il Mac è in questo molto più efficiente, ed è uno dei motivi per cui molte PMI italiane ci stanno arrivando.

La seconda è il tempo di setup e di manutenzione. Una RTX 5090 richiede driver CUDA, configurazione di vLLM o llama.cpp, tuning della quantizzazione, debugging di edge case su modelli specifici. Un Mac Mini con Ollama va da zero al primo prompt in dieci minuti. Per un’azienda piccola, il tempo del proprio sviluppatore è la voce più costosa di tutte: vale la pena pagarla anche 500 euro in più all’hardware se questo significa risparmiare due giorni di setup.

La terza è il rinnovo. L’hardware AI sta evolvendo velocemente. Un acquisto di oggi è probabilmente sostituibile entro 3 anni con qualcosa di significativamente meglio. Vale la pena pensare il setup in modo modulare, dove l’orchestrator (LocalAI), il vector DB, gli agenti, sono indipendenti dal motore di inferenza sottostante, così quando arriva la prossima generazione di chip si cambia solo quello.

Il software che fa la differenza

L’hardware è metà del lavoro. L’altra metà è lo stack software che ci gira sopra, ed è dove negli ultimi 12 mesi è cambiato tutto. Tre componenti vanno scelti bene fin dall’inizio.

Il motore di inferenza. Ollama è la scelta più semplice per cominciare, perfetto per Mac e PC, ha l’API compatibile OpenAI, supporta MLX su Apple Silicon dalla versione 0.5. Llama.cpp è la base sotto Ollama, più tecnico, dà più controllo. vLLM è per setup server seri con GPU NVIDIA, supporta batching e ha throughput superiore per più utenti. MLX è il framework Apple ottimizzato per Metal, può essere 30-50% più veloce di Ollama su Mac per alcuni modelli. La scelta dipende dal vostro hardware e dal team che dovrà manutenerlo.

L’orchestratore. Qui è dove entra LocalAI. Senza un orchestratore, ogni applicazione del vostro stack chiama direttamente Ollama o vLLM, e quando volete cambiare modello dovete ritoccare ogni client. Con un orchestratore, esponete un unico endpoint compatibile OpenAI, ci puntate tutte le applicazioni, e potete scambiare il motore sotto, gestire più modelli in parallelo, fare A/B testing, aggiungere autenticazione e logging. È il single point of integration che vi salva mesi di refactor quando l’hardware sotto cambia.

Il vector database per il RAG. Qdrant è la scelta più equilibrata oggi, gira bene su hardware modesto, ha buona documentazione, supporta filtri complessi. Weaviate è più potente ma più pesante. Chroma è il più leggero per iniziare ma scala meno. La scelta qui dipende dalla dimensione del corpus documentale che pensate di gestire.

Da dove cominciare se siete una PMI italiana

Se siete il CTO di una PMI italiana e state pensando di portare l’AI in casa, il mio consiglio è ridurre il primo step alla minima espressione possibile. Comprate un Mac Mini M4 Pro 48 GB. Installateci Ollama in dieci minuti. Scaricateci sopra Llama 3.3 14B o Qwen 4 32B. Apriteci sopra LocalAI come gateway. Provate una settimana con un caso d’uso piccolo, magari un agente che risponde a domande sul vostro manuale aziendale via RAG. Misurate latenza, qualità delle risposte, soddisfazione degli utenti.

Se la prova regge, scalate. Se non regge, avete speso 1.800 euro e una settimana di tempo per imparare cosa serve davvero. Confronto con un POC su OpenAI o Anthropic che, fra licenze enterprise e committment iniziale, sarebbe costato spesso di più senza darvi controllo dell’infrastruttura.

L’AI privata oggi non è più un esperimento da ricercatori. È una scelta di architettura accessibile, con costi noti e curva di apprendimento ragionevole, soprattutto per chi parte dai modelli open-weight più solidi (Llama, Mistral, Qwen) e da uno stack software maturo (Ollama, LocalAI, Qdrant).

Per chi vuole capire come si costruisce concretamente l’ecosistema sopra l’hardware, ho scritto una guida completa a LocalAI qualche mese fa, e nelle prossime settimane pubblicherò una guida operativa step-by-step all’installazione completa in azienda. Per chi sta valutando il setup giusto rispetto alle proprie necessità specifiche, c’è la pagina Advisory con i formati di lavoro che propongo.

La domanda da farsi oggi non è più “siamo pronti per l’AI privata”. È: che modello vogliamo far girare per primo nei nostri processi, e su che hardware lo facciamo girare nei prossimi sei mesi?

GDPR e LLM: quando un dato aziendale esce di casa

Il 18 marzo 2026 il Tribunale di Roma ha annullato la sanzione da 15 milioni di euro che il Garante per la protezione dei dati personali aveva irrogato a OpenAI nel novembre 2024 per la gestione di ChatGPT. Sentenza 4153/2026, motivazioni non ancora depositate, solo dispositivo. Quella sanzione era diventata, in due anni, il caso simbolo del rapporto fra GDPR e LLM. Adesso è caduta, e con lei l’idea che bastasse un provvedimento del Garante a chiarire i confini fra normativa europea e AI generativa americana.

Però il problema giuridico resta intatto: quando un dipendente di un’azienda italiana scrive il nome di un cliente dentro ChatGPT o Claude per riassumere un contratto, quel dato attraversa l’Atlantico, finisce in un’infrastruttura americana, viene processato da un modello di cui non controlliamo i dataset di training, e torna indietro come output. Sopra questo flusso si sovrappongono GDPR, AI Act, Schrems II, Data Privacy Framework, decisioni dei garanti nazionali, sentenze dei tribunali. Il risultato per chi lavora in azienda è una tela densa di vincoli che cambiano spesso, raramente in modo sincronizzato, e ognuno applicabile a casi specifici che non sempre il giurista interno riesce a circoscrivere bene.

Mi capita spesso, lavorando come advisor con CEO e CTO italiani, di sentire la stessa domanda formulata in modi diversi: ma alla fine, posso usare OpenAI sui dati dei miei clienti, o no? La risposta breve è che dipende, e quel dipende è dove si sta giocando una partita seria fra sovranità giuridica europea e dominanza tecnologica americana. Vorrei provare a dare una mappa praticabile, da imprenditore che ha visto il problema dal vivo, non da giurista.

Cosa dice il GDPR di un dato che entra in un LLM

Il GDPR è del 2016, è entrato in applicazione nel 2018, e nessuno dei suoi articoli è stato scritto pensando ai large language model. Però i suoi principi cardine restano applicabili a qualsiasi trattamento di dati personali, e un prompt che contiene il nome di una persona, l’indirizzo di un’azienda, una mail di un fornitore, una pratica medica, sono tutti dati personali ai sensi dell’articolo 4.

Quattro dimensioni del GDPR si attivano quando un dato personale finisce dentro un LLM cloud: la base giuridica del trattamento (articolo 6), la trasparenza nei confronti dell’interessato (articoli 12-14), la minimizzazione del dato (articolo 5), e il trasferimento internazionale verso paesi terzi (capitolo V, articoli 44-50). Il caso ChatGPT ha attivato tutte e quattro: il Garante italiano contestava a OpenAI di non avere una base giuridica adeguata per addestrare il modello sui dati personali, di non aver dato informativa agli interessati, di non aver implementato sistemi di age verification, e di trasferire dati verso gli Stati Uniti.

Il punto più sottile, però, è il quarto. Schrems II ha invalidato nel luglio 2020 il Privacy Shield che fino ad allora regolava il flusso di dati UE-USA. Da quel momento, ogni azienda europea che usa un servizio americano deve fare una valutazione caso per caso del rischio di sorveglianza governativa, deve adottare clausole contrattuali standard rafforzate, deve implementare misure tecniche supplementari come la cifratura end-to-end con chiavi che restano in UE. Nel luglio 2023 è arrivato il Data Privacy Framework, terzo tentativo dopo Safe Harbor e Privacy Shield, e Max Schrems ha già annunciato che lo porterà nuovamente davanti alla Corte di Giustizia. La storia, vista dall’esterno, sembra un loop che continua a non chiudersi.

Il caso ChatGPT e cosa è successo davvero

Vale la pena ricostruire il caso in tre passaggi, perché segna lo stato dell’arte del rapporto fra LLM e GDPR in Italia.

Marzo 2023: il Garante blocca temporaneamente ChatGPT in Italia per la prima volta. OpenAI si adegua su quasi tutti i punti contestati, il servizio viene riattivato dopo qualche settimana. Dicembre 2024: il Garante conclude l’istruttoria e sanziona OpenAI per 15 milioni di euro, ordinando anche una campagna informativa di sei mesi. Marzo 2026: il Tribunale di Roma annulla la sanzione, sentenza 4153/2026. Le motivazioni non sono ancora pubbliche al momento in cui scrivo, però il dispositivo è chiaro: la sanzione cade integralmente.

Cosa significa per chi deve decidere oggi se usare ChatGPT, Claude o Gemini sui dati aziendali? Tre cose, secondo me. La prima è che lo strumento sanzionatorio del Garante è meno solido di quanto sembrasse: i tribunali stanno mostrando di poter ribaltare provvedimenti anche molto strutturati. La seconda è che il fatto stesso che il caso sia arrivato fino qui dimostra quanto la materia sia controversa, e che ogni azienda italiana resta esposta a contestazioni se non struttura bene la propria posizione documentale. La terza è la più importante: l’annullamento della sanzione non significa che il trattamento sia lecito, significa solo che quel provvedimento specifico non reggeva. Il sostrato GDPR resta in piedi, e il prossimo caso può essere il vostro.

Le quattro verticali italiane dove il problema è già operativo

Negli ultimi diciotto mesi ho seguito direttamente o di sponda progetti in quattro settori italiani dove l’uso degli LLM cloud sta già generando attriti giuridici concreti. Vorrei riportare cosa ho visto succedere.

Banche e finanza. Le grandi banche italiane hanno tutte progetti AI attivi, però il commitment legale è massimo. Le sandbox interne usano modelli open-weight in infrastruttura privata. L’uso di ChatGPT o Claude su dati di clientela è proibito per policy nella stragrande maggioranza dei casi. Le DPIA (Data Protection Impact Assessment) sono diventate documenti corposi, con sezioni dedicate ai modelli AI, e gli ispettori di Banca d’Italia stanno cominciando a chiederle. Per le banche medio-piccole, che non hanno il budget per un’infrastruttura AI privata, il dilemma è reale: aspettare l’evoluzione normativa, o cominciare con il cloud accettando il rischio. La risposta che vedo emergere è terza: AI privata su Mistral, Llama o modelli simili, gestita on-premise o su cloud sovrano italiano.

Sanità. Qui la sensibilità è massima per ovvi motivi: i dati sanitari sono categoria particolare ai sensi dell’articolo 9 GDPR. Le aziende sanitarie pubbliche e private che ho visto adottare LLM stanno tutte andando su soluzioni private. Niente ChatGPT, niente Claude.ai dalla finestra del browser. Strumenti AI integrati nei gestionali clinici, con modelli fine-tuned su dataset sanitari e infrastruttura sotto controllo dell’azienda. Il vincolo qui è doppio: GDPR più normativa specifica sanitaria, e nessun primario è disposto a mettere la firma su un trattamento dove il dato esce dal perimetro ospedaliero.

Pubblica amministrazione. Il PSN (Polo Strategico Nazionale) e l’Agenzia per la Cybersicurezza Nazionale stanno dettando linee guida sempre più stringenti sull’uso di AI nei processi della PA. La direzione è chiara: dati pubblici dei cittadini italiani devono restare in cloud sovrani, su infrastrutture nazionali. Questo apre uno spazio commerciale enorme per soluzioni AI private che possano installarsi dentro il perimetro PSN. Diverse software house italiane si stanno posizionando su questo, e ho il sospetto che nei prossimi diciotto mesi vedremo accelerazione forte.

Manifattura e proprietà intellettuale. Qui il problema non è solo il dato personale, è il segreto industriale. Aziende manifatturiere italiane che caricano disegni tecnici, formule, processi produttivi dentro ChatGPT per chiedere ottimizzazioni stanno regalando informazioni potenzialmente strategiche a un fornitore che, per quanto contrattualmente impegnato a non trainare sui dati enterprise, opera comunque sotto giurisdizione americana. Il punto qui sfora dal GDPR, va su trade secret, segreto industriale, sicurezza economica nazionale. Però è una conversazione che adesso i CTO italiani fanno con i CEO, e prima non si faceva.

La banca italiana che voleva sapere dove gira il modello

Racconto una scena reale, leggermente anonimizzata. Lavoro nel 2025 con il team innovazione di una banca italiana medio-grande che sta valutando di adottare un sistema AI generativa per la customer assistance. Il fornitore propone un’integrazione standard con un grande modello cloud americano. Il responsabile compliance, dopo aver letto il contratto, chiede una cosa apparentemente semplice: “Possiamo avere certezza che, quando un nostro consulente filiale interroga il sistema con il nome di un cliente per ricostruire la sua posizione, quel nome non passi per un data center fuori dall’Unione?”. Il fornitore impiega due settimane per rispondere, poi torna con una soluzione ibrida che usa pre-processing locale e poi chiama il modello cloud su dati anonimizzati. Funziona, ma costa il doppio del setup originale, e introduce latenza.

Quella domanda era la domanda giusta, ed è la domanda che oggi fanno i clienti sofisticati durante le RFP. Se la vostra applicazione AI non sa rispondere bene a quella domanda, perde la gara. E rispondere bene, sempre più spesso, significa: “Il modello gira nella nostra infrastruttura, sotto controllo italiano, mai i dati escono dal perimetro”.

L’unica architettura che chiude il problema alla radice

Ci sono tre modi di gestire la conformità GDPR su un’applicazione AI in produzione. Il primo è usare un grande LLM cloud americano e costruire un apparato documentale e contrattuale robusto (DPIA, clausole contrattuali, registro dei trattamenti, valutazione TIA per il trasferimento dati). Funziona, ma è costoso da mantenere, e ogni cambio di policy del fornitore impone una nuova valutazione. Il secondo è usare un LLM cloud europeo, tipo Mistral hostato in Francia. Mitiga il problema del trasferimento extra-UE, ma non lo elimina del tutto perché Mistral comunque processa dati su infrastruttura cloud condivisa. Il terzo è portare il modello in casa, on-premise o su cloud privato sotto controllo aziendale.

Il terzo modo, che fino a due anni fa era proibitivo per ragioni di capex hardware e complessità operativa, oggi è alla portata di aziende dai 50 dipendenti in su. I modelli open-weight (Llama 3.3, Mistral, Qwen, DeepSeek) sono molto vicini alle prestazioni dei top di gamma cloud sui task aziendali standard. L’hardware necessario per farli girare in locale è sceso a una frazione di quello che serviva nel 2023. E lo stack software per orchestrarli sta maturando rapidamente.

Su questo terreno ho investito personalmente, come cofondatore di LocalAI.io. LocalAI è un progetto open-source che permette di costruire ecosistemi di AI privata partendo dai modelli open-weight esistenti, con tutto lo stack che serve per portare un prodotto in produzione: gateway compatibile con le API OpenAI, gestione di modelli multipli, RAG, agenti con memoria, deployment on-premise o su cloud privato italiano. È usato in produzione da aziende che hanno deciso di avere il proprio strato AI in casa, e da team che vogliono mantenere la flessibilità di cambiare modello senza rifare il prodotto.

La conversazione su GDPR e LLM nel 2026 si è spostata. Da terreno legale astratto è diventata terreno di architettura concreta. Le aziende italiane che capiscono questo, e che spostano il proprio stack AI dentro un perimetro controllato, eliminano alla radice il 70-80% delle questioni che oggi tengono sveglio il responsabile DPO. Le altre continueranno a discutere clausole contrattuali con i fornitori americani, a stipulare TIA che invecchiano dopo pochi mesi, a sperare che il prossimo accordo UE-USA regga davanti alla Corte di Giustizia. È legittimo, ma è un modo molto laborioso di costruire un prodotto AI serio.

Per chi sta vivendo questa decisione, ho scritto la settimana scorsa un articolo che riassume le dieci ragioni per portare l’AI privata al tavolo del board, e dopo questo articolo ne pubblicherò altri sul tema (TCO, scelta del modello open-weight, AI Act ad agosto 2026). Per una conversazione diretta sul vostro caso specifico, c’è la pagina Advisory.

La domanda finale, quella che vale la pena tenere davanti quando si decide oggi su un progetto AI aziendale, è semplice. Volete che la vostra compliance GDPR dipenda da una sentenza che può arrivare fra tre anni, da un accordo UE-USA che può essere annullato fra cinque, da un fornitore americano che può cambiare le sue policy fra tre mesi? Oppure preferite costruire il vostro prodotto sopra un’infrastruttura che resta sotto il vostro controllo, dove la conformità è una proprietà strutturale invece di un esercizio documentale continuo?

Fine della consulenza? McKinsey cambia il rate dei partner

Tutti hanno notato la cifra, forse, ammesso che abbiate ascoltato il podcast. E quasi tutti hanno parlato di fine della consulenza guardando il dato sbagliato.

A gennaio 2026, sul podcast All In, Bob Sternfels (global managing partner di McKinsey) ha dichiarato che la sua azienda conta 60.000 dipendenti, di cui 25.000 agenti AI a fianco di 40.000 umani, con l’obiettivo di raggiungere la parità entro fine anno. La notizia è stata ripresa in tutto il mondo come prova che la consulenza strategica sta automatizzandosi più in fretta di qualsiasi altro settore knowledge-intensive.

C’è chi ha tirato fuori il termine “fine della consulenza” e chi, dall’altra parte, ha sminuito ricordando che i concorrenti EY e PwC parlano di poche unità di agenti capaci di fare il lavoro pesante senza bisogno di scalare a 25.000.

Trovo che entrambe le narrazioni siano interessanti, e in larga parte sbagliate. La notizia vera, secondo me, è arrivata pochi giorni fa, a metà maggio, quando il Financial Times ha riferito che McKinsey sta riducendo la quota cash della remunerazione dei partner per spostarne una parte maggiore in equity. È una notizia di compensation, apparentemente tecnica, ed è quella che racconta cosa sta cambiando davvero in quel settore.

Provo a spiegare perché.

Cambiano le compensation

Per capire l’importanza del cambio compensation serve un veloce ripasso di come è strutturata storicamente una grande consulenza strategica. McKinsey, BCG, Bain, e le big four nella loro componente advisory, sono partnership professionali. Il modello economico è semplice e ha retto per decenni: si vendono ore di consulente, organizzate in progetti, fatturate a rate molto alte, calcolate su un mix di seniority. Il partner del progetto guadagna due cose: uno stipendio base relativamente contenuto, e una quota dei profitti annuali che dipende dal volume e dalla marginalità dei progetti che ha portato a casa. La quota di profitto è cash, distribuita ogni anno, e rappresenta storicamente la parte più sostanziosa della remunerazione.

Questo modello si regge su un assunto: che i ricavi siano sufficientemente prevedibili anno per anno. Se conosci più o meno quanto fatturerai e con quanta marginalità, puoi distribuire la maggior parte dei profitti subito ai partner senza creare instabilità finanziaria. Per anni questo è stato vero. I clienti grandi rinnovavano contratti, le tariffe orarie crescevano insieme all’inflazione, i progetti grandi si ripetevano. Non c’era bisogno di tenere capitale in azienda, perché il flusso di cassa era stabile.

Adesso quel flusso sta diventando volatile, per due ragioni che la mossa McKinsey rende esplicite. Primo: l’AI sta comprimendo le ore necessarie per fare il lavoro. Se un team che prima fatturava 5.000 ore per un progetto adesso ne fattura 2.000 perché 3.000 le fanno gli agenti, la base imponibile del fatturato si riduce. Secondo: il pricing si sta spostando dal time & materials all’outcome-based. Anziché vendere ore, McKinsey sta provando sempre di più a vendere risultati specifici, legando una parte significativa del compenso al raggiungimento di obiettivi misurabili per il cliente. Risultato? I ricavi diventano più discontinui e più rischiosi.

In un modello a remunerazione cash di anno in anno, la combinazione di queste due tendenze è esplosiva. Un cattivo anno svuota la partnership. Quindi bisogna tenere più capitale in azienda, distribuirne meno subito, dare ai partner una partecipazione che si valorizza nel tempo invece di pagarli a profitti annuali. Da qui lo spostamento in equity.

Perché la notizia conta più del numero degli agenti

Se prendi il numero 25.000 agenti, è una cifra grande ma di marketing. Conta cosa fanno e quanto valore generano davvero, e su questo le testimonianze esterne sono variegate. Il global engineering chief di EY, Steve Newman, ha commentato in modo pungente che “alcuni dei migliori risultati che abbiamo arrivano da una manciata di agenti che fanno il lavoro pesante” e che il numero di agenti, di per sé, non si traduce automaticamente in valore. EY parla di “una manciata” di agenti che producono il valore reale, BCG dichiara che l’AI consulting sarà il 20% dei suoi ricavi 2024, Accenture ha riorganizzato cinque unità nella nuova “reinvention services”. Ogni big sta giocando una partita diversa.

Il cambio compensation, invece, è una decisione strutturale che dice una cosa precisa: McKinsey ha smesso di scommettere sulla prevedibilità del proprio business e ha cominciato a gestirsi come un’azienda con ricavi volatili. È la mossa di un’azienda che si sta riorganizzando per affrontare un decennio diverso, non per gestire una transizione di breve.

Tradotto in linguaggio operativo: la consulenza più elite del mondo ha appena ammesso pubblicamente che il proprio modello di ricavo non sta più funzionando come prima. Per un settore che vive di certezze trasmesse al cliente, è un’ammissione importante.

E chi fruisce della consulenza cosa deve valutare?

Per chi guida un’azienda italiana e ha rapporti consolidati con grandi società di consulenza, ci sono tre conseguenze pratiche da iniziare a osservare nei prossimi mesi.

La prima è sui pricing. Il modello time & materials non scomparirà del tutto, ma diventerà sempre più residuale. Nelle nuove proposte ti aspetterai sempre più spesso una struttura mista: una parte fissa contenuta, una parte legata al raggiungimento di KPI predefiniti. È una buona notizia per chi compra, perché allinea gli incentivi del consulente con il valore generato. È anche una sfida nuova, perché obbliga a definire ex ante quali sono gli outcome misurabili, e questo richiede una capacità di scoping che molte aziende clienti non hanno ancora sviluppato.

La seconda è sulla struttura dei team. Se le ore si riducono e gli agenti AI fanno parte del lavoro analitico, il team di progetto che ti arriva sarà più snello. Meno junior, più senior consultant che orchestrano agenti. Per il cliente, questo cambia la dinamica di interazione quotidiana, perché spariscono i punti di contatto routinari, gli incontri operativi di follow-up, le revisioni intermedie che fino a ieri tenevano il progetto incollato alla tua organizzazione. C’è un rischio di disconnessione che va gestito con governance esplicita.

La terza è sui contenuti. Quando una consulenza ti vende un outcome, ha incentivo a portarti la soluzione che funziona, non quella che fattura di più. È un’inversione che storicamente molti clienti hanno sperato e raramente ottenuto. La domanda diventa: come misuriamo davvero l’outcome? Se la definizione del successo la scrive il consulente, sarà tarata in modo da renderlo raggiungibile. Se la scrivi tu cliente, devi avere chiaro cosa stai chiedendo, e questa è di nuovo una capacità interna che va costruita.

Il pezzo che mi convince meno

Una cosa che leggo in molti commentatori, e che secondo me è prematura, è che la consulenza tradizionale stia per essere disintermediata dagli stessi modelli AI che le grandi società stanno usando. La logica è: se McKinsey usa Claude per fare le sue analisi, perché io cliente non posso usare Claude direttamente e saltare McKinsey?

La logica funziona, ma solo per una fetta del lavoro che la consulenza fa. La parte di sintesi documentale, ricerca di mercato strutturata, benchmark settoriale, è effettivamente sempre più replicabile in autonomia con un buon prompt e un team interno competente. Quella parte sta scomparendo dalla value proposition delle consulenze, e infatti i partner di McKinsey lo stanno già dicendo apertamente.

Ma c’è una parte che resta scarsa e che non si comprime: l’autorità simbolica del consulente esterno nelle decisioni difficili. Quando un board deve prendere una decisione che spaccherà il management, una società di consulenza serve a fornire copertura politica più che analitica. Quando una famiglia proprietaria deve fare la transizione generazionale, serve una voce terza che dia legittimità alla scelta. Quando un CFO deve giustificare una ristrutturazione, serve un report con un logo riconoscibile. Tutto questo l’AI non lo sostituisce, perché non è informazione, è autorità. E l’autorità si costruisce con persone, relazioni, presenza fisica nei posti che contano.

Il cambio compensation di McKinsey, in questa lettura, ha senso. La consulenza non sparisce ma si sdoppia. Una parte commodity, sempre più automatizzata e a basso margine. Una parte high-touch, fatta di partner senior che vendono autorità e relazioni in situazioni dove conta più chi parla di cosa dice. È sulla seconda parte che si concentreranno gli equity stake. La prima parte, in qualche anno, sarà gestita quasi interamente da agenti, e questo i partner di McKinsey lo sanno bene.

Fine della consulenza o solo del suo vecchio modello?

Se questo è lo scenario, allora chi prende consulenza in Italia farebbe bene a chiedersi due cose, oggi. La prima: sto pagando per la parte commodity o per la parte high-touch? Se il mio rapporto con la consulenza è prevalentemente fatto di deliverable analitici, ricerche, benchmark, decking, allora sto pagando una cosa che fra tre anni potrò fare da solo con un team minuscolo armato di buoni agenti, magari su un’infrastruttura di AI privata sotto il mio controllo. Conviene cominciare ad attrezzarsi adesso, prima che il mercato si riallinei. La seconda: sto comprando vera autorità decisionale, e se sì, da chi? Perché la promessa di autorità del brand consulenza tradizionale dipende dalla stabilità del modello che la sosteneva. Se il modello cambia, anche l’autorità si rinegozia.

Da imprenditore che vede passare diverse aziende attraverso questi rapporti, dico che il vero rischio non è essere disintermediati. Il rischio è continuare a pagare la consulenza come se non stesse cambiando, mentre dall’altra parte i partner di McKinsey hanno già accettato che il loro mondo è cambiato e si stanno organizzando di conseguenza. Quando il fornitore si ristruttura prima del cliente, il cliente paga il conto della ristrutturazione del fornitore. È sempre andata così. Lo è ancora di più adesso, con tutta questa AI in mezzo.

Se volete ragionare su come attrezzarvi, lavoro esattamente su questo nei percorsi di advisory.

Manus AI, la guida completa per le aziende: agente, costi, governance

Cosa significa “agente autonomo” davvero

Per capire Manus AI c’è una distinzione che sembra banale e invece fa tutta la differenza. ChatGPT, Claude, Gemini sono assistenti conversazionali: il ciclo è prompt-risposta, e chi guida il processo resta sempre l’utente, che decompone il problema, lancia richieste in sequenza, ricompone i risultati a mano. Manus rompe questo schema. Riceve un brief in linguaggio naturale, costruisce un piano di esecuzione visibile, e parte da solo, pianifica i passi, apre un browser, esegue ricerche, scarica file, esegue codice, salva risultati, consegna un artefatto finale.

A raccontarlo così sembra una sfumatura semantica, in pratica è un cambio di paradigma, ed è la prima cosa da mettere a fuoco su Manus AI. La documentazione ufficiale di Manus parla di “virtual colleague with its own computer”, e l’immagine rende. L’agente vive in una sandbox Linux Ubuntu completa, con shell, file system persistente, browser Chromium, interpreti Python e Node.js, e può perfino esporre servizi web all’esterno. La parte tecnica più interessante, raccontata in dettaglio dal post di E2B che fornisce l’infrastruttura, è che ogni sessione gira su microVM Firecracker, le stesse macchine virtuali leggere sviluppate da AWS per Lambda. Il risultato pratico è che l’agente può lavorare per decine di minuti, anche un’ora, mantenendo lo stato tra un passo e l’altro, persino quando il dispositivo dell’utente è spento.

Questo cambia il modo in cui si chiede a Manus di fare qualcosa. Un prompt per ChatGPT richiede precisione sulla forma della risposta, perché il modello deve restituire un testo subito. Un brief per Manus richiede precisione sull’obiettivo finale e sui criteri di successo, perché il modello prenderà decine di micro-decisioni autonome durante l’esecuzione, senza poter chiedere conferma a ogni passaggio. È una scrittura più vicina a quella che useresti per un consulente esterno che riceve un brief e torna dopo due giorni con il dossier, non a quella che useresti per un assistente in chat. Tengo questa analogia per tutta la guida, perché è la chiave mentale che fa funzionare lo strumento.

Le due modalità e il pannello “Manus’s Computer”

Il prodotto si articola su due modalità. Chat Mode funziona come un assistente conversazionale tradizionale, costa pochissimi crediti, serve a domande veloci, sintesi rapide, ricerca puntuale. Agent Mode è la modalità autonoma vera, dove Manus prende il brief, costruisce il task plan, e parte. La differenza in termini di costi è netta, e va capita prima di iniziare a usare il prodotto in modo regolare, perché Chat Mode resta per molti utenti il novanta per cento dell’uso quotidiano.

L’elemento più distintivo dell’interfaccia è “Manus’s Computer”, un pannello laterale che mostra in tempo reale tutto ciò che l’agente sta facendo: quali pagine apre, cosa cerca, quali file scrive, quali comandi lancia nel terminale. Per chi viene da anni di chatbot dove tutto è invisibile, è un’esperienza diversa, si vede l’agente lavorare, si intercettano gli errori prima che compromettano l’intero task, si interviene spostandolo da una direzione sbagliata. Una review su Cybernews lo descrive come guardare un ricercatore al lavoro con una checklist davanti, ed è fedele.

Il punto delicato è che questa trasparenza si paga con una maggiore responsabilità di supervisione. Manus può sbagliare click sul browser, fraintendere un’istruzione, costruire un piano errato, e senza un occhio sul “Computer” l’agente consuma crediti per minuti producendo un output che alla fine non serve. La logica corretta è dargli un brief chiaro, lasciarlo lavorare, ma tenere sotto controllo i primi passi del piano. Se il piano iniziale regge, di solito l’esecuzione regge. Se è sbagliato, meglio fermarsi e riformulare. La regola pratica, ad ogni nuovo task, è chiedersi quanti strumenti diversi userei se facessi io questo lavoro: se la risposta è uno, basta Chat Mode, se sono tre o più, vale la pena passare ad Agent Mode.

Come si scrive un brief per un agente autonomo

Un brief per Manus non è un prompt per ChatGPT, ed è la singola cosa che fa la differenza tra task riusciti e task abbandonati a metà esecuzione. Un prompt conversazionale è una richiesta puntuale a cui il modello risponde subito. Un brief per Manus è la descrizione di un risultato finale e dei criteri per riconoscerlo come riuscito.

Un esempio, partendo da una richiesta sbagliata: “fammi una ricerca sui competitor”. Manus parte, ma il piano è generico, l’output incerto, i crediti consumati senza un punto di arrivo chiaro. Lo stesso task in versione corretta: “produci un dossier su cinque competitor italiani nel settore X, per ognuno raccogli sede legale, fatturato ultimi due esercizi disponibili da bilanci pubblici, posizionamento dichiarato sul sito, principali clienti citati in case study, presenza su LinkedIn dei C-level. Output: un file markdown con cinque schede da una pagina ciascuna, link a tutte le fonti, e una tabella riassuntiva finale”. Stessa richiesta sostanziale, risultato completamente diverso.

La differenza è che il secondo brief specifica quattro cose che il primo lasciava implicite: il perimetro del task, i dati da raccogliere, la struttura dell’output, le fonti accettabili. Manus eccelle quando questi quattro vincoli sono chiari, perché può costruire un piano di esecuzione lineare. Quando uno solo dei quattro manca, l’agente deve indovinare, e gli indovinelli costano crediti. La documentazione ufficiale suggerisce di pensare a sé stessi come a un manager che assegna un compito a un collaboratore esterno, ed è un’analogia che vale la pena adottare mentalmente prima ancora di iniziare a digitare. C’è anche una funzione che conviene conoscere dalla prima sessione: l’agente può essere fermato in qualsiasi momento, e si interviene chiedendo correzioni puntuali, suggerendo alternative, fornendo credenziali quando il sito richiede login. Questa pausabilità è uno dei tratti che distinguono Manus dagli agenti puramente background.

Piani, crediti, costi: il modello economico

Manus usa un sistema a crediti, e questo cambia profondamente l’esperienza rispetto agli abbonamenti illimitati di ChatGPT Plus o Claude Pro. Il piano gratuito offre trecento crediti che si rigenerano ogni ventiquattr’ore, più mille crediti starter una tantum, con accesso al Chat Mode e a Manus 1.6 Lite in Agent Mode. Basta per testare il prodotto e capire se ha senso salire di piano.

I piani Pro partono da venti dollari al mese per quattromila crediti, salgono a quaranta dollari per ottomila crediti con accesso al Wide Research, e arrivano a duecento dollari per il piano top che porta i crediti mensili a quarantamila e abilita la generazione batch di slide e siti. Il piano Team parte da venti dollari per seat con un minimo di due membri, e introduce funzionalità di workspace condiviso. La fatturazione annuale taglia circa il 17 per cento. Per i numeri aggiornati c’è la pagina ufficiale dei piani, ma il dato che conta per ragionare sui costi è un altro: i crediti mensili non si accumulano da un mese all’altro, mentre quelli acquistati come add-on restano disponibili finché l’abbonamento è attivo. Una review su Spectrum AI Lab lo conferma analizzando le regole di rollover.

Il dato concreto che serve per dimensionare il budget: un task di ricerca semplice consuma intorno ai cinquanta-sessanta crediti, un’analisi dataset di media complessità ne brucia trecento, un dossier di Wide Research approfondito arriva a quattro o diecimila crediti in una singola esecuzione. Manus non stima il costo di un task prima di lanciarlo, e in caso di crediti insufficienti si ferma a metà esecuzione senza addebiti automatici di overage. Per le aziende il budgeting va dunque fatto a posteriori nelle prime settimane, finché il team non sviluppa un’intuizione sui costi tipici dei propri task ricorrenti. Un consiglio che do sempre: tenere un piccolo log dei task lanciati, con brief, esito, crediti consumati, perché dopo dieci o quindici task emergono i pattern, alcuni tipi di richiesta rendono bene e altri sono sistematicamente difficili, e quel log diventa la base per capire dove Manus sostituisce ore di lavoro e dove invece produce solo overhead di supervisione.

I limiti veri delle prime sessioni

Manus non è perfetto, e conviene saperlo in partenza per evitare delusioni mal indirizzate. I problemi più comuni nelle prime sessioni sono tre. L’agente a volte fraintende il brief e parte in una direzione sbagliata, fa click errati sul browser scegliendo elementi che sembravano giusti, e in task lunghi perde il filo del piano iniziale divergendo verso obiettivi secondari.

Il primo problema si risolve scrivendo brief più precisi. Il secondo è una limitazione tecnica, mitigata dal browser visivo che permette di vedere gli errori e correggerli, ma resta una causa frequente di crediti consumati senza output utile. Il terzo è il più insidioso, e si gestisce dividendo i task lunghi in sotto-task più piccoli, ognuno con un output ben definito, invece di chiedere all’agente di completare in una singola esecuzione una pipeline articolata. Una review approfondita su Lindy nota che Manus funziona bene su task con percorso lineare e meno bene su quelli con logica condizionale ramificata, ed è un’osservazione utile per calibrare le aspettative fin dall’inizio.

I task su cui rodarsi senza rischiare frustrazione, nelle prime settimane, sono tre. La ricerca strutturata multi-fonte, dove Manus apre decine di pagine e le legge integralmente, producendo risultati migliori di un assistente conversazionale. L’estrazione dati da fonti web, dove l’agente apre la pagina, esegue lo scraping, scrive uno script di parsing se serve, salva il CSV, e risolve in cinque o dieci minuti quello che a mano ne richiederebbe quaranta. La generazione di documenti formattati a partire da input strutturati, dove dato un file Excel con i risultati di una survey l’agente produce un report con grafici, executive summary, sezioni per ogni domanda. Questi tre pattern coprono buona parte del valore quotidiano di Manus per un manager, e funzionano come esercizi di apprendimento.

Projects e Connectors: l’agente che entra nello stack di lavoro

Fino a metà 2025 Manus aveva un problema strutturale: ogni sessione partiva da zero. L’agente non sapeva nulla del lavoro precedente, delle abitudini del team, delle conversazioni in corso, e andava istruito ogni volta. A dicembre 2025 è arrivata la prima risposta strutturale sotto forma di Projects con Connectors, ed è il momento in cui Manus smette di essere un tool per task estemporanei e inizia a operare dentro il proprio contesto.

Un Project è un workspace persistente che conserva istruzioni di base, file di riferimento, cronologia delle conversazioni correlate. Invece di spiegare ogni volta a Manus chi siete, cosa fa la vostra azienda, qual è il tono di voce, quali sono i clienti chiave, queste informazioni vivono dentro il Project e l’agente le richiama all’inizio di ogni nuovo task. La pagina ufficiale del lancio descrive l’idea di trasformare task ripetibili in spazi persistenti. L’impatto si manifesta in tre direzioni: la qualità degli output, perché con il contesto già caricato Manus produce risultati più allineati al brand e al settore, il risparmio di crediti, perché spariscono i passi che l’agente farebbe per capire il contesto, e la possibilità di delegare task ricorrenti a chi nel team ha meno familiarità con lo strumento, perché il Project incapsula la complessità.

Qui si gioca la partita vera dei Connectors. Un Project può collegarsi nativamente, via protocollo MCP, ai servizi che già si usano: Gmail, Notion, Stripe, HubSpot, Slack, Google Calendar, Hugging Face, Google Drive, GitHub, e l’elenco continua a crescere. MCP è lo standard aperto che Anthropic ha proposto nel 2024 e che si sta affermando come lingua franca per l’integrazione tra agenti e tool esterni, un tema legato a doppio filo a come si evita il vendor lock-in nei progetti AI enterprise. Un esempio concreto: con il connettore Gmail attivo si può chiedere a Manus di leggere le email ricevute negli ultimi cinque giorni dai clienti enterprise, identificare quelle con una richiesta esplicita di follow-up, produrre una sintesi per priorità. Manus legge davvero la posta, applica i filtri, restituisce la sintesi. Con Slack attivo si può chiedere di guardare il canale vendite delle ultime due settimane e riassumere le obiezioni ricorrenti dalle call. A maggio 2026 Manus ha aggiunto i Connector Recommendations, che identificano quando un task richiede un servizio non ancora collegato e suggeriscono di attivarlo dall’interfaccia, riducendo l’attrito di scoprire a metà task che mancava una credenziale.

La tentazione iniziale è creare un Project generico chiamato “lavoro” e usarlo per tutto. Funziona male, e dopo qualche settimana produce confusione. La logica corretta è creare Project ristretti per dominio o per processo, uno per la competitive intelligence, uno per la produzione di contenuti, uno per l’analisi del customer feedback, ognuno con istruzioni mirate e connettori selezionati. Sui connettori conviene restare minimali, perché ogni connettore amplia la superficie di accesso ai dati: un Project di ricerca pubblica non ha bisogno di Gmail collegato, uno di produzione contenuti non ha bisogno di Stripe. La regola del privilegio minimo si applica anche qui, e protegge da scenari dove l’agente, in un momento di confusione, accede a dati che non doveva toccare.

Wide Research, la funzione dove Manus stacca gli altri

Ci sono task per cui un chatbot non basta, e per cui anche una “deep research” come quella di ChatGPT o Perplexity resta in superficie. Sono i dossier che richiedono di aprire decine di pagine, leggerle integralmente, estrarre dati strutturati, confrontarli, citarli con riferimenti puntuali. Wide Research è la funzione di Manus AI pensata esattamente per questo, disponibile sui piani Pro da quaranta dollari mensili in su, ed è uno dei punti dove il prodotto mostra il suo vantaggio competitivo più chiaro.

L’agente entra in una sessione estesa, lavora per quaranta-ottanta minuti, apre decine o centinaia di pagine, mantiene uno stato persistente, salva risultati intermedi, consegna un dossier corposo. La differenza con le ricerche standard riguarda la durata, certo, ma soprattutto la profondità di lettura: invece di fermarsi agli snippet dei primi risultati, l’agente apre davvero le pagine e le legge per intero. Sul confronto con la “deep research” di altri vale la pena guardare i numeri con cautela. Un’analisi su The Planet Tools che ha testato Manus su GAIA, il benchmark di riferimento per agenti AI, riporta uno score dell’86,5 per cento sul livello uno, 70,1 sul livello due, 57,7 sul livello tre, contro il 74,3, 69,1 e 47,6 di OpenAI Deep Research. I benchmark di prodotto vanno presi con le pinze, ma indicano una direzione: su task di ricerca multi-step strutturati Manus si comporta in modo competitivo, e in alcuni scenari supera la concorrenza più affermata.

Le regole sul brief valgono qui con un’intensità maggiore, perché un brief vago per un task da cinquanta crediti produce uno spreco accettabile, mentre per un task da cinquemila crediti produce uno spreco doloroso. I quattro elementi che fanno la differenza sono il perimetro, la struttura dell’output, le fonti accettabili, i criteri di successo. Wide Research rende particolarmente bene su tre terreni. La competitive intelligence strutturata, dove l’agente apre siti aziendali, comunicati, press release, e produce dossier che a un analista umano richiederebbero due o tre giornate. La due diligence light, che non sostituisce quella formale ma serve a valutare preliminarmente una controparte, raccogliendo informazioni pubbliche, segnalando red flag, ricostruendo la storia del management, con la capacità di citare puntualmente le fonti costruendo un audit trail della ricerca. Il market scan e la ricerca regolatoria, dove serve coprire molte fonti istituzionali, paper, comunicati di authority, banche centrali, organismi europei.

Sui costi conviene dare cifre concrete, perché il modello a crediti rende facile sottostimare l’investimento finché non ci si trova il budget mensile bruciato a metà mese. Un dossier di complessità media consuma tra i mille e i tremila crediti, uno ad alta complessità arriva a quattromila o diecimila in un’unica esecuzione. Sul piano Pro da quaranta dollari con ottomila crediti mensili, un task ben dimensionato occupa il dieci per cento del budget, mentre uno fuori scala può cannibalizzare un mese intero. Il calcolo che vale la pena fare è quanto tempo umano risparmia il dossier: se un’analisi da otto ore viene prodotta in trenta minuti con duemila crediti, il ROI è evidente, se invece il dossier è di qualità scarsa e va integrato a mano per quattro ore, il calcolo si ribalta. Per i dossier davvero importanti, quelli destinati a riunioni con stakeholder esterni o a decisioni di investimento, conviene un pilot in piccolo: stessa struttura ma su due o tre soggetti invece di dieci, si valuta la qualità, si calibra il brief, poi si lancia il task completo.

Wide Research è la scelta sbagliata quando la fonte primaria è una sola e già nota, e allora conviene caricare il documento in Chat Mode o in un Project e ragionarci sopra. Lo è quando la ricerca richiede accesso a database proprietari come Bloomberg, Crunchbase Pro, Pitchbook, perché Manus non ha accesso nativo e produrrà un dossier basato su fonti pubbliche più povere. E non funziona quando la domanda è soggettiva e richiede un giudizio interpretativo che presuppone esperienza di settore, perché valutare se un’azienda è un buon target di acquisizione è una sintesi di mercato, finanza, competitive e fit culturale che richiede chi conosce il contesto strategico interno. Wide Research prepara il terreno, non prende la decisione.

Scheduled Tasks e Cloud Computer: l’agente che lavora anche di notte

C’è un momento, in chi inizia a usare Manus seriamente, in cui ci si accorge che il vero collo di bottiglia si sposta: dalla capacità dell’agente al tempo dell’utente che deve lanciare i task. Le riunioni occupano la mattina, le revisioni il pomeriggio, e i task ricorrenti che si volevano lanciare ogni settimana si fanno una volta sì e due no, finché si smette. Qui Manus ha investito di più nell’ultimo anno, e a fine aprile 2026 ha consegnato il salto più rilevante del suo percorso prodotto.

Scheduled Tasks permette di programmare l’esecuzione di un task a cadenza fissa, ogni mattina, ogni lunedì, il primo del mese, ogni tre ore. L’agente lancia il task in autonomia, esegue, salva i risultati, eventualmente invia notifiche. Per chi è abituato a Zapier o n8n l’idea è familiare, per chi viene solo da chatbot è un cambio di prospettiva. Una review su Work Management lo descrive come la funzione che fa sembrare Manus più un operations tool che una novità AI, ed è fedele, perché il valore non sta nel singolo task pianificato ma nell’accumularsi di task ricorrenti che insieme costruiscono una piccola infrastruttura di business intelligence che gira da sola. I limiti vanno conosciuti: sul piano gratuito due Scheduled Tasks attivi, sui piani Pro il limite sale a venti task concorrenti e pianificati.

Il salto qualitativo è il Manus Cloud Computer, lanciato il 30 aprile 2026, descritto dalla stampa specializzata come il primo prodotto mainstream che dà a un agente un “permanent home”. Fino ad allora ogni sessione viveva in una sandbox effimera che si chiudeva al termine del task, mentre con Cloud Computer l’agente ha una macchina virtuale dedicata, sempre accesa, che mantiene stato, file, database, processi attivi anche tra un task e l’altro. Una rassegna su AI Automation Global descrive l’impatto come il passaggio dal 2025, anno del chat agent, al 2026, anno dell’agent runtime, un posto dove gli agenti vivono, reagiscono a eventi, accumulano effetti collaterali. Cloud Computer è disponibile in tre tier, accessibile da desktop e mobile, ed è proposto come no-code: si descrive l’obiettivo in linguaggio naturale e Manus provisiona e mantiene la macchina sottostante. Per le funzioni IT abituate a parlare di VM, container, processi supervisor, l’astrazione conta, perché non si gestisce più infrastruttura, si gestisce intento.

Gli scenari dove Scheduled Tasks ripaga rapidamente sono concreti. Il monitoring competitivo giornaliero, un task che ogni mattina controlla i siti dei competitor selezionati e invia un digest entro le otto, così il manager arriva in ufficio già allineato. Il digest settimanale di customer feedback, che ogni lunedì apre i ticket della settimana precedente, identifica i topic ricorrenti, segnala i feedback critici. La rassegna stampa di nicchia, che per chi lavora in public affairs o comunicazione scandaglia testate specializzate e account di settore producendo una rassegna ragionata, un sostituto credibile per certi scenari di servizi più costosi. Un caso descritto su NoCode MBA mostra come un setup simile per tracciare advertiser su newsletter di settore abbia intercettato lead prima della concorrenza.

I task pianificati hanno insidie diverse da quelli in tempo reale. Un task lanciato a mano lo supervisioni e se va male lo fermi, uno pianificato gira di notte e se sbaglia produce output sbagliati per giorni prima che qualcuno se ne accorga. Tre regole tengono conto di questa asimmetria. Essere conservativi sul perimetro, perché un task ricorrente deve fare poco ma bene, non è il contesto per un Wide Research da quattromila crediti ma per task semplici da cento o duecento. Configurare il fail-fast, in modo che se le fonti non sono accessibili l’agente notifichi l’errore invece di produrre output silenziosamente sbagliato. Fare una review periodica, una volta al mese, per vedere quali task generano valore e quali sono diventati rumore di fondo, perché la tendenza naturale è accumulare task senza mai potarli e dopo sei mesi ci si ritrova con quindici Scheduled Tasks di cui tre servono davvero.

Il valore vero emerge quando queste funzioni si combinano. Un Project con istruzioni mirate, connettori attivi sui propri tool, Scheduled Tasks che girano in autonomia, Cloud Computer che mantiene stato persistente, insieme diventano un’infrastruttura leggera di automazione che assomiglia a quello che le aziende grandi costruiscono con team IT dedicati. Un Project di sales intelligence con HubSpot attivo, dove ogni mattina un task apre i deal stagnanti da più di trenta giorni, controlla l’attività recente dei contatti su LinkedIn, identifica trigger di vita come un cambio ruolo o un post recente, suggerisce a quale account dare follow-up prioritario, con il Cloud Computer che mantiene memoria di lungo termine sui contatti per non ripetere segnalazioni già fatte. Due anni fa questo livello richiedeva un team di RevOps con Salesforce, Outreach, Clay, Apollo e un consulente di setup, oggi richiede un piano Manus Pro e una settimana di configurazione. C’è un caveat che ricordo sempre: tutta questa infrastruttura passa da una piattaforma esterna che ha accesso a dati aziendali sensibili, e il livello di automazione raggiunto è proporzionale alla quantità di credenziali condivise, un tema che chi ha vincoli di sovranità del dato risolve spostando lo strato AI dentro il perimetro, come racconto a proposito di infrastrutture di AI privata.

Collab, Desktop App e Design View: quando diventa risorsa di squadra

Per buona parte del 2025 Manus era un prodotto individuale. Un singolo utente apriva un task, lo seguiva, ne raccoglieva l’output, e per i team che volevano usarlo insieme l’unica strada era condividere screenshot e riprodurre a mano la stessa esecuzione. Da fine 2025 il prodotto ha coperto questo limite con un set di funzioni dedicate al lavoro di squadra.

Manus Collab apre i workspace alla collaborazione multi-utente con un solo link. Si genera, si condivide, e chi lo riceve entra nel workspace, vede lo stato dei task, partecipa alle conversazioni con l’agente, contribuisce al brief, accede agli output. Per chi viene da Notion, Linear, Figma, il pattern è familiare. L’effetto si misura sul sistemico più che sulla singola funzione: quando due persone lavorano insieme su un task le iterazioni si moltiplicano, una scrive il brief, l’altra lo affina, una valuta l’output intermedio, l’altra chiede correzioni, e la qualità finale supera quella che si otterrebbe in solitaria. Una review su Lindy nota che il lavoro di squadra è uno dei terreni dove i prodotti agentici stanno colmando il distacco rispetto agli strumenti collaborativi tradizionali. Un Manus solitario è uno strumento, un Manus condiviso può diventare un processo aziendale.

La Desktop App per Mac e Windows, descritta nella documentazione come “My Computer”, porta tre vantaggi pratici. L’accesso ai file locali senza upload manuale, così si lavora su documenti e fogli che vivono sulla propria macchina senza prima caricarli nel cloud. La persistenza visiva, perché l’app resta aperta in background e le notifiche sui task completati arrivano nel sistema operativo invece di disperdersi tra mille schede. E il senso di professionalità dello strumento, meno banale di quanto sembri, perché un’applicazione dedicata cambia il modo in cui un team percepisce un tool e abbassa la resistenza all’adozione strutturata. Resta una limitazione che conviene conoscere: anche con l’app desktop, l’esecuzione dell’agente avviene nella sandbox cloud, non sulla macchina locale, ed è un vincolo di sicurezza che vale per tutti gli agenti autonomi sul mercato.

Design View è il modulo dedicato alla generazione e all’editing di immagini, lanciato con una novità tecnica: integra Nano Banana Pro, il modello di generazione visuale di Google noto per la qualità delle iterazioni successive a partire dalla stessa immagine sorgente. Si carica o si genera un’immagine, e si chiedono modifiche in linguaggio naturale, cambia lo sfondo, togli la persona sulla destra, trasforma il giorno in notte, ogni modifica produce una nuova versione e il workspace mantiene la storia delle iterazioni. Per il marketing serve a produrre varianti per A/B test, social, landing page senza passare ogni volta dal design team per modifiche minori, per il design diventa uno sketchbook collaborativo, per la comunicazione interna permette di personalizzare template senza competenze grafiche. La qualità di Nano Banana Pro è alta sulle modifiche iterative dello stesso soggetto, meno costante quando si chiede una composizione completamente nuova, quindi conviene trattarlo come strumento di editing più che di creazione, affidando le brand asset di valore alto a designer professionisti.

C’è un tratto che accomuna gli scenari di squadra, e vale la pena fissarlo. Il valore di Manus per i team non sta nella sostituzione del lavoro umano, sta nella riduzione del tempo morto tra una decisione e la sua materializzazione. Cambia il throughput del processo creativo o produttivo, non la qualità finale dell’output, che resta dipendente dalla professionalità di chi lavora. Per aziende dove il time-to-market dei contenuti o delle materializzazioni visuali è un fattore competitivo, è una differenza che si misura in giornate di lavoro recuperate ogni settimana.

API e Custom MCP Server: integrare l’agente nei sistemi aziendali

C’è una fascia di lettori per cui usare Manus come prodotto finito non basta. Sono i CTO, gli IT manager, i lead developer che devono valutare se e come integrarlo dentro flussi esistenti, sopra database proprietari, dentro pipeline che girano su altri stack. Per questi profili la domanda non è come si usa Manus, è come si costruisce qualcosa con Manus. Due strade complementari, l’API per integrazioni server-to-server e i Custom MCP Server per esporre i sistemi interni all’agente.

L’API Manus permette a un sistema esterno di lanciare task sull’agente, ricevere risultati, gestire l’esecuzione in modo programmatico. La logica è quella di qualunque API moderna, chiave di accesso, endpoint, JSON in input e output, gestione asincrona dei task lunghi. Un caveat onesto: la documentazione tecnica sull’API è ancora in consolidamento e non ha la completezza di provider più maturi come OpenAI o Anthropic. Una guida su Skywork che ha analizzato pattern di integrazione con Stripe, Slack, Notion e Google Sheets nota che Manus si concentra sulla generazione rapida di app complete ma non documenta pubblicamente un developer SDK, un marketplace di plugin o un framework webhook strutturato. In pratica le integrazioni oggi si fanno in due modi, tramite middleware costruito ad hoc che riceve eventi dai propri sistemi e li traduce in chiamate Manus, oppure tramite polling per i servizi senza webhook affidabili. Entrambi richiedono uno sviluppatore esperto, e nessuno dei due è plug-and-play come l’esperienza dei Connectors nativi.

I Custom MCP Server fanno l’opposto: permettono a Manus di chiamare i sistemi aziendali interni come se fossero strumenti standard. Per le aziende strutturate è la direzione più potente, perché evita il problema della completezza dell’API e sfrutta lo standard aperto MCP. Si costruisce un server, ospitabile in cloud privato, on-premise o hybrid, che espone una serie di tool al protocollo, ognuno con un nome, una descrizione, parametri tipizzati, e un’implementazione che parla con i sistemi interni, per esempio “trova cliente per codice fiscale”, “estrai ultime fatture”, “aggiorna stato pratica”, “verifica disponibilità magazzino”. Si configura Manus per usare il server, e da quel momento l’agente opera sui sistemi proprietari dentro qualunque task autonomo. La documentazione integrazioni di Manus indica proprio questa possibilità di esporre CRM interni, database, API legacy in modo nativo. Per chi conosce il pattern del tool function calling negli LLM tradizionali, è la stessa cosa elevata a protocollo aperto e portabile, dove il server scritto per Manus può in linea di principio essere usato da altri agenti compatibili MCP, evitando il lock-in tecnologico.

Tre pattern ricorrono nelle integrazioni serie. Il ticket-enrichment, dove un sistema di ticketing genera un ticket, un trigger chiama Manus che con un Custom MCP Server sul CRM interno analizza il contenuto, identifica il cliente, recupera lo storico, classifica la richiesta, propone una priorità e un primo draft di risposta, e il ticket arricchito torna all’operatore umano con contesto già pronto. Il monitoring-and-routing, dove una pipeline di ingestion raccoglie input eterogenei e un task Manus li classifica, identifica i casi che richiedono attenzione umana, indirizza gli altri verso processi automatici, lo smistamento intelligente che dieci anni fa richiedeva regole if-then complesse. Il report-and-distribute, dove un task pianificato genera report periodici partendo da CRM, ERP, BI, li compone in documenti formattati, li distribuisce via email, Slack, Notion, una sostituzione credibile di parte del lavoro che oggi fanno manualmente i business analyst.

Tre temi tecnici vanno affrontati prima dello sviluppo. Webhook e polling sono i due modelli per la reattività, i webhook efficienti ma con endpoint pubblici e gestione delle retry, il polling più semplice ma con latenza e carico costante, e nella maggior parte dei casi conviene un layer ibrido. La gestione delle credenziali è il punto sensibile, perché con i Custom MCP Server le credenziali ai sistemi interni vivono nel server stesso, che diventa il punto critico di sicurezza, da isolare in rete dedicata, con credentials manager come Vault o i secrets manager cloud, con rotazione regolare e log di ogni accesso. L’idempotenza è il terzo, perché un task Manus può essere ritentato dopo errore o ricevere lo stesso input due volte, e i tool esposti devono produrre lo stesso risultato se chiamati due volte con gli stessi parametri, evitando doppie scritture. Sulla scelta tra costruire e comprare, il criterio è quello classico: si costruisce custom quando ci sono sistemi proprietari unici, requisiti di sicurezza specifici, volumi che ammortizzano lo sviluppo, e si compra il prodotto quando il caso d’uso è coperto dai Connectors nativi e il team non ha competenze per mantenere integrazioni custom. La variante intermedia più frequente è “buy the platform, build the connectors”, Manus come piattaforma chiavi in mano per il novanta per cento dei casi standard e un Custom MCP Server dedicato per i sistemi proprietari critici.

Adozione enterprise: governance, sicurezza, costi, proprietà

Un decisore che ha capito cosa fa il prodotto si trova davanti alle domande che contano quando si passa da “uno sperimenta nel team” a “lo adottiamo come strumento aziendale”. Quanto costa su scala team, quali garanzie di sicurezza offre, dove finiscono i dati, qual è il contesto di proprietà e governance, quando vale la pena e quando no.

Su scala team la logica di Manus AI è la stessa degli utenti individuali, con dinamiche di scala da comprendere. Il piano Team parte da venti dollari al mese per seat con un minimo di due membri, e introduce workspace condiviso, single sign-on, funzionalità di amministrazione, una pool di crediti gestita collettivamente. Per un’azienda con dieci utilizzatori attivi il costo base è duecento dollari al mese, più gli eventuali add-on per i picchi. Il calcolo che conta è quello dei crediti, non quello del seat, perché i casi più costosi, Wide Research, Cloud Computer attivo, task autonomi lunghi, concentrano buona parte del budget se non si stabilisce una disciplina interna. I crediti mensili non si accumulano, quelli da add-on restano finché l’abbonamento è attivo, e questa asimmetria spinge a una calibrazione fine, meglio un piano leggermente sotto il fabbisogno medio integrato con add-on quando serve, che un piano sovradimensionato che spreca crediti ogni mese.

Tre limiti operativi impattano l’organizzazione. Il limite di task concorrenti, uno solo sul gratuito, venti su Pro, scalabile con i seat ma con un tetto sul Team, che emerge quando un team di otto persone tenta di lanciare ognuno un Wide Research nello stesso pomeriggio e alcuni restano in coda. Il limite di Scheduled Tasks attivi, dove la disciplina di tenere pochi task ben fatti è anche un’auto-limitazione virtuosa. Il limite di Wide Research, dove le sessioni hanno durate massime e i crediti possono saturare il budget mensile, tanto che per team con bisogno frequente di dossier il piano top da duecento dollari diventa quello sostenibile.

Su sicurezza, data residency e audit trail Manus ha una maturità intermedia, i meccanismi di base ci sono ma la documentazione enterprise non è ancora al livello dei provider più consolidati. Tutto ciò che passa per la sandbox cloud, file caricati, contenuti delle conversazioni, output prodotti, viene processato dalla piattaforma, e per dati non particolarmente sensibili è coerente con qualunque SaaS moderno. Per dati regolamentati, categorie particolari GDPR, segreto bancario, dati sanitari, classificati pubblici, questa è la prima asimmetria da considerare, perché Manus non è oggi un prodotto certificato per la gestione di dati ad alta sensibilità, e per questi scenari va verificato puntualmente cosa il proprio framework di compliance consente. Sulla data residency, l’infrastruttura sottostante gira su provider cloud americani, e per aziende italiane ed europee in PA centrale o in settori finanziari di rilevanza sistemica, con vincoli espliciti di sovranità del dato, questo è un nodo da valutare caso per caso. Per la maggior parte delle aziende private il framework di trasferimento internazionale copre adeguatamente, ma l’analisi va documentata formalmente. Sull’audit trail il prodotto registra conversazioni ed esecuzioni e offre l’accesso alla cronologia, sufficiente per l’accountability interna, mentre per audit formali le funzionalità avanzate come log immutabili, export strutturato, integrazione SIEM, sono in consolidamento e vanno verificate con il vendor.

C’è poi un punto di proprietà e governance del prodotto che merita di essere riportato con precisione, perché si è mosso parecchio negli ultimi mesi. Manus nasce da Butterfly Effect, società fondata in Cina con radici a Pechino e Wuhan, poi reincorporata a Singapore nel 2025. A dicembre 2025 Meta ha annunciato l’acquisizione di Manus, riportata intorno ai due miliardi di dollari, dichiarando che avrebbe accelerato l’innovazione AI per i propri prodotti consumer ed enterprise. L’operazione ha attratto scrutinio sia negli Stati Uniti sia in Cina, e il 27 aprile 2026 la National Development and Reform Commission cinese ha bloccato l’acquisizione, chiedendo alle parti di annullarla, in una mossa che la stampa internazionale ha collegato alle preoccupazioni di Pechino sul trasferimento di tecnologia avanzata e talento. Meta ha risposto che la transazione era pienamente conforme alle leggi applicabili e che si attende una risoluzione appropriata della questione. Allo stato attuale lo scenario resta aperto e non del tutto chiarito, anche perché parte del personale risultava già integrato nei team Meta. Per le aziende che valutano l’adozione il punto non è prendere posizione su una vicenda geopolitica, è registrare che il prodotto attraversa una fase di evoluzione e incertezza societaria, con i lati positivi degli investimenti continui e i lati di consapevolezza sui possibili cambiamenti di pricing e di policy. Per settori con vincoli stringenti sulla provenienza geografica dei fornitori cloud, PA centrale, difesa, sanità, banking sistemico, questo va verificato con le funzioni di compliance interne, mentre per il resto del mercato privato il tema è meno stringente di quanto a volte appaia.

La griglia decisionale: quando Manus AI è la scelta giusta

Resta da mettere insieme tutto in criteri sintetici, da combinare con il contesto specifico di ogni azienda. La domanda preliminare, prima ancora di aprire l’account, riguarda il proprio flusso di lavoro: ha task multi-passo che oggi vengono eseguiti a mano per mancanza di alternative, oppure è già strutturato intorno a strumenti specializzati che coprono ogni segmento?

Una griglia grossolana ma utile parte dal tempo. Se il task richiede meno di cinque minuti di lavoro umano, Manus è un’overkill costosa ed è meglio un assistente conversazionale. Se richiede tra cinque minuti e un’ora, e attraversa più strumenti o più fonti, Manus può essere la scelta giusta. Se richiede più di un’ora di lavoro complesso ma altamente strutturato, vale la pena valutare se non sia più adatto a una pipeline costruita con API e tooling dedicato. Manus è la scelta giusta quando l’azienda ha bisogno regolare di task multi-passo oggi eseguiti a mano, quando il team ha competenze digitali medio-alte e può investire un mese o due nella curva di apprendimento, quando i casi d’uso prevalenti riguardano ricerca approfondita, generazione di documenti formattati, monitoraggio continuo, supporto a customer operations e sales, e quando i dati toccati non sono in fasce di sensibilità elevata oppure si è disposti a costruire un Custom MCP Server che isoli il perimetro.

È invece da rivalutare con attenzione quando l’azienda opera in settori altamente regolati con vincoli di sovranità del dato espliciti, quando il team non ha la disponibilità per investire nella curva di apprendimento e cerca un tool da accendere e usare, quando i casi d’uso sono prevalentemente conversazionali e iterativi, per i quali un assistente tradizionale è più adatto, e quando il budget è strutturalmente sotto i venti dollari mensili per utente, perché il modello a crediti rende il piano gratuito limitante per un uso professionale serio.

In molti casi reali la risposta sta nel mezzo, ed è una valutazione sfumata che conviene chiudere con un pilot strutturato, un trimestre di prova con un team ristretto di tre o cinque power user, obiettivi misurabili sul tempo umano risparmiato e sulla qualità degli output, e una decisione formale a fine trimestre se estendere all’organizzazione o fermarsi. È l’approccio che evita sia il rifiuto pregiudiziale sia l’adesione entusiastica non sostenibile, ed è quello che la maggior parte delle aziende che adottano con successo nuovi tool AI sta usando in questa fase. C’è anche un criterio organizzativo che vedo spesso sottovalutato: le aziende che adottano Manus con successo sono quelle che dedicano una persona o un piccolo team alla curva di apprendimento iniziale, prima di estendere l’uso al resto dell’organizzazione, perché lanciarlo dall’alto come tool generalista, senza un nucleo di power user che sviluppi pattern riconoscibili, tende a produrre frustrazione e abbandono.

Tutto questo ragionamento, dalla scelta del modello fino all’architettura di governance, è esattamente il tipo di valutazione che mi capita di affiancare quando un’azienda mi chiede un assessment sulla propria adozione AI. Se Manus entra in un disegno più ampio di sovranità del dato e infrastruttura interna, vale la pena leggerlo insieme alle scelte di stack che ho raccontato altrove, dal perché Mistral è diventata la scelta enterprise più seria d’Europa per chi vuole l’AI dentro il proprio perimetro, fino a cosa cambia per il GDPR quando un dato esce dall’azienda e si appoggia a una piattaforma esterna come Manus. In Pelle Digitale ho provato a descrivere come l’interfaccia digitale media il nostro rapporto con il lavoro e con noi stessi, e un agente autonomo come Manus è il caso limite di questa mediazione, uno strumento che non risponde più soltanto, agisce. Per una conversazione diretta sul vostro caso specifico c’è la pagina Advisory.

A inizio percorso lasciavo aperta una domanda, e la richiudo qui dopo aver attraversato tutto il prodotto. Aprire un account, dedicare due settimane all’esperimento concreto, scegliere tre task realistici del proprio lavoro e provarli con la disciplina vista in queste pagine, perché la risposta sul valore di Manus per il proprio contesto arriva solo dall’esperienza diretta e nessuna guida può sostituirla. Senza dubbio è in quella prova concreta che si gioca la differenza tra chi avrà cavalcato l’onda degli agenti autonomi e chi la guarderà passare?

Leggi anche: ecosistema di AI privata

10 ragioni per portare l’AI privata al tavolo del board

Quando un’azienda inizia a costruire prodotti su AI, la prima scelta è quasi sempre la stessa: ci si appoggia ai grandi provider americani, e si lascia la AI privata come ipotesi da valutare “più avanti”. OpenAI, Anthropic, Google, qualche volta Mistral. Sono comodi, documentati, hanno API stabili, hanno modelli che funzionano davvero bene, hanno reparti enterprise che rispondono alle email.

Per le prime settimane, va benissimo così. Il problema arriva dopo, quando il prodotto smette di essere un prototipo e diventa qualcosa su cui dipende un pezzo di fatturato, di reputazione, di rapporto col cliente. È a quel punto che la domanda cambia, e diventa una domanda di architettura, non più di tool. Quanto controllo abbiamo davvero sul fondamento di quello che stiamo costruendo?

Negli ultimi mesi ho lavorato su questa domanda con diversi CEO e CTO di aziende italiane, e mi sono convinto che la AI privata vada considerata seriamente per almeno dieci ragioni. Non come fissazione tecnica, non come scelta ideologica anti-Big Tech, ma come opzione architetturale concreta che merita un posto al tavolo del board accanto alle proposte cloud-only.

I dati del cliente finiscono in posti che non controllate

Un contratto enterprise con OpenAI o Anthropic vi dà garanzie legali importanti: zero retention, niente training sui vostri dati, audit trail. Ma il dato tecnico resta: quando il vostro cliente invia una richiesta, quel testo viene processato dentro un data center che non è vostro, da un’infrastruttura che non vedete, sotto giurisdizioni che cambiano in base a dove sta il fornitore. Per applicazioni che trattano contratti, dati sanitari, proprietà intellettuale, strategie commerciali, questa distanza fisica fra dato e azienda è esattamente il punto su cui si stanno irrigidendo i clienti enterprise. Una banca italiana che valuta un vostro prodotto AI non vuole solo sapere che siete GDPR-compliant. Vuole sapere dove gira il modello e chi può guardarci dentro.

Le fondamenta sono in affitto

Costruire un prodotto AI completamente sopra un servizio esterno è comodo per la velocità di sviluppo, ma è l’equivalente di costruire un edificio su un terreno di cui non avete il rogito. Funziona finché funziona. Il giorno in cui il proprietario decide di cambiare le regole del condominio, vi ritrovate a discuterle dalla posizione più debole possibile. Non sto dicendo che OpenAI o Anthropic siano cattivi padroni di casa, anzi. Sto dicendo che la relazione resta strutturalmente asimmetrica, e questa asimmetria diventa rischio quando il vostro prodotto è in produzione presso clienti che si aspettano continuità per anni.

Quanto durano davvero le API che state usando

Modelli che vengono deprecati. Endpoint che spostano comportamento da una versione all’altra. Limiti di token che si modificano. Policy d’uso che si stringono o si allargano. Funzionalità beta che diventano premium. Le aziende che hanno costruito prodotti seri sopra le API dei grandi provider lo sanno: ogni rilascio è anche un piccolo lavoro di regressione testing per capire cosa è cambiato senza preavviso. La vostra roadmap di prodotto non è mai veramente vostra finché dipende dalla roadmap di qualcun altro, soprattutto quando quel qualcun altro rilascia tre versioni maggiori l’anno.

Erediterete la reputazione di chi vi dà il modello

Il nome famoso oggi rassicura il vostro cliente. Domani può finire dentro uno scandalo, una controversia regolatoria, una scelta commerciale impopolare, un caso di sicurezza, un’inchiesta giornalistica. Quando succede, il vostro prodotto eredita istantaneamente la coda di quella reputazione. I clienti più sofisticati lo sanno e mettono nelle loro RFP domande sempre più specifiche su quale modello state usando, dove gira, chi lo controlla. La risposta “usiamo il provider X” è già oggi una risposta che apre conversazioni invece di chiuderle.

I costi non sono sotto il vostro controllo

Potete ottimizzare i prompt, ridurre i token in uscita, fare prompt caching, scegliere il modello più piccolo per ogni task. Sono tutti esercizi utili, e li facciamo tutti. Però il prezzo finale al token lo decide qualcun altro, e lo decide guardando le proprie esigenze di margine, non le vostre. Negli ultimi due anni i costi dei modelli sono scesi rapidamente, ed è una buona notizia per chi è entrato adesso. Ma non c’è nessuna garanzia che continuino a scendere allo stesso ritmo, e ci sono diversi segnali di prezzi che stanno iniziando a risalire su modelli premium con context window molto lunghe o capacità agentic specifiche. Per chi pianifica un business plan a tre anni, è una variabile che vale la pena guardare con attenzione. Su questo tema ho scritto di recente in Quanta intelligenza artificiale stai davvero governando?.

La demo non è la produzione

Quando si dimostra un proof of concept, si usa quasi sempre il modello più potente disponibile. Funziona bene perché costa, e perché si lavora su volumi piccoli. Quando lo stesso prodotto va in produzione con cento clienti, mille clienti, diecimila utenti finali, i conti cambiano: i volumi salgono, la latenza diventa un problema reale, il budget per ogni interazione si stringe, e all’improvviso il modello che faceva la magia nella demo è troppo costoso per girare a regime. Comincia la caccia al modello “abbastanza buono” più economico, e quella caccia si fa molto meglio quando il modello sotto è una commodity che potete sostituire, non un servizio chiuso che dovete riconfigurare ogni volta.

I grandi provider americani non sono imbattibili

C’è un’idea diffusa, e secondo me sbagliata, che i grandi player AI siano destinati a vincere sempre perché hanno inventato la categoria. Non hanno inventato la categoria. Hanno estratto un enorme valore da una combinazione storicamente fortunata di dati pubblici scrapati prima delle restrizioni, infrastruttura GPU comprata in massa al momento giusto, distribuzione ai consumer arrivata prima di tutti gli altri. Tutte cose imitabili da chiunque abbia abbastanza capitale e tempo. Mistral in Europa, DeepSeek e Qwen in Cina, Meta con Llama, Cohere, Stability, decine di laboratori più piccoli stanno già pubblicando modelli open-weight competitivi su task specifici. L’ecosistema sta inevitabilmente convergendo verso una commoditizzazione almeno parziale, ed è ragionevole pensare che fra tre anni il “vincitore” del 2024 non sarà più automaticamente la scelta obbligata del 2027.

La sovranità digitale è diventata clausola contrattuale

Fino al 2023, parlare di sovranità digitale veniva visto come un argomento politico da convegno, lontano dalle decisioni operative di un’azienda. Nel 2026 è diventato un capitolo dei contratti enterprise. Il combinato disposto di GDPR, AI Act europeo, Schrems II, scadenze del PNRR e tensioni geopolitiche fra Stati Uniti, Europa e Cina sta riportando a casa una domanda che sembrava sepolta: dove sta fisicamente il software critico della mia azienda, e chi ha potere giurisdizionale su di esso? Per le aziende che lavorano con la pubblica amministrazione, con la difesa, con il settore bancario o sanitario italiano, questa domanda si è già trasformata in clausole contrattuali specifiche. Per tutte le altre aziende, è solo questione di tempo prima che arrivi nelle gare e nelle due diligence.

Il vendor lock-in tecnico è un debito che si accumula in silenzio

Ogni volta che ottimizzate un prompt per un modello specifico, sviluppate una tool integration su un’API specifica, costruite memoria semantica sopra un embedding-as-a-service specifico, state accumulando un debito tecnico di portabilità. Quel debito non si vede nei primi sei mesi, perché tutto funziona. Si vede al ventiquattresimo mese, quando provate a fare una proof of concept con un altro provider per ragioni di prezzo o di feature e scoprite che la migrazione costa quanto rifare metà del prodotto da zero. Quel debito si riduce drasticamente se il modello sotto è un’astrazione che potete sostituire, e si azzera se quel modello vive dentro un’infrastruttura che possedete. La domanda da farsi oggi non è solo quanto costa cominciare con un provider, è quanto costerebbe cambiarlo fra due anni.

AI Act e compliance non sono un problema futuro

Dall’agosto 2026 entrano in vigore i primi obblighi sostanziali del Regolamento europeo sull’AI per i sistemi ad alto rischio. Le aziende che usano modelli proprietari di terze parti per casi d’uso classificati ad alto rischio si troveranno a dover dimostrare conformità su dati di training, valutazioni di bias, documentazione tecnica, sistemi di monitoraggio, gestione del rischio. Su un modello chiuso, gran parte di queste informazioni vi vengono fornite o non vi vengono fornite dal provider. Su un modello che gira nella vostra infrastruttura, anche se è un modello open-weight scaricato da Hugging Face, la documentazione è almeno auditable, il fine-tuning è tracciabile, il dataset usato è esplicito. La differenza, per chi opera in finanza, sanità, HR, pubblica amministrazione, sta diventando rilevante in modo concreto e a breve termine.

Per chi vuole iniziare, c’è LocalAI.io

La AI pubblica resta utile, e in molti casi resta la scelta giusta per le prime fasi di sperimentazione di un prodotto. Però se la vostra applicazione dipende strutturalmente da privacy, controllo dei costi, sovranità e autonomia strategica, allora la AI privata non è una fissazione tecnica, è semplicemente buona architettura.

Su questo tema ho investito personalmente come cofondatore di LocalAI.io, un progetto open-source che permette di costruire ecosistemi di AI privata a partire dai modelli open-weight già esistenti, con tutto lo stack che serve per portare un prodotto in produzione: gateway compatibile con le API OpenAI, gestione di modelli multipli, RAG, agenti con memoria, deployment on-premise o su cloud privato. LocalAI è usato oggi in produzione da aziende che hanno deciso di avere il proprio strato AI in casa, e da team che vogliono mantenere la flessibilità di cambiare modello senza rifare il prodotto. Per chi vuole capire come funziona nel concreto, ho scritto una guida operativa completa qualche mese fa. Vale la pena darci un’occhiata se queste dieci ragioni hanno toccato qualche corda del vostro contesto.

La domanda finale resta sempre la stessa, e si fa più seria man mano che il vostro prodotto AI cresce. Su cosa state costruendo davvero, comodità immediata di chi vi dà il modello, oppure controllo nel lungo periodo di chi tiene insieme il vostro business? Se è una conversazione che vi sta riguardando, c’è la pagina Advisory con i formati di collaborazione che propongo a CEO e leadership team che stanno affrontando questi temi.

Il 57% di McKinsey è il numero sbagliato per fare scelte aziendali

Il 25 novembre 2025 il McKinsey Global Institute ha pubblicato uno dei report più discussi dell’ultimo semestre, Agents, Robots, and Us: Skill Partnerships in the Age of AI. La cifra che è girata su tutti i media internazionali è una: il 57% delle ore lavorative negli Stati Uniti è tecnicamente automatizzabile oggi, senza attendere ulteriori breakthrough. Il 44% via agenti AI, il 13% via robotica. Una percentuale così alta che, raccontata male, suona come un annuncio di disoccupazione di massa.

Leggere così quel numero, secondo me, è il modo peggiore di usare quel report. Il 57% misura il potenziale tecnico in laboratorio, non lo scenario reale di adozione. Usarlo per fare scelte aziendali porta nella direzione opposta a quella utile. Ho letto il report intero in questi giorni e provo a dare la mia lettura, da chi lavora in azienda con le aziende, non da chi commenta da fuori.

Il 40% è il dato da cui partire

Il 57% è il limite superiore in laboratorio. Risponde alla domanda: se prendiamo gli strumenti AI e robotici che già esistono, quante ore di lavoro umano potrebbero in teoria essere svolte dalle macchine? La risposta è oltre la metà. Ma McKinsey stesso sottolinea che questa cifra non si tradurrà in posti persi nella stessa proporzione, per tre ragioni che il report spiega bene.

  • Tempo di adozione: l’adozione richiederà anni, in molti casi decenni, perché le aziende devono ridisegnare i flussi prima di poter automatizzare.
  • Mix di attività dentro ogni ruolo: la maggior parte dei lavori contiene un mix di attività, e raramente un singolo lavoro è automatizzabile al 100%.
  • Gap fra laboratorio e produzione: molte attività che oggi sembrano automatizzabili in laboratorio non lo sono in produzione, per ragioni di affidabilità, responsabilità legale, accettabilità sociale o semplice costo del bilanciamento errore-supervisione.

Il numero che secondo me andrebbe letto in parallelo è un altro che si nasconde nel report: circa il 40% dei lavori cade nelle categorie a più alta automatizzabilità, principalmente attività amministrative, legali junior, programmazione di routine. Quel 40% non sparisce, ma cambierà natura entro l’orizzonte 2030, e cambierà bruscamente per chi non si attrezza per tempo. Questo dovrebbe essere il dato da cui partono le riunioni di leadership team in questi mesi, non il 57% da titolo apocalittico.

Persone, agenti software, robot fisici: il framework di McKinsey

Il contributo più interessante del report è il framework dei sette archetipi di lavoro che McKinsey costruisce mappando 800 occupazioni rispetto a tre dimensioni: quanto è people-centric, quanto è agent-centric (cioè automatizzabile da AI software), quanto è robot-centric (cioè automatizzabile da hardware). Ne emergono profili misti che rispecchiano quello che si vede nei contesti reali. Un radiologo è people-centric per la responsabilità clinica e agent-centric per l’analisi delle immagini, e la combinazione delle due dimensioni in un’unica figura professionale è un nodo organizzativo nuovo da governare.

La parola chiave del framework è partnership. McKinsey parla di collaborazione fra persone, agenti software e robot fisici, ciascuno con la propria competenza, orchestrati in workflow ridisegnati. La parte più scomoda del messaggio è che il framework funziona solo se l’organizzazione fa il lavoro di ridisegno. Se prendi un workflow esistente, ci ficchi dentro un agente AI sopra al processo che hai sempre fatto, non ottieni il 57%, ottieni nel migliore dei casi un risparmio del 10-15% e una serie di frustrazioni operative.

Per chi compra AI in azienda, questo punto vale più di mille slide. Il valore non sta nel tool, sta nel ridisegno del processo intorno al tool. Senza ridisegno, il ROI delle implementazioni AI rimane sotto le attese e i progetti finiscono nel limbo dei pilot perpetui.

Tre competenze umane che si fanno scarse

Una parte del report che mi ha colpito riguarda le competenze umane che diventano più rare, e quindi più richieste, man mano che l’AI assorbe i compiti standardizzati. McKinsey mappa migliaia di skill estratte dagli annunci di lavoro e individua tre cluster che resistono e crescono.

Il primo è quello delle skill relazionali avanzate: gestione del conflitto, negoziazione, coaching, costruzione del consenso in gruppi diversi. Sono attività che richiedono lettura del contesto sociale, contestualizzazione, judgement etico, e che le macchine fanno male anche quando sanno parlare bene.

Il secondo è quello del problem framing: la capacità di formulare la domanda giusta da porre all’AI, di distinguere un buon prompt da uno mediocre, di interpretare un output e capire quando merita fiducia e quando no. È una skill che ha più a che fare con il pensiero critico che con la tecnica, e curiosamente è una skill che il sistema scolastico italiano non ha mai sviluppato in modo sistematico.

Il terzo è quello dell’orchestrazione: tenere insieme processi multi-step in cui interagiscono persone diverse, agenti diversi, sistemi diversi. Project manager evoluti che capiscono dove inserire un agente nel flusso e dove tenere fermo l’umano. Sono profili che fino a un anno fa non esistevano e che adesso le aziende si contendono.

Tre skill scarse, prezzi che si muovono. È quasi un piccolo manuale di come riallocare il budget HR per il prossimo triennio.

Tre conversazioni che i board italiani dovrebbero aprire entro fine anno

In Italia il dibattito sull’AI nel lavoro è ancora dominato da due narrative simmetriche e sbagliate. La prima dice che l’AI ci ruberà i posti e che bisogna proteggerli con qualche regolazione. La seconda dice che l’AI è un super-strumento neutro, basta adottarlo per essere più competitivi. Il report di McKinsey mostra che entrambe queste narrative perdono il punto.

Le aziende che vinceranno il prossimo decennio non saranno quelle che adottano l’AI prima, ma quelle che ridisegnano i propri processi intorno alla collaborazione fra persone, agenti software e robot fisici. Per farlo serve qualcosa che in Italia abbiamo strutturalmente poco, ovvero capacità di trasformazione organizzativa profonda. Non capacità di acquistare tool, ne abbiamo a sufficienza. Capacità di rimettere mano a chi fa cosa, di toccare le abitudini consolidate, di accettare che metà del valore di un’implementazione AI si gioca prima ancora di accenderla, nella riprogettazione del flusso che le sta intorno.

Per chi guida un’azienda strutturata, oggi, ci sono tre conversazioni che meritano di essere portate al tavolo del board nei prossimi tre mesi.

La prima: quali nostri workflow contengono il maggior numero di ore standardizzabili, e quali no? Una mappa di alto livello del 57% dentro la nostra realtà specifica.

La seconda: chi sono i nostri orchestratori naturali? Persone che hanno già la capacità di tenere insieme processi multi-attore, che capiscono dove servono le competenze relazionali e dove serve la disciplina tecnica. Le aziende che riescono a identificarli e a metterli nei posti giusti partiranno con un vantaggio enorme.

La terza: dove possiamo permetterci di pilotare un workflow completamente ridisegnato, e non solo automatizzato a strati? Dove ci possiamo permettere il rischio di romperlo e ricostruirlo, su uno scope contenuto, per imparare come si fa prima di doverlo fare su scala?

Sono tre domande che non hanno bisogno di numeri da 57% per essere utili. Hanno bisogno di tempo dedicato dalla leadership, e di sufficiente coraggio per dare risposte concrete entro fine anno. Da imprenditore vedo molte aziende ferme alla prima delle tre, alcune che hanno provato la seconda, pochissime che hanno avuto il coraggio della terza. È lì, secondo me, che si decide la parte interessante del prossimo ciclo competitivo italiano. Non nei budget AI, che ormai tutti hanno. Nelle scelte organizzative dietro a quei budget.


Articolo di riferimento: McKinsey Global Institute, Agents, Robots, and Us: Skill Partnerships in the Age of AI, 25 novembre 2025.