Il problema non è più fare un progetto di AI. È farlo diventare parte della vostra azienda.

Per un po’ abbiamo avuto un problema abbastanza semplice: capire se l’intelligenza artificiale potesse produrre valore nelle aziende. Oggi quella domanda comincia a essere meno interessante.

BearingPoint, una società di consulenza, ha appena diffuso una ricerca condotta ad agosto su 1.050 dirigenti di organizzazioni pubbliche e private in Europa, negli Stati Uniti e in Cina. Il 74% delle organizzazioni che usano già l’AI nel proprio lavoro dichiara di vederne effetti misurabili sui costi o sui ricavi. Eppure soltanto il 13% dice di aver esteso i propri progetti del tutto secondo il piano con cui erano stati approvati. Non vuol dire che gli altri abbiano fallito: una sperimentazione serve proprio a cambiare idea.

Ma c’è un dettaglio più interessante. Il primo ostacolo indicato, secondo il comunicato, è la complessità delle regole. Subito dopo viene l’integrazione con i sistemi e i processi che le aziende usano da tempo, e più di metà dei dirigenti considera decisivo poter contare su dati affidabili. Il modello, insomma, spesso ha già dimostrato di saper fare il lavoro. Quello che si inceppa viene dopo.

Numeri da leggere con cautela

Questi numeri vanno letti con cautela. BearingPoint vende proprio il genere di lavoro di cui la ricerca parla, e un sondaggio fra dirigenti non è una statistica ufficiale né descrive per forza le imprese italiane. L’Italia nel campione c’è, ma compare soltanto nell’infografica, dentro una voce «altra Europa» insieme ad Austria, Irlanda, Paesi Bassi e Svizzera, e non ha mai un numero suo. Anche il 74% va letto fino in fondo. È calcolato sulle 685 organizzazioni che hanno già qualcosa in esercizio, e la pagina della ricerca aggiunge che per quasi metà l’effetto resta sotto il 4% dei costi e sotto il 2% dei ricavi.

Per l’Italia una statistica ufficiale esiste, e dà numeri molto più bassi. Secondo l’ISTAT, nel 2025 usava almeno una tecnologia di intelligenza artificiale il 16,4% delle imprese con almeno dieci addetti: il 53,1% delle grandi e il 15,7% delle piccole e medie. Fra quelle che la usano, una su tre non indica alcuna finalità aziendale, ed erano il 15,5% un anno prima. L’istituto parla di un’adozione «sempre più diffusa ma ancora poco strutturata».

La stessa cautela vale per le percentuali che da due anni girano su quanti progetti di AI falliscano. Il 95% attribuito al MIT viene da un rapporto che dichiara le proprie cifre «directionally accurate», cioè indicative, perché fondate su interviste e non su dati ufficiali delle aziende. L’«oltre l’80%» che si cita come dato RAND è una stima che RAND riprende da un articolo di Fortune del 2022: le sue 65 interviste riguardavano le cause dei fallimenti e non la loro frequenza. Il 30% di Gartner era una previsione sul 2025, fatta nel 2024. Sono misure di cose diverse, e messe in fila dicono soprattutto che alla domanda «quanti falliscono» non c’è una risposta sola. Capita anche nel giro di poche ore: il lancio in inglese di Reuters sulla ricerca BearingPoint scrive che meno di un terzo delle aziende è riuscito ad andare oltre i progetti pilota. Nel comunicato questo dato non c’è, e la ripartizione che BearingPoint pubblica dice che il 65% delle organizzazioni ha già qualcosa in esercizio.

C’è anche chi fa notare che la fatica di portare una tecnologia nuova dentro un’organizzazione complessa è vecchia quanto l’informatica aziendale: l’abbiamo vista con i gestionali e con il passaggio al cloud. Molte aziende sono ancora nella fase in cui si esplora, ed è sano che un progetto cambi strada quando scopre che alcune ipotesi di partenza erano sbagliate. La ricerca stessa dice che quasi tre quarti hanno ritoccato il perimetro iniziale o si sono estesi meno del previsto, che è un’altra cosa rispetto a fallire. Lo penso anch’io, e per questo non costruisco il ragionamento sull’idea che il 13% sia poco. Mi interessa capire dove stanno, sempre più spesso, i problemi che emergono dopo la dimostrazione. Secondo me stanno nell’ambiente in cui vogliamo far lavorare il modello.

