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?

Mistral AI nelle aziende italiane? Perché nel 2026 è diventata la scelta enterprise più seria d’Europa

Tre conversazioni recenti con CIO italiani sullo stesso identico tema. Una banca media del Nord, un gruppo manifatturiero del Veneto, un’azienda sanitaria privata di Roma. Domande diverse, problema sottostante identico: come spostare carichi AI dal cloud americano senza rallentare i progetti e senza far esplodere il budget infrastrutturale.

Ognuno per la sua ragione ovviamente: la banca per la piena applicazione dell’AI Act dal 2 agosto 2026 sui sistemi ad alto rischio, il gruppo manifatturiero perché i dati di produzione non possono finire in dataset di training di nessuno, l’azienda sanitaria perché il GDPR sui dati paziente in cloud extra-UE è diventato un mal di testa che non vale i risparmi.

In tutte e tre le conversazioni Mistral AI è arrivata sul tavolo con sollecitazioni differenti e suggestioni tecniche, e in due casi su tre è già la scelta tecnica in valutazione per il prossimo trimestre.

Mistral nel 2026 non è più interpretabile come “l’alternativa europea sperimentale“. È diventata piuttosto rapidamente la prima risposta seria che si dà a un CIO italiano quando i vincoli sono compliance e sostenibilità dei costi. Provo a spiegare perché, e quando invece non lo è (soprattutto poi sul tema sovranità ci torno in dettaglio).

Chi è Mistral AI

L’azienda è francese, sede a Parigi, fondata nel 2023 da ricercatori usciti da Meta e DeepMind. La distanza tra quel punto di partenza e dove sta oggi vale la pena guardarla con i numeri, perché definisce il tipo di vendor con cui si tratta.

ARR a 400 milioni di dollari a gennaio 2026, salito da circa 20 milioni un anno prima secondo il CEO Arthur Mensch. Valutazione 13,8 miliardi dopo il round chiuso a fine 2025 con Series C guidata da ASML. Quattro sedi globali oltre Parigi: Stati Uniti, Regno Unito, Singapore. E una traiettoria di prodotto che a marzo 2026 ha visto sei rilasci in quindici giorni, dalla famiglia Small 4 che unifica reasoning vision e coding fino a Forge per il training enterprise.

Sul fronte clienti il segnale italiano è arrivato a febbraio e marzo. Il 26 febbraio Accenture ha annunciato una partnership strategica pluriennale per scalare AI enterprise sicure in Europa, con Mauro Macchi, CEO Accenture EMEA, a confermare l’investimento. Il 18 marzo è arrivato l’accordo con Reply, focalizzato proprio su “soluzioni di intelligenza artificiale generativa locali, personalizzabili, sicure e pronte per l’utilizzo in contesti enterprise”, come dichiarato dal CTO Filippo Rizzante. Reply lavora con Mistral nel training e nella valutazione dei modelli per pubblica amministrazione, difesa, financial services e sanità, oltre a telco ed energia. I settori dove la conformità non è un’opzione e la sovranità del dato è un requisito di gara.

Quando un’azienda italiana media decide oggi di mettere Mistral nel proprio stack, non sta scommettendo su una startup. Sta acquistando da un vendor che ASML, Ericsson, ESA, due agenzie governative di Singapore, Accenture e Reply hanno già qualificato in scenari produttivi reali.

Apache 2.0 come scelta strategica non per ideologia

Il vero discriminante di Mistral non è la qualità del modello: su quel terreno la competizione con OpenAI, Anthropic e Google è una corsa serrata che cambia ogni tre mesi o forse meno. Il vero discriminante è la licenza con cui i modelli vengono distribuiti. Apache 2.0, permissiva, commerciale, senza clausole che escludano usi specifici. Mistral Large 3, Magistral Small, Devstral, Ministral: tutti rilasciati con licenza Apache 2.0 o equivalente.

Per un CIO questo significa tre cose pratiche.

La prima è l’assenza di lock-in del vendor. Se domani Mistral aumenta i prezzi API, cambia condizioni contrattuali, viene acquisita da un attore non gradito, viene esclusa da un programma di compliance europea, il modello continua a girare. I pesi del modello sono scaricabili, replicabili, ospitabili dove serve. Non esiste un equivalente in OpenAI, Anthropic o Google: nessuno dei tre rilascia i pesi dei propri modelli flagship. Quando si firma un contratto con loro si firma una dipendenza permanente dall’infrastruttura del fornitore.

La seconda è il self-hosting che funziona davvero. Non quello finto di “Azure OpenAI in region europea”, dove il dato si muove in un perimetro Microsoft ma il modello resta proprietà di OpenAI e la trasparenza sul training data resta zero. Con Mistral si può prendere Mistral Medium 3.5, metterlo su server bare metal in un data center italiano, e avere il controllo completo del flusso: i dati non escono mai dall’infrastruttura, i log restano interni, le richieste non transitano per servizi terzi. Per settori regolati la differenza è strutturale: permette di chiudere il progetto AI in conformità invece di doverlo riprogettare quando arriva l’audit.

La terza è la possibilità di auditare il modello per i requisiti dell’AI Act. Per i sistemi classificati ad alto rischio dall’articolo 6 del regolamento europeo, da agosto 2026 servono evidenze documentali su training data, processo di sviluppo, gestione dei bias, robustezza. Con un modello open-weight si può esaminare quello che effettivamente gira, fare valutazioni indipendenti, produrre la documentazione che chiede AgID. Con un modello chiuso si dipende dalla buona fede e dai certificati del vendor, che vanno bene fino a quando non vanno bene.

Apache 2.0 non è un argomento ideologico. È un’architettura di rischio enterprise.

Mistral contro la concorrenza

I benchmark MMLU-Pro e LMArena occupano metà delle slide nei pitch dei vendor AI, ma non sono il criterio giusto per scegliere quale modello mettere in produzione in un’azienda europea. Lo sono per il singolo task scientifico in laboratorio, non per la decisione di acquisto.

I criteri che muovono davvero la firma di un contratto enterprise in Italia sono cinque, e ho provato a mettere i quattro vendor principali su ognuno.

Sulla residency dei dati nel perimetro UE, Mistral vince netto: La Plateforme gira interamente in data center europei, e il self-hosting permette residency totale. OpenAI offre region europee ma con metadati che possono uscire, Claude di Anthropic non ha ancora residency europea garantita per tutti i tier, Google Gemini ha region UE ma resta soggetto a Cloud Act statunitense.

Sul self-hosting reale, solo Mistral lo offre con i modelli flagship. OpenAI, Anthropic e Google non lo permettono, possono offrirti al massimo deployment in cloud privato gestito da loro.

Sull’italiano nel training data come priorità di prodotto, Mistral parte avvantaggiata perché l’italiano è una lingua di confine della Francia, presente nelle fonti europee usate per il training fin dai primi modelli. OpenAI e Google hanno italiano buono ma derivato, Claude si difende. Il dettaglio si sente quando i casi d’uso sono terminologia legale e finanziaria, o linguaggio medico italiano: Mistral produce testi che un madrelingua riconosce come scritti in italiano, non tradotti.

Sul supporto enterprise europeo, Mistral ha staff in Europa con fusi compatibili, contratti redatti su norma europea, capacità di firmare DPA conformi al GDPR senza emendamenti acrobatici. Gli altri tre vendor possono offrirlo, ma è sempre una negoziazione caso per caso.

Sul presidio fisico in Europa, Mistral ha sede e team principale a Parigi, con presenza commerciale diretta nei principali mercati europei. Per un’azienda italiana questo si traduce in interlocutori reggiungibili, processi di escalation prevedibili, riunioni di servizio fattibili senza notti negli US.

Cinque criteri, Mistral vince su tutti, gli altri tre vendor perdono almeno su due ciascuno. Questo non significa che siano scelte sbagliate in assoluto, significa che se il caso d’uso è italiano e regolato Mistral parte da un vantaggio strutturale che gli altri devono recuperare a forza di concessioni contrattuali.

Quando Mistral non è la scelta giusta

