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?

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.

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?”

Anthropic sposta l’esecuzione dentro l’azienda, la regia resta fuori

Il 19 maggio, al primo Code with Claude tenuto a Londra, Anthropic ha annunciato due funzionalitร  che spostano in modo concreto dove vivono gli agenti AI dentro le aziende. La prima si chiama self-hosted sandboxes ed รจ in public beta. La seconda si chiama MCP tunnels ed รจ in research preview. Messe vicine valgono piรน di quanto sembrino a una lettura veloce della release note, e provo a dire perchรฉ.

Il punto di partenza tecnico รจ semplice. Claude Managed Agents รจ l’infrastruttura ospitata di Anthropic per far girare sessioni agentiche lunghe e tool-heavy. Fino a maggio, tutto stava lรฌ: l’agent loop con orchestrazione e gestione del contesto, l’esecuzione dei tool, la connessione ai servizi esterni. Adesso una parte di quello stack puรฒ uscire da Anthropic e rientrare dentro il perimetro del cliente, mentre l’altra resta dove era. La regia rimane su Anthropic. L’azione si sposta a casa tua.

Schema del MCP tunnel di Anthropic: esecuzione dentro la sandbox, regia esterna
Fonte: Anthropic, schema del MCP tunnel.

L’esecuzione si sposta a casa tua

Quando un agente esegue un tool, esegue codice. Apre file, installa pacchetti, chiama API, scarica risorse. Fino a ieri tutto questo avveniva nei sandbox gestiti da Anthropic. Da oggi puoi configurare l’agente perchรฉ esegua quegli stessi tool dentro la tua infrastruttura, oppure presso un provider gestito a tua scelta (Cloudflare, Daytona, Modal, Vercel sono i nomi citati). I tuoi file sensibili, le repository di codice, i pacchetti privati, i segreti di configurazione non lasciano piรน la tua rete. E il logging di audit, le policy di sicurezza, gli strumenti di monitoring che hai giร  sul tuo perimetro continuano a vedere e regolare quello che fa l’agente.

L’orchestrazione, invece, resta su Anthropic. L’agent loop, la gestione del contesto, la recovery dagli errori, la pianificazione delle azioni successive sono tutti gestiti dall’API di Claude. Cambia solo dove materialmente vengono eseguite le chiamate. Se l’agente decide di lanciare uno script Python per processare un file, lo script gira sul tuo sandbox, non sul loro.

Un canale che parla solo verso l’esterno

Gli MCP tunnels affrontano il problema speculare. Come fa un agente a parlare con i tuoi sistemi interni senza che tu debba esporli a internet? Il Model Context Protocol รจ lo standard aperto che Anthropic ha promosso lo scorso anno per far dialogare gli agenti con sorgenti dati e servizi esterni. Funziona bene quando i servizi sono pubblici, meno bene quando sono dentro un network privato.

Il meccanismo che hanno introdotto รจ un gateway leggero, che il cliente dispiega dentro la propria rete, e che apre una singola connessione outbound verso Anthropic, cifrata end-to-end. Nessuna porta inbound da aprire. Nessun endpoint pubblico. Nessuna modifica al firewall. Sopra quel canale possono passare conversazioni MCP verso server interni che ospitano database, knowledge base, ticketing system, API private. L’agente di colpo puรฒ chiamare quei sistemi come fossero tool standard, ma il traffico non transita mai sull’internet pubblico.

Dove finisce l’azienda, dove comincia il modello

A una lettura superficiale รจ un aggiornamento di sicurezza e compliance. Per le aziende regolate รจ una notizia importante perchรฉ toglie uno dei blocchi tipici all’adozione, quel “non possiamo far uscire i dati” che ferma centinaia di progetti ogni anno. Per chi vende AI in enterprise รจ una mossa competitiva contro i player che offrono giร  installazioni on-premise complete.

C’รจ anche un altro livello. Anthropic sta dichiarando, in modo molto operativo, dove finisce l’azienda e dove comincia il modello. Per anni la domanda “dove vive un’AI aziendale” ha avuto due risposte estreme: o tutto in cloud sul provider, oppure tutto on-premise con uno stack auto-ospitato. Adesso ne sta diventando praticabile una terza, piรน sottile. La testa pensante del sistema, l’agent loop, resta fuori dall’azienda perchรฉ lรฌ sta l’innovazione che si muove troppo veloce per essere replicata internamente. Le mani che toccano i dati e i tool tornano dentro perchรฉ lรฌ stanno le regole, la responsabilitร , il perimetro legale e culturale.

รˆ una decomposizione interessante. Non รจ cloud, non รจ on-prem, รจ un terzo modello in cui l’autoritร  decisionale dell’agente รจ separata dall’autoritร  esecutiva. Anthropic decide come ragiona. Tu decidi cosa puรฒ toccare. La superficie di contatto fra i due livelli รจ codificata in due primitive ben definite, il sandbox e il tunnel.