«Bene, adesso usiamolo tutti»

Chi in un’azienda o in un ente pubblico ha approvato una prova riuscita conosce il giorno in cui qualcuno, soddisfatto, dice: «Bene, adesso usiamolo tutti». Da quel momento la domanda cambia. Finché era una prova, bastava che il sistema funzionasse su cinquanta documenti scelti con cura, con chi lo aveva costruito seduto lì accanto. Adesso deve funzionare sui documenti veri, rispettare le regole su chi può vedere che cosa, reggere le eccezioni e restare comprensibile a persone che al progetto non hanno partecipato.

Ogni passaggio risponde a una domanda diversa. La dimostrazione serve a capire se il sistema sa fare una cosa. Con la sperimentazione si verifica se sa farla su una parte del nostro lavoro, con dati e utenti veri. Poi bisogna capire se sappiamo farlo funzionare sempre allo stesso modo, con costi e accessi sotto controllo. L’ultima domanda è di un’altra natura: possiamo permetterci di dipenderne? Quando un’attività entra nel lavoro di tutti i giorni non basta che il sistema funzioni in media. Bisogna sapere chi ne risponde, come ci si accorge che qualcosa sta andando storto, che cosa succede se il modello smette di rispondere, quale versione ha prodotto un certo risultato e come si torna indietro. Quello che si vede nella dimostrazione è soltanto l’inizio del lavoro.

La prova riesce perché qualcuno la protegge

Una sperimentazione può riuscire proprio perché toglie di mezzo, per qualche settimana, quasi tutto ciò che rende difficile l’uso quotidiano. Si usano dati puliti, si scelgono utenti convinti, si restringe il perimetro e le eccezioni si conoscono in anticipo. Il gruppo tecnico osserva ogni passaggio, e quando succede qualcosa di strano qualcuno lo sistema a mano prima che diventi un problema.

Sono condizioni utilissime per capire se una capacità esiste, e sono l’opposto di quello che succederà dopo. I dati saranno quelli che sono, gli utenti non avranno partecipato a niente, il gruppo tecnico lavorerà su altro e il sistema dovrà spiegarsi da solo nella settimana in cui chi l’ha costruito è in ferie. In un certo senso la prova riesce perché l’organizzazione la protegge, e l’uso quotidiano le toglie proprio quella protezione.

Scrivere l’offerta era la parte facile

Immagino un’azienda di medie dimensioni che vende servizi ad altre imprese e vuole un assistente che aiuti i commerciali a preparare le offerte. Nella sperimentazione l’assistente riceve il listino, dieci offerte già inviate, le schede dei servizi e un modello di documento. In pochi minuti produce una bozza sorprendentemente buona, e si decide di darlo a tutto l’ufficio commerciale.

A quel punto si scopre che il listino ufficiale non coincide sempre con quello usato davvero. Alcuni clienti hanno condizioni particolari, concordate in uno scambio di email e mai riportate altrove. Certe schede esistono in tre versioni, e solo una è aggiornata. Un servizio non si può vendere in certe combinazioni, e lo sa soltanto chi è in azienda da molto. Alcune offerte richiedono l’approvazione di chi poi dovrà eseguire il lavoro o del direttore finanziario, altre possono partire subito.

La prova aveva dimostrato che l’assistente sapeva scrivere un’offerta. Il passaggio a tutto l’ufficio mostra che scrivere l’offerta era la parte facile, e che un sistema che lavora davvero deve conoscere l’organizzazione. In un’azienda sanitaria o in un ufficio comunale l’elenco avrebbe altre voci, e sarebbe lungo almeno altrettanto.