Una guida che racconta solo i vantaggi di un vendor è un brochure di vendita, non un’analisi. Ci sono tre scenari in cui oggi consigliare Mistral è sbagliato, e vale la pena chiamarli con il loro nome.

Il primo è il reasoning scientifico al limite dello stato dell’arte. Se l’applicazione è ricerca farmaceutica avanzata, analisi giuridica multi-giurisdizione su corpus immensi, problemi matematici di livello olimpionico, oggi Claude Opus 4.7 e GPT-5 hanno ancora un margine sul reasoning più sofisticato che Magistral 1.2 sta accorciando ma non ha annullato. Per quei casi la differenza di qualità giustifica i costi e i compromessi sulla sovranità.

Il secondo è la startup early-stage con un team piccolo e zero ops engineering. Mistral via API è semplice, ma quando ha senso passare a self-hosting servono competenze di MLOps che una startup di sei persone non ha. In quei contesti il managed service di OpenAI risparmia mesi di lavoro, e i vincoli di sovranità sono meno stringenti perché il dato del cliente arriva dopo che il prodotto esiste. Mistral diventa la scelta giusta nel passaggio dalla fase early alla fase di scaling enterprise.

Il terzo è il prodotto consumer chat brand-aware. ChatGPT ha vinto la guerra del marchio sul mercato consumer, e per molti casi d’uso l’utente vuole proprio ChatGPT, non un assistente generico. Le Chat di Mistral è un ottimo prodotto, ma se l’obiettivo è uno chatbot brand-coherent per consumer italiani che valga come acquisition channel, l’ecosistema di OpenAI, le sue integrazioni e il suo nome restano un asset che Mistral non eguaglia.

Dire questo apertamente fa parte del lavoro di advisor. Quando un vendor vince sempre su tutto, in un’analisi seria, qualcosa non torna.

I tre scenari italiani dove Mistral è la risposta giusta

Mi è capitato negli ultimi mesi di affiancare aziende che hanno fatto questa scelta, e gli scenari ricorrenti sono tre. Sono quelli che ho davanti più spesso quando mi chiamano per un assessment AI, e probabilmente sono anche i tuoi.

La banca media italiana. Mille o duemila dipendenti, focus retail e PMI, sistemi core legacy ma con un’innovation unit che da due anni sperimenta AI. Il problema concreto è doppio: agosto 2026 porta l’AI Act sui sistemi ad alto rischio, che per le banche include credit scoring, prevenzione frodi, customer journey con decisioni automatiche, e contemporaneamente il rapporto sui costi cloud LLM cresce del 40% trimestre su trimestre.

La configurazione Mistral tipica è ibrida. Mistral Medium 3.5 in self-hosting su due nodi NVIDIA H200 per i carichi sensibili (customer support che tocca dati cliente, sistemi decisionali, generazione documenti contrattuali), Mistral Large 3 via La Plateforme per i carichi esplorativi dove la sovranità è meno critica. Investimento infrastruttura nell’ordine dei 400-500 mila euro una tantum più contratti di supporto, con un break-even sui costi API che si raggiunge tra il diciottesimo e il ventiquattresimo mese per un volume di richieste tipico di un istituto da mille dipendenti.

Il gruppo manifatturiero del Nord. Tre o quattro stabilimenti, ricavi nella fascia 200-500 milioni, prodotti su misura con brevetti propri e know-how di produzione che è il vero asset competitivo. Il problema è che i prompt che farebbero davvero la differenza, quelli che mettono in pari l’AI generativa con un ingegnere senior, contengono dati di produzione, specifiche tecniche riservate, parametri di processo. Caricarli su cloud americano significa metterli in dataset di training futuri, anche con le clausole “data privacy” più tirate, perché il rischio anche solo di esposizione fa già scattare i policy interni.

La configurazione Mistral tipica qui è on-premise pura. Mistral Small 4 o Medium 3.5 su un singolo server NVIDIA H100 in azienda, integrato con la documentazione tecnica via vector database, esposto agli ingegneri di processo come assistente di reparto. Investimento infrastruttura nell’ordine dei 150-200 mila euro, gestione delegata a un partner sistemistico locale, zero traffico esterno per i carichi core. ROI atteso non in risparmio diretto ma in compressione dei tempi di sviluppo prodotto e di problem-solving sulla linea, dove ogni giorno guadagnato vale ordini di grandezza superiori al costo dell’infrastruttura.

La sanità privata romana o milanese. Strutture da 200-500 dipendenti, mix di ambulatorio specialistico, diagnostica, ricovero breve. Il problema è la combinazione GDPR articolo 9 sui dati particolari più AI Act sui sistemi ad alto rischio in sanità, su cui le interpretazioni del Garante diventano più restrittive ogni sei mesi. Inviare dati paziente, anche pseudonimizzati, a un LLM cloud americano significa preparare la difesa legale prima del progetto.

La configurazione Mistral tipica qui è ibrida controllata. Mistral Medium 3.5 self-hosted per tutto quello che tocca dati paziente (refertazione assistita, prima lettura immagini diagnostiche, transcript di visite), Mistral Large 3 via API solo per carichi senza dati personali (knowledge base medica, formazione interna, comunicazione marketing). L’infrastruttura interna costa di più, intorno ai 300 mila euro per il setup iniziale, ma è la sola architettura che permette di sostenere un’ispezione del Garante senza dover dichiarare data breach preventivi.

In tutti e tre i casi, la scelta di Mistral non è ideologica, è strutturale. È quello che permette di fare il progetto AI in conformità con i vincoli esistenti, senza spostare il problema avanti di sei mesi nella speranza che le normative diventino più morbide.

Il percorso pragmatico di impianto

Per un’azienda che oggi sta valutando se Mistral è una scelta sensata, il percorso che funziona è di circa quattro settimane, e non richiede investimenti significativi prima di aver capito se l’opzione regge.

La prima settimana è di assessment dei carichi AI attuali. Mappa di tutte le sperimentazioni in corso, identificazione dei carichi che toccano dati sensibili, classificazione preliminare rispetto all’AI Act, stima del costo annualizzato delle API LLM attuali. Da questa mappa esce la lista dei carichi candidabili a Mistral, che spesso non è il 100% del totale ma una porzione mirata.

La seconda settimana è di prova pilota. Le Chat Pro Team a 24,99 euro al mese per utente per dare ai team interni un assistente che gira su infrastruttura europea, in parallelo qualche giorno-uomo di un developer sui modelli via La Plateforme per validare la qualità sui prompt aziendali reali. Costo totale della prova nell’ordine dei 1.500 euro, output un go/no-go tecnico su Mistral con dati propri, non sui benchmark di marketing.

La terza settimana è di design dell’architettura target. Decisione tra le tre opzioni principali: solo API La Plateforme (low setup, costi ricorrenti), ibrida API più self-hosting parziale (setup medio, ottimizzazione costi a 18 mesi), self-hosting completo (setup alto, sovranità massima). La scelta dipende dal mix dei carichi mappati al primo passo e dal profilo di rischio del settore.

La quarta settimana è di business case e decisione. Confronto a tre anni tra l’architettura proposta e lo status quo, considerando costi infrastrutturali, costi API, costi di gestione, valore della sovranità nel risk management, fattibilità di compliance AI Act. Da qui esce o non esce la decisione di buy.

Questo schema funziona per la maggior parte delle aziende italiane sopra i cento dipendenti. Sotto quella soglia, di solito la complessità organizzativa del self-hosting non si giustifica e Mistral resta interessante via Le Chat e API, senza la parte infrastrutturale.

Queste valutazioni non sono mai solo tecniche. La scelta giusta dipende da come è strutturato il data flow aziendale, dai vincoli regolamentari specifici del settore, dalle competenze interne disponibili, dai progetti AI già in corso. Ogni azienda ha la sua mappa dei rischi e dei vantaggi, e i parametri che ho indicato sono ordini di grandezza che vanno calibrati sul caso reale.

