Debito tecnico nell’era dell’AI: più facile da ripagare, più facile da accumulare

• Il debito tecnico non è una passività di bilancio ma decide quanto costa cambiare. Nelle grandi imprese italiane il 39% del portafoglio applicativo andrebbe modernizzato e l’obsolescenza è la prima criticità segnalata dai CIO (Osservatorio Cloud Ecosystem & Sovereignty, Politecnico di Milano, 2025). 
• Si comporta come un debito finanziario: ha un capitale (il costo per estinguerlo), matura un interesse (il costo aggiuntivo pagato a ogni modifica finché resta aperto) e, a differenza di un debito finanziario, può ridurre il valore delle opzioni future dell’impresa. 
• L’AI agisce sui due lati del debito: lo rende più facile da ripagare (McKinsey riporta accelerazioni dal 40 al 50% nei tempi di modernizzazione, su casi aziendali non generalizzabili) e più facile da accumulare (uno studio su progetti open source rileva un aumento persistente della complessità del codice). L’effetto netto non è scritto nella tecnologia: DORA 2025 descrive l’AI come un amplificatore della qualità delle pratiche esistenti. 
• La proposta degli autori è considerare governato un debito materiale quando sono espliciti almeno quattro elementi: ragione, responsabile, interesse stimato e data di riesame.

L’obiettivo manageriale non è eliminare il debito tecnico, ma governarlo: decidere quale debito assumere, quale interesse siamo disposti a pagare, per quanto tempo e in cambio di quale valore. 

Nelle grandi imprese italiane il 39% del portafoglio applicativo andrebbe modernizzato. È quanto emerge da un’indagine dell’Osservatorio Cloud Ecosystem & Sovereignty del Politecnico di Milano su 69 aziende con oltre 1.000 addetti, nella quale l’obsolescenza tecnologica risulta la prima criticità segnalata dai CIO [Osservatorio Cloud Ecosystem & Sovereignty, 2025], come avevamo già evidenziato in un precedente lavoro [Ficagna e Mainetti, 2026]. Dietro questo numero non c’è soltanto un problema di manutenzione. C’è una questione che riguarda il vertice dell’impresa: quanto ci costa oggi la capacità di cambiare che abbiamo perso ieri, e dove conviene smettere di pagarne il prezzo. 

Il debito tecnico, però, non nasce necessariamente da un errore. Quando un team rinvia un refactoring per rispettare una scadenza importante, può aver scelto consapevolmente di comprare tempo: portare prima una funzionalità sul mercato, verificare un’ipotesi con i clienti, cogliere una finestra competitiva che potrebbe chiudersi. È il senso originario della metafora: quando Ward Cunningham la introdusse, nel 1992, osservava che un po’ di debito accelera lo sviluppo, a condizione di ripagarlo prontamente [Cunningham, 1992]. 

Il problema nasce quando il debito, scelto consapevolmente o emerso nel tempo, smette di essere visibile come trade-off: non è più chiaro perché lo stiamo mantenendo, quale interesse stiamo pagando e quando la decisione andrebbe riesaminata. Modifica dopo modifica, ciò che aveva prodotto un vantaggio, o che semplicemente non rappresentava un problema, si trasforma in una frizione crescente sulla capacità dell’impresa di cambiare. 

Per questo riteniamo incompleta una rappresentazione ancora frequente, che considera il debito tecnico un difetto da eliminare anziché un trade-off da governare. Dal punto di vista manageriale, il debito tecnico si comporta come un debito finanziario e produce almeno tre effetti distinti. Ha un capitale: lo stock di interventi che sarebbero necessari per estinguerlo. Matura un interesse: un costo aggiuntivo che l’impresa paga a ogni modifica del sistema, per tutto il tempo in cui il debito resta aperto, sotto forma di interventi più lenti e costosi, innovazione frenata e un rischio maggiore di errori e disservizi. E, a differenza di un debito finanziario, può ridurre il valore delle opzioni future dell’impresa, perché rende più costoso cambiare strada. Evitarne ogni forma significa investire oggi per proteggere opzioni che forse non eserciteremo mai; accumularlo senza renderlo visibile significa guadagnare velocità oggi e perdere capacità di scelta domani. 

La domanda utile non è se il debito tecnico sia buono o cattivo, ma quando sia una scelta consapevole e quando diventi il risultato dell’inerzia. Una domanda che l’AI rende più urgente, perché agisce su entrambi i lati del debito: lo rende più facile da ripagare e, nello stesso tempo, più facile da accumulare.

