“Dove possiamo usare l’intelligenza artificiale?”
È una domanda che oggi compare con sempre maggiore frequenza nelle organizzazioni.
È comprensibile.
Gli strumenti sono diventati accessibili, le capacità crescono rapidamente e attività che fino a poco tempo fa richiedevano sistemi specialistici possono essere affrontate attraverso una semplice conversazione con un modello.
Scrivere.
Riassumere.
Classificare.
Cercare informazioni.
Analizzare documenti.
Generare codice.
Tradurre.
Estrarre dati.
Supportare decisioni.
Le possibilità sembrano moltiplicarsi quasi ogni settimana.
Proprio per questo, però, partire dalla tecnologia può essere fuorviante.
La domanda più corretta non è:
dove possiamo usare l’AI?
Ma è:
quale problema stiamo cercando di risolvere?
Prima del modello viene il problema. Prima dell’automazione viene la responsabilità.
Una tecnologia in cerca di un problema
Quando arriva uno strumento nuovo tendiamo naturalmente a cercargli un’applicazione.
È successo con molte tecnologie.
Con l’intelligenza artificiale il fenomeno è ancora più evidente, perché la sua versatilità permette di immaginare un utilizzo quasi ovunque.
Ed è proprio qui che nasce il rischio.
Se iniziamo dal modello, ogni attività può sembrare un possibile caso d’uso.
Un documento può essere riassunto.
Una mail può essere scritta.
Una riunione può essere trascritta.
Una tabella può essere analizzata.
Una procedura può essere interrogata.
Una presentazione può essere generata.
Ma il fatto che qualcosa possa essere fatto con l’intelligenza artificiale non ci dice ancora se sia utile farlo.
Serve conoscere il problema.
Quanto tempo richiede oggi l’attività?
Con quale frequenza viene eseguita?
Qual è il livello di qualità richiesto?
Quanto costa un eventuale errore?
Il risultato deve essere verificato?
Quali informazioni vengono utilizzate?
Sono dati riservati?
Esiste già uno strumento che svolge bene quella funzione?
L’AI migliora davvero il processo oppure aggiunge semplicemente un altro passaggio?
Solo dopo queste domande la tecnologia inizia ad avere un contesto.
Un caso d’uso non è una funzionalità
Dire che un modello può “riassumere documenti” descrive una capacità.
Non ancora un caso d’uso.
Un vero caso d’uso è molto più specifico.
Chi deve leggere quei documenti?
Per quale ragione?
Quanto sono lunghi?
Quali informazioni servono?
Il riepilogo deve essere completo oppure deve evidenziare soltanto alcuni elementi?
Cosa accade se viene omesso un dettaglio importante?
Qualcuno controllerà il risultato?
Quanto tempo si risparmia rispetto alla modalità attuale?
La differenza può sembrare sottile, ma cambia completamente il modo di progettare la soluzione.
La funzionalità appartiene alla tecnologia. Il caso d’uso appartiene al processo.
È nel secondo che possiamo capire se l’intelligenza artificiale produce realmente un miglioramento.
Partire dall’attività reale
Un buon punto di partenza consiste nell’osservare il lavoro così come avviene oggi.
Non chiedere immediatamente dove inserire l’AI.
Chiedere invece dove esistano attività che presentano caratteristiche interessanti.
Per esempio:
- grandi quantità di informazioni da leggere;
- testi ripetitivi da produrre;
- classificazioni che assorbono molto tempo;
- ricerca di informazioni distribuite tra molti documenti;
- confronti tra versioni;
- estrazione di dati da contenuti non strutturati;
- attività nelle quali una prima bozza accelera il lavoro;
- processi in cui l’utente deve consultare molta conoscenza prima di prendere una decisione.
Questo non significa che tutte queste attività debbano essere automatizzate.
Significa che rappresentano punti nei quali vale la pena approfondire.
La differenza è importante.
L’obiettivo non è trovare un posto per l’AI.
È trovare un problema nel quale le sue caratteristiche possano essere realmente utili.
Il tempo risparmiato non è l’unico valore
Molte valutazioni sull’intelligenza artificiale partono dalla produttività.
Quanto tempo possiamo risparmiare?
È una domanda importante.
Ma non è l’unica.
Una tecnologia può essere utile anche se permette di:
- ridurre errori;
- trovare più facilmente un’informazione;
- rendere accessibile una conoscenza dispersa;
- migliorare la qualità di una prima analisi;
- rendere più uniforme un’attività ripetitiva;
- aiutare una persona a considerare elementi che avrebbe potuto trascurare;
- ridurre il carico cognitivo;
- dedicare più attenzione alle decisioni che richiedono esperienza.
Immaginiamo un’attività che richieda trenta minuti e che, grazie all’AI, continui a richiederne quasi altrettanti.
Potrebbe sembrare un fallimento.
Ma se quei trenta minuti passano dalla ricerca manuale delle informazioni alla loro verifica e interpretazione, il risultato può essere comunque molto interessante.
Non abbiamo necessariamente risparmiato tempo.
Abbiamo spostato il tempo verso un’attività a maggior valore cognitivo.
È un modo diverso di valutare l’utilità.
L’AI non elimina automaticamente il lavoro
Una delle semplificazioni più diffuse consiste nell’immaginare l’intelligenza artificiale esclusivamente come sostituzione di attività umane.
In molti casi la trasformazione più interessante è invece un’altra.
La persona continua a svolgere l’attività, ma dispone di uno strumento capace di preparare, organizzare o interpretare una parte delle informazioni.
Il modello può produrre una prima bozza.
La persona la rivede.
Può estrarre informazioni.
La persona verifica quelle rilevanti.
Può suggerire una classificazione.
La persona conferma o corregge.
Può individuare elementi all’interno di un documento.
La persona interpreta le conseguenze.
In questi casi non stiamo scegliendo tra uomo e macchina.
Stiamo ridisegnando la distribuzione del lavoro tra i due.
E questa progettazione è spesso più importante della scelta del modello.
Human in the loop non è una formula
L’espressione “human in the loop” viene utilizzata molto spesso.
Rischia però di diventare una rassicurazione generica.
“Ci sarà comunque un controllo umano.”
Ma quale controllo?
In quale momento?
Su cosa?
Con quali informazioni?
Con quale responsabilità?
Se un sistema genera cento risultati e una persona deve verificarli tutti parola per parola, forse l’automazione ha prodotto meno beneficio di quanto sembrasse.
Se invece il modello segnala chiaramente i punti che richiedono attenzione e permette alla persona di concentrarsi sulle eccezioni, il rapporto cambia.
Il controllo umano deve quindi essere progettato.
Non semplicemente dichiarato.
Tenere una persona nel processo ha senso soltanto se è chiaro cosa debba controllare e perché.
L’affidabilità dipende dal contesto
Chiedere se un modello sia “affidabile” in assoluto serve a poco.
L’affidabilità necessaria dipende dall’attività.
Un errore in una bozza interna può essere facilmente corretto.
Un errore in un’informazione utilizzata per una decisione importante può avere conseguenze completamente diverse.
Una classificazione imprecisa può essere accettabile se serve soltanto a suggerire una priorità.
Può essere inaccettabile se determina automaticamente un esito.
Un riepilogo può essere utile per orientarsi in un documento.
Può essere insufficiente quando è necessario conoscere ogni dettaglio.
La stessa tecnologia può quindi essere perfettamente adeguata in un caso e inadatta in un altro.
La domanda non è:
quanto è affidabile l’AI?
La domanda è:
quanto deve essere affidabile questo risultato per poter essere utilizzato in questo punto del processo?
È una differenza enorme.
Gli errori non sono tutti uguali
Quando valutiamo una soluzione AI tendiamo a parlare genericamente di accuratezza.
Ma un errore non vale necessariamente quanto un altro.
Possiamo distinguere almeno concettualmente tra errori:
- immediatamente visibili;
- facilmente correggibili;
- difficili da individuare;
- privi di conseguenze rilevanti;
- capaci di propagarsi nel processo;
- potenzialmente critici.
Un testo scritto male viene probabilmente riconosciuto.
Un numero plausibile ma errato all’interno di un’analisi può essere molto più insidioso.
Una risposta incompleta a una domanda generale può essere accettabile.
La stessa omissione in un’attività di verifica potrebbe non esserlo.
Per questo un buon caso d’uso non considera soltanto la frequenza dell’errore.
Considera la natura dell’errore e cosa accade dopo.
Il dato che entra nel modello conta quanto il modello
L’attenzione pubblica si concentra spesso sui modelli.
Quale usare?
Quanto è potente?
Quanti parametri possiede?
Qual è il benchmark migliore?
Nelle applicazioni organizzative, però, un’altra domanda può essere ancora più importante:
su quali informazioni deve lavorare?
Se chiediamo a un assistente di rispondere sulla base della conoscenza aziendale, il problema non riguarda soltanto l’AI.
Riguarda anche la qualità della conoscenza.
I documenti sono aggiornati?
Esistono versioni duplicate?
Le informazioni sono strutturate?
Le fonti sono affidabili?
I permessi sono coerenti?
È possibile capire da dove provenga una risposta?
Se la base informativa è confusa, l’intelligenza artificiale non la rende automaticamente ordinata.
Può persino rendere quella confusione più facile da interrogare e, quindi, più difficile da riconoscere.
Un modello sofisticato non corregge una conoscenza organizzativa mal gestita.
È uno dei motivi per cui AI, knowledge management e governance dell’informazione sono molto più vicini di quanto possano sembrare.
La risposta deve poter essere verificata
Per molti casi d’uso organizzativi, uno degli elementi più importanti non è soltanto la qualità della risposta.
È la possibilità di verificarla.
Se un assistente restituisce un’informazione tratta da documenti interni, poter risalire alla fonte cambia completamente l’esperienza.
La persona può controllare.
Può interpretare il contesto.
Può accorgersi che il documento è superato.
Può distinguere un fatto da una sintesi prodotta dal modello.
La trasparenza diventa quindi parte dell’utilità.
Non perché ogni utente debba comprendere il funzionamento tecnico del modello.
Ma perché deve poter comprendere su cosa si basa il risultato che sta utilizzando.
La semplicità dell’interfaccia può nascondere il rischio
Uno degli aspetti più affascinanti dell’AI generativa è la semplicità dell’interazione.
Scriviamo una domanda.
Riceviamo una risposta.
Questa naturalezza è uno dei motivi del suo successo.
Ma crea anche un effetto particolare.
Un sistema estremamente complesso può sembrare semplice quanto una conversazione.
E quando qualcosa appare semplice da utilizzare, tendiamo facilmente a considerarlo semplice anche da governare.
Non lo è.
Dietro quella finestra possono esistere problemi relativi a:
- riservatezza;
- autorizzazioni;
- qualità delle fonti;
- trattamento dei dati;
- sicurezza;
- affidabilità;
- proprietà delle informazioni;
- conservazione;
- responsabilità.
La buona esperienza utente deve nascondere la complessità operativa.
La buona governance, invece, deve continuare a vederla.
Una demo convincente non è ancora un progetto
Con l’intelligenza artificiale è relativamente facile costruire dimostrazioni impressionanti.
Prendiamo alcuni documenti.
Facciamo una domanda.
Otteniamo una risposta in pochi secondi.
Il confronto con la ricerca manuale sembra immediatamente favorevole.
Ma una demo risponde principalmente a una domanda:
questa cosa è tecnicamente possibile?
Un progetto deve rispondere a molte altre.
Funziona su tutti i documenti rilevanti?
Come vengono aggiornate le fonti?
Chi può accedere a cosa?
Come gestiamo un risultato sbagliato?
Chi è responsabile della verifica?
Quale processo viene modificato?
Quanto tempo viene realmente risparmiato?
Cosa succede quando il modello non sa rispondere?
Come misuriamo la qualità?
Quanto costa utilizzare la soluzione su scala reale?
Come cambia il lavoro delle persone?
È in questo passaggio che l’innovazione smette di essere una dimostrazione tecnologica e diventa progettazione organizzativa.
Il progetto pilota deve poter fallire
Una sperimentazione ha valore anche quando dimostra che un’idea non funziona abbastanza bene.
Può sembrare paradossale.
Ma un progetto pilota serve proprio a ridurre l’incertezza prima di una decisione più grande.
Se il risultato atteso è già considerato obbligatoriamente positivo, non stiamo sperimentando.
Stiamo cercando una conferma.
Un buon pilota dovrebbe partire da ipotesi chiare.
Per esempio:
- il modello ridurrà il tempo necessario per una determinata attività;
- gli utenti riusciranno a trovare più rapidamente le informazioni;
- la qualità della prima bozza sarà sufficiente a rendere vantaggiosa la revisione;
- il numero di errori resterà entro un limite accettabile;
- la soluzione gestirà correttamente una percentuale significativa dei casi.
Alla fine possiamo scoprire che l’ipotesi era sbagliata.
È un risultato.
Abbiamo imparato qualcosa prima di trasformare una possibilità tecnologica in un sistema più grande, costoso e difficile da cambiare.
Non automatizzare la responsabilità per errore
Esiste una differenza fondamentale tra automatizzare un’attività e trasferire una decisione.
Un modello può raccogliere informazioni utili a una persona che deve decidere.
Può evidenziare anomalie.
Può suggerire alternative.
Può classificare.
Può produrre una raccomandazione.
Ma nel momento in cui quella raccomandazione produce automaticamente una conseguenza, il problema cambia.
Dobbiamo sapere:
chi è responsabile?
quale livello di errore è accettabile?
come viene contestata una decisione?
quali elementi può vedere chi deve verificarla?
come vengono gestite le eccezioni?
La disponibilità di un modello capace di eseguire un compito non dovrebbe determinare automaticamente il livello di autonomia che gli concediamo.
La capacità tecnica e l’autorità decisionale sono due cose diverse.
Anche non usare l’AI può essere una buona decisione
In questo momento esiste una pressione naturale verso l’adozione.
Le organizzazioni non vogliono restare indietro.
I team vogliono sperimentare.
I fornitori presentano continuamente nuove soluzioni.
Gli utenti iniziano a utilizzare autonomamente strumenti disponibili sul mercato.
È giusto esplorare.
Ma l’esplorazione dovrebbe permettere anche una conclusione molto semplice:
qui l’AI non serve.
Forse il processo è già efficiente.
Forse una regola deterministica garantisce risultati migliori.
Forse l’integrazione tra due sistemi risolve il problema in modo più affidabile.
Forse bastava organizzare meglio le informazioni.
Forse l’attività è così rara che automatizzarla non produce alcun beneficio significativo.
Scegliere di non utilizzare una tecnologia non significa essere poco innovativi.
Può significare averla valutata correttamente.
Innovazione non è utilizzare la tecnologia più nuova. È scegliere quella più utile al problema.
Dal modello al sistema
Quando un caso d’uso supera la sperimentazione, il modello diventa soltanto una parte della soluzione.
Servono informazioni.
Regole.
Permessi.
Interfacce.
Logging.
Monitoraggio.
Feedback.
Processi di verifica.
Gestione delle eccezioni.
Responsabilità.
Formazione.
Integrazione con gli strumenti esistenti.
A quel punto appare evidente un principio che durante le prime demo può essere facile dimenticare:
l’AI non è il sistema. È una componente del sistema.
E il valore finale dipende da come tutte le altre componenti vengono progettate intorno a essa.
La domanda giusta cambia il progetto
“Dove possiamo usare l’AI?” parte dalla tecnologia.
“Quale problema possiamo risolvere meglio?” parte dall’organizzazione.
La differenza sembra piccola.
Ma porta in direzioni molto diverse.
Nel primo caso rischiamo di costruire un catalogo di possibilità.
Nel secondo possiamo costruire una priorità.
Quale attività crea più attrito?
Dove perdiamo più tempo?
Quale informazione è difficile da trovare?
Quale decisione richiede una quantità eccessiva di lavoro preparatorio?
Quale compito ripetitivo sottrae attenzione ad attività più importanti?
A quel punto possiamo chiederci se l’intelligenza artificiale sia lo strumento adatto.
Forse sì.
Forse no.
Ed è proprio questa libertà di risposta a rendere la domanda utile.
Perché l’obiettivo non è dimostrare che possiamo usare l’AI.
È capire dove può migliorare davvero il modo in cui lavoriamo.
artificial intelligenceintelligenza artificialegenerative AIinnovazioneprocessiautomazionecasi d'usohuman in the loopadozione digitale