Quando l’IA è corretta e il processo è sbagliato

Immagina uno scenario comune nei servizi finanziari. Un team utilizza l’IA per esaminare i contratti: centinaia di pagine, clausole ripetitive e lavoro di routine che normalmente richiede giorni di lavoro per gli impiegati. Il modello identifica i rischi e le referenze ai paragrafi corretti. Eppure, il risultato non è quello atteso.

Si scopre che il problema è nella cartella dei contratti, dove i file sono denominati contract_v1.docx, contract_v2.docx, contract_final.docx, contract_final2.docx e contract_finalfinal_THIS_ONE.docx.

L’IA ha selezionato l’ultimo file salvato. Ma quel file era una versione più vecchia che qualcuno aveva aperto e salvato automaticamente la settimana precedente.

Il modello ha fatto esattamente ciò per cui era stato progettato. Il processo, tuttavia, lo ha deluso.

Quando il modello non è il problema

Nel mio articolo precedente, ho sostenuto che i fallimenti dell’IA spesso iniziano al di fuori del modello – nelle strutture di governance, proprietà e decisione che lo circondano. Ma la governance è solo una parte del problema. Anche un sistema di IA ben governato avrà difficoltà se il processo su cui si basa dipende da documenti obsoleti, eccezioni informali o percorsi di approvazione progettati per un ritmo di lavoro molto più lento.

Quando un sistema di IA produce un risultato scadente, il modello è solitamente il primo sospettato. Forse ha hallucinato, frainteso il compito o ricevuto un prompt debole. Ma a volte il modello ha fatto esattamente ciò che doveva fare. Il fallimento si è verificato nel processo che ha fornito le informazioni o nell’organizzazione che non poteva agire sul suo output.

La distribuzione dell’IA rivela problemi di processo che esistevano sempre ma non erano mai visibili – come uno strumento di diagnostica. Esso espone debolezze che le persone avevano precedentemente compensato senza pensare: contesto mancante, proprietà non chiara e soluzioni informali che non erano mai state documentate.

Velocità senza capacità

L’IA non accelera solo l’output. Accelerà anche le escalation, le richieste di decisione e la scoperta dei problemi. Un modello segnala un’anomalia in tempo reale, non il venerdì pomeriggio quando qualcuno finalmente trova il tempo di esaminare i log.

Le organizzazioni non sono pronte per questo ritmo. I processi di approvazione, i percorsi di escalation, l’autorità decisionale – tutto ciò è stato calibrato per la velocità umana. Quando l’IA produce output più velocemente di quanto l’organizzazione possa assorbirli, possono verificarsi tre cose:

• L’IA attende una decisione, cancellando il guadagno di efficienza.
• Gli impiegati ignorano il suo output e tornano a ciò che credono funzioni – il vecchio processo.
• Gli impiegati spingono le decisioni in avanti senza verificarle adeguatamente perché si sentono sotto pressione per mantenere la velocità promessa dalla tecnologia.

Alcuni impiegati tornano ai controlli manuali perché si sentono più sicuri. Altri approvano i risultati senza averli verificati perché si sentono sotto pressione per mantenere la velocità promessa dalla tecnologia. In entrambi i casi, l’organizzazione paga per un output più veloce senza diventare più veloce nel prendere decisioni responsabili.

La proprietà può anche diventare confusa. Chi è responsabile per la revisione di un’anomalia segnalata, decidere se il modello è sbagliato ed escalare il problema quando sono coinvolti più team? Senza una risposta chiara, l’IA continua a funzionare in background, producendo output che nessuno possiede veramente.

Ciò riflette un problema organizzativo più ampio. Come ha osservato un’analisi di Forbes alla fine del 2025, quando la tecnologia cambia i flussi di lavoro più velocemente di quanto un’organizzazione possa assorbirli, il risultato non è l’efficienza; è il sovraccarico di lavoro. L’IA può accelerare una fase del processo, ma il suo valore dipende ancora dalla capacità dell’organizzazione di assorbire e agire su ciò che produce.

La conoscenza silenziosa che nessuno ha scritto

Immagina che Martin sappia che il contratto della società con un fornitore include un’eccezione per i pagamenti inferiori a 2.000 euro. È stato concordato verbalmente tre anni fa ma non è stato documentato. Quando la società distribuisce l’IA per automatizzare le approvazioni dei pagamenti, il sistema blocca il pagamento – correttamente, secondo il contratto scritto.