Una delle definizioni più influenti nella letteratura scientifica è stata formulata nel 2016 da un seminario internazionale di ricerca a Dagstuhl: il debito tecnico è un insieme di scelte di progettazione o di implementazione convenienti nel breve periodo, che creano però un contesto tecnico capace di rendere i cambiamenti futuri più costosi o persino impossibili [Avgeriou et al., 2016]. Non parliamo quindi soltanto di codice scritto male: il debito può annidarsi nell’architettura, nei test, nella documentazione, nei requisiti e nell’infrastruttura. In un’indagine su oltre 1.800 professionisti sono proprio le scelte architetturali a emergere come la sua fonte principale [Ernst et al., 2015]. Il debito tecnico, in altre parole, non si riconosce tanto da come appare il codice, quanto dalla frizione che introduce nella capacità di cambiare il sistema.

Se il debito nascesse solo da scorciatoie consapevoli, governarlo significherebbe semplicemente decidere meglio. La realtà è più articolata, e proponiamo di distinguerne tre forme. Il debito assunto è quello del team che rinvia il refactoring per anticipare valore: una scelta, giusta o sbagliata che sia. Il debito maturato nasce dall’apprendimento: quando comprendiamo meglio il dominio, scopriamo che la progettazione di ieri non è più adeguata, e non c’è colpa in questo, è il prezzo dell’imparare. Il debito ereditato emerge dall’evoluzione del contesto: componenti che escono dal supporto, tecnologie che diventano obsolete, vincoli normativi che cambiano. Non tutta l’obsolescenza è debito tecnico; lo diventa quando le scelte incorporate nel sistema rendono costoso adattarsi al nuovo contesto. 

È questa terza forma a emergere con più forza nei portafogli delle grandi organizzazioni, come suggerisce il dato dell’Osservatorio. Spesso nessuno l’ha decisa esplicitamente; eppure qualcuno deve assumersene la responsabilità e governarla.

Una chiave interpretativa particolarmente utile viene dagli studi sul miglioramento dei processi, e in particolare dalla trappola della capacità descritta da Repenning e Sterman. Sotto pressione, le organizzazioni tendono a chiedere alle persone di lavorare di più anziché investire nella capacità del processo: la produzione migliora subito, la capacità si erode lentamente, la pressione cresce e il ciclo si rinforza. Il titolo del loro lavoro riassume il meccanismo: nessuno riceve credito per aver risolto problemi che non si sono mai verificati [Repenning e Sterman, 2001]. 

Nei sistemi informativi questa trappola trova un terreno ideale. Una nuova funzionalità è visibile oggi e ha un committente. Architettura, testabilità e manutenibilità producono invece un valore che si vede soprattutto quando manca, e con un ritardo che rende difficile ricostruire il legame tra causa ed effetto: la rigidità introdotta oggi costerà fra due anni, alla quarantesima modifica, probabilmente sotto la responsabilità di qualcun altro. Non è quindi soltanto un problema di competenza, ma anche di struttura: incentivi, ritardi e responsabilità distribuite nel tempo. Per questo le raccomandazioni tecniche, da sole, non bastano; servono meccanismi di governo che rendano visibili e attribuibili i costi del rinvio.  

La Figura 1 rappresenta i due cicli di questa dinamica: quello che offre un sollievo immediato e quello che, con ritardo, erode la capacità di cambiare. 

Il linguaggio finanziario offre a CIO, CFO e CEO una cornice comune, a patto di ricordare che la corrispondenza è imperfetta. Il capitale è il lavoro, o il costo, stimato per rimuovere le condizioni che identifichiamo come debito. L’interesse è il costo aggiuntivo che continuiamo a sostenere finché quel debito resta aperto: più lavoro per realizzare una modifica, più test per gestirne l’incertezza, più tempo per comprendere un componente, più rilavorazioni o un maggiore rischio operativo. 

Il debito è uno stock; l’interesse è un flusso. E quel flusso dipende da due fattori: quanta frizione il debito introduce in ogni cambiamento e quanto spesso siamo chiamati a modificare il sistema. Per questo Seaman e Guo hanno proposto di stimare, accanto al capitale e all’interesse, anche la probabilità che l’interesse venga effettivamente pagato [Seaman e Guo, 2011]. 

