Perché la transizione all’intelligenza artificiale, per il software italiano, è un problema cognitivo prima che di organico
C’è un equivoco diffuso, in queste settimane, nei consigli di amministrazione italiani che si interrogano sul proprio rapporto con l’intelligenza artificiale. L’equivoco consiste nel credere che la questione sia, in fondo, un problema di competenze da trovare sul mercato. Mancano persone che sappiano usare i modelli linguistici, si dice. Bisogna assumerle, o formare i team interni, mandarli a corsi. Una volta colmato il debito formativo, il software che già esiste (quello costruito negli ultimi vent’anni, su cui poggiano la contabilità, la logistica, le operations) potrà essere “esteso” con qualche funzione di intelligenza artificiale. Una ristrutturazione edilizia, in sostanza: stesso edificio, impianti aggiornati.
È una lettura comprensibile, e in Italia ha pure una giustificazione statistica. Secondo l’Osservatorio sulle Competenze Digitali 2025, curato da AICA, Anitec-Assinform e Assintel con Talents Venture, nel Paese mancano circa duecentotrentaseimila professionisti ICT per stare al passo con la media europea, e per ogni due posizioni aperte si presenta un solo candidato. Con numeri del genere è naturale leggere il problema come scarsità di offerta: troppe poche persone, troppe poche competenze. La soluzione sembra ovvia. Trovare le competenze che mancano.
Il guaio è che questa diagnosi, per quanto fondata sui numeri occupazionali, manca il bersaglio. La difficoltà più seria che incontrano oggi le software house italiane non è quantitativa. È qualitativa, e in buona misura cognitiva. Riguarda i professionisti migliori, non i mediocri. Riguarda i senior, non i principianti. E nasce dal fatto che il mestiere ha cambiato statuto, non soltanto strumenti.
Il deterministico come seconda natura
Chi ha imparato a programmare in Italia negli anni Novanta o Duemila (ed è in larga parte questa la generazione che oggi guida i team tecnici delle nostre software house) ha interiorizzato, prima ancora di un linguaggio, una grammatica del mondo. In quella grammatica, dato un input, esiste un output. Esiste un output. Se il programma ne produce due diversi nelle stesse condizioni, c’è un bug. Il debugging è la disciplina, paziente e a tratti ascetica, di ridurre il sistema fino a far tornare quella corrispondenza univoca. L’eleganza di un’architettura si misura da quanto è prevedibile, la robustezza da quanto sa fallire in modo riconoscibile.
Vent’anni di questa pratica non producono solo competenza. Producono una forma mentis. Una disposizione sedimentata in profondità: leggere il mondo computazionale come un territorio che, almeno in linea di principio, può essere mappato senza residui. Il software, visto così, è un linguaggio in cui ogni ambiguità è un difetto da sanare.
Dentro questi sistemi si introduce ora qualcosa di radicalmente diverso. Un Large Language Model è una macchina probabilistica. A parità di input (lo stesso identico input, perfino con la temperatura a zero) può restituire risposte equivalenti nel senso ma diverse nella forma, e a volte può sbagliare pur essendo addestrato bene. La sua correttezza si misura in distribuzioni, non nel singolo caso. Qui il debugging tradizionale non ha presa: non c’è uno stato da ricostruire, c’è una superficie statistica da governare. Luciano Floridi, filosofo dell’informazione che ha insegnato a Oxford e oggi dirige il Digital Ethics Center di Yale, descrive da anni questo passaggio come una mutazione dell’infosfera. E non è un’osservazione astratta. Mettere un componente probabilistico dentro un’architettura pensata per essere deterministica non è allargare una casa. È un innesto fra specie diverse, e come ogni innesto obbliga a rileggere che cosa sia diventato, nel complesso, il sistema che lo ospita.
Dove la frizione si manifesta davvero
Questa differenza non resta sulla lavagna. Si addensa in tre punti precisi, ed è lì che i progetti italiani tendono a impantanarsi.
Il primo punto è ciò che entra e ciò che esce dal modello. Nel vecchio paradigma un errore è un’eccezione, un evento discreto che il codice intercetta e gestisce. Quando invece la risposta del modello non rispetta lo schema atteso (e succede, anche imponendo formati rigidi) non si ha un’eccezione ma una fluttuazione. La distinzione non è da pedanti: un’eccezione la catturi, una fluttuazione la tolleri. Vuol dire validare l’output sul piano del significato, frapporre un livello di astrazione fra il modello e il codice, prevedere ripieghi che non hanno la forma “se errore, allora X” ma “se la risposta non regge il criterio, riformula”. Lo stesso vale per ciò che entra. La tecnica oggi più seria per ancorare un modello a un dominio specifico, la Retrieval-Augmented Generation, non vive sui database relazionali su cui sono nati i gestionali italiani. Vive su spazi vettoriali, con scelte delicate su come spezzare i documenti e una sincronizzazione continua fra l’archivio e l’indice semantico. Aggiungere una colonna “vettoriale” a una tabella che già esiste non chiude la questione, la sposta di un metro. Un team che non ha mai costruito una pipeline di machine learning finisce per passare al modello contesti fuori fuoco, e il modello, ligio, allucina su quei contesti.
Il secondo punto è il tempo, e con il tempo la sicurezza. La singola risposta sta lasciando il campo ai flussi agentici, dove il modello non si limita a rispondere ma agisce: pianifica, chiama strumenti, guarda cosa succede, riprova. Il pattern di riferimento, ReAct, è stato formalizzato da Shunyu Yao e colleghi a Princeton in un articolo del 2022 ormai classico. Un’architettura monolitica e sincrona, fatta per servire pagine in millisecondi, non sopporta l’idea di un processo fermo trenta secondi in attesa che un agente chiuda un ciclo di otto chiamate. Non è un problema di prestazioni ma di topologia, e impone un altro disegno: eventi invece di sequenze, servizi asincroni, lo stato della sessione tenuto separato dal motore che esegue. A tutto questo si aggiunge un fronte di rischio che prima non c’era. L’interfaccia tradizionale ha input vincolati e una superficie d’attacco ampia ma conosciuta. Un’interfaccia in linguaggio naturale ha, per definizione, input illimitato. La prompt injection è una vulnerabilità senza precedenti nel vecchio mondo. Simon Willison, sviluppatore britannico tra i co-creatori del framework Django e autore di uno dei blog tecnici più letti del settore, ne ha coniato il nome nel settembre 2022, mostrando come i controlli di accesso costruiti a livello applicativo saltino nel momento in cui è il modello a decidere cosa eseguire.
Il terzo punto è il ciclo di vita. Il consueto processo di rilascio continuo dà per scontato che a cambiare sia il codice, mentre l’ambiente sotto resta fermo. Con i modelli linguistici è il contrario. Il codice si tocca di rado, ma il modello evolve di continuo: i fornitori pubblicano versioni nuove, ritirano le vecchie, cambiano i valori di default. C’è un fenomeno, il model drift, che nel software tradizionale non ha gemelli. La stessa applicazione, stessa versione, stesso codice, può comportarsi in modo diverso a sei mesi di distanza, solo perché è cambiato ciò che le sta sotto. Sorvegliarlo con i normali strumenti di monitoraggio delle prestazioni significa avere una telemetria cieca proprio dove serve vedere. Servono pratiche dedicate, che fino a tre anni fa non esistevano come disciplina.
Il punto vero, e perché è cognitivo
Si dirà che è tutta materia tecnica, e che un buon ingegnere con vent’anni di mestiere, messo nelle condizioni di studiarla, la impara. È vero solo a metà, ed è qui che conviene parlare chiaro.
Quello che si vede nei team senior non è un vuoto di nozioni. È un’intuizione di fondo che alle nozioni resiste. Si riconosce da segnali piccoli e insistenti. La tendenza a trattare il modello come una qualsiasi API, da interrogare aspettandosi sempre la stessa risposta. La fatica a progettare verifiche che guardino alle distribuzioni invece che al singolo caso. Il sospetto, mai dichiarato ma sempre all’opera, che un sistema il quale “non funziona sempre” sia un sistema rotto da riparare, e non un sistema fatto bene il cui esito va letto in termini di probabilità. Questa intuizione (chiamiamola la grammatica deterministica) è ciò che vent’anni di mestiere serio scrivono nella testa di un ingegnere. Non è un difetto. È la stessa qualità che ha permesso a quegli ingegneri di costruire i sistemi affidabili su cui il Paese gira tutti i giorni. Ma è un attrezzo tagliato su un mestiere preciso, e quando il mestiere cambia statuto l’attrezzo non si riaffila da solo.
Su questo c’è un dato che meriterebbe una cornice, appeso al muro delle direzioni tecniche. Uno studio del MIT, condotto dall’iniziativa NANDA del Media Lab e intitolato The GenAI Divide: State of AI in Business 2025, ha esaminato oltre trecento implementazioni aziendali di intelligenza artificiale generativa. A fronte di trenta-quaranta miliardi di dollari investiti, circa il novantacinque per cento dei progetti non porta alcun ritorno misurabile. Ma il cuore della cosa è la spiegazione. Secondo gli autori la colpa non è dei modelli, che funzionano. È del “learning gap”: l’incapacità delle aziende di far entrare quei modelli nei propri processi e nella propria cultura. Gli strumenti, scrive il rapporto, brillano nelle dimostrazioni e poi non si adattano alla realtà operativa. È, misurata sul campo, la stessa cosa che qui si sostiene per via di ragionamento. Il problema non è il modello. È la testa dell’organizzazione che lo accoglie.
Il nodo generazionale italiano
C’è un risvolto che in Italia pesa più che altrove, e si lega dritto al deficit di competenze da cui siamo partiti. Il discorso corrente è quello del reskilling: formiamo le persone che abbiamo, le aggiorniamo, il divario si chiude. È un discorso rassicurante e in parte necessario. Però gira intorno a una cosa scomoda.
I neolaureati, paradossalmente, partono spesso avvantaggiati. Non perché ne sappiano di più, ne sanno molto meno, ma perché non hanno ancora interiorizzato la grammatica che oggi tocca in parte disimparare. Tornare a pensare in modo probabilistico costa meno fatica a chi non ha passato vent’anni a pensare in modo deterministico. Vuol dire che, proprio in questo passaggio, la curva dell’esperienza smette di salire sempre. Oltre un certo punto, una parte di quel capitale diventa un peso. Non un peso che cancella il valore del senior, sarebbe assurdo dirlo, ma un peso vero, che la retorica del reskilling preferisce non nominare perché è sgradevole da ammettere.
Per il tessuto software italiano questa è una tenaglia. Da una parte mancano i giovani. Ne entra sul mercato circa la metà di quanti ne servono, e le software house, in gran parte microimprese, se li contendono con stipendi che spesso non reggono il confronto con l’estero o con le multinazionali. Dall’altra ci sono i senior, che sono la risorsa più preziosa di quelle aziende, perché custodiscono la conoscenza dei domini applicativi e dei clienti, e sono allo stesso tempo quelli su cui la riconversione mentale grava di più. Così le aziende devono fare insieme due cose difficili. Attrarre una generazione che scarseggia e ha mille alternative. E accompagnare una generazione esperta in un cambiamento che le chiede di rimettersi ad apprendere proprio dove era maestra. La seconda, sul piano umano prima ancora che organizzativo, è la più dura.
Cosa serve davvero
La conclusione non è che i senior siano da rottamare. Sarebbe una sciocchezza, e per le software house italiane un suicidio. La conoscenza dei domini, il disegno di architetture che durano, il fiuto per distinguere un debito tecnico che si può reggere da uno che affonda l’azienda restano cose che nessun ventiquattrenne possiede. La conclusione è un’altra. La transizione non si fa con un corso, e nemmeno con un anno di corsi. Si fa accettando che il mestiere è salito di livello, e che il cambiamento non è cumulativo. In certe zone non si somma alla competenza di prima. La rimpiazza.
Lo stesso studio MIT, accanto al dato sui fallimenti, lascia un’indicazione pratica da prendere sul serio. I progetti che hanno messo insieme specialisti interni e competenze esterne sono andati molto meglio di quelli affidati ai soli reparti IT. Tradotto: le aziende che reggono la transizione non si limitano ad aggiornare i team che hanno. Costruiscono accanto a essi dei nuclei AI-native, con vera autonomia, e fanno circolare le competenze nei due sensi. Dai senior verso i nuovi nuclei, sul dominio e sull’architettura. Dai nuovi nuclei verso i senior, sul paradigma probabilistico e sulle pratiche che ne derivano. È un lavoro lento, costoso, politicamente spinoso, perché chiede a chi è stato protagonista di accettare per un tratto il ruolo dell’allievo. Le aziende che scelgono la scorciatoia, una formazione spot, una consulenza una tantum, il “tanto i nostri sviluppatori sono bravi”, sono esattamente quelle che in questi mesi sfornano sistemi splendidi in demo e fragili in produzione. Vanno a ingrossare quel novantacinque per cento.
Non è una faccenda di età anagrafica. Si conoscono ingegneri di cinquantacinque anni che hanno fatto la transizione meglio di colleghi di trenta. È una faccenda di disponibilità a riconoscere che il paradigma è cambiato, e che la propria forma mentis, la cosa più preziosa e più difficile da rimettere in discussione, va in parte riformata. Chi non lo riconosce non è incompetente. È fermo a un mestiere che non esiste più nella stessa forma. E in un Paese che già stenta a trovare le persone, trattare quelle che ha come se dovessero solo aggiungere una competenza, invece che ripensarne una, è uno spreco che il software italiano non si può permettere. Nei prossimi diciotto mesi, la differenza comincerà a vedersi nei bilanci.
Alberto Viotto
