Il vero debito legacy non è il codice: sono le decisioni che abbiamo smesso di mettere in discussione

di Fabio Moioli e Alan Trefler

Qualche settimana fa, durante una cena a Milano con alcuni senior executive di grandi aziende italiane, una conversazione sull’intelligenza artificiale ha preso una direzione meno prevedibile del solito. Parlavamo di agenti, di software enterprise e di come le imprese possano trasformarsi. A un certo punto ci siamo soffermati sui token, le unità con cui vengono misurati input e output dei modelli generativi. Sembrava una questione di costi tecnologici. In realtà, il tema era molto più profondo: quanto spesso chiediamo all’AI di ragionare su qualcosa che l’organizzazione dovrebbe aver già deciso?

Immaginiamo un processo che viene eseguito milioni di volte. Se a ogni passaggio un modello linguistico deve ricostruire da zero una regola che conosciamo già, non stiamo soltanto aumentando i costi. Stiamo scegliendo di affidare a un sistema probabilistico una decisione che, in molti casi, potrebbe essere presa una volta, formalizzata e applicata in modo prevedibile. La capacità di ragionare è preziosa quando il problema è nuovo o ambiguo. Non necessariamente quando continuiamo a riproporre la stessa domanda.

Da qui nasce un paradosso importante per la leadership: l’AI può aiutarci a ripensare processi che esistono da decenni, oppure può renderli semplicemente più veloci. La prima possibilità è trasformazione. La seconda rischia di essere soltanto una modernizzazione del passato.

Il ragionamento più costoso può essere quello che non serviva

Siamo abituati a considerare un sistema tanto più sofisticato quanto più è autonomo, capace di interpretare e decidere. Ma nelle imprese il valore non coincide con la quantità di ragionamento generato. Un reclamo insolito, una pratica assicurativa con informazioni contraddittorie o una situazione imprevista possono richiedere di valutare il contesto, confrontare alternative e gestire incertezza. È il terreno nel quale l’AI generativa può offrire capacità prima difficili da ottenere con le sole regole tradizionali.

Ci sono però anche decisioni già comprese e vincoli che esistono per buone ragioni. Il calcolo di una soglia, un requisito normativo, un controllo di autorizzazione o una procedura standard devono spesso essere eseguiti in modo ripetibile, trasparente e verificabile. Affidare ogni volta tali passaggi alla libera interpretazione di un modello può aggiungere variabilità proprio dove l’organizzazione ha bisogno di coerenza.

È una distinzione sulla quale Alan Trefler insiste da tempo: utilizzare intensamente l’AI nella fase di progettazione, quando serve comprendere un sistema, individuare le assunzioni nascoste e immaginare un modo migliore di lavorare; utilizzarla invece in modo selettivo nell’esecuzione quotidiana, quando buona parte delle decisioni è già stata definita. Non significa opporre regole e intelligenza artificiale, ma combinarle con criterio: ragionamento probabilistico dove crea valore, esecuzione deterministica dove il comportamento deve essere affidabile, supervisione umana dove le conseguenze lo richiedono.

Vista così, l’economia dei token non riguarda soltanto il costo unitario dell’AI. Costringe a domandarci dove l’intelligenza debba essere impiegata. Un’azienda che consuma meno token perché ha progettato meglio il lavoro può essere più evoluta di un’azienda che fa ragionare un agente su ogni singolo passaggio. L’obiettivo non è usare meno AI in assoluto. È evitare di sprecarne le capacità.

Le applicazioni conservano decisioni di cui abbiamo dimenticato il motivo

Quando parliamo di sistemi legacy, pensiamo al codice vecchio, alle infrastrutture obsolete, ai linguaggi difficili da mantenere e al debito tecnico. È una descrizione corretta, ma incompleta. Le applicazioni contengono anche decisioni. Un certo percorso cliente esiste perché il Crm è stato configurato in un modo preciso. Un’approvazione è richiesta perché anni prima due sistemi non riuscivano a scambiarsi un’informazione. Un’attività passa da una funzione all’altra perché ciascuna possiede un pezzo diverso della logica di business.

Con il tempo, queste scelte smettono di apparire come scelte. Diventano «il modo in cui lavoriamo». I manager cambiano, le tecnologie evolvono, le ragioni originarie si perdono. Le regole, invece, continuano a essere eseguite. Alcune proteggono ancora un rischio reale, una responsabilità o un diritto del cliente. Altre sopravvivono solo perché in passato cambiarle era complesso o costoso.

È qui che la modernizzazione del legacy incontra una questione di leadership. Un progetto può sostituire perfettamente l’infrastruttura e lasciare intatta una logica organizzativa superata. Può migrare una vecchia applicazione sul cloud, aggiungere un’interfaccia conversazionale, accelerare i tempi di risposta e non cambiare nulla nelle decisioni che contano. Il risultato sarà tecnicamente migliore, ma strategicamente molto simile al punto di partenza.

L’AI offre oggi una possibilità più interessante: aiutarci a ricostruire il perché delle regole incorporate nei sistemi, mettere in relazione documentazione e comportamenti effettivi, individuare ridondanze e simulare alternative. Non basta chiedere «come trasferiamo questa applicazione?». La domanda più utile è «quali delle decisioni incorporate in questa applicazione prenderemmo ancora oggi?». Quando la risposta è «non tutte», il lavoro non è più soltanto una migrazione informatica. È un ripensamento dell’organizzazione.

Prima di automatizzare dodici passaggi, chiediamoci perché siano dodici