Cambia anche il modo di comprarla

In Pelle Digitale avevo provato a descrivere come la mediazione tra noi e le macchine stesse cambiando forma. Quello che vedo qui รจ una variante infrastrutturale dello stesso fenomeno. La pelle non รจ piรน solo l’interfaccia in cui parliamo col modello. รˆ anche la membrana tecnica che decide cosa passa e cosa no, cosa esce dall’azienda e cosa rientra, cosa il modello puรฒ sapere e cosa no. La progettano gli ingegneri di Anthropic disegnando le primitive del sistema. La progettiamo noi configurando policy, tunnel, sandbox.

Chi sta portando agenti AI in produzione dentro un’azienda strutturata, con questa architettura, deve mettere in conto tre cose che fino a ieri non c’erano.

Sul piano contrattuale e legale il discorso “i miei dati attraversano i server del fornitore” diventa meno semplice da fare, perchรฉ in molti scenari non รจ piรน vero. Tool execution e dati restano dentro, l’agente fuori vede solo quello che il sandbox gli restituisce. Vanno aggiornati i template di DPIA, le clausole nei contratti con i fornitori, le policy di data residency.

Sul piano organizzativo bisogna decidere chi gestisce un agente AI con questa architettura. Lo sviluppo software perchรฉ esegue codice. L’infrastruttura perchรฉ ospita sandbox e gateway. Il security perchรฉ definisce le policy del perimetro. Il data team perchรฉ decide quali sistemi interni esporre via MCP. Sono quattro funzioni che fino a ieri non lavoravano insieme su questo tipo di progetti, e bisognerร  costruire workflow nuovi per farle convivere.

Sul piano strategico, Anthropic dichiara con queste mosse di voler diventare l’infrastruttura di default per gli agenti enterprise. Non un fornitore di modelli sotto, ma un layer di orchestrazione che si integra dentro le aziende mantenendo i confini tecnici e di sicurezza che le aziende vogliono. Per chi compra รจ una scelta strategica diversa rispetto a scegliere un fornitore di LLM piรน una soluzione di agentic framework messa su a parte. Per chi vende prodotti AI on top, conviene capire dove si posiziona la propria offerta rispetto a questo stack che si sta consolidando.

Il debug a cavallo del confine

C’รจ una cosa che la documentazione di Anthropic non risolve, e che secondo me sarร  il punto di osservazione piรน interessante nei prossimi mesi. Quando l’agent loop sta fuori e i tool girano dentro, il debugging di un comportamento anomalo dell’agente diventa un esercizio distribuito. Il log dell’orchestrazione lo vede Anthropic. Il log dell’esecuzione lo vedi tu. La correlazione fra una decisione presa dal modello e un’azione fatta sul tuo sandbox passa attraverso due piani di osservabilitร  separati. Per capire perchรฉ un agente ha cancellato un file di troppo, serviranno entrambi.

Vedere come si organizza questa osservabilitร  a cavallo del confine sarร  uno degli indicatori migliori per capire se il pattern decolla davvero, o se resta confinato ai casi d’uso piรน semplici. La promessa tecnica c’รจ, la direzione mi sembra giusta. Resta da vedere quanto in fretta le aziende, anche quelle non super-tech, riusciranno ad attrezzarsi per giocare a questo gioco con la maturitร  che richiede.


Articolo di riferimento: New in Claude Managed Agents: self-hosted sandboxes and MCP tunnels, Anthropic, 19 maggio 2026.

La rivoluzione dellโ€™AI non avverrร  dallโ€™oggi al domani

Da un paio di anni, ogni giorno, nel nostro stream social appaiono proclami entusiasti su come lโ€™intelligenza artificiale rivoluzionerร  tutto in un lampo. Secondo previsioni, fin troppo ottimistiche, lโ€™AI sarebbe giร  alle soglie di โ€œallacciarci le scarpe, cucinare al posto nostro, gestire le nostre aziende e risolvere la fame nel mondoโ€, con un impatto economico annuo stimato in decine di migliaia di miliardi di dollari.

Questa visione รจ seducente, senza dubbio, ma, per dirla con le parole di Paul Hlivko, รจ anche una โ€œallucinazioneโ€. La realtร  che vivo da consulente e imprenditore nel digitale mi insegna che abbiamo giร  visto film simili con altre tecnologie emergenti, e raramente il finale รจ allโ€™altezza del trailer promozionale, per quanto, io stesso, penso che questa volta ci sia molta differenza rispetto ai precedenti impatti e tutto potrebbe andare decisamente in modo diverso. Lโ€™AI revolution tanto decantata arriverร , sรฌ, ma non in modo istantaneo nรฉ magico. E su questo ne sono certo, perchรฉ lo vedo, e perchรฉ la preparazione culturale, infrastrutturale e tecnologica nelle aziende non รจ cosi matura come necessiterebbe per poter veramente avere gli effetti desiderati.

