Il disegno di legge sui token non è il caso aziendale dell'IA

Ogni addetto al recupero crediti perdeva tempo prima ancora di iniziare il vero lavoro. Il compito non era solo quello di comprendere la situazione del cliente, decidere il passo successivo o portare avanti la conversazione. Prima che tutto ciò potesse accadere, qualcuno doveva aprire diversi sistemi ERP, confrontare i dati delle fatture, verificare lo stato dei pagamenti, controllare le discrepanze, riconciliare le differenze e acquisire la sicurezza necessaria per sapere cosa fosse effettivamente vero. Dall'esterno, il lavoro sembrava quello di un'attività di recupero crediti. All'interno, gran parte del lavoro consisteva nell'assemblaggio: raccogliere i frammenti, controllare i numeri e preparare il terreno prima che l'addetto al recupero crediti potesse svolgere il lavoro per cui era stato concepito.

Quel lavoro nascosto costava circa due ore al giorno a ciascun addetto al recupero crediti. Non appariva drammatico perché le persone si erano adattate. L'organizzazione aveva imparato a convivere con le difficoltà quotidiane legate al passaggio tra i sistemi, al confronto dei dati e alla preparazione delle informazioni prima di poter agire. Ma quando questo tipo di lavoro si ripete ogni giorno all'interno di un team, smette di essere un inconveniente e diventa un onere strutturale. L'automazione del confronto delle fatture tra i diversi sistemi ha permesso di recuperare circa 9.000 ore di lavoro, non sostituendo il personale o fingendo che il recupero crediti non richiedesse giudizio, ma eliminando il carico di lavoro di assemblaggio che distoglieva le persone qualificate da attività a maggior valore aggiunto.

Questo è l'aspetto che molti business case sull'IA ancora trascurano. Si concentrano troppo sui costi tecnologici visibili e non abbastanza sui costi operativi invisibili. Nell'IA, questo spesso significa guardare solo il conto dei token senza considerare i costi operativi correlati. La definizione del prezzo del modello è fondamentale. Token di input, token di output, caching, finestre di contesto, latenza, livelli di servizio del fornitore, commissioni della piattaforma e limiti di utilizzo: tutti questi elementi sono importanti. Nessuna azienda dovrebbe ignorarli. Ma non costituiscono il business case nel suo complesso. Sono solo una voce all'interno del business case, e a volte nemmeno la più importante.

La vera questione economica non è quale modello sia più economico per token. La vera questione è quale schema operativo produca il costo più basso e affidabile per risultato risolto. Questa distinzione è importante perché un token è facile da contare, mentre un risultato risolto è più difficile da quantificare. Un token si trova in una fattura. Un risultato risolto si trova all'interno di un flusso di lavoro, con tutte le revisioni, correzioni, rilavorazioni, escalation, tempi di attesa, governance, gestione delle eccezioni e giudizio umano necessari per portare effettivamente a termine il lavoro. Quando l'economia dell'IA viene misurata solo a livello di modello, il business case può sembrare semplice, mentre l'operazione rimane complessa.

Ecco come i business case dell'IA diventano troppo ottimistici. Contano la bozza ma non la riscrittura. Contano la risposta del chatbot ma non il contatto successivo. Contano la prima risposta ma non il caso riaperto. Contano l'interazione del modello ma non lo sforzo umano necessario per rendere l'output utilizzabile. Contano l'automazione visibile e ignorano le persone che, silenziosamente, proteggono il flusso di lavoro da una progettazione scadente. Non si tratta di un dettaglio finanziario. È la differenza tra l'attività dell'IA e il valore dell'IA.

Il modello a token è attraente perché offre ai leader qualcosa di concreto. Un modello è più economico. Un altro è più veloce. Uno gestisce contesti più lunghi. Un altro è migliore nel ragionamento. Uno supporta la memorizzazione nella cache. Un altro ha un costo per chiamata inferiore. Il confronto appare rigoroso perché i numeri sono chiari, ma la chiarezza al livello sbagliato può comunque trarre in inganno. Un modello economico potrebbe produrre un output che richiede più revisione, correzione e escalation. Un modello più costoso potrebbe ridurre il lavoro successivo a sufficienza da risultare più economico nella pratica. Un modello leggero potrebbe essere perfetto per una semplice classificazione ma inadeguato per la gestione di casi complessi. Una strategia di routing potrebbe essere migliore rispetto all'imporre a un unico modello di gestire ogni tipo di lavoro.