È esattamente il tipo di analisi che mi capita di fare quando un’azienda mi chiede di affiancarla nel ridisegno della propria architettura AI. Se stai facendo questo ragionamento per la tua organizzazione, puoi contattarmi qui per una prima conversazione.

Per chi vuole scendere nel dettaglio dei modelli specifici di Mistral e capire quale conviene per ciascun caso d’uso, ho dedicato un approfondimento su come scegliere tra i modelli Mistral nel 2026 dove confronto Large 3, Medium 3.5, Small 4, Magistral, Devstral e Ministral con i criteri tecnici e di costo. Per chi invece sta valutando le opzioni di acquisto, dall’API a La Plateforme fino al self-hosting on-premise con Forge, c’è la guida dedicata su API, self-hosting, Forge: cosa scegliere e quanto costa davvero.

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?

Magnifica Humanitas: Leone XIV e il bivio dell’IA

Al centro di Magnifica Humanitas, la prima enciclica di Leone XIV, ci sono due immagini bibliche contrapposte. Una è la torre di Babele, costruita per toccare il cielo e per farsi un nome, fatta crollare nella confusione delle lingue. L’altra sono le mura di Gerusalemme che Neemia ricostruisce dopo l’esilio, pezzo per pezzo, affidando a ciascuna famiglia un tratto. Babele come progetto di potere, uniformità, autosufficienza. Gerusalemme come opera lenta e distribuita, fondata su responsabilità condivisa.

Quando oggi ho letto questa coppia di immagini, nelle prime pagine di Magnifica Humanitas, mi sono accorto che la stessa polarità l’avevo descritta in modo diverso quando ho scritto il mio libro Pelle Digitale ormai qualche mese fa, ma con altri nomi.

Babele per me si chiama “megastruttura accidentale”, riprendendo Bratton. Gerusalemme l’ho chiamata “umanesimo aumentato”. Stesso concetto, lessico diverso, e la cosa mi ha stupito non poco: c’è poco da stare sereni e pensare che sia un caso se una visione tecnologica converge con una visione teologica e spirituale. È un segnale, probabilmente, che il tempo del dibattito puramente tecnico è finito o sicuramente ormai superato.

Cosa dice Magnifica Humanitas

Leone XIV non scrive contro la tecnica e a mio avviso nemmeno contro l’AI. La inserisce dentro un quadro di responsabilità che le tecnologie da sole non possono darsi. L’impalcatura di tutto il testo si regge su cinque punti.

Il primo è la denuncia del paradigma tecnocratico, già al centro di Laudato si’, qui aggiornato all’IA con un’accentuazione nuova. Al paragrafo 95 il Papa scrive che il controllo di piattaforme, dati e capacità di calcolo non appartiene più agli Stati ma a grandi attori economici e tecnologici “che, di fatto, fissano le condizioni di accesso”. Lo dice un Papa, ma potrebbe averlo scritto Shoshana Zuboff, sociologa ed economista americana, professoressa dell’Harvard Business School che è diventata un riferimento centrale del dibattito critico sul digitale per via di un libro del 2019, The Age of Surveillance Capitalism (in italiano Il capitalismo della sorveglianza, Luiss University Press), considerato uno dei testi più influenti dell’ultimo decennio su economia digitale e potere delle piattaforme.

Il secondo punto è un’antropologia del limite contro transumanesimo e postumanesimo. I sistemi di IA, scrive al paragrafo 99, “imitano alcune funzioni dell’intelligenza umana” ma non hanno esperienza né corpo, non hanno coscienza morale. Non capiscono ciò che producono. La distinzione fra imitare e capire diventa il fulcro di un’intera argomentazione che oppone la pienezza umana, fatta di limite e relazione, alla promessa di un potenziamento illimitato.

Il terzo punto è la fenomenologia delle nuove schiavitù digitali. Ghost worker che etichettano dati per pochi centesimi, adolescenti che lavorano nelle miniere di terre rare, reti criminali che usano profilazione e pagamenti anonimi per la tratta, neocolonialismo dei dati sanitari estratti dal Sud globale sotto l’etichetta della ricerca. Su tutto questo, ai paragrafi 173-178, c’è un passaggio in cui il Papa chiede sinceramente perdono a nome della Chiesa per il ritardo storico sulla condanna della schiavitù, e usa quel precedente come monito a queste nuove forme di schiavitù.

Il quarto punto salda epistemologia e democrazia. Senza ricerca condivisa della verità dei fatti, la vita democratica si svuota. Hannah Arendt viene citata direttamente: il suddito ideale dei totalitarismi è chi non distingue più fra fatto e finzione. La disinformazione non nasce con l’IA, ma trova in questa un moltiplicatore.

Il quinto punto è il disarmo dell’IA. Rifiuto delle armi autonome letali, critica all’idea che il giudizio morale possa essere ridotto a calcolo, controllo umano effettivo come condizione non negoziabile. Qui dentro c’è il paragrafo 107, uno dei più affilati, complessi e delicati del testo, che secondo me dovrebbe leggerlo chiunque sviluppa modelli: non basta moralizzare la macchina, allinearla a valori umani, se non si discute chi decide quei valori. La domanda dell’alignment, scrive Leone XIV, non è un tema tecnico ma politico.

Sette nodi dove mi ritrovo in quello che scrivo spesso

Il primo nodo è il paradigma tecnocratico. In Pelle Digitale apro descrivendo Apple, Google e Amazon come “signori della gabbia dorata”, architetti di ecosistemi che catturano l’esperienza e la monetizzano. L’enciclica al paragrafo 95 arriva alla stessa diagnosi da un lessico apparentemente opposto. Io descrivo un meccanismo, fatto di estrazione di dati, monetizzazione, lock-in degli utenti. Il Papa nomina un peccato: idolatria del profitto, dominio sull’altro, pretesa di autosufficienza. Linguaggi differenti che vengono da tradizioni che da secoli non si parlano, e che improvvisamente convergono sulla stessa fotografia: pochi attori privati che decidono per tutti, con strumenti opachi e responsabilità diluite.

Poi c’è l’ambiente. Io lo chiamo “pelle digitale” e “sistema nervoso invisibile” e intendo lo strato che avvolge persone, oggetti e città. Leone XIV al paragrafo 76 parla esplicitamente di “ecosistema digitale” che, come l’ambiente naturale, può essere custodito o sfruttato, condiviso o monopolizzato. La metafora ambientale, applicata al digitale, è uguale.

Il terzo nodo è l’opacità algoritmica. Nel capitolo 7 del libro io racconto i bias, facendo degli esempi in particolare cito COMPAS sulla recidiva e il caso del recruiting di Amazon, e arrivo a parlare di “teocrazia digitale” per descrivere algoritmi-divinità che decidono senza dover dare spiegazioni. L’enciclica, ai paragrafi 102-107, costruisce la stessa argomentazione con parole più “sobrie”: black box, accountability, catena di responsabilità non delegabile alla macchina. Il Papa non usa “teocrazia”. Ma il problema che descrive è esattamente quello a mio avviso.

Quarto nodo: i ghost worker. Nel libro dedico una pagina alla materia che si nasconde dietro l’immaterialità apparente del cloud e al lavoro umano che c’è dietro. Una catena globale di corpi e luoghi che regge la leggerezza apparente di una risposta generata in due secondi. Il paragrafo 173 di Magnifica Humanitas entra in questa anatomia con una forza che pochi documenti pubblici hanno. Leone XIV scrive che ogni risposta dell’IA proviene da “una lunga catena di mediazioni” che include risorse naturali, infrastrutture energetiche e persone. Nomina la fatica invisibile di chi etichetta dati e modera contenuti per compensi minimi, “spesso giovani donne”. Aggiunge l’estrazione delle terre rare, dove “adolescenti e bambini lavorano in condizioni pericolose”. E chiude con la frase che spacca la sezione: “corpi segnati, mutilati, consumati perché il flusso del calcolo non si interrompa”.