Come disse il pioniere Alan Turing nel 1950, la domanda era se le macchine potessero pensare; oggi la vera domanda รจ se noi sappiamo pensare in modo intelligente a come usare le macchine. In altre parole, il fattore critico non รจ la potenza dellโ€™AI in sรฉ, ma la nostra capacitร  di adottarla con giudizio e integrarla concretamente nel tessuto dellโ€™innovazione aziendale. Con questo approfondimento, riflessivo e provocatorio, provo a far capire perchรฉ la rivoluzione dellโ€™AI sarร  un percorso graduale (e accidentato), e quale mentalitร  dovrebbero adottare manager e aziende per trarne valore reale.

Perchรฉ lโ€™adozione dellโ€™AI sarร  lenta, complessa e piena di attriti

La storia ci insegna che ogni ondata tecnologica, dal cloud alla blockchain, รจ stata accompagnata da un picco di hype seguito da un lungo declino (utile a far pulizia di progetti non sostenibili) e subito dopo da un arduo processo di consolidamento e adozione. E lโ€™AI non farร  eccezione, per quanto tutto stia viaggiando ad una velocitร  di crociera assurda: implementarla in azienda significa toccare processi, abitudini e modelli di business consolidati.

Il problema non รจ scrivere qualche riga di codice in piรน, ma affrontare il cambiamento culturale e organizzativo necessario per far funzionare davvero queste soluzioni nella pratica quotidiana. Spesso le grandi organizzazioni si muovono lentamente: procedure di compliance, revisioni di sicurezza e approvazioni multiple, processi incancreniti, paura del cambiamento che fanno sรฌ che lโ€™adozione di un semplice strumento AI richieda mesi invece che giorni, creando attriti interni che soffocano lโ€™innovazione. Questa cautela รจ comprensibile (proteggere dati e rispettare normative รจ essenziale) ma a volte si trasforma in una iperprudenza paralizzante. Il risultato? Le aziende piรน lente rimangono indietro mentre concorrenti piรน agili sperimentano e imparano sul campo. Chi aspetta troppo rischia di perdere quote di mercato, talenti e opportunitร  di crescita, perchรฉ il vero rischio oggi non รจ lโ€™AI in sรฉ, ma restare fermi mentre gli altri avanzano. A me fa ridere quando sento imprenditori dire โ€œNoi ci muoviamo dopo, e mentre gli altri sbagliano fatturiamo su altro. Poi ci muoviamo e facciamo meglio degli altriโ€. Fa ridere perchรฉ se da una parte il concetto รจ anche corretto โ€œlasciamo che gli altri sbaglino, noi bruciamo menoโ€ nella pratica, in un contesto nuovo, chi sbaglia con metodo, impara prima e agisce di conseguenza, con maggiore consapevolezza e maturitร .

Un caso emblematico รจ quello di IBM Watson: dopo la vittoria trionfale a Jeopardy! nel 2011, Watson venne annunciato come il medico AI infallibile che avrebbe rivoluzionato la sanitร . Eppure, fuori dai laboratori, anche una tecnologia potentissima si รจ scontrata con la dura realtร  operativa: integrare lโ€™AI nei flussi clinici e nei sistemi ospedalieri si รจ rivelato incredibilmente difficile, al punto che molti progetti sono naufragati nonostante gli ingenti investimenti. Come osservava amaramente un esperto coinvolto, IBM โ€œรจ partita con il marketing prima e il prodotto poiโ€, generando aspettative altissime, ma โ€œquando si รจ passati ai fatti, la strada si รจ rivelata incredibilmente duraโ€.

Questa lezione vale per tutti: non basta una demo spettacolare perchรฉ una soluzione AI funzioni nel mondo reale, bisogna fare i conti con legacy tecnologico, processi disallineati e resistenze umane.

Le statistiche degli ultimi anni sui fallimenti nei progetti di trasformazione digitale sottolineano ulteriormente questo punto. Studi di Harvard Business Review indicano che circail 70% delle trasformazioni digitali fallisce, e non per problemi tecnici, ma a causa di resistenze culturali e mancanza di allineamento nella leadership. In altre parole, sette volte su dieci la tecnologia era pronta, ma lโ€™organizzazione no. Implementare lโ€™AI richiede quindi una seria strategia di change management: governance chiara, sponsor forti ai vertici e coinvolgimento delle persone a tutti i livelli. Senza questi ingredienti, anche lโ€™algoritmo piรน potente rimane inutilizzato o, peggio, genera caos invece di efficienza.

Il problema delle aspettative e dei bias cognitivi