Un’applicazione vicina alla dismissione, modificata due volte l’anno, può avere un capitale elevato e un interesse trascurabile; un’altra, con meno debito ma modificata ogni settimana, può costare molto di più. La domanda rilevante si sposta così da quanto debito abbiamo a quanto ci costa portarlo. Non significa rinunciare a stimare il costo del risanamento, ma affiancargli quello del mancato intervento: è sul confronto fra i due che CIO, CFO e CEO possono concordare le priorità.

Il debito tecnico non è una passività contabile. Il Conceptual Framework dell’IFRS definisce la passività come un’obbligazione attuale a trasferire una risorsa economica per effetto di eventi passati, cioè un dovere che l’impresa non ha la possibilità pratica di evitare [IFRS Foundation, 2018]. Nessuno obbliga un’impresa a intervenire su un sistema: può scegliere se, quando e come modificarlo, sostituirlo o dismetterlo. 
La contabilità, tuttavia, non è cieca. Non rileva il debito tecnico come categoria autonoma, ma ne intercetta alcuni effetti dal lato dell’attivo. La vita utile del software capitalizzato va rivista almeno a ogni chiusura d’esercizio, e tra i fattori da considerare lo IAS 38 indica l’obsolescenza tecnologica e il livello di spesa di manutenzione necessario per ottenere i benefici attesi; analogamente, tra gli indicatori di riduzione di valore lo IAS 36 include l’obsolescenza e risultati economici peggiori del previsto [IASB, IAS 36 e IAS 38]. I principi non nominano il debito tecnico, e la spesa di manutenzione non coincide con il suo interesse: il collegamento che proponiamo è interpretativo, ma concreto, perché è attraverso queste stime, e quindi attraverso ammortamenti e svalutazioni, che il debito entra nei conti. 
C’è poi un effetto meno visibile. Per lo IAS 38 la maggior parte della spesa successiva su un’immobilizzazione immateriale mantiene benefici già esistenti e va a conto economico, mentre lo sviluppo di un nuovo sistema controllato dall’impresa può, a precise condizioni, essere capitalizzato. Ne deriva un’asimmetria: gli interventi continui di rimozione del debito pesano sul risultato dell’esercizio, mentre un programma di sostituzione può essere trattato, almeno in parte, come investimento. Dove budget e incentivi guardano soprattutto al risultato annuale, questa asimmetria crea una pressione implicita a rinviare, finché il problema non giustifica un progetto straordinario. Il trattamento esatto dipende dai principi contabili applicati e dal tipo di soluzione adottata. 
Per il CIO, qui si apre uno spazio di dialogo con il CFO: non si tratta di riconoscere una nuova passività, ma di rendere visibile una frizione economica che i prospetti mostrano solo indirettamente, verificando che lo stato del patrimonio applicativo si rifletta davvero nelle stime sulla sua vita utile e sul suo valore recuperabile. 

Accanto a capitale e interesse serve una terza lente, che la ricerca ha sviluppato in un filone parallelo: il valore di opzione dell’architettura. Baldwin e Clark hanno mostrato che la modularità crea valore perché moltiplica le opzioni di cambiamento [Baldwin e Clark, 2000], e nella letteratura sui sistemi informativi Sambamurthy, Bharadwaj e Grover hanno descritto le opzioni digitali come fondamento dell’agilità d’impresa [Sambamurthy et al., 2003].  

Quando investiamo nella qualità strutturale di un sistema, spesso non compriamo una funzionalità: compriamo la possibilità di decidere più tardi, quando avremo informazioni migliori.  
Un sistema modulare e dotato di buone interfacce permette di cambiare un processo, sostituire un fornitore, integrare un’acquisizione o abilitare nuovi servizi senza rimettere in discussione l’intero impianto. Un sistema fortemente accoppiato restringe progressivamente questo spazio: l’applicazione può continuare a svolgere perfettamente il suo compito corrente, ma è l’impresa a diventare meno libera di chiederle qualcosa di diverso. In questa prospettiva il debito tecnico non produce solo un costo di rimozione e un interesse: erode il valore delle opzioni digitali, perché rende progressivamente più lento e costoso esercitarle. Ed è proprio la capacità che il business vede meno, finché scopre di non averla più.  
La Figura 2 riassume questa logica: il capitale come costo potenziale della rimozione, l’interesse come frizione pagata a ogni modifica, più spesso quanto più spesso tocchiamo il sistema, e le alternative a disposizione dell’impresa che si restringono quando la frizione cresce.