Quando un Papa nomina i corpi mutilati dentro un’enciclica sull’intelligenza artificiale, sta facendo un’operazione che nessun rapporto o paper accademico può fare: mette la materia umana al centro morale del dibattito, e non ai suoi margini. La conseguenza al paragrafo 174 è esplicita e a mio avviso centrale: una tecnologia che promette emancipazione ma produce nuove forme di subordinazione globale contraddice il principio fondamentale della dignità della persona.

C’è poi tutto il tema della mente estesa, attenzione catturata, forme di dipendenza che ne derivano. Nel capitolo 4 io ho scritto della cognizione distribuita di Andy Clark, e nel capitolo 6 sull’economia dell’attenzione progettata per catturarci. L’enciclica ai paragrafi 100 e 170 parla di “delega” cognitiva e di modelli imprenditoriali che “prosperano sulla debolezza umana”. Qui c’è uno scarto interpretativo che vale la pena tenere aperto: Clark vede nell’estensione un guadagno, il Papa la legge come rischio. E a mio avviso tutte e due sono vere.

Sesto, c’è il tema dello human-in-the-loop, che ho dichiarato pilastro del capitolo finale del libro. L’enciclica, parlando di IA militare al paragrafo 200, usa la stessa nozione con parole quasi sovrapponibili: la forza letale non può essere delegata a processi automatizzati, deve restare sotto “un controllo umano effettivo, consapevole e responsabile”.

Settimo, il più delicato a mio avviso. L’alignment come questione politica. Nel libro parlo di ethics by design e cito Stuart Russell sull’allineamento ai valori umani. Il Papa al paragrafo 107 fa un passo che la letteratura tecnica raramente fa: chiede chi decide quei valori. Se l’allineamento è una scelta morale, è una scelta che non può essere appannaggio di pochi laboratori. È un punto della discussione che sposta tutta la conversazione sull’IA dall’ingegneria alla politica, e lo fa con una precisione che dovrebbe far riflettere chi lavora su questi temi.

Dove Magnifica Humanitas va ben oltre le riflessioni comuni

Il primo punto è la questione delle armi autonome. Io ne parlo in modo leggero nel capitolo sull’agency degli agenti, ma non la centro. Leone XIV le mette al cuore di un intero capitolo, riconosce che la riabilitazione contemporanea della guerra come strumento di politica internazionale è uno dei segni più gravi del tempo, e collega il riarmo all’IA in modo che dieci anni fa sarebbe stato impensabile. Ha ragione e condivido pienamente, gli scenari ibridi e gli attacchi cyber stanno cambiando la grammatica dei conflitti, e non si può parlare di etica dell’IA senza arrivare a parlare di questo.

Il secondo è il neocolonialismo dei dati sanitari. Nel libro descrivo l’asimmetria della medicina basata su dati, ma resto sul piano dell’individuo. L’enciclica al paragrafo 178 lo allarga ai popoli: chi possiede oggi i dati sanitari di intere popolazioni, raccolti sotto il segno della ricerca, “possiede in realtà una leva strutturale sul futuro”. È una lettura geopolitica dell’estrazione dei dati che a gennaio, quando ho pubblicato il libro, per quanto ne fossi consapevole non ho pensato di affrontare.

Il terzo, e forse il più importante, è la memoria storica. Il Papa usa il ritardo con cui la Chiesa ha condannato la schiavitù come monito sul presente: se non vogliamo chiedere perdono in futuro per non aver visto le nuove asimmetrie di oggi, dobbiamo nominarle adesso. È una valutazione che solo un’istituzione con quel tempo lungo può fare. La riflessione laica contemporanea, la mia compresa, ha una memoria corta. Senza memoria lunga, certe asimmetrie restano fuori dal campo visivo.

E poi c’è il nodo del lavoro

C’è un punto su cui Leone XIV passa, e su cui non ho una posizione netta. È il capitolo sul lavoro, paragrafi 148-169, praticamente la parte più operativa di tutta l’enciclica a mio avviso e quella che parla più direttamente al mondo dell’impresa e della trasformazione digitale.

Il Papa cita san Benedetto e l’ora et labora, parla del lavoro come cammino di maturità e realizzazione. Al paragrafo 148 “lavoro” significa opera e contributo, fatica che ha senso, attività con cui prolunghiamo in qualche modo l’opera del Creatore. Ma già al paragrafo 149 la parola scivola sull’occupazione retribuita che produce sostentamento.

Un’ambiguità antica, che la Dottrina Sociale trascina dalla Rerum Novarum del 1891 in poi, e che oggi pesa, perché tiene insieme due cose che dovremo scindere con intelligenza.

Lo scenario che mi interessa, e che discuto da tempo con un amico parroco con cui non sono d’accordo, è quello in cui l’automazione derivante da AI e Robot libera davvero l’umanità dalla necessità di lavorare per sussistere. È uno scenario plausibile, forse il più radicale (e ottimista per certi versi). In quel mondo un reddito universale di base diventa obbligo strutturale prima ancora che scelta politica: senza, l’IA produce solo concentrazione di ricchezza e povertà di massa. E se la base materiale è garantita, si apre uno spazio per un altro tipo di lavoro, fondato su contributo e non su scambio. Il lavoro dei monaci copisti che hanno salvato la civiltà occidentale tra il VI e il XII secolo. Il lavoro delle madri che crescono i figli. Il lavoro dei volontari che reggono le associazioni, dei contributori di codice open source, dei ricercatori che pubblicano senza ricavarne nulla. Nessuna di queste attività è retribuita. Tutte sono lavoro nel senso pieno benedettino del termine.

Il mio amico Don Michele la pensa diversamente. Non esiste dignità senza lavoro, mi ripete ogni volta che ne parliamo, e lo dice con una fermezza esperienziale prima che ideologica. Vede ogni giorno cosa succede alle persone che il lavoro lo perdono o non lo trovano. Vede come si perde il senso di sé. Per lui il lavoro è un dato antropologico, non un dettaglio economico: è la forma stessa attraverso cui l’essere umano matura e si riconosce. Ed è qui che la sua tradizione e la mia visione del futuro si incontrano in modo costruttivo, perché ha ragione anche lui, su un pezzo del problema che spesso chi ragiona di reddito universale rimuove.

L’essere umano matura attraverso il fare che ha conseguenze. Senza un’opera che lo metta in rapporto con la realtà, con i limiti dei materiali, con il giudizio degli altri, con la propria fatica, la dignità diventa un’astrazione interiore che non regge. La tradizione cristiana lo sa da Genesi in poi, l’uomo è collaboratore della creazione e non spettatore. E sociologicamente succede esattamente quello che il mio amico vede sul campo: nelle comunità dove l’occupazione collassa senza essere sostituita da altre forme di contributo riconosciuto, le persone non fioriscono, si rovinano, entrano in forme diverse di collisione sociale. Le ricerche sulle zone deindustrializzate americane, sui quartieri operai italiani dopo le chiusure delle fabbriche, lo confermano. Se le persone non si sentono utili, tutto collassa.

Magnifica Humanitas apre un varco proprio su questo nodo. Al paragrafo 154 Leone XIV scrive che una società che garantisse occupazione solo a una minoranza esporrebbe molti a “inattività forzata, assenza di responsabilità, mancanza di impegni e stimoli quotidiani, con esiti di impoverimento umano e culturale in contrasto con l’elevato livello di sviluppo tecnico”. Lo chiama “paradosso di progresso materiale e regressione antropologica”. E conclude che è necessario “ripensare il lavoro stesso e il suo rapporto con la cittadinanza, perché l’assenza di occupazione non pregiudichi la partecipazione sociale”. Il Papa non sta dicendo che senza occupazione retribuita non c’è dignità. Sta dicendo che la nozione novecentesca di lavoro, quella che lega stipendio e dignità in un nodo unico, sta diventando inadeguata e va sciolta con cura.

Il “lavoro” come lo intendiamo oggi, un’attività salariata separata dalla vita domestica, misurata in ore, scambiata sul mercato del lavoro, è un’invenzione industriale di duecento anni.

