Perchè un progetto AI può fallire anche se la tecnologia funziona

 

Un progetto di Intelligenza Artificiale può raggiungere ottimi risultati dal punto di vista tecnico e, allo stesso tempo, non produrre alcun impatto significativo sull’organizzazione.

Il modello risponde correttamente.
L’integrazione funziona.
Le performance sono soddisfacenti.
Il sistema viene messo a disposizione degli utenti.

Eppure, dopo alcuni mesi, viene utilizzato poco, non modifica realmente il processo oppure non genera il beneficio economico e operativo atteso.

Il problema, in questi casi, non è necessariamente l’Intelligenza Artificiale.

È la distanza tra una tecnologia che funziona e una soluzione che funziona all’interno dell’azienda.

Questa distinzione sta diventando particolarmente importante ora che l’AI entra progressivamente nei processi quotidiani e non viene più utilizzata soltanto per sperimentazioni isolate.

 

Il successo tecnico non coincide con il successo del progetto.

Quando si valuta un progetto AI è facile concentrarsi sulle prestazioni del sistema.

Quanto è accurato?
Quanto velocemente risponde?
Quanto bene interpreta i documenti?
Quanto è affidabile nel riconoscere una determinata situazione?

Sono aspetti essenziali, ma rappresentano soltanto una parte del risultato. Un progetto aziendale dovrebbe essere valutato anche attraverso altre domande:

Ha ridotto il tempo necessario per svolgere un’attività?
Ha diminuito errori o rilavorazioni?
Le persone lo utilizzano realmente?
Ha migliorato la qualità di una decisione?
Ha eliminato un collo di bottiglia?
Ha prodotto un beneficio misurabile rispetto alla situazione precedente?

Una soluzione può quindi superare tutti i test tecnici e fallire comunque come progetto aziendale.

È anche per questo che il NIST AI Risk Management Framework considera l’AI come un sistema da governare lungo l’intero ciclo di vita, collegando progettazione, utilizzo, misurazione e gestione del rischio, e non soltanto la fase di sviluppo.

 

1. È stato scelto il problema sbagliato.

Una delle cause più semplici è anche una delle più frequenti: partire dall’AI anziché dal problema.

L’organizzazione individua una tecnologia interessante e successivamente cerca un’attività sulla quale applicarla. Il percorso dovrebbe essere inverso.

Prima occorre capire dove esiste un problema sufficientemente rilevante da giustificare un intervento. Solo successivamente ha senso valutare se l’Intelligenza Artificiale sia lo strumento corretto.

Un processo lento, ad esempio, potrebbe non avere bisogno dell’AI.

Potrebbe essere sufficiente eliminare un’approvazione, integrare due sistemi, utilizzare meglio una funzionalità dell’ERP oppure correggere una regola che genera continuamente eccezioni.

Inserire l’AI in quel processo non eliminerebbe necessariamente l’inefficienza.

Potrebbe semplicemente aggiungere tecnologia sopra un problema organizzativo già esistente.

È lo stesso principio che abbiamo approfondito parlando di dove abbia realmente senso introdurre l’Intelligenza Artificiale in azienda.

 

2. Il processo non è pronto.

Anche quando il caso d’uso è corretto, il processo nel quale l’AI viene inserita potrebbe non esserlo.

Responsabilità poco definite, eccezioni continue, attività svolte fuori dal sistema e passaggi che cambiano da persona a persona rappresentano un terreno difficile per qualsiasi progetto di automazione.

L’AI non rende automaticamente ordinato ciò che è disordinato. In alcuni casi può addirittura rendere più difficile individuare il problema, perché introduce un ulteriore livello tra l’attività e la persona che la esegue. Prima di automatizzare un processo è quindi necessario comprenderlo.

Quali attività lo compongono?
Dove vengono prese le decisioni?
Quali informazioni sono necessarie?
Quali eccezioni sono realmente giustificate?
Quali passaggi esistono soltanto per abitudine?

È anche uno dei motivi per cui temi come process mining e process intelligence stanno diventando rilevanti: prima di decidere dove inserire automazione e AI è utile conoscere il comportamento reale del processo, non soltanto quello descritto sulla carta.

 

3. I dati ci sono, ma non sono sufficientemente affidabili.

Un altro errore consiste nel considerare la presenza di molti dati equivalente alla disponibilità di buoni dati.

Non è così. I dati possono essere: incompleti, duplicati, non aggiornati, distribuiti tra sistemi differenti, interpretati in modo diverso dalle varie funzioni oppure privi del contesto necessario per essere utilizzati correttamente.

Il modello può funzionare perfettamente dal punto di vista tecnico e continuare a produrre risultati poco utili perché il problema è ciò che gli viene fornito.

Questo vale in modo ancora più evidente per i sistemi generativi.

Se l’AI deve rispondere utilizzando procedure, documenti e know-how aziendale, diventa necessario stabilire quali fonti siano affidabili, quali siano aggiornate e quali informazioni possano essere utilizzate nei diversi contesti.

È una questione che riguarda direttamente anche la governance della conoscenza. AIM Bridge, ad esempio, nasce proprio dall’esigenza di rendere il know-how aziendale meno disperso e più facilmente accessibile e utilizzabile.

 

4. L’AI funziona, ma rimane fuori dal processo.

È possibile sviluppare un ottimo strumento che le persone devono però ricordarsi di aprire, interrogare e utilizzare separatamente dalle applicazioni con cui lavorano ogni giorno. In questo caso il problema non è il modello. È l’esperienza operativa.

