Un ingegnere gestionale che ha passato vent'anni dentro le organizzazioni a guardare come si organizza il lavoro, e che poi si è messo a costruire software per i problemi che quel lavoro continuava a generargli.
Mi sono laureato in Ingegneria Gestionale a Padova nel 2004. Per i nove anni successivi ho lavorato nell'azienda di mio padre, cinquecento persone, dove mi occupavo di ottimizzazione dei processi interni: capire dove il lavoro si inceppava, perché due reparti si passavano la stessa informazione tre volte, quanto costava davvero una procedura che sulla carta sembrava impeccabile. È stata la mia formazione vera. Quel rapporto non si è mai interrotto: ancora oggi seguo il controllo dei processi principali di quell'azienda — quando parlo di organizzazioni complesse non attingo a un ricordo di vent'anni fa, ma a una realtà da cinquecento persone che continuo a guardare da dentro mentre cambia.
Poi ho reinterpretato a modo mio il mestiere di famiglia, quello immobiliare: prima una società di costruzioni, poi quello che oggi è un gruppo di cinque società specializzate, che gestiscono centinaia di immobili nel Nord Italia sotto marchi distinti per pubblici distinti. Negli stessi anni ho affiancato consulenze in aziende di settori spesso lontani dal mio — ed è stata quella la scuola migliore, perché entrare in un'organizzazione che non è la tua costringe a capire come funziona davvero invece di darlo per scontato.
Gestire centinaia di unità immobiliari, con contratti diversi, scadenze diverse, inquilini diversi, non è un problema immobiliare: è un problema di organizzazione a scala, e a un certo punto smette di essere risolvibile a colpi di fogli Excel e telefonate. L'ho scoperto sulla mia pelle molto prima che l'intelligenza artificiale generativa diventasse un argomento da bar.
Da quando ho aperto la prima società ho sempre affiancato al lavoro immobiliare un secondo lavoro, meno visibile: costruire strumenti software per risolvere i problemi che il primo continuava a generarmi. Piccoli automatismi, prima. Poi sistemi più strutturati. Poi, quando la tecnologia lo ha reso possibile, sistemi che non eseguono soltanto, ma che imparano. Quel binario a un certo punto è diventato una cosa a sé — ed è da lì che nascono i tre strumenti di questa pagina.
Metto in fila questi passaggi non per elencare un curriculum, ma perché spiegano da dove arriva il modo di ragionare che trovi in queste pagine. Un ingegnere gestionale che ha passato vent'anni a guardare come si organizza il lavoro, e che poi si è messo a costruire software, tende a vedere l'intelligenza artificiale in modo diverso da chi ci arriva dall'informatica pura: non come una tecnologia da applicare, ma come un pezzo di un'organizzazione che o si incastra con tutto il resto, o non serve a niente.
Tutto quello che ho costruito nasce da un divario in cui mi sono scontrato ripetutamente: quello tra ciò che l'intelligenza artificiale generalista promette in una demo e ciò che un'azienda vera — con la sua storia, i suoi vincoli e i suoi criteri non scritti — riesce davvero a delegarle. Non è un divario che si chiude con un prompt più lungo né con un agente più sofisticato. Quello che ho imparato attraversandolo, spesso a mie spese e con più di un errore lungo la strada, sta per intero nel libro.
Sul nome. IdemMind non nasce dall'idea di un'identità nuova generata da un algoritmo, ma dalla mente di chi lo usa, resa continuativa e consultabile: idem, lo stesso — non un'imitazione.
Prompt, agenti, gemelli virtuali: come si costruisce un'intelligenza artificiale che decide con i criteri di chi guida l'azienda, attraverso il Metodo M.I.T.O.S.
È il quinto libro che pubblico, e il primo su questo tema: gli altri quattro nascevano da un mestiere diverso, e alcuni sono arrivati in cima alle classifiche di categoria su Amazon. Qui dentro c'è per intero quello che ho imparato attraversando il divario fra ciò che l'AI promette in una demo e ciò che un'azienda vera riesce davvero a delegarle — errori compresi.
Prima chi c'è dietro, e da quali problemi è passato. Poi i tre strumenti che ne sono usciti — IdemMind è uno dei tre — e il metodo che li tiene insieme, compreso il caso in cui la risposta giusta è non comprare nulla.
Un'azienda si comporta come un organismo: ha uno scheletro che la tiene in piedi, un sistema nervoso che decide, e un sistema immunitario che la protegge. Sono tre problemi diversi, e la ragione più comune per cui un progetto di intelligenza artificiale non produce quello che prometteva è averli confusi — aver chiesto al software sbagliato di risolvere il problema di un altro. Per questo gli strumenti sono tre, e li diciamo tutti e tre anche quando ne vendiamo uno solo.
Mappa chi fa cosa, tiene aggiornata la documentazione che descrive come l'azienda funziona davvero, verifica che ogni attività abbia più di una persona in grado di svolgerla, forma chi entra e controlla chi c'è già. È ciò che un'azienda sa eseguire senza doverci pensare ogni volta.
Osserva come decidi nei casi che nessuna procedura ha previsto, accumula quel modo di decidere giorno dopo giorno, e a un certo punto comincia a poterlo applicare al posto tuo su casi che somigliano a quelli già visti. È ciò che si attiva quando la struttura non basta più.
Quali strumenti di intelligenza artificiale l'azienda sta davvero usando, con quali dati, e cosa serve fare — spesso molto meno di quanto venga raccontato in giro. Non aggiunge capacità: protegge quelle che ci sono, in proporzione al rischio reale.
Chi fa cosa, con quali strumenti, dentro quale processo, e soprattutto dove la mappa smette di descrivere come si lavora davvero. È il meno interessante dei cinque e nessuno lo finanzia volentieri, ma viene prima per una ragione sola: un'intelligenza artificiale addestrata su un'organizzazione confusa eredita la confusione invece di ridurla. Non la segnala e non la corregge — la esegue più in fretta.
ExoCoTre righe al giorno, ogni volta che qualcuno decide a istinto senza consultare una procedura: cosa ha deciso, e cosa lo ha fatto propendere in quella direzione. La parola che porta il peso è «continua»: un'intervista una tantum produce la versione che una persona crede di seguire, quasi sempre diversa da quella che segue davvero.
IdemMindMesi, non settimane, perché il sistema impari cosa concludere e non soltanto come suonare: lo stile si copia in fretta, il giudizio richiede continuità. Si chiama trasferire e non addestrare perché quello che passa non è una competenza tecnica — è un modo di decidere che fino a ieri si trasmetteva soltanto stando accanto a chi lo possedeva. È l'unico passaggio su cui la potenza non offre scorciatoie.
IdemMindQuali strumenti l'azienda sta davvero usando, con quali dati, e se la fiducia che dichiarano corrisponde a quanto sono affidabili davvero. Arriva qui e non prima perché ha senso proteggere qualcosa che esiste già. Con un'eccezione che ribalta l'ordine: se in azienda circolano già strumenti che nessuno ha valutato, questo passaggio diventa il primo e non il quarto.
VerifAIActIl criterio non resta fermo, e un sistema addestrato sul passato deve saper distinguere un cambiamento da un errore — altrimenti tratterà come sbaglio ogni tuo ripensamento, o come nuova regola ogni tua distrazione. È il passaggio che quasi nessuno fa, perché il rischio che copre non ha sintomi: un sistema che ha ragione per mesi ottiene qualcosa di più pericoloso di un errore — ottiene che si smetta di controllarlo.
IdemMindIl ragionamento per intero — i cinque strati di profondità di un sistema di IA, le quattro diagnosi da cui partire, e le cinque domande da fare a qualunque fornitore, compresi noi — sta nel libro, che si legge senza comprare nulla. Vai alla guida → Se invece volete capire che cosa cambierebbe nella vostra azienda, la strada più diretta è parlarne: quarantacinque minuti, gratuiti, per capire la situazione prima di proporre qualunque cosa — compresa la possibilità che per la vostra azienda non serva ancora nulla di tutto questo.