Puntata 307 — Il debito tecnico-AI

Livello: 💡 Manager AIlluminato · Capitolo 28 · Stato dell’arte aziendale

Ogni PoC AI lasciato in eredità diventa un mini-castello di carte: prompt sparsi, RAG non aggiornati, integrazioni fragili. Il “tech debt” classico aveva un nuovo cugino, ed è più subdolo.

una sala server di un’azienda. Nei rack ordinati ci sono server etichettati con anni (1990, 2000, 2010). In un angolo, in disordine, una pila di scatole di cartone con scritto a pennarello: “PoC ChatGPT marketing 2024”, “Chatbot HR v1”, “RAG legale”, “AI ticket triage abbandonato”. Una telecamera di ragnatela copre un cartone polveroso

Cos’è il “debito tecnico-AI”

Il technical debt classico (Cunningham, 1992) è il “costo futuro” delle scelte tecniche frettolose: codice scritto male oggi, da riscrivere domani.

Il debito tecnico-AI è simile ma più sottile:

Tipo	Descrizione	Esempio tipico
Prompt debt	Prompts non versionati, sparsi, non testati	Stesso prompt copia-incollato in 47 posti diversi
Data debt	RAG/embedding non aggiornati	Knowledge base ferma a settembre 2024
Integration debt	API + middleware fragili	Una API change rompe 8 features
Model debt	Lock-in a modelli specifici	GPT-4 ritirato e tu non puoi migrare
Governance debt	Mancanza audit/logging/policy	Non sai chi ha usato cosa, quando, su quali dati
Skill debt	Team senza competenze per maintenance	Chi sapeva del progetto se n’è andato

A differenza del debito tecnico classico (che è visibile nel codebase), il debito AI è spesso invisibile finché qualcosa non si rompe. E spesso si rompe a 12-24 mesi dal go-live, quando il PoC è già scalato in produzione.

Come si accumula (la sequenza tipica)

Fase 1 (mese 1-2, “PoC eccitante”):

Team marketing lancia chatbot AI con un vendor.
Prompt scritti in Excel da un junior.
RAG popolato con un export Confluence di marzo.
Integrato in 1 endpoint via webhook.
Va live, demo al CdA, applausi.

Fase 2 (mese 3-6, “produzione”)

Si scala a 3 use case.
Si aggiungono 12 prompt variations sparsi.
2 nuove integrazioni con CRM e ticketing.
Nessun versioning, nessun test automatico.

Fase 3 (mese 9-12, “problemi iniziano”)

Cliente segnala risposta sbagliata.
Nessuno sa quale prompt è stato eseguito.
Knowledge base non aggiornata da 8 mesi.
L’AI dice ancora “Q3 2024 è il prossimo trimestre”.
Il vendor cambia API; 3 features rotte.

Fase 4 (mese 12-18, “panic mode”):

Si scopre che 5 fonti diverse generano “AI output” senza coordinamento.
Audit: dove va il dato? Domanda senza risposta.
Junior che ha fatto il PoC è uscito.
Si scopre che si paga per 4 vendor diversi che fanno cose simili.
“Cosa stiamo davvero usando?” → nessuno lo sa.

Riconoscibile?

I 6 tipi di debito, in dettaglio

1. Prompt debt

Il più diffuso. Sintomo: cerchi “prompt ChatGPT” in azienda e trovi 47 risultati. Spesso varianti diverse dello stesso prompt.

Costo:

Inconsistenza di output (modello A dice X, modello B dice Y per stessa domanda).
Impossibile A/B testare miglioramenti.
Quando cambi modello, devi rifare 47 prompt.

Mitigazione: prompt library centrale, versionata in git, testata. Tool: PromptHub, LangSmith, Helicone, o un repository interno.

2. Data debt (RAG, embedding)

Le knowledge base AI invecchiano silenziosamente.

Sintomo: l’AI cita una policy aziendale del 2023 che è stata cambiata. O afferma che il prodotto X ha una feature Y che è stata rimossa.

Costo: brutta figura con clienti, decisioni interne basate su info vecchie, possibili problemi legali.

Mitigazione: pipeline automatica di re-indexing della knowledge base. Almeno settimanale, ideale near-realtime. Monitoring “freshness” della base.

3. Integration debt

Ogni vendor AI ha cambiato API almeno una volta nel 2024-25. Cambiamenti breaking in funzioni “trovate”, deprecazione di modelli.

Sintomo: dopo un upgrade di vendor, qualche feature dell’azienda inizia a comportarsi male.

Costo: incident, downtime, fix-firefight.

Mitigazione: abstraction layer sulle chiamate AI. Test di regressione su use case core. Monitoring stretto.

4. Model debt (lock-in)

Hai scelto “GPT-4 Turbo” come modello standard. Buona scelta nel 2024. Nel 2026 è deprecato e devi migrare.

Sintomo: lettera dal vendor “questo modello non sarà più disponibile da DD/MM/YYYY”.

Costo: re-test di tutto, possibile shift di prompt strategy, downtime.

Mitigazione: multi-model architecture dove possibile. Documenta perché un modello specifico. Roadmap migrazione condivisa con vendor.

5. Governance debt