Prima c’erano contadini e artigiani, monaci e madri di famiglia, scribi e copisti. Tutte figure che producevano valore senza essere “occupate” nel senso novecentesco. Hannah Arendt nella Condizione umana distingue tre cose. Labor, la fatica per sopravvivere. Work, la creazione di opere durevoli. Action, l’azione che lascia traccia nel mondo umano. Solo il primo è lavoro nel senso economico stretto. Gli altri due sono ciò che intendo quando parlo di un lavoro non remunerato fatto di passione e contributo.

Da Arendt in poi sappiamo che la dignità del lavoro stipendiato novecentesco era un fascio di tre cose tenute insieme. Un fare che incontra resistenza reale: i materiali e il tempo, la fatica, il giudizio degli altri. Senza questo l’identità si squaglia. Un riconoscimento sociale del valore di quel fare. Senza questo l’attività diventa hobby privato e non sostiene la dignità pubblica. Una base materiale di sussistenza che permetta di farlo senza disperazione. Senza questa, ogni discorso su “passione e ambizione” è privilegio per ricchi. Il salario industriale offriva i tre insieme, e questo ne ha fatto il modello dominante per due secoli. L’errore di chi parla solo di reddito universale, il mio compreso quando alleggerisco troppo il discorso, è pensare che la sola base materiale basti. L’errore opposto, di chi difende una visione ottocentesca del lavoro, è pensare che solo il lavoro retribuito possa fornire le altre due.

C’è poi un nodo geografico che l’enciclica nomina al paragrafo 153 e che vale la pena ripetere. La transizione non procederà in modo omogeneo. Le società ricche si automatizzano caoticamente e producono disoccupazione. Vaste regioni del Sud globale restano intrappolate in quelle che Leone XIV chiama “economie ibride” dove lavoro umano sottopagato e tecnologie parziali convivono senza mai trasformarsi davvero. Diventano serbatoi di manodopera precaria e focolai di migrazioni forzate. Il discorso sul futuro del lavoro va sempre tenuto a due velocità, perché chi parla di reddito universale spesso parla da Paesi ricchi e dimentica che intere economie del pianeta non hanno mai conosciuto il salario industriale come modello.

Siamo all’inizio di una transizione in cui dobbiamo inventare istituzioni che riconoscano come lavoro il fare non retribuito. Se non lo facciamo, la sostituzione algoritmica del lavoro stipendiato sarà una catastrofe antropologica, e su questo l’enciclica ha ragione a essere allarmata. Se lo facciamo, può essere lo spostamento di senso del lavoro più grande dai tempi della riforma benedettina. La domanda concreta, quella che resta aperta, è questa: quali istituzioni possono oggi riconoscere come dignità il lavoro non remunerato? La parrocchia ne è una storica. L’associazione di volontariato un’altra. La famiglia estesa un’altra ancora. Sono tutte istituzioni in crisi, ognuna per ragioni sue. Servono forme nuove, e quelle vecchie vanno rigenerate. Su questo l’enciclica è ambigua secondo me, e credo che il prossimo passo della Dottrina Sociale dovrà essere più esplicito di quanto Leone XIV osi oggi in questa enciclica.

Cosa cambia, se cambia qualcosa

Chi sviluppa e finanzia IA, chi la regola, non può più dichiararsi “tecnico” come schermo. Il paragrafo 209 dell’enciclica chiama in causa scienziati e imprenditori, investitori e autorità accademiche, politici. Quando ci si limita a guardare al proprio settore, scrive Leone XIV, ci si illude di svolgere un compito moralmente neutro. Mi ci ritrovo perfettamente, perché è la stessa argomentazione che faccio nel manifesto finale del libro: il fallimento etico è un fallimento progettuale.

La responsabilità progettuale, che chiamo ethics by design, l’enciclica la riformula come responsabilità condivisa fra istituzioni capaci di regolare, imprese che riconoscono nel lavoro e nella dignità un criterio di successo, corpi intermedi che ricostruiscono fiducia.

C’è un altro elemento operativo che vale la pena segnalare, perché passa sottotraccia ma c’è e non è sottovalutabile. Magnifica Humanitas al paragrafo 159 chiede esplicitamente di superare il Prodotto Interno Lordo come metrica unica dello sviluppo. Servono, scrive Leone XIV, parametri complementari capaci di misurare dignità del lavoro, prosperità condivisa, riduzione delle disuguaglianze, salvaguardia ambientale. Per chi lavora in impresa e si confronta ogni trimestre con KPI finanziari, è un invito a chiedersi quali metriche stiamo davvero usando per misurare il successo dei progetti tecnologici che lanciamo.

Lo stesso vale per il paragrafo 163, dove il Papa elenca quattro criteri operativi che diventano una check-list utile per chi progetta sistemi di IA che incidono su persone. Trasparenza e responsabilità nelle decisioni algoritmiche che riguardano accesso al credito e al lavoro, ai servizi essenziali. Inclusione e accesso ai benefici dell’innovazione, perché la tecnologia non allarghi il divario fra chi ha e chi non ha. Misure di equità che correggano gli squilibri creati dalla concentrazione di ricchezza e potere. Cooperazione internazionale, perché molte decisioni economiche superano i confini degli Stati. Sono cose verificabili, più che principi generici. E sono il vero terreno comune fra una riflessione laica sulla tecnologia e la Dottrina Sociale aggiornata.

Nessuno di noi che lavora su queste materie ha gli strumenti per agire da solo. La convergenza fra tradizioni distanti, su questo, è un dono che vale la pena prendere sul serio.

Neemia ricostruì le mura di Gerusalemme con famiglie diverse, ognuna su un tratto. Nessuna ricostruì l’intera cinta da sola. A chi progetta tecnologia oggi tocca il tratto in cui passa la decisione su cosa deleghiamo, cosa controlliamo, cosa restiamo capaci di giudicare. Il prossimo noi, come scrivevo a chiusura del manifesto di Pelle Digitale, inizia da lì.


Lettera Enciclica Magnifica Humanitas di Papa Leone XIV, 15 maggio 2026.

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.

La politica sull’AI non sa cosa promettere, e questo è un problema

Mi è capitato sotto gli occhi nelle ultime settimane un saggio di Dan Kagan-Kans, The left is missing out on AI, che parte da una constatazione sull’America ma vale anche per l’Italia e probabilmente per buona parte d’Europa. Il dibattito politico sull’intelligenza artificiale, dice in sostanza, ha un buco preciso al centro. Da una parte ci sono i tecnici e gli imprenditori che progettano i sistemi e ne disegnano gli usi. Dall’altra ci sono i policy maker che cercano di limitare i danni, regolare l’esistente, mettere paletti. Manca quasi del tutto, in mezzo, una cosa che invece c’era stata in abbondanza durante la Rivoluzione Industriale: la voce dei movimenti politici che proponevano una loro visione di come la nuova tecnologia avrebbe dovuto servire un progetto di società. Saint-Simon, Owen, Fourier, Marx, ciascuno con un’idea diversa, talvolta opposta, ma tutti con un’idea precisa di cosa fare delle macchine a vapore e dei telai meccanici per costruire il mondo che volevano.

Adesso, in piena rivoluzione AI, quella voce non c’è. O meglio, c’è in modo asimmetrico, in alcune frange della destra americana e in pochissimi nodi accademici, mentre la sinistra in particolare arriva all’AI con due posture parallele: o regolatoria-difensiva oppure indifferente. Manca il terzo movimento, quello che Kagan-Kans identifica come essenziale: una proposta di società in cui l’AI faccia certe cose specifiche per costruire un futuro migliore, immaginate non da chi vende la tecnologia ma da chi rappresenta gli interessi delle persone che ci dovranno vivere dentro.

Questa lettura mi sembra istruttiva e provo a portarla a casa, in Italia, dove la situazione è ancora più acuta.

Il vuoto che non vediamo