Il problema non è la contrapposizione tra economico e costoso. Il problema è l'adeguatezza al risultato. Il lavoro aziendale non termina quando l'IA genera una risposta. Il lavoro termina quando il caso è valido, accettato, controllato e non viene riassegnato all'organizzazione come rilavorazione. Se un flusso di lavoro si chiude rapidamente ma si riapre in seguito, la prima chiusura non rappresenta il risultato reale. Se una risposta viene generata velocemente ma richiede più tempo per essere convalidata da una persona, la velocità del modello non corrisponde al valore aziendale. Se un operatore instrada rapidamente il lavoro ma invia le eccezioni al responsabile sbagliato, la velocità di instradamento non è produttività. È confusione accelerata.

Ecco perché l'unità di costo è importante. Se l'organizzazione misura il costo per chiamata di modello, ottimizzerà le chiamate più economiche. Se misura il costo per risultato risolto, ottimizzerà il lavoro per ottenere risultati migliori. Questi due approcci possono portare a decisioni molto diverse. Il primo approccio riguarda la scelta dello strumento. Il secondo riguarda la gestione operativa. Nel primo caso ci si chiede quale linea di modelli sia più economica. Nel secondo caso ci si chiede se il flusso di lavoro produca un risultato affidabile senza nascondere il problema altrove.

L'esempio delle 9.000 ore è utile perché mostra quale sia spesso il costo reale prima ancora dell'introduzione dell'IA. Il costo non era racchiuso in una fattura tecnologica ordinata. Era invece insito nel carico di lavoro quotidiano di preparazione: due ore al giorno per ogni addetto alla raccolta dati, su più sistemi. Il lavoro non sembrava inefficiente perché le persone continuavano a svolgerlo. Il problema era che l'organizzazione aveva normalizzato lo spreco. Ed è esattamente ciò che accade in molti programmi di IA. La fattura del modello è visibile perché viene inviata dal fornitore. La fattura delle correzioni è nascosta perché viene assorbita dai dipendenti. La fattura delle escalation è nascosta perché viene addebitata dai manager. La fattura delle rilavorazioni è nascosta perché il reparto operativo la considera un volume di lavoro normale. La fattura della fiducia è nascosta perché i dipendenti evitano silenziosamente di utilizzare lo strumento per il lavoro che conta davvero.

La fattura è visibile, ma i costi sono distribuiti. Ecco perché i business case per l'IA devono partire dal lavoro effettivo, non dalla definizione dei prezzi tramite modelli. Qual è il costo attuale del flusso di lavoro? Quanto tempo viene impiegato per preparare, cercare, verificare, correggere, segnalare e riaprire? Cosa significa un risultato positivo? Quali passaggi sono di routine? Quali richiedono un giudizio? Quali eccezioni si ripetono? Cosa succede quando il risultato è errato? Quale revisione umana rimane, e si tratta di una supervisione pianificata o di una correzione occulta? Senza porsi queste domande, l'organizzazione potrebbe approvare un business case apparentemente perfetto, ma con un quadro dei costi incompleto.

Questo è importante perché l'IA spesso migliora la prima fase visibile prima ancora di migliorare l'intero flusso di lavoro. Scrive più velocemente, riassume più velocemente, classifica più velocemente, recupera più velocemente e genera più velocemente. Questa velocità è utile, ma non si traduce automaticamente in valore. Il valore dipende da ciò che accade dopo la comparsa del risultato. Il dipendente si fida? Il cliente lo accetta? Il caso rimane chiuso? Il flusso di lavoro evita rilavorazioni? Il risultato riduce le escalation? Migliora il controllo? Libera risorse per attività migliori? O si limita semplicemente a spostare lo sforzo in attività di verifica, correzione e spiegazione?

