Negli ultimi due anni quasi ogni organizzazione con cui ci confrontiamo ha visto almeno una dimostrazione di intelligenza artificiale generativa. Molte ne hanno commissionata una interna. Poche hanno oggi un sistema realmente in produzione, usato ogni giorno da chi lavora nei processi.
Raramente è una questione di budget. Quasi mai è una questione di modello. È una questione di che cosa viene chiesto al sistema nel momento in cui smette di essere una prova.
Che cosa rende facile una demo
Una demo lavora in condizioni scelte.
I documenti sono selezionati: leggibili, aggiornati, coerenti tra loro. Le domande sono quelle a cui il sistema sa rispondere, perché sono state provate prima. Non ci sono permessi da rispettare, perché nessuno sta accedendo a dati reali di cittadini, clienti o dipendenti.
Soprattutto, nessuno deve rispondere di un errore. Se la demo sbaglia, si riformula la domanda e si va avanti.
Questo non rende le demo inutili. Servono a verificare che una direzione tecnica sia percorribile e a costruire consenso interno. Il problema nasce quando vengono lette come una stima del lavoro necessario.
Che cosa serve in produzione
Passando in produzione cambiano cinque cose insieme.
I dati diventano quelli reali: scansioni storiche, versioni multiple dello stesso documento, formati disomogenei, allegati che nessuno ha mai classificato.
I permessi diventano vincolanti. Un sistema che risponde non può mostrare a un utente un contenuto che quell’utente non avrebbe potuto aprire nel repository di origine.
Serve tracciabilità. Quale fonte ha generato quella risposta, chi ha eseguito quell’azione, in quale momento e con quale esito.
Il carico diventa continuo: non una sessione dimostrativa, ma interrogazioni distribuite lungo la giornata, con tempi di risposta che devono restare accettabili anche nei picchi.
E serve manutenzione. I documenti cambiano, le procedure cambiano, i modelli vengono aggiornati o dismessi dai fornitori.
I quattro punti dove i progetti si fermano
Nella nostra esperienza i progetti che non superano la fase pilota si bloccano quasi sempre su uno di questi quattro punti.
1. La qualità della base documentale. Un archivio con duplicati, versioni non allineate e scansioni di bassa qualità produce risposte incoerenti anche con il modello migliore disponibile. La verifica non è un dettaglio tecnico: è la prima attività di progetto. In un ente che gestisce pratiche, per esempio, la stessa circolare può esistere in tre versioni in tre cartelle diverse, e nessuna delle tre porta in evidenza quale sia quella vigente.
2. L’integrazione con i sistemi già in uso. Un assistente che non legge dal protocollo, dall’ERP o dal gestionale di pratica costringe le persone a un doppio lavoro. Il valore non nasce dalla conversazione: nasce dal fatto che il sistema vede gli stessi dati che vede l’operatore. È qui che il progetto incontra i temi meno visibili e più costosi: API disponibili o assenti, gestione dei permessi, allineamento delle anagrafiche.
3. La responsabilità interna. Un sistema in produzione ha bisogno di qualcuno che ne risponda: chi approva le modifiche, chi verifica gli output, chi decide quando fermarlo. Quando il progetto resta un’iniziativa senza un titolare operativo, sopravvive finché dura l’attenzione della direzione. Poi si spegne.
4. L’assenza di indicatori. Senza una misura definita prima dell’avvio, la valutazione del sistema diventa un’impressione. E l’impressione di chi ha visto la demo è diversa da quella di chi usa lo strumento ogni giorno su casi difficili. Tempo medio di lavorazione, percentuale di casi gestiti senza rilavorazione, riduzione degli errori di completezza: sono numeri che vanno concordati all’inizio, quando è ancora possibile misurare la situazione di partenza.
Come si imposta un progetto perché arrivi in produzione
Non esiste una scorciatoia, ma esiste una sequenza che riduce il rischio.
Si parte da un dominio documentale ristretto e ben governato. Una tipologia di pratica, una famiglia di prodotto, un corpus normativo. Un perimetro piccolo permette di verificare l’accuratezza su casi reali e di correggere l’impostazione quando costa poco.
Si definiscono gli indicatori prima di sviluppare. Se non è possibile dire quale numero dovrà migliorare, il progetto non è ancora pronto per partire.
Si progettano i punti di arresto insieme alle funzionalità. Dove il sistema deve chiedere conferma, quando deve dichiarare di non sapere, quali azioni restano esclusivamente umane. Questi vincoli non sono un limite del sistema: sono ciò che lo rende utilizzabile in un contesto con responsabilità formali.
Si rilascia per fasi, partendo da un caso a basso rischio, e si estende solo dopo la validazione degli operatori.
E si tratta la formazione come parte del progetto. Chi usa il sistema deve conoscerne i limiti quanto le capacità, altrimenti il primo errore diventa una ragione per abbandonarlo.
Che cosa questo approccio non risolve
Un percorso strutturato non elimina i problemi organizzativi.
Se l’archivio documentale è privo di governo, l’AI lo renderà evidente, non lo risolverà. Se due uffici non concordano su quale sia la procedura corretta, nessun sistema deciderà al loro posto. Se non esiste un titolare interno, il progetto resterà una sperimentazione anche se tecnicamente riuscito.
Vale anche il contrario: alcuni processi non hanno bisogno di intelligenza artificiale. Una regola deterministica o una revisione del flusso di lavoro possono produrre più valore, con meno rischio e meno costo di manutenzione. Dirlo fa parte del lavoro.
In chiusura
La domanda utile all’inizio di un progetto non è se l’AI funziona. Funziona.
La domanda è se l’organizzazione ha i dati, l’integrazione, i ruoli e gli indicatori per sostenerne l’uso quotidiano. È una valutazione che si può fare in poche settimane, prima di impegnare un budget significativo.
Se state valutando un caso concreto nella vostra organizzazione, siamo disponibili a un confronto tecnico su quel processo specifico: quali dati servono, dove sono i punti di attrito e che cosa sarebbe realistico misurare nei primi mesi.