Per spiegare bene di cosa parla Kagan-Kans serve riallineare la prospettiva storica. Quando, a inizio Ottocento, le filande meccaniche cominciavano a riorganizzare la produzione manifatturiera in Inghilterra e Francia, non si limitarono a sostituire lavoratori artigiani: scatenarono un dibattito intellettuale e politico che durò decenni, in cui movimenti diversi presero posizione su come usare quelle macchine per fini sociali diversi. I sansimoniani volevano un’industria razionalizzata e gestita da scienziati per il benessere collettivo. Robert Owen sperimentava comunità modello in cui le macchine alleviavano il lavoro e generavano tempo libero per la formazione. Fourier immaginava i falansteri. Marx ed Engels costruivano un’analisi del rapporto capitale-lavoro che attraversa due secoli di pensiero.

Si può essere d’accordo o no con ognuno di questi progetti, ma tutti condividevano una cosa: la pretesa di prescrivere usi specifici della tecnologia per fini politici dichiarati. Non si chiedevano solo come limitare i danni delle macchine, si chiedevano come usarle per costruire la società che volevano.

Oggi, davanti all’AI, questo livello di proposta è quasi assente. C’è abbondanza di analisi sui rischi, di richieste di regolazione, di paure articolate. C’è una quantità ancora maggiore di entusiasmo tecnocratico da parte di chi costruisce i sistemi. In mezzo, però, manca il livello propositivo. Mancano i movimenti che dicono: l’AI dovrebbe essere usata per fare X, Y, Z, secondo un disegno di società che si chiama in questo modo, perché crediamo a queste idee specifiche sul bene comune.

Perché è un vuoto, non un’attesa

Una risposta facile sarebbe dire che è presto. Che si tratta di tecnologie nuove, di applicazioni in corso di stabilizzazione, di scenari ancora sfumati, e che la politica arriverà dopo, quando ci sarà più chiarezza su cosa effettivamente questa tecnologia faccia.

Non penso che sia così, per due ragioni che credo importanti. La prima è che la storia non funziona così. I sansimoniani non aspettarono che la rivoluzione industriale fosse completata per immaginare cosa farne. Cominciarono a immaginarla mentre era ancora in corso, mentre i contorni erano sfumati, e proprio per questo riuscirono a influenzare la direzione. Aspettare la chiarezza significa rinunciare al diritto di disegnare. La seconda è che mentre la politica aspetta, qualcun altro disegna. Quel qualcun altro sono in larga parte le imprese tech, che hanno priori molto definiti sull’uso desiderabile dell’AI: massimizzare l’efficienza, ridurre i costi del lavoro, accelerare il ciclo di sviluppo dei prodotti, espandere la capacità di calcolo. Nessuno di questi obiettivi è cattivo in sé, ma neanche uno coincide automaticamente con un disegno di società sostenibile, equa, capace di sostenere chi rimane indietro.

Il rischio reale di questo vuoto, secondo me, non è la sopraffazione politica della tecnologia. È il contrario: che la politica, non avendo proposte proprie, finisca per importare le priorità del settore tecnologico come se fossero priorità collettive. Già adesso, in molte agende governative italiane, si parla di AI in termini ripresi quasi letteralmente dai pitch di aziende che vendono soluzioni AI. Senza un livello propositivo autonomo, la politica resta in posizione subordinata, regolatoria nel migliore dei casi, ancillare nel peggiore.

Tre cose che potrebbe dire chi volesse riempirlo

Provo a immaginare cosa proporrebbe un movimento politico contemporaneo serio, se decidesse di occupare quel vuoto. Non parlo di programmi elettorali completi, parlo di idee-cardine attorno a cui costruire una visione propositiva sull’AI.

La prima idea potrebbe riguardare il tempo. L’AI può comprimere drasticamente il tempo necessario per certe attività cognitive e operative. Cosa ne facciamo di quel tempo? In una visione economicista, lo trasformiamo in maggior output a parità di ore. In una visione diversa, lo restituiamo alle persone sotto forma di settimana lavorativa più corta, riduzione del lavoro non retribuito, aumento del tempo per la cura, lo studio, la cittadinanza attiva. È una scelta politica, non tecnica. Ma serve un movimento che la metta sul tavolo, perché di default non si sceglierà mai questa direzione.

La seconda idea potrebbe riguardare la conoscenza. L’AI sta concentrando rapidamente l’accesso a una nuova generazione di strumenti cognitivi nelle mani di chi può pagarseli o di chi lavora in aziende che li adottano per primi. La differenza tra chi ha accesso a un assistente AI di alto livello e chi non ce l’ha è già oggi un nuovo divario, e crescerà rapidamente. Un movimento politico serio dovrebbe avere un’idea su come democratizzare quell’accesso: scuole pubbliche che integrano questi strumenti, biblioteche civiche come hub di accesso, formazione adulta non come optional ma come servizio universale. Anche qui, è una scelta politica.

La terza idea potrebbe riguardare l’autonomia. Più gli agenti AI diventano capaci di agire sul mondo, più diventa critica la domanda: chi controlla davvero questi sistemi quando decidono al posto nostro? L’attuale architettura, dominata da una manciata di aziende USA e cinesi, non è l’unica possibile. Esistono alternative open, federate, locali, che richiedono investimenti pubblici per essere competitive. Un movimento che voglia tenere il controllo democratico sulle infrastrutture cognitive del futuro dovrebbe finanziare e proteggere questi modelli alternativi, prima che la concentrazione attuale diventi irreversibile.

Sono tre proposte ovvie, in un certo senso. Eppure non vedo una forza politica italiana che le abbia formulate insieme, dentro una cornice coerente, con la pretesa di costruire un futuro specifico anziché solo gestire l’esistente.

Il punto che mi tocca personalmente

In Pelle Digitale avevo provato a descrivere come la frontiera tra noi e le macchine si stesse facendo più sottile e più aderente, e in Spatial Shift avevo allargato la prospettiva guardando come si stesse riconfigurando lo spazio in cui agiamo. Tornando su quei libri oggi mi accorgo che entrambi descrivono fenomeni in corso senza prescrivere un esito politico. Faccio l’analista, non il proponente. È una scelta legittima per chi scrive da imprenditore. È anche, però, un sintomo del problema che Kagan-Kans diagnostica.

La verità è che osservare e descrivere è la parte facile. Proporre cosa fare di queste tecnologie per costruire la società che vogliamo è la parte difficile, perché richiede una visione politica esplicita, e in questo momento storico in Italia è quasi imbarazzante esprimerne una. Si fa fatica a discutere di visioni politiche di lungo periodo senza essere immediatamente catalogati su un asse destra-sinistra che ha smesso di catturare le distinzioni rilevanti.

Eppure, se non lo facciamo noi, lo faranno altri al posto nostro. Lo faranno bene, perché hanno interesse a farlo. E nessuno di loro avrà come priorità le persone che oggi sento attorno a me ogni giorno, lavoratori cinquantenni che dovranno reinventarsi, studenti che non sanno se le loro lauree avranno valore tra cinque anni, imprenditori medi che si chiedono se le loro aziende riusciranno a stare in piedi nel decennio.

Non ho una proposta politica completa da offrire qui. Ho una sensazione precisa che mi accompagna da mesi: che il pezzo più importante della partita sull’AI non si stia giocando nei laboratori di Anthropic o nelle policy room di Bruxelles, ma in una stanza vuota che nessuno ancora sta occupando. La stanza in cui qualcuno dovrebbe stare disegnando un’idea di società che dia un senso politico a tutta questa potenza tecnica. Senza quel disegno, anche le tecnologie migliori finiscono per servire fini che nessuno ha mai esplicitamente scelto. È successo già due secoli fa, con conseguenze che paghiamo ancora. Mi piacerebbe che questa volta facessimo meglio.

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.

Quanta intelligenza artificiale stai davvero governando?

Usare intelligenza artificiale e governarla sono due cose diverse. Quasi nessuna organizzazione che conosco ha ancora fatto il salto dalla prima alla seconda, e il conto sta arrivando, in modo molto concreto, sotto forma di budget esplosi a fine mese.

Le due cose sembrano simili. Non lo sono per niente.