Perchรฉ continuiamo a sopravvalutare la velocitร  con cui lโ€™AI trasformerร  tutto? La risposta risiede in alcuni bias, non quelli dellโ€™AI, ma quelli umani, i bias cognitivi che affliggono anche manager navigati. In particolare (e confermo che ne ho ho avuto riscontri da vicino) tre bias giocano un ruolo chiave nellโ€™alterare le nostre aspettative:

  • Fallacia della pianificazione. Tendiamo sistematicamente a sottostimare il tempo e la complessitร  necessari per implementare cambiamenti su larga scala. Con lโ€™AI, molti leader assumono che โ€œbasterร  lanciare un progetto pilota e in pochi mesi vedremo risultati rivoluzionariโ€, ignorando le lunghe fasi di integrazione, formazione del personale, aggiustamenti e iterazioni che invece sono la norma. รˆ lo stesso ottimismo ingenuo che porta a sforare tempi e budget in tanti progetti IT.
  • Bias dellโ€™ottimismo. Ci illudiamo che lโ€™adozione sarร  fluida e indolore, sottovalutando gli ostacoli. Quando una nuova tecnologia sembra promettere benefici enormi, scatta in noi una propensione a vedere il bicchiere mezzo pieno: crediamo che dipartimenti, partner e clienti abbracceranno con entusiasmo la novitร . La realtร  insegna che spesso ci sono piรน resistenze che entusiasmo iniziale, ed รจ normale, perchรฉ ogni novitร  rompe equilibri esistenti.
  • Bias di โ€œrecencyโ€. Siamo sviati dai successi recenti in altri contesti. Ad esempio, il boom virale di ChatGPT tra i consumatori (oltre 100 milioni di utenti in pochissimo tempo) porta alcuni a credere che anche nelle imprese lโ€™adozione sarร  immediata e spontanea. Ma ciรฒ che avviene nel mercato consumer, dove un tool puรฒ diffondersi organicamente grazie alla curiositร  individuale, non si replica automaticamente in azienda, dove subentrano considerazioni di sicurezza, compliance, ROI e integrazione con sistemi preesistenti. E aggiungo di trust.

Questi bias generano aspettative irrealistiche. Chi decide, preda dellโ€™entusiasmo, annunciano grandi trasformazioni a tappe forzate, sottovalutando la fase di transizione. Si crea cosรฌ un pericoloso gap tra promesse e realtร : quando i risultati tardano (perchรฉ inevitabilmente tarderanno rispetto alle fantasie iniziali), si rischiano disillusione, tagli ai fondi e un effetto boomerang sul supporto interno allโ€™AI.

Per evitare questo ciclo negativo, i leader dovranno fare un passo indietro e adottare un approccio piรน lucido, bilanciando visione e pragmatismo. Come recita la cosiddetta Legge di Amara, di cui ho scritto anche tempo fa, tendiamo a sopravvalutare lโ€™impatto di una tecnologia nel breve termine e a sottovalutarne gli effetti nel lungo termine. Serve quindi pazienza nel breve e perseveranza strategica per coglierne il vero potenziale nel lungo periodo.

I limiti economici e infrastrutturali dei modelli di AI attuali

Al di lร  delle questioni organizzative, esistono constraint tecnici ed economici molto concreti che rallentano lโ€™adozione massiva dellโ€™AI oggi. I modelli di Generative AI di ultima generazione, ย come i GPT di OpenAI, richiedono una potenza di calcolo e una quantitร  di dati semplicemente fuori scala rispetto ai sistemi tradizionali. Allenare da zero un modello come GPT-3, ad esempio, รจ stato stimato costare fra i 4 e i 12 milioni di dollari, e lโ€™evoluto GPT-4 ha probabilmente richiesto investimenti nellโ€™ordine di decine di milioni.

Non si tratta solo di comprare qualche server: servono migliaia di GPU specializzate, enormi dataset, team di ricerca altamente qualificati e un consumo energetico impressionante (centinaia di tonnellate di COโ‚‚ per una singola addestramento di modello di grandi dimensioni). Questo significa che pochissime organizzazioni al mondo possono permettersi di sviluppare in house modelli AI generalisti di questo calibro.

La maggior parte delle aziende dovrร  affidarsi a modelli e infrastrutture fornite dai grandi player (OpenAI/Microsoft, Google, Amazon, Anthropic, ecc.), con implicazioni in termini di costi operativi (accesso via cloud a pagamento), dipendenza strategica e gestione dei dati sensibili.

Anche utilizzare questi modelli pre-addestrati non รจ banale: integrarli nei propri prodotti o processi richiede lavoro di ingegnerizzazione, personalizzazione e manutenzione continua. Le attuali implementazioni di GPT, ad esempio, tendono a โ€œallucinareโ€ (ovvero generare output errati o inventati) e a riflettere bias presenti nei dati di training. Per usare queste AI in contesti aziendali mission-critical, serve costruire intorno ad esse tutta unโ€™architettura di guardrail, con controlli, filtri e validazioni che ne imbrigli il comportamento. Questo aggiunge complessitร  ulteriore. Vi รจ poi il tema cruciale dei dati. Un algoritmo di AI รจ solo potente quanto i dati di cui si nutre. Molte imprese scoprono, avviando progetti AI, di non avere dati di qualitร  sufficiente, o di averli in silos non comunicanti, pieni di errori e incoerenze.