Sul primo lato, l’AI può ridurre il costo di attività onerose come la comprensione dei sistemi esistenti, la generazione di test e la conversione del codice. McKinsey riporta, da progetti condotti con una propria metodologia, accelerazioni dal 40 al 50% nei tempi di modernizzazione e riduzioni intorno al 40% dei costi derivanti dal debito tecnico [Bawcom e Fitzpatrick, 2024]. Google descrive una migrazione interna in cui circa l’80% delle modifiche è stato generato dall’AI e i tempi si sono ridotti, secondo le stime degli ingegneri, di circa la metà [Nikolov et al., 2025]. Sono casi aziendali, non risultati generalizzabili, e gli stessi autori di McKinsey avvertono che convertire il codice senza ripensarne la struttura significa soltanto trasferire il debito su una piattaforma nuova. Ma indicano che l’economia della modernizzazione sta cambiando. 

Sul secondo lato, l’AI aumenta la quantità di cambiamento che un’organizzazione è in grado di produrre. Il rapporto DORA 2025, basato su quasi 5.000 professionisti, descrive l’AI come un amplificatore: potenzia le organizzazioni con pratiche solide e amplifica le disfunzioni delle altre [DeBellis et al., 2025]. Uno studio su progetti open source che hanno adottato un assistente di programmazione basato sull’AI ha rilevato un aumento significativo ma transitorio della velocità di sviluppo, accompagnato da un incremento persistente degli avvisi di analisi statica e della complessità del codice, che nel tempo si associa a un rallentamento della velocità inizialmente guadagnata [He et al., 2026]. 

È un paradosso solo apparente: l’AI ci rende più capaci sia di ripagare il debito sia di crearne di nuovo. L’effetto netto non è scritto nella tecnologia: dipende dalla qualità del sistema socio-tecnico in cui l’accelerazione viene assorbita. Architettura, pratiche di ingegneria, controlli, competenze e disciplina di governo determinano se la maggiore velocità si traduce in capacità aggiuntiva o in nuova fragilità. Per chi guida l’impresa la conseguenza è concreta: adottare l’AI nello sviluppo senza governare il debito significa comprare velocità oggi a un tasso di interesse che spesso nessuno misura.

Capitale, interesse e valore delle opzioni non sono osservabili con la precisione di un debito finanziario; le loro stime dipendono dal perimetro considerato, dalle alternative disponibili e dalla frequenza futura dei cambiamenti, che per definizione conosciamo solo in parte. Trasformare ogni fragilità tecnica in un indicatore economico rischierebbe di produrre falsa precisione, burocrazia e una sicurezza ingiustificata. 

L’obiezione è fondata, ma indica un limite del modello, non una ragione per abbandonarlo. Governare il debito tecnico non significa contabilizzare ogni imperfezione del codice, né attribuirle un valore monetario. Significa portare a livello manageriale solo il debito che diventa materiale, perché incide in modo significativo sul costo del cambiamento, sul rischio o sulle opzioni strategiche dell’impresa. La metafora resta utile finché resta ciò che è: uno strumento per rendere espliciti i trade-off nel tempo, non una contabilità parallela. Non serve a produrre un numero esatto, ma a disciplinare una decisione che l’impresa deve comunque prendere: continuare a pagare l’interesse, ridurre il capitale o accettare consapevolmente di restringere alcune opzioni future.

Se accettiamo questa lettura, una politica di “debito zero” ha poco senso come obiettivo manageriale. L’obiettivo è una disciplina di governo. Proponiamo di considerare governato un debito quando sono espliciti almeno quattro elementi: la ragione per cui esiste, un responsabile, una stima dell’interesse che genera e una data di riesame. Per il debito assunto, la ragione è il valore anticipato: se non sappiamo dire quale, difficilmente siamo davanti a una scelta. Per il debito maturato ed ereditato la ragione diventa l’origine, ma gli altri elementi restano indispensabili: qualcuno deve vedere quel debito anche a progetto concluso, qualcuno deve sapere quanto costa, e la data di riesame impedisce che il temporaneo diventi permanente per dimenticanza.  
Questa disciplina va proporzionata alla scala. In un’azienda di medie dimensioni può bastare inserire il debito materiale nel piano di evoluzione delle applicazioni e riesaminarlo periodicamente insieme ai responsabili di business. In una grande impresa serve una vista di portafoglio che confronti applicazioni, dipendenze e priorità di investimento. In un gruppo occorre chiarire chi presidia il debito che attraversa piattaforme comuni, singole società e fornitori, perché l’interesse può ricadere su soggetti diversi da chi ha preso la decisione originaria.  
Anche il finanziamento cambia natura. Riservare una quota fissa del budget IT alla riduzione del debito non è la soluzione ideale, ma è una scelta pragmatica: protegge gli interventi strutturali proprio dalla pressione al rinvio descritta sopra. Funziona se quella quota è un pavimento, non un automatismo, e se una funzione con una visione d’insieme, come l’architettura d’impresa, la indirizza con criteri coerenti con quelli che proponiamo e ne verifica gli effetti nel tempo. Il passaggio decisivo è dalla modernizzazione come evento eccezionale alla gestione continua del ciclo di vita, calibrando gli investimenti sull’interesse generato, sulla frequenza attesa del cambiamento, sulla criticità del sistema e sulle opzioni strategiche da preservare.

