C’è un tipo di telefonata che ogni tanto arriva in azienda, e mette i brividi a chi la riceve. Non è il server che si è rotto: quello si ripristina. È la frase “l’unico che sapeva come funziona non c’è più”. Il gestionale gira, i clienti vengono fatturati, gli ordini escono. Ma sotto c’è un programma scritto quindici o vent’anni fa da una persona che oggi è in pensione, o malata, o semplicemente sparita dai radar. Nessuna documentazione. Il codice sorgente, quando c’è, è un blocco muto. E finché tutto va, nessuno lo tocca. Il problema è il giorno in cui qualcosa va cambiato — una nuova aliquota, un tracciato bancario diverso, un’integrazione — e ci si accorge che dentro quella scatola nera non sa più entrare nessuno.

Perché il legacy pericoloso non è quello vecchio

Ci siamo abituati a pensare al software legacy come a un problema di età: linguaggi obsoleti, macchine antiche, roba da rottamare. Ma l’età, da sola, non è il rischio. Un sistema vecchio ben documentato, con qualcuno che lo conosce, è solo scomodo. Il rischio vero è un altro: la conoscenza di come funziona vive in una testa sola, e quella testa sta per uscire dall’azienda. Il software diventa orfano. È un rischio di continuità aziendale, non di reparto IT — e non riguarda solo i colossi con i mainframe. Le forme più comuni nelle PMI sono banalissime: il gestionale su misura di uno sviluppatore che non c’è più, il foglio Access diventato negli anni il vero cervello operativo, il software di settore il cui fornitore ha chiuso o non aggiorna più. La scala del fenomeno è enorme: si stima che nel mondo girino in produzione qualcosa come 220 miliardi di righe di COBOL, e Gartner prevede entro il 2029 un buco del 30% di programmatori capaci di leggerle. Ogni riga è una piccola dipendenza da qualcuno che, prima o poi, non risponderà al telefono.

Cosa è cambiato: l’AI sa leggere

Per decenni questo rischio si poteva solo subire. Ricostruire cosa faceva un programma non documentato significava mesi di lavoro di un ingegnere bravo che leggeva riga per riga, ipotizzava, provava. Costoso, lento, spesso rimandato finché non scoppiava l’emergenza. La cosa nuova — quella che cambia davvero l’equazione — è che oggi l’AI legge il codice. Non lo esegue soltanto: lo interpreta, lo riassume, ricostruisce cosa fa un modulo e come si lega agli altri, scrive la documentazione che non è mai esistita. Morgan Stanley ha raccontato di aver dato in pasto a uno strumento interno nove milioni di righe di codice legacy per interpretarle, risparmiando circa 280.000 ore di lavoro. Sui costi che storicamente pesavano di più, i numeri che circolano parlano di riduzioni del 75-80% sulla sola documentazione. Tradotto per una PMI: quella scatola nera che nessuno sapeva più aprire, adesso si può far raccontare.

La chiave è il dato, non il codice

Qui però c’è la parte che quasi nessuno dice, e che ho imparato sul campo. Spesso il codice non è la porta giusta da cui entrare. A volte manca del tutto — hai il programma che gira ma non i sorgenti — e a volte è talmente aggrovigliato che leggerlo ti dice come è scritto, non come viene usato. La verità di un sistema sta molto più spesso nei suoi dati che nelle sue istruzioni. È lì che si legge il comportamento reale: quali campi vengono davvero compilati, quali no, quali regole gli utenti hanno aggirato negli anni con trucchi che nessuna specifica ha mai scritto. E per arrivare ai dati oggi c’è uno strumento che due anni fa non esisteva: MCP, lo standard aperto — nato di recente e già adottato da tutti i grandi — che permette all’AI di collegarsi a un sistema e leggerne i dati dove sono, senza toccare nulla. Colleghi il traduttore, e cominci a esplorare: interroghi il database in linguaggio naturale, cerchi le anomalie, ricostruisci le regole dai dati invece che dal codice. Il sistema orfano smette di essere una scatola nera e diventa qualcosa che puoi intervistare.