L'eroe operativo celebra il risparmio tangibile. L'architetto segue i costi fino a quando il risultato non è effettivamente definito. Un modello che riduce i tempi di redazione di cinque minuti sembra un'ottima soluzione finché il caso non viene riaperto. Un chatbot che gestisce più richieste sembra un'ottima soluzione finché non aumentano i contatti ripetuti. Un flusso di lavoro automatizzato sembra un'ottima soluzione finché le eccezioni non vengono segnalate ai supervisori. Un modello più economico sembra un'ottima soluzione finché la revisione umana non diventa il vero centro di costo. Non si tratta di scetticismo fine a se stesso, ma di disciplina operativa.

La stessa logica si manifesta nei piccoli dettagli. In un'altra operazione, ridurre il tempo di download delle fatture da 16 a 8 secondi potrebbe sembrare un dettaglio insignificante se considerato isolatamente. Mezzo secondo qui, qualche secondo lì, un clic in meno, un file recuperato più velocemente. I leader spesso ignorano i piccoli attriti perché non sembrano strategici. Ma ripetuti su un flusso di lavoro elevato, i piccoli attriti si accumulano. Pochi secondi moltiplicati per migliaia di transazioni diventano capacità. Un controllo manuale ripetuto ogni giorno diventa una struttura di costi. Un cambio di sistema ricorrente diventa una tassa occulta. La dimensione dell'elemento non conta tanto quanto la sua frequenza e il ruolo che svolge nel flusso di lavoro.

Anche i business case per l'IA richiedono la stessa disciplina. L'output di un modello può sembrare economico, ma se ogni output richiede una piccola correzione, e tale correzione si ripete su migliaia di casi, il costo reale cambia. Se un flusso di lavoro fa risparmiare qualche minuto ma crea un tasso di riapertura più elevato, la situazione economica cambia. Se uno strumento riduce un tipo di lavoro manuale ma aggiunge più lavoro di revisione altrove, il risparmio non è completo. È solo spostato. Il business case non dovrebbe chiedersi solo cosa l'IA elimina, ma anche cosa lascia indietro.

È qui che molti programmi diventano fragili. Presuppongono che la revisione umana sia gratuita perché le persone sono già presenti. Presuppongono che le correzioni siano temporanee perché il modello migliorerà. Presuppongono che le segnalazioni siano rare perché il campione pilota era privo di errori. Presuppongono che la governance sia un onere perché non sembra generare produttività. Presuppongono che l'adozione implichi valore perché l'utilizzo è visibile. Questi presupposti rendono il business case più facile da approvare e più difficile da difendere.

La correzione umana è una delle trappole più grandi. Viene spesso presentata come una supervisione responsabile, e a volte lo è. Esistono flussi di lavoro in cui la revisione umana è necessaria, preziosa e intenzionalmente progettata. Ma c'è una differenza tra supervisione e correzione. La supervisione protegge il lavoro. La correzione compensa una progettazione debole. Se una persona rivede l'output di un'IA perché il flusso di lavoro richiede un giudizio, questo può essere considerato una buona governance. Se una persona riscrive l'output, controlla tre sistemi, colma le lacune di contesto, identifica l'eccezione e impedisce che un'azione errata venga eseguita, questo è un lavoro nascosto. Se questo lavoro nascosto non viene misurato, il business case dell'IA è incompleto.

Lo stesso vale per l'escalation. Un certo grado di escalation è necessario, soprattutto in attività ad alto rischio, ma un'escalation evitabile ha un costo. Quando l'IA non rileva un'eccezione, instrada un caso in modo errato o genera un output di cui un dipendente in prima linea non può fidarsi, il problema viene segnalato a un supervisore, uno specialista, un manager, un team di gestione del rischio o un responsabile a contatto con il cliente. Questo tempo è più costoso, più problematico e raramente viene considerato nel confronto tra modelli. Il costo dell'IA non si limita a ciò che il modello ha consumato, ma include anche ciò che l'organizzazione ha dovuto fare per rendere il risultato utilizzabile.

Ecco perché il costo per risultato risolto è uno standard migliore del costo per token. Un risultato risolto include l'intero percorso: input, recupero, interazione con il modello, revisione umana, correzione, escalation, governance, chiusura e finestra di qualità successiva alla chiusura. Se il caso viene riaperto, significa che il risultato non è stato risolto come suggerito dalla dashboard. Un caso di assistenza clienti non è risolto solo perché il bot ha risposto una volta. È risolto quando il cliente non ha bisogno di tornare per lo stesso problema. Un flusso di lavoro finanziario non è risolto solo perché il sistema ha registrato una voce. È risolto quando la voce è valida, riconciliata e non crea correzioni a valle. Un flusso di lavoro di approvvigionamento non è risolto solo perché è stato estratto un documento. È risolto quando l'ordine può procedere con dati affidabili, una convalida corretta e eccezioni controllate.

