Tag: enterprise AI

AI & GENAI, TECH & BUSINESS

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.

AI & GENAI, TECH & BUSINESS

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

Cosa significa “agente autonomo” davvero

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

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

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

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

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

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

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

Come si scrive un brief per un agente autonomo

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

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

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

Piani, crediti, costi: il modello economico

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

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

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

I limiti veri delle prime sessioni

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

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

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

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

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

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

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

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

Wide Research, la funzione dove Manus stacca gli altri

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Adozione enterprise: governance, sicurezza, costi, proprietà

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

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

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

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

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

La griglia decisionale: quando Manus AI è la scelta giusta

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

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

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

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

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

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

Leggi anche: ecosistema di AI privata

AI & GENAI, TECH & BUSINESS

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.

AI & GENAI, TECH & BUSINESS

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

Schema del MCP tunnel di Anthropic: esecuzione dentro la sandbox, regia esterna
AI & GENAI

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.

AI & GENAI

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.