Se per utilizzare l’AI bisogna: uscire dall’ERP, copiare informazioni, aprire un’altra applicazione, formulare manualmente una richiesta, interpretare il risultato e successivamente riportarlo nel processo, il beneficio può ridursi drasticamente.

 

5. Nessuno ha definito chi è responsabile.

Un progetto AI introduce inevitabilmente nuove responsabilità.

Chi verifica che continui a funzionare correttamente?
Chi decide quali fonti può utilizzare?
Chi interviene se la qualità delle risposte peggiora?
Chi stabilisce quando un risultato deve essere verificato da una persona?
Chi è responsabile dell’aggiornamento delle informazioni?
Chi decide quando il sistema può svolgere autonomamente un’attività?

Sono domande organizzative, non tecniche.

Il NIST struttura proprio la gestione del rischio AI intorno alle funzioni Govern, Map, Measure e Manage, mettendo la governance come elemento trasversale all’intero ciclo di vita.

Più l’AI acquisisce autonomia, più queste responsabilità devono diventare esplicite.

Non è sufficiente sapere che il sistema “funziona”. Occorre sapere chi governa il suo funzionamento nel tempo.

 

6. Le persone non sono state coinvolte.

Una delle differenze tra una demo e un progetto aziendale è che il secondo deve entrare nel modo in cui le persone lavorano.

Se chi deve utilizzare la soluzione viene coinvolto soltanto alla fine, possono emergere problemi che la fase tecnica non aveva intercettato.

Il sistema potrebbe richiedere informazioni che nella realtà non sono disponibili.

Potrebbe introdurre un passaggio che rende il lavoro più lento. Potrebbe produrre risposte corrette ma difficili da interpretare. Oppure potrebbe essere semplicemente percepito come qualcosa che si aggiunge alle attività esistenti invece di semplificarle.

L’adozione non è quindi una fase successiva al progetto. È parte del progetto.

Anche il quadro europeo sta attribuendo crescente attenzione a questo aspetto. L’AI Act prevede misure relative all’AI literacy, richiedendo alle organizzazioni che utilizzano sistemi AI di intervenire sulle competenze delle persone che li utilizzano o li gestiscono.

Non perché tutti debbano diventare esperti di machine learning. Ma perché chi utilizza l’AI deve comprendere sufficientemente cosa può fare, quali sono i suoi limiti e quando è necessario verificare il risultato.

 

7. Non è stato deciso come misurare il valore.

Un ultimo problema emerge spesso dopo il go-live.

Il sistema è disponibile. Viene utilizzato. Ma nessuno sa dire con precisione se abbia prodotto il risultato atteso.

Per evitarlo è necessario stabilire prima dell’implementazione quali indicatori verranno utilizzati.

Se l’obiettivo è ridurre il tempo necessario per recuperare informazioni, bisogna conoscere il tempo iniziale e misurare quello successivo.
Se l’obiettivo è ridurre errori, bisogna avere una baseline.
Se si vuole velocizzare un processo, serve conoscere il tempo di attraversamento precedente.
Se l’AI deve ridurre le richieste rivolte agli esperti interni, occorre poter osservare se questo avviene realmente.

La misurazione permette anche di prendere una decisione importante che spesso viene trascurata: continuare, correggere oppure interrompere il progetto.

Un sistema AI non deve essere mantenuto soltanto perché è stato sviluppato. Deve continuare a giustificare il proprio utilizzo.

 

Un progetto AI è un progetto di trasformazione, non solo tecnologico.

Quando questi elementi vengono messi insieme, emerge una conclusione abbastanza chiara.

Perché un progetto AI produca valore servono contemporaneamente:

un problema rilevante, che giustifichi l’intervento
un processo sufficientemente chiaro, nel quale inserirlo
dati e conoscenza affidabili, sui quali possa lavorare
integrazione, affinché entri realmente nel flusso operativo
governance, per stabilire responsabilità e limiti
persone preparate, che sappiano utilizzarlo correttamente
metriche, per capire se il beneficio atteso si sta realizzando

La tecnologia può funzionare perfettamente e uno solo di questi elementi può essere sufficiente a compromettere il risultato complessivo.

È proprio questa la differenza tra implementare AI e trasformare un processo attraverso l’AI.

 

Prima del modello viene il contesto.

La qualità dei modelli continuerà a migliorare. Questo renderà progressivamente meno distintiva la semplice capacità di accedere a una tecnologia molto performante.

La vera differenza sarà sempre più nella capacità dell’organizzazione di capire dove applicarla, con quali dati, dentro quale processo e con quale obiettivo.

Per questo un progetto AI dovrebbe iniziare molto prima della scelta del modello.

Dovrebbe iniziare dall’analisi della situazione esistente.

È anche il principio con cui AIM Major affronta l’introduzione dell’Intelligenza Artificiale nei processi aziendali: partire dal problema, comprendere processi, sistemi e informazioni e soltanto successivamente individuare la tecnologia più coerente con il risultato da raggiungere.

Perché il successo di un progetto AI non si misura nel momento in cui il sistema riesce a funzionare.

Si misura quando il processo in cui viene inserito funziona meglio di prima.

AIM Major affianca le aziende nell’analisi dei processi e nell’individuazione dei casi d’uso nei quali Intelligenza Artificiale, automazione e integrazione possono generare un risultato concreto.

Contattaci per valutare dove e come introdurre l’AI nei processi della tua azienda.