Secondo un rapporto Deloitte, in gran parte delle organizzazioni meno di un terzo dei progetti pilota di AI generativa arriva a essere messo in produzione, spesso proprio perchรฉ le aziende faticano a raccogliere e ripulire tutti i dati necessari su cui far correre i modelli. Non sorprende quindi che, per capitalizzare sulle tecnologie GPT, molte aziende stiano investendo non solo nellโ€™AI in sรฉ, ma in massicci sforzi di data engineering e gestione del dato. Senza basi dati solide, lโ€™AI resta un motore potente ma senza carburante.

Cโ€™รจ poi una considerazione infrastrutturale: poche realtร  dispongono giร  oggi di piattaforme IT in grado di integrare senza colli di bottiglia gli output di un modello generativo nei workflow esistenti. Ad esempio, se un modello GPT elabora in linguaggio naturale richieste dei clienti, come si collega poi ai sistemi di CRM, ai database interni, ai flussi di lavoro del servizio clienti? Spesso sono necessarie integrazioni custom, middleware e adattamenti dei sistemi legacy, tutte attivitร  che richiedono tempo, competenze (scarse) e investimenti (con budget ancora piรน scarsi). E nel frattempo la tecnologia AI continua a evolvere rapidamente, il che significa che ciรฒ che integriamo oggi potrebbe dover essere rivisto tra 6 mesi (se faccio una valutazione pessimistica eh). Anche questo contribuisce a frenare unโ€™adozione immediata e ubiqua dellโ€™AI in azienda: cโ€™รจ un delta temporale inevitabile tra lโ€™emergere della tecnologia e la sua maturazione in soluzioni industrializzate, scalabili e affidabili.

Il vero valore dellโ€™AI: integrazione nei processi e nei flussi decisionali

Dove risiede allora il vero valore dellโ€™AI in azienda? La risposta, controintuitiva per alcuni, che spiego costantemente quando faccio formazione, รจ che il valore non deriva dallโ€™AI in isolamento, ma dalla sua integrazione intelligente nei processi esistenti e nei flussi decisionali quotidiani.

Lโ€™AI da sola non creerร  valore; saremo noi umani, con il nostro ingegno organizzativo, a creare valore grazie allโ€™AI, se saremo disposti a fare il duro lavoro di integrarla, governarla e scalarla con criterio. Ciรฒ significa ripensare comeprendiamo decisioni, come sviluppiamo prodotti, come interagiamo con clienti e dipendenti, inserendo lโ€™AI come โ€œcopilotaโ€ che amplifica le nostre capacitร .

Per capire questo concetto, รจ utile pensare allโ€™AI non come a una bacchetta magica, ma come a un nuovo membro del team, uno strumento che va orchestrato. Prendiamo lโ€™esempio di OpenAI: hanno rilasciato un modello potente come ChatGPT al pubblico, ma il suo impatto in ambito enterprise si sta realizzando davvero solo quando viene inglobato in piattaforme di lavoro. Un caso pratico รจ Microsoft, che sta integrando le capacitร  di GPT-4 nel suo ecosistema Office (il progetto Microsoft 365 Copilot). Invece di lanciare unโ€™ennesima applicazione stand-alone, Microsoft sta portando lโ€™AI dentro Word, Excel, Outlook, Teams e gli altri strumenti che milioni di persone usano ogni giorno. Questo รจ emblematico: il salto di produttivitร  non avviene insegnando ai dipendenti ad usare un nuovo software miracoloso, ma potenziando gli strumenti familiari con funzionalitร  AI.

Ad esempio, in Teams lโ€™AI potrร  trascrivere e riassumere riunioni, in Outlook smistare la posta e proporre risposte, in Excel analizzare trend nei dati. Lโ€™AI diventa cosรฌ parte del flusso di lavoro esistente, riducendo le frizioni nellโ€™adozione perchรฉ gli utenti non devono cambiare abitudini radicalmente, ma trovano semplicemente โ€œun aiutante in piรนโ€ nelle attivitร  di sempre.

Stesso discorso nel caso di Google e lโ€™integrazione della suite di workplace, oltre alle piattaforme dedicate di Gemini, o ancora anche Apple che sta puntando a portare lโ€™AI nel device, ma non con una app, ma integrata nellโ€™esperienza completa. Allo stesso modo, molte aziende stanno ottenendo benefici concreti dallโ€™AI dove la integrano nel processo decisionale: sistemi di raccomandazione che suggeriscono al marketing la prossima offerta da fare a un cliente (ma lasciano al manager la decisione finale), dashboard arricchite da previsioni AI che supportano i dirigenti nel pianificare produzione o scorte, chatbot interni che aiutano i dipendenti a navigare tra le policy aziendali o a reperire informazioni rapidamente.