E quando i sorgenti mancano del tutto, si può risalire alla logica anche per altre vie — ci sono tecniche di ingegneria inversa che ho affinato negli anni e che non si improvvisano leggendo un articolo. Il punto che conta qui non è il metodo, è la notizia: la porta, quasi sempre, adesso si trova.

MCP compra tempo

C’è un secondo effetto di questo modo di lavorare, ed è forse il più prezioso per chi deve decidere con i piedi per terra. Partire dai dati significa che non sei costretto a spostare il sistema per cominciare a usarne il valore. Puoi iniziare a leggere e a travasare quei dati dentro altri strumenti — un cruscotto aggiornato, un CRM, un magazzino nuovo — lasciando l’originale esattamente dov’è, acceso, a fare il suo lavoro. Il legacy da monolite-da-migrare-tutto-in-una-notte diventa una semplice sorgente di dati, che puoi svuotare e mandare in pensione un pezzo alla volta, quando ti fa comodo. È l’opposto del progetto-cattedrale con la data del go-live scritta col sangue. È l’ordine di cui ho già scritto altrove: prima l’AI prepara il terreno, poi eventualmente arriva la piattaforma. MCP, in questa storia, non è la soluzione: è la cosa che ti compra il tempo per trovarla senza panico.

La parte onesta: l’AI ti dice cosa fa, non perché

Detto tutto il bello, adesso la verità scomoda, perché senza questa il resto diventa marketing. L’AI ti dice benissimo cosa fa un sistema. Non ti dice perché lo fa. Quella riga che scarta gli ordini sopra una certa cifra il venerdì potrebbe essere un bug dimenticato, oppure l’unica cosa che vi ha salvato da un cliente moroso nel 2014: il codice non lo sa, e nemmeno l’AI. Ricostruire l’intento di business dietro a un comportamento è ancora un lavoro umano, e resta il più delicato. I numeri lo confermano: si stima che il 77% dei programmi di modernizzazione non arrivi mai in fondo, e i tool generici, lasciati soli, producono quelli che qualcuno ha chiamato “scheletri di classi” — codice sintatticamente corretto e concettualmente vuoto, che replica la forma e perde la sostanza. ING ha impiegato diciotto mesi solo per validare che il nuovo sistema si comportasse come il vecchio su due miliardi di transazioni: non a riscrivere, a controllare che nulla si rompesse in silenzio. La lezione è netta: l’AI comprime spettacolarmente il lavoro di lettura e traduzione, ma la validazione — il “questo comportamento serve o è spazzatura?” — resta la parte in cui devi mettere te stesso.

Le mosse concrete

Se in azienda hai un sistema che ti fa venire in mente questa telefonata, tre cose in ordine. Primo: fai una mappa. Per ogni sistema decidi se tenerlo e integrarlo (funziona, ti serve), se rifarlo (logica valida ma debito tecnico alto), o se sostituirlo (fornitore morto, nessun accesso ai dati) — dai la priorità ai processi dove il legacy genera più errori, tipicamente disponibilità di magazzino, prezzi, avanzamento delle commesse. Secondo: non riscrivere per moda. La domanda-soglia non è “quanto è vecchio”, ma “quante persone sanno come funziona”: se la risposta è una, o zero, quello è il tuo problema numero uno, prima ancora della tecnologia. Terzo, ed è la mossa che quasi nessuno fa: metti l’AI a documentare il sistema mentre la persona che lo conosce è ancora in azienda. È il momento in cui vale di più. La macchina ricostruisce il cosa, la persona conferma o smentisce il perché, e per una volta quella conoscenza finisce scritta da qualche parte invece che andarsene in pensione con chi la custodiva.

Perché è questo il punto, alla fine. L’AI non riscrive il tuo passato al posto tuo. Fa una cosa più modesta e più utile: te lo fa finalmente leggere. E leggere il proprio passato, con calma, prima che la telefonata arrivi, è esattamente la differenza tra decidere e rincorrere.