Ho visto circolare nelle ultime settimane un grafico che mi ha colpito per la sua semplicità, il tipo di visualizzazione che riesce a mettere insieme in modo immediato qualcosa che si intuiva ma non si riusciva ancora a formulare bene. Su scala logaritmica, due curve: i ricavi da abbonamento per posto, piatti e stabili nel tempo, e il costo reale per token di inferenza, che cresce in modo esponenziale con l’intensità d’uso. Finché le linee restano separate, il margine esiste, le aziende che costruiscono su questi modelli respirano. Dopo l’incrocio, il grafico lo chiama “Profit Collapse.” Non è un modello accademico, è quello che le aziende che hanno messo intelligenza artificiale in produzione su larga scala stanno già vedendo nelle loro dashboard finanziarie.

Un caso che ha fatto girare molto rumore nelle ultime settimane: il CTO di Uber ha dichiarato di aver consumato in quattro mesi l’intero budget previsto per l’anno intero. Non perché i modelli non funzionassero. Perché nessuno aveva progettato il workflow con la consapevolezza che ogni chiamata ha un peso, che la somma di migliaia di micro-interazioni che sembrano gratuite diventa, alla scala di un’azienda come Uber, una spesa concreta, reale, non pianificata.

Il prezzo del flat-rate è stato l’ignoranza

Per due anni, i modelli di pricing a tariffa fissa hanno fatto una cosa molto precisa: hanno reso invisibile il costo reale dell’inferenza. La subscription mensile, il “paga X al mese e usa quanto vuoi”, ha creato nelle organizzazioni un’abitudine pericolosa, quella di non porsi le domande giuste sul consumo. Quanti token stiamo generando davvero? Chi li genera? Quale parte del flusso di lavoro produce valore misurabile e quale è ridondanza computazionale, automazione per automazione?

Quelle domande non venivano poste perché il modello economico non le rendeva urgenti. Adesso lo diventano, perché il pricing a token le mette sul tavolo ogni mese, come voce di costo separata, attribuibile, visibile.

La reazione che osservo più spesso è quella sbagliata: tagliare le licenze, ridurre l’accesso, aspettare che i costi scendano ancora. È una risposta di gestione del budget, non una risposta di strategia. E rischia di far perdere il vantaggio competitivo che si stava costruendo nel momento peggiore.

Adottare e governare sono due fasi diverse

C’è una distinzione che mi sembra fondamentale e che non viene fatta abbastanza, anche tra le persone che lavorano sul tema con serietà.

Adottare vuol dire integrare strumenti nei processi, formare le persone, misurare i primi risultati, dimostrare che funziona. È la fase in cui quasi tutte le organizzazioni si trovano, o si sono trovate nell’ultimo anno e mezzo. È necessaria, è il punto di partenza, ed è giusta.

Governare è qualcosa di diverso, più granulare e più esigente. Significa sapere dove ogni interazione con un modello si inserisce nel flusso operativo, quali sono le condizioni di attivazione, quanto pesa in termini di contesto, quanto costa ogni singola risposta e perché vale quello che costa. Significa avere visibilità sul consumo in tempo reale, non scoprirlo a consuntivo a fine mese. Significa, soprattutto, aver progettato i processi attorno agli strumenti, non aver semplicemente incollato un modello linguistico sopra un flusso di lavoro che esisteva già prima e che continua a funzionare esattamente come prima, solo con un layer di testo generato in più.

La gran parte delle organizzazioni che conosco è ancora nella fase dell’adozione. Si vede dai sintomi: budget che arrivano come sorprese, utilizzi distribuiti in modo caotico tra team diversi, nessuna metrica di efficienza sul consumo, nessuna distinzione operativa tra le interazioni che creano valore e quelle che lo consumano senza restituirlo.

Perché tenere l’intelligenza dentro cambia tutto

In questo contesto, spostare i modelli dentro perimetri controllati, on-premise o in architetture ibride dove il dato sensibile non esce, smette di essere una posizione ideologica sulla sovranità del dato e diventa una scelta molto concreta, economica e operativa insieme.

I vantaggi sono due, e si sovrappongono. Il primo è la prevedibilità dei costi: un modello che gira su infrastruttura propria ha un costo fisso che si pianifica, con una variabile di consumo che rimane interna, controllabile, non affidata all’intensità d’uso di tremila dipendenti distribuiti su fusi orari diversi. Il secondo è la compliance, che con l’AI Act in vigore e la pressione normativa che continua a crescere è diventata un requisito operativo con scadenze e responsabilità, ben oltre il perimetro di chi si occupa di legale.

Non tutti i casi d’uso hanno bisogno di modelli privati. Molti flussi di lavoro funzionano perfettamente su API pubbliche, purché siano stati progettati con la consapevolezza del costo. Ma la scelta tra pubblico e privato non può essere presa senza aver prima risposto alle domande di governo: chi usa cosa, con quale frequenza, per fare cosa, e quanto rende.

I token come risorsa operativa

C’è un cambio culturale che secondo me non sta avvenendo alla velocità giusta, ed è quello di trattare il consumo di token come una risorsa operativa, con la stessa serietà con cui si trattano le ore di computing, la banda di rete, lo storage.

In ogni organizzazione tecnologicamente matura, queste metriche hanno un owner, un budget, un ciclo di ottimizzazione. Il consumo di token, finora, non ne ha avuto uno. Era nascosto nel flat-rate, o era abbastanza economico da sembrare irrilevante come singola voce.

Non è più così, e la risposta non è tagliare, come dicevo. La risposta è costruire la governance prima che il budget esploda: monitoraggio in tempo reale, attribuzione del consumo per team e per processo, soglie di allerta, revisione periodica dei flussi ad alto costo. È lavoro di ingegneria, di processo, di cultura organizzativa. È il lavoro che separa chi sta ancora adottando da chi sta davvero costruendo.

C’è un parallelo che mi viene in mente pensando a come siamo arrivati qui. Nel mondo dello sport professionistico, c’è stato un momento in cui le squadre hanno smesso di valutare i giocatori a occhio e hanno iniziato a misurare tutto, ogni azione, ogni metro percorso, ogni contatto. Quella trasformazione non ha reso lo sport meno umano, ha reso le decisioni più informate. Qualcosa di simile sta per succedere con l’intelligenza artificiale in azienda: chi impara a misurare prima, e a misurare le cose giuste, arriverà avvantaggiato alla fase successiva.

La competizione si sposta

Ci sarà un punto, e credo non lontano, in cui la competizione sull’intelligenza artificiale in azienda non si giocherà più sull’accesso ai modelli. I modelli sono già disponibili, i costi di inferenza scendono, la barriera tecnica all’ingresso si abbassa. La competizione si giocherà su chi riesce a usarli in modo economicamente sostenibile, con processi progettati per reggere la scala, non solo la demo, e con la capacità di misurare, ottimizzare, correggere in tempo reale.

Le organizzazioni che arriveranno avvantaggiate a quella fase sono quelle che adesso, mentre la conversazione pubblica è ancora tutta sull’adozione e sui casi d’uso, stanno costruendo la governance. Stanno ponendo ai loro team le domande scomode. Stanno mettendo metriche dove prima c’erano impressioni. Stanno disegnando flussi di lavoro che hanno senso economico oltre che funzionale.

Senza dubbio, la domanda che conta adesso non è “stai usando intelligenza artificiale?” ma “sai cosa sta facendo l’intelligenza artificiale che stai usando, e quanto ti costa davvero governarla?”

Onlyness e leadership: perché il change management non funziona più

Ho ascoltato in questi giorni il podcast con Nilofer Merchant in cui torna sul concetto che porta avanti da anni, quello che lei chiama onlyness, e lo applica a un’idea che mi sembra meriti più attenzione di quella che riceve in Italia: la fine del change management come l’abbiamo conosciuto. Merchant viene da una carriera lunga in Apple e Autodesk, ha lanciato oltre cento prodotti, è una delle voci più riconosciute sul Thinkers50, e da qualche tempo dice una cosa precisa. Il change management, inteso come piano che parte dall’alto e si distribuisce sotto, è uno strumento del Novecento. Funzionava in un mondo in cui chi stava in cima sapeva la direzione e chi stava sotto doveva essere portato a seguirla, con la giusta combinazione di leve di influenza, comunicazione e formazione. Era un sistema di controllo travestito da accompagnamento.

