Quasi tutti i progetti AI che vedo nelle aziende sono costruiti su presupposti completamente errati.
Il disegno lo spiega benissimo: l’AI immaginata da un board è una grande scatola magica dove ci butti dentro i dati, lei li processa, e ne esce valore.
Peccato non sia quello che succede per davvero, e la scatola magica in realtà contenga millemila partizioni e complessità senza le quali il dato fatica ad essere processato: se sei fortunato ne escono dati validi ma il costo di processo in token è esagerato, se sei sfortunato ne esce nonsense.
È così perché l’elaborazione e la sua qualità dipendono dalla struttura dei dati che dai in pasto alla macchina. Niente struttura corretta, niente elaborazione.
Questo era vero anche ai tempi dei sistemi esperti e della BI con data visualization, che a dirla così sembra che io stia parlando di qualcosa successo negli anni novanta, e invece era il mondo di non più di quattro anni fa.
Peraltro il paradosso è che con la generativa la situazione si complica perché la parte elaborativa (scelta del modello, addestramento e tuning) oggi la compri a consumo, ed era la parte che faceva più paura, quindi oggi tutti pensano che il grosso sia stato fatto.
Peccato sia rimasto fuori tutto il resto: ovvero ciò che avrebbe dovuto veramente far paura: tutta la struttura del dato la dobbiamo comunque costruire e in più si sono aggiunti i problemi specifici della generativa: sicurezza, compliance legal e privacy, protezione degli aspetti di proprietà intellettuale, e infine etica e osservabilità deterministica di processo e risultati.
L’Esempio che Convince Sempre
Faccio un esempio con un caso e-commerce: immaginatene uno con un programma fedeltà omnicanale (negozio fisico e online). Mettete un agente AI in customer care e fate arrivare una cliente che chiede quanti punti ha. Se nel CRM quella cliente esiste due volte perché il dato non è deduplicato, oppure se ci sono sincronie notturne tra l’attività della rete commerciale e la base dati dove opera l’agente, quello le comunicherà con grande sicurezza il saldo sbagliato.
Il modello ha fatto benissimo il suo lavoro. Il danno nasce nella pulizia dei dati e dalla loro sincronicità, che magari nessuno aveva messo a budget.
Perché i Pilot Muoiono
Ecco perché i pilota AI spesso muoiono di morte precoce oppure si arenano in mancanza di adoption reale. Il problema emerge solo quando qualcuno va a spulciare nei dati e si accorge di idiosincrasie e limitazioni della macchina rispetto al caso d’uso ideale presentato in board sei mesi prima.
Se dovessi rifare da zero il budget di un progetto AI partirei dal fondo del disegno e lascerei il modello per ultimo, perché è l’unica voce che il mercato continua a rendere più economica. Su qualità del dato e sincronia near real-time invece no: li sarei preciso al limite dell’ossessivo compulsivo.
E la stessa cosa dovreste fare anche voi.
Nel vostro ultimo progetto AI, quale pezzo di progetto non era a budget ma avrebbe dovuto esserlo?