In tutti questi casi, lโ€™AI non sostituisce la decisione umana, bensรฌ la informa e la velocizza con insight aggiuntivi. Il valore non sta nellโ€™aver โ€œmesso un modello di deep learning in produzioneโ€ per vanto tecnologico, ma nellโ€™aver risolto un problema di business, che sia ridurre i tempi di risposta al cliente, aumentare la personalizzazione di un servizio o migliorare la qualitร  delle decisioni grazie a dati che prima erano inutilizzabili.

Un concetto chiave qui รจ lโ€™economia dellโ€™innovazione: le tecnologie producono ritorni quando riescono a combinarsi con altre innovazioni e con complementi organizzativi. Lโ€™energia elettrica, per esempio, ha trasformato lโ€™industria solo dopo che le fabbriche hanno riprogettato completamente i processi produttivi attorno ad essa (decentralizzando le macchine e cambiando il layout delle linee). Analogamente, lโ€™AI darร  il meglio di sรฉ quando le imprese ristruttureranno processi e flussi di lavoro per sfruttarne le capacitร . Ciรฒ puรฒ richiedere di ripensare ruoli, ridefinire KPI e instaurare meccanismi di governance per monitorare lโ€™operato dellโ€™AI (dati utilizzati, accuratezza, imparzialitร ) cosรฌ da fidarsi dei suoi output. Sono cambiamenti manageriali e organizzativi profondi, non semplici upgrade tecnologici.

La capitalizzazione delle tecnologie GPT , ossia la capacitร  di generare valore tangibile dai vari ChatGPT, GPT-4, ecc., dipende da quanto bene le aziende sanno prodottizzarle nei propri servizi e prodotti. Ad esempio, cโ€™รจ differenza tra limitarsi a usare ChatGPT per generare qualche testo e invece incorporare un modello linguistico nel proprio servizio clienti automatizzato, integrato con la base di conoscenza aziendale e tarato sul tono di voce del brand. Il secondo approccio richiede piรน sforzo iniziale, ma crea un asset che differenzia davvero lโ€™azienda e genera efficienza continua.

In sostanza, non si tratta di provare lโ€™ultimo giocattolo AI in modo estemporaneo, bensรฌ di costruire soluzioni in cui lโ€™AI sia un componente stabile e ben congegnato. Chi riesce in questo trasforma lโ€™AI da costo sperimentale a leva di produttivitร  e vantaggio competitivo.

Perchรฉ il futuro non รจ (solo) il generative AI, ma sistemi compound e multimodali

In questo periodo lโ€™attenzione mediatica si รจ polarizzata sulla Generative AI (modelli che creano testi, immagini, ecc.). Ma se allarghiamo lโ€™orizzonte, il futuro dellโ€™AI aziendale non sarร  unicamente il prossimo modello generativo piรน potente o โ€œsenzienteโ€.

Piรน probabilmente, vedremo emergere sistemi compound e multimodali: ovvero ecosistemi di modelli piรน piccoli e specializzati che collaborano, e piattaforme AI capaci di gestire input e output molteplici (testo, visione, audio, dati strutturati) allโ€™unisono. I risultati piรน avanzati giร  oggi nellโ€™AI derivano sempre piรน da queste architetture composte anzichรฉ da un singolo modello monolitico. Molti applicativi, per esempio, usano la tecnica del RAG retrieval-augmented generation: un motore di ricerca interno recupera informazioni da fonti affidabili e un modello generativo le usa per comporre la risposta, aumentando accuratezza e freschezza dei contenuti. Oppure pensiamo agli assistenti vocali: combinano modelli di riconoscimento vocale, modelli di NLP per comprendere il testo, modelli di dialogo per rispondere e magari moduli di visione (se devono anche interpretare immagini).

Lโ€™AI del futuro somiglierร  piรน a unโ€™orchestra che a un solista: tanti micro-servizi intelligenti coordinati per un obiettivo. Questo approccio โ€œa sistemiโ€ massimizza i risultati attraverso unโ€™ingegneria ingegnosa, non solo facendo training su un unico mega-modello. In altre parole, conterร  molto come progettiamo lโ€™ecosistema aziendale, non solo quanto รจ grosso, e questo Simone Cicero con Boundaryless lo sa bene e lo predica da tempo.

Un trend giร  in atto รจ la proliferazione di modelli specializzati: invece di usare un modello generico enorme per tutto, le aziende iniziano ad adottare piรน modelli piccoli, ognuno ottimizzato per un compito o un dominio (es: un modello linguistico per analisi di sentiment nei feedback clienti, un modello diverso per generare codice, un altro per riconoscere immagini di prodotti, ecc.). Questo approccio โ€œmodulareโ€ puรฒ essere piรน efficiente: ogni modello piรน piccolo richiede meno risorse, puรฒ essere addestrato sui dati specifici dellโ€™azienda (guadagnando in pertinenza) e soprattutto puรฒ essere combinato con gli altri quando serve affrontare compiti complessi.

