Quando non automatizzare
In ogni progetto di AI arriva il momento in cui qualcuno chiede perché il sistema abbia ancora bisogno di una persona. Di solito è la domanda più importante della riunione, e quasi sempre le si risponde troppo in fretta.
Tempo fa abbiamo costruito una piattaforma di supporto per un'azienda di utility. La forma era ordinaria: assistenti interni e verso il cliente sopra un layer di retrieval, collegati direttamente alla casella di supporto, con una bozza di risposta preparata per ogni richiesta in arrivo. La parte interessante è dove ci siamo fermati.
L'operatore resta l'ultimo passo. Legge la bozza, la valuta con un pollice e una riga di testo libero, la corregge e la invia. Le valutazioni alimentano una dashboard. E il continuous learning — la mossa successiva ovvia, quella che ogni presentazione commerciale mette a slide quattro — è stato deliberatamente escluso.
Il vincolo non era tecnico
Il cliente non voleva che la base di conoscenza venisse rimodellata implicitamente da chiunque si trovasse al supporto quella settimana. La voleva possedere: sapere cosa c'è dentro, chi ce l'ha messo e quando. Non è prudenza verso l'AI. È una posizione del tutto ragionevole su chi risponde di quello che l'azienda dice ai propri clienti.
Si poteva discutere. Ci sono buoni controargomenti — revisione umana, promozione a stadi, versionamento della conoscenza, rollback. Li ho usati tutti, in passato. Ma la lettura onesta di quella stanza era che la discussione sarebbe costata più fiducia di quanto valesse la funzionalità, e che un sistema consegnato senza sarebbe stato usato ogni giorno, mentre uno consegnato con sarebbe rimasto dietro un processo di revisione che nessuno aveva il tempo di eseguire.
Un sistema autonomo che nessuno accende vale zero. Uno assistito, usato ogni giorno, vale tutto.
Cosa si perde e cosa si guadagna
Senza continuous learning il sistema migliora a lotti invece che in continuo. Qualcuno deve guardare la dashboard, leggere le bozze valutate male e decidere cosa cambiare nella base di conoscenza. È lavoro vero, ed è più lento.
Quello che si guadagna è un sistema di cui l'organizzazione si fida davvero, una base di conoscenza che resta leggibile a chi ne risponde, e un segnale di feedback onesto — perché gli operatori valutano liberamente quando le loro valutazioni non stanno riscrivendo in silenzio la fonte di verità alle loro spalle.
Il pattern, generalizzato
La domanda interessante non è mai stata cosa sa fare il modello. È quanto ne regge un'organizzazione. E la capacità di assorbimento dipende da fiducia, regolamentazione, responsabilità e abitudini: nessuna di queste si muove alla velocità della tecnologia.
Quindi la mossa utile, quando si incontra un vincolo del genere, è chiedersi se sia un fraintendimento da correggere o una posizione attorno a cui progettare. I fraintendimenti valgono un'ora di spiegazione. Le posizioni valgono un'architettura.
In pratica oggi parto sempre da assistito prima che autonomo, e tengo l'umano all'ultimo passo finché non ci sono prove — misurate, non affermate — che toglierlo sia sicuro. Non perché sia prudente sull'AI. Perché è così che finisce per essere usata davvero.