È proprio in questo contesto che le conversazioni con i fornitori necessitano di maggiore disciplina. I fornitori possono mostrare le capacità dei modelli, le funzionalità della piattaforma, esempi di automazione e confronti di costo. Questo è utile, ma non sufficiente. L'organizzazione deve portare nella conversazione la propria realtà operativa. Altrimenti, il fornitore finisce per plasmare il business case in base a ciò che lo strumento può mostrare, non in base alle reali esigenze del lavoro. Un'azienda che non comprende chiaramente il proprio flusso di lavoro diventa un facile acquirente di soluzioni di intelligenza artificiale generiche. Sente dire che l'IA ridurrà i tempi di gestione, migliorerà la produttività, supporterà i dipendenti, automatizzerà le attività ripetitive e libererà capacità. Queste affermazioni possono essere vere, ma solo se il lavoro viene selezionato e progettato correttamente.

La questione non è se l'IA possa creare valore in generale. Può farlo. La questione è se questo intervento dell'IA crei un valore misurabile in questo flusso di lavoro, una volta calcolati tutti i costi. Per rispondere a questa domanda sono necessarie prove operative. È necessario un punto di riferimento. Quanto tempo richiede il lavoro oggi? Dove si blocca? Con quale frequenza viene corretto? Con quale frequenza viene riaperto? Quali eccezioni portano a un'escalation? Quanto impegno viene profuso nella ricerca, preparazione, confronto e convalida prima che inizi il lavoro visibile? Chi si fa carico dell'onere nascosto?

Nel caso delle 9.000 ore, il peso nascosto non era di natura filosofica. Era quotidiano e misurabile. Due ore al giorno per ogni addetto alla raccolta dati venivano assorbite dal confronto tra sistemi diversi prima che potesse iniziare il lavoro a maggior valore aggiunto. Una volta eliminato questo peso, l'attività ha guadagnato capacità senza fingere che il problema fossero le persone. Il problema non era il dipendente, ma la progettazione del lavoro. Questa lezione si applica direttamente all'intelligenza artificiale. Se il business case dell'IA si basa sulla sostituzione dello sforzo umano senza comprenderne la natura, sarà superficiale. Parte dello sforzo è uno spreco. Parte è valutazione. Parte è controllo. Parte è gestione delle eccezioni. Parte è compensazione per sistemi inefficienti. Considerare tutto ciò come un unico "tempo risparmiato" porta a decisioni sbagliate.

Un'analisi di fattibilità rigorosa permette di distinguere le diverse attività. Cosa dovrebbe scomparire? Cosa dovrebbe essere automatizzato? Cosa dovrebbe rimanere un'attività umana? Cosa dovrebbe diventare conoscenza riutilizzabile? Cosa dovrebbe innescare un'escalation? Cosa non avrebbe mai dovuto essere un onere manuale fin dall'inizio? Questa distinzione è ciò che impedisce all'IA di diventare un ulteriore livello di costosa confusione. Cambia anche il modo in cui il dipartimento finanziario dovrebbe considerare l'IA. Il CFO non dovrebbe limitarsi a chiedere quanto costa il modello. Dovrebbe chiedersi dove si concentra il valore, se il costo esce dal sistema o si sposta semplicemente, se la capacità viene effettivamente liberata, se i tassi di riapertura sono in calo, se il flusso di lavoro è più facile da gestire e se l'organizzazione sta creando conoscenza riutilizzabile o pagando di nuovo per riscoprire lo stesso lavoro l'anno prossimo.

Queste domande non sono contro l'IA. Sono a favore del valore. Proteggono l'organizzazione dalla mera apparenza. La mera apparenza dell'IA si manifesta quando l'organizzazione può indicare l'attività svolta ma non è in grado di dimostrare un miglioramento operativo. Uno strumento è attivo. Una dashboard è funzionante. Le persone lo utilizzano. Il fornitore è soddisfatto. Il programma interno sembra moderno. Ma il lavoro reale è ancora pesante. I dipendenti continuano a correggere. I manager continuano a segnalare problemi. Le eccezioni continuano a ripetersi. Il reparto finanziario continua a non riuscire a vedere chiaramente il valore. Questa non è trasformazione. È solo una mera operazione di facciata.