Consideriamo, a titolo di esempio, un processo di gestione dei sinistri con dodici passaggi e quattro approvazioni umane. L’AI può aiutare a compilare documenti, riassumere informazioni, verificare condizioni e ridurre il tempo di ciascuna approvazione. È un miglioramento misurabile, e può essere utile. Ma perché ci sono dodici passaggi? E perché servono proprio quattro approvazioni?

Forse uno dei controlli è nato quando le informazioni non erano disponibili in tempo reale. Un altro perché sistemi diversi non potevano dialogare. Un terzo potrebbe essere invece indispensabile per proteggere il cliente, limitare una frode o garantire la conformità normativa. Trattare tutti i passaggi come ugualmente necessari equivale a rinunciare alla domanda più importante prima ancora di iniziare a progettare.

I progetti di automazione tendono a partire da ciò che è più facile misurare: ore risparmiate, pratiche elaborate, produttività per operatore, tempi di risposta. Ma un processo che passa da dodici a sei passaggi può produrre un valore diverso e potenzialmente maggiore di un processo che conserva tutti i dodici passaggi eseguendoli in metà tempo. Per scoprirlo bisogna osservare il risultato finale, non soltanto la velocità delle attività intermedie.

Questo vale anche per i controlli. Eliminare un’approvazione inutile non significa eliminare la responsabilità; può significare renderla più esplicita, sostituire un controllo manuale con una regola verificabile o riservare l’attenzione umana alle eccezioni che la meritano davvero. La differenza tra semplificazione e scorciatoia sta nella capacità di capire quale rischio ogni passaggio doveva governare e se quel rischio esiste ancora.

Dalla rigidità delle applicazioni alla fluidità del business

Alan utilizza l’espressione business fluidity per descrivere la possibilità di superare parte della rigidità costruita intorno alle applicazioni. Per decenni le imprese hanno acquistato un Crm, un Erp o una piattaforma di customer service e hanno poi organizzato attività, dati e responsabilità attorno a quei sistemi. I confini della tecnologia hanno finito spesso per diventare confini dell’organizzazione.

Con l’AI, alcune di queste barriere possono indebolirsi. Un’interfaccia capace di comprendere l’intento dell’utente, recuperare informazioni da sistemi differenti e attivare processi può permettere di interagire con il lavoro da svolgere anziché con le singole applicazioni che ne custodiscono i pezzi. Il cliente non vuole sapere quale sistema possiede il dato necessario a risolvere il suo problema. Un dipendente non dovrebbe dover ricostruire manualmente il percorso attraverso cinque applicazioni per completare un’attività.

Questa fluidità, però, non nasce automaticamente dall’introduzione di un agente. Se autorizzazioni, dati, controlli e responsabilità restano frammentati, un agente può semplicemente attraversare la frammentazione più velocemente. Per rendere il business realmente più fluido occorre decidere chi può fare che cosa, quali azioni richiedono conferma, come si conserva la tracciabilità e chi risponde delle conseguenze. L’autonomia tecnologica non sostituisce il disegno organizzativo.

È un cambiamento rilevante per il top management perché riguarda i confini tra funzioni, i diritti decisionali e la capacità di adattare il modello operativo. Se quei confini erano stati creati soprattutto da limiti informatici, l’AI ci offre la possibilità di riconsiderarli. Se invece proteggevano un’esigenza reale di controllo, dovremo preservarli, magari in una forma nuova. È questa distinzione, non il numero di agenti installati, a misurare la maturità di una trasformazione.

Il rischio è far funzionare magnificamente il passato

L’AI rende più semplice scrivere software, creare interfacce e automatizzare attività. È una capacità straordinaria, ma porta con sé un rischio: produrre più velocemente anche nuova complessità. Un’impresa può creare un’applicazione migliore intorno a una regola superata, un assistente molto efficace per attraversare un percorso cliente inutilmente frammentato o un agente autonomo inserito in un modello operativo che nessuno ha avuto il coraggio di mettere in discussione.

Ogni progetto può sembrare un successo preso singolarmente. I tempi si riducono, l’esperienza appare più fluida, i costi scendono. Eppure l’organizzazione continua a difendere le stesse decisioni di ieri. Si può diventare molto efficienti nel fare qualcosa che non dovrebbe più essere fatto. E, se l’AI abbassa il costo di sviluppare software, possiamo persino costruire i sistemi legacy di domani con una velocità mai vista prima.

Per questo la trasformazione con l’AI dovrebbe iniziare prima dell’automazione. Prima di approvare un grande investimento, un comitato esecutivo dovrebbe interrogarsi su quali decisioni il processo attuale incorpora, quali sono ancora necessarie, quali derivano da vincoli scomparsi e quali risultati si vorrebbero ottenere se si potesse ripartire da zero. Dovrebbe poi stabilire dove servono regole certe, dove serve la capacità dell’AI di interpretare eccezioni e dove rimane indispensabile il giudizio umano.

Queste domande sono meno spettacolari di una demo, ma toccano il cuore della leadership. La tecnologia può rendere visibili alternative e conseguenze, aiutare a ricostruire le ragioni di una regola e accelerare la riprogettazione. Non può assumersi al posto del management la responsabilità di decidere quali compromessi abbandonare e quali principi preservare.

Il problema più profondo dei sistemi legacy non è dunque l’età del codice. Sono le decisioni del passato che, una volta trasformate in software, hanno smesso di sembrarci decisioni. L’AI può aiutarci a riconoscerle di nuovo. Stabilire quali meritano di sopravvivere è una scelta di leadership.

L’articolo Il vero debito legacy non è il codice: sono le decisioni che abbiamo smesso di mettere in discussione è tratto da Forbes Italia.