Alla fine, la metafora finanziaria è utile soprattutto perché ci costringe a domande semplici. Perché accettiamo questo debito? Quale beneficio otteniamo oggi? Quale interesse prevediamo di pagare? E quando riesamineremo la decisione di mantenerlo? L’AI le rende più urgenti: abbassa il costo di interventi ieri proibitivi e, insieme, accelera l’accumulo di nuovo debito.  
Per questo il debito tecnico non va né demonizzato né normalizzato. Va governato. L’obiettivo non è costruire sistemi senza debito, ma organizzazioni che sanno perché lo assumono, quale interesse pagano e quanta libertà futura cedono in cambio. È qui che il debito tecnico smette di essere una questione del solo IT e diventa una scelta d’impresa: l’equilibrio fra valore presente e libertà futura. 

 

 

(Pubblicato originariamente su LinkedIn il 5/10/2026)

Avgeriou, P., Kruchten, P., Ozkaya, I., & Seaman, C. (2016). Managing technical debt in software engineering (Dagstuhl Seminar 16162). Dagstuhl Reports, 6(4), 110-138. 

Baldwin, C. Y., & Clark, K. B. (2000). Design Rules, Vol. 1: The Power of Modularity. MIT Press. 

Bawcom, A., & Fitzpatrick, M. (2024). AI for IT modernization: Faster, cheaper, and better. McKinsey & Company, 2 dicembre 2024. 

Cunningham, W. (1992). The WyCash portfolio management system. OOPSLA '92 Experience Report. ACM SIGPLAN OOPS Messenger, 4(2), 29-30 (1993). 

DeBellis, D., Storer, K., Harvey, N., et al. (2025). DORA 2025 State of AI-assisted Software Development Report. Google. 

Ernst, N. A., Bellomo, S., Ozkaya, I., Nord, R. L., & Gorton, I. (2015). Measure it? Manage it? Ignore it? Software practitioners and technical debt. Proceedings of ESEC/FSE 2015, 50-60. ACM. 

Ficagna, M., & Mainetti, S. (2026). Il debito tecnico entra nel bilancio: perché CIO e CFO devono misurarlo. ZeroUno, 9 settembre 2026. 

He, H., Miller, C., Agarwal, S., Kästner, C., & Vasilescu, B. (2026). Speed at the cost of quality: How Cursor AI increases short-term velocity and long-term complexity in open-source projects. Proceedings of MSR 2026. ACM. doi:10.1145/3793302.3793349 

IASB. IAS 36 Impairment of Assets; IAS 38 Intangible Assets. IFRS Foundation. 

IFRS Foundation (2018). Conceptual Framework for Financial Reporting. 

Nikolov, S., Codecasa, D., Sjovall, A., Tabachnyk, M., Chandra, S., Taneja, S., & Ziftci, C. (2025). How is Google using AI for internal code migrations? arXiv:2501.06972. 

Osservatorio Cloud Ecosystem & Sovereignty, Politecnico di Milano (2025). Indagine su 69 grandi aziende italiane con oltre 1.000 addetti. 

Repenning, N. P., & Sterman, J. D. (2001). Nobody ever gets credit for fixing problems that never happened: Creating and sustaining process improvement. California Management Review, 43(4), 64-88. 

Sambamurthy, V., Bharadwaj, A., & Grover, V. (2003). Shaping agility through digital options: Reconceptualizing the role of information technology in contemporary firms. MIS Quarterly, 27(2), 237-263. 

Seaman, C., & Guo, Y. (2011). Measuring and monitoring technical debt. Advances in Computers, 82, 25-46.