Questo è il sapere tacito: la conoscenza organizzativa che vive nella testa delle persone piuttosto che nei sistemi. Ogni azienda ne ha. E la maggior parte delle aziende non ha idea di quanto ne abbiano.

L’IA può utilizzare solo la conoscenza che le è stata resa accessibile. L’eccezione di Martin non esiste dal punto di vista del sistema. Senza quel contesto, la sua decisione può essere tecnicamente corretta ma operativamente sbagliata.

La McKinsey ha identificato la stessa sfida nelle distribuzioni di IA agente. La costruzione di agenti di IA efficaci richiede alle aziende di codificare le pratiche degli esperti che possono esistere in procedure standard – o solo come conoscenza tacita nella testa degli impiegati. In altre parole: la distribuzione dell’IA può quindi essere la prima volta che un’azienda vede quanto il processo dipenda da ciò che sa Martin.

La fonte di verità falsa

L’output dell’IA più pericoloso non è sempre quello palesemente errato. Può essere una risposta credibile, presentata in modo professionale, prodotta da informazioni obsolete.

Per anni, molti dipartimenti hanno operato con più versioni dello stesso documento perché Jane del dipartimento legale sa sempre quale sia quello autoritativo. L’IA, purtroppo, non lo sa.

A meno che non le siano state date regole per distinguere tra le versioni, il sistema non ha motivo di mettere in discussione il documento che riceve. E così l’IA esegue la revisione correttamente – sul documento sbagliato. Ciò può essere peggiore di nessuna revisione perché l’output sembra credibile.

Un impiegato esperto può sapere dove si trova la verità e può navigare attraverso il caos. Un sistema, tuttavia, necessita di un metodo affidabile per identificare quale informazione è attuale, approvata e rilevante.

La conoscenza tacita, i documenti non affidabili e i processi di approvazione costruiti per la velocità umana sembrano essere problemi separati. Ma condividono la stessa causa radice. Nessuno di loro è stato creato dall’IA, ma l’IA li rende più difficili da ignorare.

Domande da rispondere prima di costruire un agente

Prima di distribuire un agente di IA, un’organizzazione dovrebbe essere in grado di rispondere a tre domande.

Quali decisioni dipendono dalla conoscenza che non è mai stata documentata?

Ciò significa identificare le eccezioni, le scorciatoie e le decisioni che gli impiegati esperti applicano senza descriverle consapevolmente. Le interviste sole potrebbero non rivelare tutta questa conoscenza. Le organizzazioni potrebbero dover osservare come il lavoro viene effettivamente eseguito e confrontarlo con il processo ufficiale.

Come il sistema identificherà le informazioni attuali, approvate e rilevanti?

Fornire all’agente l’accesso a più documenti non risolve il problema se non può distinguere un contratto approvato da una bozza o una politica attiva da una obsoleta. La versione, la proprietà, lo stato di approvazione e le regole di conservazione devono essere chiare abbastanza perché il sistema possa identificare quale fonte dovrebbe governare la sua decisione.

Possono i processi di approvazione e escalation esistenti assorbire il volume e la velocità del suo output?

I team dovrebbero stimare non solo quanto lavoro l’agente possa completare, ma anche quanti controlli, eccezioni e escalation quel lavoro potrebbe creare. Il quadro di gestione del rischio dell’IA della NIST raccomanda di definire chiaramente i ruoli e le responsabilità per la supervisione umana dei sistemi di IA. Questi devono essere progettati per il volume previsto prima del deploy del sistema – non dopo che gli impiegati sono stati sopraffatti da esso.

Queste non sono domande da rispondere una volta e dimenticare. I processi cambiano, i documenti invecchiano e le eccezioni non documentate si accumulano di nuovo. La prontezza quindi deve essere mantenuta, non solo stabilita prima del lancio.

L’IA pronta inizia con il processo

La prontezza per l’IA non è solo una prova della tecnologia. È una prova di quanto l’organizzazione abbia reso i propri processi sufficientemente espliciti perché la tecnologia possa operare all’interno di essi.

Preparare un’organizzazione per l’IA richiede quindi più che selezionare un modello o costruire un agente. Significa chiarire la proprietà, identificare le informazioni autoritative, documentare le eccezioni e ridisegnare come gli output vengono esaminati, escalati e attuati.

Questo è un lavoro difficile, ma un deploy fallito costringerà comunque l’organizzazione a farlo. L’unica variabile è il momento.