La strada migliore è più concreta. Partite dal costo attuale del lavoro. Includete le componenti invisibili. Calcolate la ricerca, l'assemblaggio, la verifica, la correzione, la riapertura, l'escalation e la governance. Quindi decidete dove l'IA può ridurre gli attriti in modo responsabile. Dopo l'implementazione, misurate se il risultato complessivo è migliorato, non se il primo output è apparso più velocemente. Questo è particolarmente importante man mano che le organizzazioni passano da assistenti virtuali ad agenti. Un assistente virtuale può aiutare una persona a produrre una bozza, riassumere un documento o preparare una risposta, ma l'essere umano è ancora vicino al risultato finale. Un agente può influenzare il flusso di lavoro in modo più diretto. Può instradare, aggiornare, attivare, dare priorità o eseguire. Questo cambia il costo di un errore.

Se un agente apporta più correzioni, il costo può aumentare rapidamente. Se gestisce male le eccezioni, l'escalation aumenta. Se agisce senza sufficiente tracciabilità, i costi di governance aumentano. Se i dipendenti non si fidano, l'adozione è superficiale. Se il flusso di lavoro non era pronto, l'organizzazione paga per la correzione. La fattura simbolica non lo mostrerà. Il lavoro svolto sì.

Ecco perché il business case dovrebbe essere costruito a livello di flusso di lavoro, non a livello di modello. Flussi di lavoro diversi richiedono logiche economiche diverse. Un'attività di classificazione a basso rischio e ad alto volume può giustificare un modello più economico con un campionamento umano limitato. Un'eccezione finanziaria complessa può giustificare un modello più robusto, controlli più rigorosi e una revisione umana più accurata. Un flusso di lavoro a contatto con il cliente può richiedere finestre di qualità e misurazione delle riaperture. Un flusso di lavoro sensibile alla conformità può richiedere tracciabilità e un'escalation controllata. Una strategia di modello valida per ogni tipo di lavoro raramente rappresenta la soluzione ideale. La soluzione ideale consiste nell'adattare il livello di capacità dell'IA, la supervisione umana, la governance e la tolleranza ai costi alla natura del lavoro.

Le organizzazioni globali necessitano di un'attenzione ancora maggiore. Lo stesso flusso di lavoro può avere un impatto economico diverso a seconda della regione, poiché variano il costo del lavoro, la complessità linguistica, la maturità dei processi, la regolamentazione, le aspettative dei clienti e la qualità dei dati. Un modello che appare efficiente in un mercato può comportare oneri di correzione in un altro. Un flusso di lavoro pronto per l'automazione in una regione può richiedere un maggiore intervento umano altrove. Un business case globale che ignora la realtà operativa locale apparirà chiaro nella sua struttura, ma caotico nell'esecuzione. La soluzione non è considerare ogni mercato un caso a sé stante, bensì utilizzare una logica economica comune, integrata da dati locali. La logica comune è il costo per risultato ottenuto. I dati locali spiegano cosa è necessario per raggiungere il risultato nel contesto specifico.

Lo stesso principio si applica ai dipendenti. Se viene chiesto loro di utilizzare l'IA ma vengono ancora valutati solo in base alla produttività manuale, ottimizzeranno in base al vecchio sistema di valutazione. Se viene chiesto loro di convalidare gli output ma la convalida viene considerata un ritardo, saranno spinti a lavorare più velocemente di quanto il flusso di lavoro possa supportare in sicurezza. Se viene chiesto loro di acquisire conoscenze ma viene premiata solo la chiusura dei casi, l'acquisizione di conoscenze rimarrà secondaria. Se viene chiesto loro di supervisionare gli agenti ma la supervisione degli agenti non è visibile nella pianificazione del carico di lavoro, il business case sottostimerà il lavoro umano necessario per rendere l'IA affidabile. Nemmeno il costo dei token lo mostrerà. Il sistema di valutazione delle prestazioni sì.