Immaginiamo per esempio un sistema AI per ecommerce che: analizza la foto che carica un utente (modello visivo), ne descrive il contenuto a parole (modello generativo multimodale), fa una ricerca nel catalogo prodotti per trovare oggetti simili (motore di ricerca AI), e infine dialoga col cliente per affinare la ricerca (modello conversazionale). Nessun singolo modello fa tutto da solo: รจ la combinazione orchestrata che realizza lโ€™esperienza utente desiderata. Questo รจ il potere dei sistemi compound.

La direzione รจ poi multimodale: giร  nel 2024 sono stati mostrati i primi modelli in grado di elaborare input misti (immagini + testo) e generare output in vari formati (es. la cosiddetta GPT-4 โ€œOmniโ€ di OpenAI). La strada dei modelli multimodali รจ agli inizi e procede piรน lentamente del previsto, ย richiede quantitร  di dati e risorse ancora maggiori, e porta con sรฉ sfide come il rischio di hallucination e bias su piรน dimensioni, ma promette applicazioni aziendali interessantissime. Si va da sistemi in grado di โ€œvedereโ€ e โ€œleggereโ€ (pensiamo alla qualitร  che puรฒ raggiungere un servizio di ispezione automatica che analizza sia immagini da telecamere sia report testuali, o un consulente AI che esamina insieme tabelle numeriche e grafici per dare consigli finanziari), fino a interfacce utente piรน naturali dove lโ€™AI capisce un comando vocale complesso e risponde con un grafico generato al volo e una spiegazione parlata.

Un altro fronte emergente รจ quello degli AI agent autonomi (agentic AI): piccoli software intelligenti capaci non solo di rispondere a domande, ma di intraprendere azioni in autonomia coordinandosi tra loro. In futuro, nemmeno troppo lontano, potremmo avere un agente AI specializzato nel monitorare metriche finanziarie aziendali, che โ€œdialogaโ€ con un altro agente specializzato nel gestire operazioni bancarie, per poi insieme eseguire transazioni o generare report, il tutto con supervisione minima umana.

รˆ unโ€™estensione del concetto di sistemi compound: non solo modelli multipli, ma agenti multipli che interagiscono e si passano il testimone sui compiti, un poโ€™ come fa un team di persone. Questo scenario รจ ancora sperimentale, ma aziende come Salesforce e ServiceNow giร  parlano di queste possibilitร . Il vantaggio potenziale รจ enorme: delegare routine complesse a squadre di โ€œassistenti digitaliโ€ che lavorano 24/7, liberando gli umani per attivitร  a maggior valore aggiunto. Ma anche qui, non aspettiamoci un salto immediato: servirร  tempo per fidarsi a lasciare che le macchine dialoghino tra loro e agiscano sulle nostre piattaforme, e ci vorranno nuovi paradigmi di sicurezza per evitare incidenti quando piรน agenti AI hanno accesso ai sistemi aziendali.

Il messaggio chiave che voglio passare e che di solito รจ una chat dei miei workshop, รจ che il futuro dellโ€™AI aziendale non sarร  un chatbot onnipotente che rimpiazza ogni applicazione, bensรฌ un tessuto connettivo di intelligenze diffuse.

Le imprese che vinceranno saranno quelle capaci di comporre queste intelligenze in modo strategico, scegliendo โ€œil cavallo giusto per ogni corsaโ€ invece di cercare un singolo cavallo di razza da far correre ovunque. Sarร  una rivoluzione piรน silenziosa e graduale di quanto il clamore mediatico suggerisca oggi, ma non meno dirompente sul lungo termine: semplicemente, avverrร  tramite molte piccole evoluzioni sommate, anzichรฉ con unโ€™unica epifania tecnologica.

La tecnologia da sola non basta. Serve leadership.

Se cโ€™รจ una cosa che un imprenditore esperto in innovazione e trasformazione digitale impara presto, รจ questa: la tecnologia da sola non basta. Serve leadership. E mai come nellโ€™adozione dellโ€™intelligenza artificiale questo risulta vero. I management si trovano stretti tra due fuochi: da un lato la necessitร  di non perdere il treno di una tecnologia potenzialmente rivoluzionaria, dallโ€™altro il dovere di filtrare il rumore dellโ€™hype e prendere decisioni ponderate. La leadership paziente non significa immobilismo o scetticismo cronico verso lโ€™AI, bensรฌ la capacitร  di dosare entusiasmo e pragmatismo:

  • vuol dire saper articolare ai propri stakeholder una visione di lungo periodo in cui lโ€™AI permea lโ€™azienda, ma allo stesso tempo evitare di promettere miracoli nel prossimo trimestre (come si sente invece spesso)
  • vuol dire investire in competenze, infrastrutture e dati fin da ora, sapendo che i frutti veri matureranno magari fra qualche anno. E va bene cosรฌ, perchรฉ chi inizierร  per tempo a costruire fondamenta solide sarร  in netto vantaggio quando lโ€™AI raggiungerร  la piena maturitร .