Quello che le persone compensavano

Credo che l’AI stia facendo emergere problemi che c’erano già: dati incoerenti, conoscenza sparsa fra le persone e le loro caselle di posta, permessi accumulati nel tempo, procedure mai scritte da nessuna parte. Finché dentro questi processi lavoravano soltanto persone, le persone compensavano di continuo. Chiedevano a un collega, ricordavano come si era fatto l’ultima volta. Sapevano quale valore copiare a mano da un sistema all’altro, e quale campo ignorare.

Chi lavora su un gestionale con dieci anni di storia sa che può contenere tre campi chiamati più o meno «stato del cliente», e che uno solo dice la verità. Un assistente legge benissimo l’italiano e non ha alcun modo di sapere quale dei tre guardare. Il difetto sta in come abbiamo organizzato le informazioni negli anni, e il modello si limita a renderlo visibile tutto in una volta. Per questo penso che i progetti di AI stiano mettendo alla prova soprattutto una cosa che nessun modello controlla: quanto un’azienda sia leggibile per chi non ci lavora da anni.

Una fatica più vecchia del software

Qualcuno dirà che sto dando un nome nuovo alla vecchia trasformazione digitale. In buona parte è vero, ed è la cosa più utile da riconoscere. Per qualche anno abbiamo trattato l’AI nelle aziende come un mondo a parte, con il suo lessico e i suoi specialisti. Quando un sistema entra davvero nel lavoro quotidiano, però, ritrova gli stessi problemi che il software affronta da decenni: dati, accessi, integrazioni, responsabilità.

La storia, in realtà, è più vecchia del software. Nel 1990 lo storico dell’economia Paul David, per capire perché i computer non si vedessero ancora nelle statistiche sulla produttività, andò a guardare che cosa era successo con il motore elettrico. Nel 1899, quasi vent’anni dopo le prime centrali, i motori elettrici fornivano meno del 5% della forza motrice delle fabbriche americane. Per arrivare a metà servirono altri vent’anni, e l’effetto sulla produttività si vide soltanto negli anni Venti. Il motore funzionava dal primo giorno. Le fabbriche, però, erano costruite per la forza dell’acqua e del vapore, con gli alberi di trasmissione appesi al soffitto e le cinghie che scendevano a muovere le macchine, e finché quegli stabilimenti reggevano a nessuno conveniva rifarli. Il guadagno arrivò quando si cominciò a dare a ogni macchina il suo motore e a disegnare l’edificio di conseguenza.

Con i gestionali è andata in modo simile. In uno studio del 2002 Erik Brynjolfsson, Lorin Hitt e Shinkyu Yang riportano che in un’installazione tipica di SAP R/3, sui venti milioni di dollari, hardware e software pesavano meno di un quinto. Il resto se ne andava per definire i requisiti, adattare il programma, ridisegnare i processi e formare le persone.

La differenza, stavolta, è che il componente nuovo non risponde sempre allo stesso modo alla stessa domanda, e tendiamo a dargli sempre più autonomia. Questo rende quei problemi più delicati e meno facili da rimandare. La parte nuova, quindi, funziona soltanto se quella vecchia del mestiere è fatta bene.

Le regole fanno le stesse domande, per iscritto

Anche per questo non mi stupisce che il primo ostacolo citato dalla ricerca sia la complessità delle regole. In sanità o in un ente pubblico le norme pongono per iscritto, e in anticipo, le domande che il lavoro quotidiano porrebbe comunque, a partire da chi risponde di una decisione e da come la si ricostruisce.

L’AI Act lo fa quasi alla lettera. A chi usa un sistema ad alto rischio l’articolo 26 chiede di affidare la sorveglianza umana a persone «che dispongono della competenza, della formazione e dell’autorità necessarie», e di conservare per almeno sei mesi i log che il sistema genera. Il Digital Omnibus ha rinviato questi obblighi a dicembre 2027, e ho già scritto perché il rinvio cambia poco per chi il sistema lo sta costruendo adesso: un registro che non esiste dal primo giorno non si ricostruisce dopo.