Quel mondo, dice Merchant, non esiste più. Esiste un altro mondo in cui la conoscenza necessaria per cambiare un’organizzazione non sta più tutta in cima ed esiste quasi sempre distribuita nei nodi, perché sono i nodi quelli che toccano i clienti, i prodotti, le anomalie, le opportunità invisibili dal piano direttivo. Allora il cambiamento non si gestisce più. Si co-crea. E il ruolo della leadership si trasforma da quello di chi indica la rotta a quello di chi sa porre le domande giuste e accetta di non sapere ancora la risposta.

Il sapere si è spostato, i framework no

Per anni ho visto progetti di trasformazione organizzativa fallire per la stessa ragione di fondo, quella che adesso Merchant nomina bene. C’era una sproporzione tra chi disegnava il cambiamento e chi lo doveva attuare. Quelli che lo disegnavano sapevano abbastanza di strategia ma poco del lavoro reale, quelli che lo dovevano attuare sapevano del lavoro reale ma erano tenuti fuori dal disegno. Il classico tentativo di sanare lo squilibrio era introdurre cicli di workshop, focus group, sondaggi di engagement. Roba che dava al sotto l’illusione di partecipare al sopra senza spostare davvero la decisione. Funzionava, a tratti, perché il sotto accettava la finzione in cambio di un po’ di considerazione.

Adesso quella finzione si rompe da sola, e non per ragioni etiche ma per ragioni di efficienza. L’AI sta amplificando un fenomeno che già era in corso da vent’anni: la conoscenza utile per prendere decisioni si è spostata verso i bordi dell’organizzazione. Strumenti come Claude, Copilot, e tutti i loro fratelli, mettono nelle mani di chi sta nei nodi capacità di analisi, sintesi, prototipazione che fino a ieri richiedevano staff dedicato. Una persona junior con un modello potente accanto può oggi produrre output decisionali che dieci anni fa erano appannaggio di consulenti senior pagati a giornata. Allora la domanda diventa imbarazzante: perché continuiamo a gestire il cambiamento come se la conoscenza fosse ancora gerarchica?

Onlyness applicata alla trasformazione

Il concetto di onlyness di Merchant è la chiave operativa che permette di uscire dall’impasse. Onlyness è il punto unico del mondo in cui solo tu stai, dato dalla combinazione esatta di esperienza, storia, prospettiva, relazioni che hai accumulato. Da quel punto unico puoi vedere cose che nessun altro vede e portare contributi che nessun altro può dare. Vista così, ogni persona in organizzazione è portatrice di onlyness, e l’onlyness non si delega.

Quando trasferisci questa idea al cambiamento organizzativo, succede una cosa interessante. Il piano dall’alto smette di essere un piano. Diventa una cornice: la domanda che si sta cercando di rispondere, il vincolo che bisogna rispettare, l’orizzonte temporale entro cui muoversi. Dentro quella cornice, sono gli onlyness distribuiti a costruire le soluzioni, una accanto all’altra, una sopra l’altra, fino a comporre qualcosa che nessuna mente singola avrebbe potuto disegnare. Il ruolo di chi guida diventa custodire la cornice, non riempirla. Tenere fermo il perché, lasciare aperto il come.

Sembra astratto e invece è molto operativo. Vuol dire che il leader passa la maggior parte del tempo a fare due cose: a formulare e riformulare la domanda finché diventa abbastanza precisa da orientare l’azione senza essere così stretta da chiudere lo spazio creativo, e a costruire le condizioni in cui le persone si sentono sicure abbastanza per portare il proprio punto unico al tavolo senza paura. La seconda cosa è la più difficile, perché va contro decenni di abitudini gerarchiche.

Onlyness e disagio: il segnale che qualcosa sta davvero cambiando

Merchant parla del disagio come componente strutturale del processo. Non lo vede come effetto collaterale da minimizzare, lo vede come segnale che si sta andando nella direzione giusta. Se durante un processo di cambiamento nessuno sta scomodo, allora con buona probabilità non sta cambiando niente di vero. Sta cambiando solo la superficie, magari i diagrammi, magari le nomenclature, magari i punteggi negli engagement survey. Ma sotto, le vecchie posizioni di potere stanno tenendo botta.

Il disagio vero arriva quando chi era abituato a decidere deve imparare ad ascoltare prima di parlare, quando chi era abituato a eseguire deve imparare a proporre, quando chi era abituato a sapere deve riconoscere apertamente che non sa. Sono tre disagi simmetrici, distribuiti nei tre livelli classici dell’organizzazione, e nessuno dei tre è gratis. Merchant non promette una scorciatoia. Dice che il leader serio è quello che lo accetta e ci convive, anziché cercare di anestetizzarlo con metodologie sempre più sofisticate.

Leader e onlyness: la nuova base dell’autorità

Nel mio libro La mente adattiva avevo cercato di descrivere come la capacità di adattamento individuale e organizzativo stesse diventando la competenza chiave del decennio. Adesso vedo che quella tesi ha bisogno di un’integrazione. L’AI non aumenta solo l’urgenza dell’adattamento, ne cambia anche la natura. Perché l’AI non è uno strumento che aspetta l’istruzione, è un agente che propone. Lavora con te, ti porge alternative, ti contesta assunzioni. Se sai usarla, è come avere accanto un collega che ha letto tutto ed è disposto a discutere all’infinito.

In quel quadro, l’organizzazione gerarchica vecchio stampo diventa un collo di bottiglia evidente. Se ogni nodo dell’organizzazione ha accesso a un partner di ragionamento di livello globale, il freno smette di essere informativo e diventa autorizzativo: non manca più la conoscenza, manca il permesso di usarla. La burocrazia interna che doveva proteggere dalla cattiva decisione adesso protegge dalla decisione e basta. E intanto i competitor più piccoli, più piatti, più disposti a co-creare, si muovono prima.

Cosa succede a chi guida quando questo si avvera? Succede che il modello mentale del leader come ultimo decisore informato non regge più. L’AI sa più cose di te, su quasi tutto. I tuoi collaboratori, ben armati di AI, sanno più cose di te sui loro ambiti specifici. La tua autorità non può poggiare sul “sapere di più”, perché è semplicemente falso. Deve poggiare su qualcos’altro: sulla qualità delle domande che fai, sulla precisione con cui custodisci la direzione, sulla capacità di tenere viva la coesione del gruppo quando tutti sanno troppe cose e nessuno sa quella decisiva.

Come si forma il prossimo livello di leadership

Se la co-creazione è davvero il nuovo paradigma e l’AI lo accelera, allora va riaperta la questione su come si forma il prossimo livello di leader. Le vecchie palestre, le carriere lineari, gli step da middle a top management, presupponevano un mondo in cui si saliva accumulando sapere e contatti. Adesso il sapere è distribuito e i contatti li media spesso un algoritmo. Quello che resta scarso, e che diventa quindi il vero asset, è la capacità di stare nel disagio della non-conoscenza, di formulare domande che muovono persone e organizzazioni, di tenere insieme talenti diversi intorno a un perché che regge.

Tre cose che non si imparano leggendo, si imparano facendo, in mezzo agli altri, fallendo davanti a loro qualche volta. Mi piacerebbe vedere più aziende che progettano percorsi di leadership su queste tre dimensioni invece che sulla classica triade conoscenze-competenze-soft skill. Sarebbe già un primo passo verso il post-change-management che Merchant prefigura. Per ora, da imprenditore che ha attraversato cambiamenti organizzativi di vari ordini di grandezza, dico che il problema più sottile sta nel cambiare l’idea che abbiamo del leader, prima ancora delle regole. E quella, le regole, non basta a smuoverla.

Se vuoi confrontarti su come riprogettare ruoli di leadership in un contesto in cui l’AI ridistribuisce la conoscenza nei nodi, c’è la pagina Advisory con i formati di collaborazione che propongo a CEO e leadership team.