Hai 17 use case AI in produzione. Domanda: chi ha approvato l’uso di dati clienti su quale modello? Quando?

Sintomo: arriva un’ispezione, una richiesta GDPR, un audit. Caos nel produrre evidenza.

Costo: sanzioni, multe, danno reputazione.

Mitigazione: AI registry (catalogo di tutti gli use case con: owner, dati toccati, modelli, vendor, DPA, data retention). Sembra burocratico. Nel 2026 è obbligatorio per AI Act.

6. Skill debt

Il junior che ha costruito il chatbot è andato in altra azienda. Nessuno sa come funziona sotto il cofano.

Sintomo: una richiesta di modifica innesca paura. “Meglio non toccare”.

Costo: paralisi su miglioramenti, dipendenza da vendor, prezzo escalation.

Mitigazione: documentazione anche minimale ad ogni componente. Knowledge sharing periodico nel team. Mai un solo “owner segreto”.

Quanto costa il debito tecnico-AI

Difficile quantificare, ma in casi che ho visto:

Azienda	Settore	Debito AI accumulato (stima)
Bank Italian mid-tier	Finance	€3-5M di “remediation” servirà in 2026-27
Mid-size pharma	Pharma	€1-2M di technical work + 3 mesi di pause progetti
Media B2B SaaS	Tech	$500k–$1M di rebuild necessario
PMI manifatturiera	Manifattura	€100-300k (relativamente contenuto)

Tipicamente: 15-30% del valore investito nei primi 18 mesi diventa debito da pagare nei 12 successivi.

La strategia “AI lifecycle management”

Quattro pratiche per evitare di accumulare debito invece di valore:

1. AI Registry obbligatoria

Catalogo centralizzato di ogni use case AI in produzione. Campi minimi:

Nome use case
Owner (un nome di persona)
Modelli usati (con versione)
Vendor
Dati toccati (categoria)
DPA aggiornato (sì/no, data)
Costo mensile attuale
Ultima revisione

Tool: anche Excel/Notion basta. L’importante è esistere.

2. Code review per i prompt

Trattare i prompt come codice. Versionati in git. Cambiamenti richiedono PR + review. Eseguiti contro test suite prima di go-live.

Suona pesante? Lo è meno del costo di un disaster di prompt mal-versionato in produzione.

3. Sunset policy

Ogni use case AI ha una scadenza implicita: ogni 12-18 mesi va riassessment.

Domande:

Funziona ancora come previsto?
Il vendor è ancora quello giusto?
I costi sono coerenti?
Va aggiornato? Sostituito? Killato?

Senza sunset, gli use case obsoleti vivono per inerzia.

4. Owner singolo per use case

Non comitato. Una persona, nominata, accountable.

Quando vendor cambia API, quel nome è l’aletta di crisi. Quando ROI non è chiaro, quel nome difende o uccide.

Senza owner unico, ogni cosa è “responsabilità di tutti” = “responsabilità di nessuno”.

Cosa cambia per il decisore

Quando approvi un PoC AI, oltre a chiedere ROI / fattibilità / sicurezza:

✅ Chiedi anche: chi sarà il maintainer a 12 mesi? È nello stesso team che lancia? Ha capacity per fare manutenzione?

✅ Chiedi: il PoC sarà documentato come si smonta in fase di morte? (Sunset plan.)

✅ Chiedi: come si integra con la AI Registry aziendale (anche se non esiste ancora, chi la inizierà)?

Sono domande noiose ma sono quelle che separano i progetti che producono valore duraturo dai progetti che diventano costi dormienti.

TEST pratico (20 min)

Audit del debito AI della tua azienda:

Quanti use case AI sono in produzione oggi? Lista.
Per ognuno:
- Chi è il maintainer attuale (nome)?
- Quando è stato ultimo aggiornamento sostanziale (codice / prompt / KB)?
- Quale vendor dietro? Quale modello? Quale versione?
- Quando scade il DPA / la licenza?
- Quanto costa al mese?
Conta quanti hai senza maintainer dichiarato, quanti senza aggiornamento da >6 mesi, quanti senza chiarezza su modello/versione.
Se più del 30% ha gap, hai debito tecnico-AI significativo.

Azione: nei prossimi 30 giorni, chiudi il gap sui 3 use case più critici. Owner nominato, doc minimale scritta, sunset criterion stabilito.

Costa 1-2 settimane di tempo. Salva 6-12 mesi di crisi futura.

Glossario lampo

Technical debt: costo futuro di scelte tecniche frettolose oggi. Metafora di Ward Cunningham, 1992.
AI Registry: catalogo centralizzato di tutti gli use case AI in azienda. Strumento di governance.
Sunset policy: piano per la fine vita di un sistema. Pratica matura. Spesso ignorata in AI.
Abstraction layer: strato di software tra applicazione e API esterna, che isola dai cambiamenti.

Take-away in una riga

Ogni PoC AI senza maintainer, documentazione, e sunset plan diventa debito tecnico-AI invisibile. A 12-18 mesi paghi 15-30% del valore investito in remediation. La governance non è burocrazia: è risk management.

➡️ Prossima puntata: Costi reali end-to-end — token, compute, integrazione, manutenzione, governance. La bolletta che il vendor non ti mostra.