AI debt: come prompt, retrieval ed evaluation stanno silenziosamente erodendo il rischio enterprise

Negli ultimi vent’anni, debito tecnico significava codice vecchio, architetture obsolete e documentazione trascurata. Nell’era dell’AI, la definizione non basta più. I nuovi strati di debito vivono dentro prompt, modelli e dipendenze dai dati — meno visibili, più difficili da misurare, e spesso più pericolosi del debito tradizionale.

Uno studio MIT del 2025 ha rilevato che il 95% dei progetti AI fallisce prima di arrivare in produzione o di generare valore. S&P Global Market Intelligence aggiunge un dato secco: il 42% delle aziende ha accantonato almeno un’iniziativa AI nel 2025, contro il 17% dell’anno prima. I motivi indicati puntano quasi tutti a sistemi mal progettati, complessi da gestire e pieni di punti di fallimento difficili da monitorare. Il risultato è un accumulo rapido di AI debt.

Il debito tecnico tradizionale era localizzato nel codice, e i bug erano riproducibili. Li trovavi nei test e li risolvevi riscrivendo. L’AI debt è distribuito: attraversa prompt, modelli, pipeline di dati e infrastrutture. È intermittente, perché l’AI è probabilistica — lo stesso input può produrre output diversi. Questo rende i test insufficienti e impone un monitoraggio continuo anche dopo il lancio, per evitare degradi graduali e peggioramento delle performance.

Le quattro nuove forme di AI debt

Prompt debt è la più visibile delle quattro. È la versione moderna dello spaghetti code: modifiche rapide ai prompt non documentate, versioni multiple senza controllo, “prompt stuffing” (riempire i prompt con dati extra per compensare mancanze). Il risultato è un insieme di istruzioni non tipate, non testate e senza versionamento, che rendono il sistema più fragile e vulnerabile.

Model dependency debt è il debito generato dalla dipendenza da modelli esterni. Quasi tutte le aziende oggi usano modelli di foundation provider tramite API. La logica applicativa dipende da modelli che l’azienda non controlla. Quando un modello viene aggiornato, le performance cambiano e la riproducibilità si perde: prompt ottimizzati per un modello falliscono su un altro, anche solo con un update dello stesso provider.

La maggior parte dei deployment enterprise usa il recupero aumentato (RAG), che attinge contesto da repository aziendali. Retrieval debt nasce da repository con dati sporchi, documenti duplicati e informazioni obsolete. L’AI risponde in modo tecnicamente corretto, ma con contenuti non più validi. È più insidioso delle allucinazioni, perché la risposta sembra giusta — lo era fino a poco prima.

Evaluation debt riflette la mancanza di standard nei test e nel monitoraggio dei modelli. I benchmark AI sono stretti e istantanei. La maggior parte delle imprese non ha ground truth dataset, standard di test consistenti o monitoraggio in tempo reale. Non esiste ancora un equivalente della CI/CD per i prompt. I CIO e i CTO non hanno visibilità chiara sulle performance dei modelli.

A queste si aggiungono le forme tradizionali di debito tecnico, aggravate dall’adozione di codice generato da AI spesso distribuito senza test adeguati. Il tutto si combina rapidamente, creando rischi su larga scala che possono portare al fallimento catastrofico di interi deployment.

La responsabilità è distribuita: i sistemi coinvolgono team di engineering, prodotto, dati e business. Quando un errore emerge, l’attribuzione è poco chiara. I segnali d’allarme sono costi di calcolo che salgono, output sempre meno accurati, eccezioni che richiedono interventi manuali. I progetti si fermano perché il ritorno sull’investimento non è chiaro e gli utenti perdono fiducia.

Come prevenire l’AI debt

L’AI debt non si risolve con modelli migliori: i tassi di fallimento restano alti anche con modelli già molto accurati. Servono migliori progettazione dei sistemi, controlli integrati e un cambio culturale.

Primo: i prompt vanno trattati come codice. Versionamento, documentazione e test rigorosi pre e post deployment. Le buone pratiche dello sviluppo tradizionale — blocchi di prompt piccoli, pochi parametri hard-coded — aiutano a contenere il debito.

Secondo: la valutazione va integrata nell’intero stack AI. Pipeline di valutazione continue, metriche sia tecniche che di business, sistemi di osservabilità che monitorino qualità degli output, tassi di errore e drift del modello e dei dati.

Terzo: l’explainability deve essere attiva di default. Tracciabilità della provenienza dei dati, dei modelli usati e dei passaggi seguiti, per permettere audit e correzioni. Serve un programma esplicito di riduzione dell’AI debt con budget dedicato, come si è fatto per la sicurezza o la modernizzazione del cloud. Deve essere guidato a livello CXO per evitare costose rilavorazioni successive.

I deployment AI enterprise non sono codice statico: sono sistemi viventi che interagiscono con l’intero stack aziendale. La sfida principale non sarà costruire sistemi intelligenti, ma mantenerli affidabili nel funzionamento reale. Le aziende che identificano e mitigano l’AI debt già in fase di progettazione sono quelle più probabili a costruire piattaforme AI sostenibili.