Ecco perché il valore dell'IA non può essere separato dalla progettazione operativa. Il modello rappresenta solo una parte del costo. La questione più importante è se l'organizzazione abbia progettato il lavoro, i ruoli, la governance e la misurazione in funzione del risultato desiderato. La lezione del caso delle 9.000 ore non è che l'automazione sia sempre la soluzione. La lezione è che il lavoro nascosto deve essere reso visibile prima di poter avanzare qualsiasi seria affermazione di valore. Una volta reso evidente l'onere di confronto nascosto, l'azienda ha potuto riprogettare il lavoro. L'IA richiede la stessa disciplina. Prima che i leader possano parlare di risparmi, devono capire quale lavoro viene eliminato, quale rimane e quale viene creato.

Altrimenti, il business case diventa troppo semplicistico. Afferma che l'IA fa risparmiare tempo, ma non tiene conto delle correzioni. Afferma che l'IA riduce i costi, ma non monitora le escalation. Afferma che l'IA migliora la produttività, ma non misura il lavoro riaperto. Afferma che l'IA supporta i dipendenti, ma non si chiede se lo strumento abbia ridotto il carico di lavoro o aggiunto un ulteriore livello di verifica. Il conto simbolico non rappresenta il business case dell'IA, perché è solo la parte più visibile del sistema. Il vero business case risiede nel lavoro. Risiede nel tempo che le persone recuperano, negli errori evitati, nella riduzione delle rilavorazioni, nel riutilizzo delle eccezioni, nel miglioramento delle decisioni, nel rafforzamento dei controlli e nella capacità riorientata verso attività che contano davvero.

I leader non devono ignorare il costo del modello. Devono comprenderlo chiaramente. Ma devono smettere di confonderlo con l'economia dell'IA. La domanda migliore non è "Quale modello è più economico?", bensì "Quale flusso di lavoro produce un risultato affidabile e risolto al giusto costo, con il giusto livello di controllo e senza nascondere l'onere altrove?". Questa domanda è più difficile, ma è anche l'unica che dice la verità.

Domande e risposte

D: Perché il progetto di legge sui token non è un caso aziendale per l'intelligenza artificiale?

A: La fattura dei token mostra solo il costo di utilizzo del modello visibile. Non include l'intero costo operativo necessario per produrre un risultato affidabile, come recupero, verifica, correzione, escalation, governance, rilavorazione, casi riaperti e tempo del personale.

D: Qual è il costo per risultato risolto?

A: Il costo per risultato risolto è il costo totale necessario per completare il lavoro correttamente e mantenerlo risolto. Include l'interazione con il modello, la revisione umana, la correzione, l'escalation, la governance e qualsiasi rilavorazione necessaria prima che il risultato sia effettivamente chiuso.

D: Un modello più economico può, nella pratica, diventare più costoso?

R: Sì. Un modello più economico può diventare più costoso se genera più correzioni, rilavorazioni, escalation o casi riaperti. Un modello più costoso può talvolta risultare più economico nel complesso se produce risultati più affidabili e riduce il lavoro nascosto ad esso correlato.

D: Quali costi nascosti dovrebbero includere i leader nei business case sull'IA?

A: I leader dovrebbero includere la correzione umana, i contatti ripetuti, i casi riaperti, l'escalation, la revisione della qualità, la governance, lo sforzo di implementazione, l'integrazione del sistema, l'infrastruttura di recupero e il tempo che i dipendenti dedicano al controllo o alla ricostruzione degli output dell'IA.

D: Come dovrebbe il settore finanziario valutare il valore dell'IA?

A: Il reparto finanziario dovrebbe guardare oltre il costo del modello e chiedersi se il flusso di lavoro è migliorato. Le domande chiave sono se i tempi di ciclo, le correzioni, le rilavorazioni, le escalation e i tassi di riapertura stanno diminuendo e se la capacità viene effettivamente liberata o semplicemente dirottata verso attività di revisione nascoste.

D: Qual è il primo passo pratico da compiere prima di approvare un business case basato sull'intelligenza artificiale?

A: Inizia mappando il costo attuale del lavoro, inclusi i costi nascosti di preparazione, ricerca, verifica, correzione e gestione dei problemi. Una volta che il costo totale è visibile, l'IA può essere valutata in base al risultato che dovrebbe migliorare, non solo in base al prezzo del modello.