Una leadership strategica nellโ€™era dellโ€™AI implica anche fare scelte coraggiose e spesso controintuitive. Resistere alla tentazione di lanciarsi su ogni moda effimera di AI generativa, e invece concentrarsi su pochi progetti chiave allineati alla strategia aziendale, anche se questo significa andare contro la pressione (FOMO) di mostrare subito qualcosa di โ€œsexyโ€ al mercato:

  • significa allocare risorse per ripulire e strutturare i dati di cui disponiamo, anche se questo lavoro oscuro non farร  notizia, perchรฉ senza dati di qualitร , lโ€™AI รจ un castello di carte
  • significa sperimentare con pilota e prototipi veloci ben disegnati (usando criteri di successo chiari) e poi scalare gradualmente ciรฒ che funziona, anzichรฉ puntare tutto su un grande progetto monolitico calato dallโ€™alto. In altre parole, pensiero big picture ma approccio graduale.

Dal punto di vista del change management, lโ€™azienda dovrร  costruire team di evangelisti e formatori allo stesso tempo: comunicare una visione ispiratrice (far capire al team perchรฉ lโ€™AI รจ importante e come migliorerร  il lavoro di tutti), ma anche mettere a disposizione formazione, linee guida e supporto pratico perchรฉ le persone sviluppino fiducia verso questi nuovi strumenti. E la fiducia, come invece succede in molte realtร , non si impone: si guadagna col coinvolgimento e dimostrando concretamente che lโ€™AI puรฒ rendere il lavoro piรน interessante, non sostituire cinicamente le persone.

Una metafora utile รจ quella dellโ€™AI comeesoscheletro per la forza lavoro: il compito dei team di formazione ed evangelizzazione รจ far sรฌ che ogni persona abbia lโ€™โ€œesoscheletroโ€ giusto (gli strumenti AI adatti) e sappia come usarlo per moltiplicare le proprie capacitร , anzichรฉ temere di essere rimpiazzata dalla macchina.

Guidare unโ€™azienda nellโ€™adozione dellโ€™intelligenza artificiale richiede visione, pazienza e concretezza, ecco perchรฉ il concetto โ€œPatience is Promptโ€. Visione per immaginare nuovi modi di operare abilitati dallโ€™AI e sfidare lo status quo. Pazienza per navigare la fase iniziale di entusiasmo e disillusione senza perdere la rotta, consapevoli che le vere trasformazioni richiedono anni, non mesi. Concretezza per focalizzarsi sul valore di business reale, integrando lโ€™AI dove aggiunge valore e misurandone lโ€™impatto con rigore.

Bisognerร  avere umiltร  in questo viaggio e sarร  fondamentale ammettere ciรฒ che non funziona, apprendere dagli errori e adattare la strategia man mano che si impara cosa davvero genera risultati (in un campo cosรฌ nuovo, nessuno ha tutte le risposte in tasca).

La buona notizia รจ che chi saprร  attuare questa guida strategica e paziente avrร  costruito un vantaggio difficilmente colmabile dai concorrenti. Per citare un concetto espresso in un rapporto Deloitte, che ho trovato condivisibile, applicare lโ€™AI solo per velocizzare vecchi modi di fare le cose significa sprecare il suo potenziale o, peggio, amplificarne i bias.

Le aziende con management piรน illuminato e coraggioso useranno invece lโ€™AI come catalizzatore per inventare โ€œnext practicesโ€ e modelli organizzativi pensati per un mondo potenziato dallโ€™AI. Saranno quelli che non si limiteranno a digitalizzare lโ€™esistente, ma che reimmagineranno il proprio business con lโ€™AI in mente, mantenendo perรฒ i piedi per terra sullโ€™esecuzione. La rivoluzione dellโ€™AI, in fondo, non avverrร  in una notte di tempesta, ma sarร  il risultato della somma di tanti sforzi mirati. E sarร  guidata non dagli algoritmi in sรฉ, ma da leader che avranno saputo traghettare le proprie organizzazioni, con lungimiranza e tenacia, attraverso le acque agitate del cambiamento tecnologico verso un nuovo approdo di valore.

Cosa portarsi a casa? Un messaggio semplice.

Non aspettatevi miracoli immediati dallโ€™AI, ma non sottovalutate nemmeno per un istante la portata trasformativa che avrร  sul lungo periodo. Agite con strategia, investite nelle fondamenta (dati, processi, persone) e preparatevi a navigare qualche scossone iniziale.

L’adozione dell’AI รจ un viaggio, non uno scatto: iniziate ora, con passo deciso ma misurato, perchรฉ chi saprร  pazientemente accelerare al momento giusto farร  la differenza nel prossimo decennio dellโ€™economia digitale. La vera rivoluzione non sarร  delle macchine pensanti, sarร  di chi avrร  imparato a pensare (e agire) meglio con le macchine.