Nella ricerca c’è un dato che va nella stessa direzione, da prendere con la cautela di prima. Nel settore pubblico e sanitario quasi metà delle organizzazioni sta ancora esplorando o sperimentando. Fra banche e assicurazioni, che di regole ne hanno almeno altrettante, è il 22%, ed è il settore più avanti di tutto il campione. Non so quanto contino le dimensioni e i bilanci di chi ha risposto. Però, se a frenare fossero le regole in sé, mi aspetterei di trovare banche e assicurazioni in fondo.

Per chi costruisce il sistema le regole sono un vincolo di progetto, e conviene trattarle così dal primo giorno.

Che cosa è diventato difficile da trovare

Questo cambia anche ciò che sul mercato è difficile da trovare. All’inizio contava chi sapeva mostrare che cosa l’AI poteva fare per un’azienda. Mi sembra un vantaggio che si sta consumando in fretta: i modelli migliorano e costano meno, e una dimostrazione convincente si costruisce in pochi giorni. Resta difficile trovare chi sa capire un processo e ridisegnarlo, collegare sistemi che non sono nati per parlarsi, decidere chi può vedere che cosa e accompagnare le persone che dovranno usare il risultato. Sono le discipline di sempre del software fatto con cura, che adesso devono fare spazio a un componente meno prevedibile degli altri.

La stessa ricerca osserva che meno di un terzo delle organizzazioni, prima di avviare un progetto di AI, valuta in modo formale se potrà essere esteso. Così le questioni di architettura, dati, responsabilità e organizzazione del lavoro arrivano spesso quando il progetto ha già dimostrato di funzionare. È il momento peggiore per scoprirle, perché a quel punto tutti si aspettano soltanto di accendere l’interruttore.

L’interesse che ho in questa storia

È anche il motivo per cui i progetti che considero più interessanti cominciano spesso quando la dimostrazione è già riuscita. A quel punto la domanda sul modello ha una risposta. Resta da capire quali sistemi deve attraversare, quali dati può usare, quali eccezioni deve gestire e che cosa deve succedere perché l’azienda possa permettersi di dipenderne.

Su questo ho un interesse diretto. Lavoro in un’azienda di software che vive proprio del tratto di strada fra una prova riuscita e un sistema su cui un’impresa o un ente possono contare. Una ricerca che descrive quel tratto come il più difficile fa comodo a me quanto a chi l’ha pubblicata. Il criterio, quindi, va applicato prima a noi.

Da noi gran parte del codice la scrive già una macchina, a partire da una specifica che scriviamo noi, e la revisione resta a una persona. Se il nostro mestiere fosse soltanto scrivere codice, saremmo fra i primi a vederlo perdere valore. Il resto del mestiere, quello che ho descritto finora, va dimostrato progetto per progetto, e chi lavora con noi ha il diritto di chiederci come lo facciamo.

Non tutte le prove devono diventare un sistema

C’è poi una conseguenza meno comoda per chi vive di integrazione. Non tutte le sperimentazioni meritano di diventare un sistema aziendale. Un assistente usato da tre persone, che fa risparmiare ore senza toccare nient’altro, può restare com’è, ed è una scelta ragionevole. Altre volte rendere affidabile una prova costa più di quanto restituirà, e scoprirlo presto è un buon risultato: molto meglio che passare tre anni a difendere una dimostrazione riuscita. Chi guadagna integrando ha ogni interesse a rispondere che conviene sempre integrare.

Il metro a cui chiedo di misurarci è questo: dire prima di firmare quanto costerà rendere affidabile una prova riuscita, e dirlo anche quando la risposta giusta è lasciarla com’è.

A chi decide lascio una domanda. Qual è il vostro progetto di AI che in prova funziona già, ma che non affidereste ancora a cento utenti veri senza tenere accanto la persona che lo ha costruito?

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →