Dal progetto pilota alla produzione: cosa cambia quando un sistema di AI deve durare

Molte aziende hanno ormai svolto un progetto pilota di AI. Parecchi erano incoraggianti: un modello leggeva fatture, riassumeva contratti, rispondeva a domande su un manuale. Molti meno sono diventati parte del modo in cui l'azienda lavora.

Il divario raramente sta nel modello. Sta in tutto ciò che al pilota era permesso ignorare.

Perché i progetti pilota si fermano

Un pilota nasce per rispondere a una domanda — il modello sa farlo? — ed è giusto che prenda scorciatoie per rispondere in fretta. I problemi iniziano quando le scorciatoie diventano il progetto.

• Accesso ai dati. Il pilota lavorava su una cartella di file di esempio. La produzione ha bisogno della casella di posta vera, dell'archivio vero e dei permessi per leggerli, concordati con i sistemi informativi e con la sicurezza.
• Integrazione. Il pilota produceva un foglio di calcolo o una risposta in una finestra di chat. La produzione ha bisogno del risultato dentro l'ERP, il CRM o il sistema dei trasporti, nel formato che accettano.
• Eccezioni. Il pilota misurava i casi riusciti. La produzione deve decidere cosa succede con gli altri: la scansione sfocata, la fattura con un'impaginazione nuova, l'email con due ordini e una correzione.
• Responsabilità. Il pilota apparteneva a un gruppo di innovazione. La produzione ha bisogno di qualcuno nelle operazioni che risponda dei risultati, e di qualcuno nei sistemi informativi che risponda del sistema.
• Valutazione. Il pilota era giudicato a impressione. La produzione ha bisogno di misure ripetibili dopo ogni modifica.
• Costi su larga scala. Una dimostrazione costa pochi centesimi. Migliaia di documenti al mese, con tentativi ripetuti e allegati lunghi, costano denaro vero, e quel costo va conosciuto prima di vederlo in fattura.

Cosa serve in produzione

In un sistema in produzione il modello è una componente tra molte, e di solito non la più grande. Intorno ci sono le parti che rendono affidabile il suo risultato.

Integrazione con i sistemi di riferimento

Il risultato di un passaggio di AI deve arrivare dove l'azienda già conserva i propri dati ufficiali. Significa scrivere nell'ERP o nel sistema di gestione dei trasporti attraverso le interfacce che offrono — servizi, tabelle di appoggio, file di importazione — con la stessa validazione che riceverebbe un dato inserito da una persona. Il sistema di riferimento resta tale; descriviamo il metodo in portare l'AI su ERP e sistemi legacy.

Validazione deterministica intorno al modello

Un modello è probabilistico; la contabilità no. Ogni valore estratto dall'AI dovrebbe superare regole che non dipendono dal modello: totali che tornano, partite IVA presenti in anagrafica, date sensate, codici che corrispondono. Quando una regola non è superata, il caso si ferma e attende una persona.

Un esempio dal nostro lavoro. Nel flusso delle fatture passive per uno spedizioniere, il primo passaggio non è l'estrazione: è verificare che il PDF sia davvero una fattura. Una casella che riceve fatture riceve anche solleciti, estratti conto e duplicati, e i dati estratti da questi documenti producono errori che sembrano legittimi. Leggi il caso studio.

Un altro. In un pilota per un gruppo di trasporti e logistica, gli ordini letti dalle email dei clienti sono validati secondo il principio del tutto o niente: se un ordine di una richiesta non supera i controlli, nessuno arriva al sistema di gestione dei trasporti. Un'importazione parziale è più difficile da correggere di nessuna importazione. Leggi il caso studio.

Revisione umana delle eccezioni

Supervisione umana non significa che una persona controlli tutto: si perderebbe il vantaggio. Significa che il sistema sa quando non è sicuro, manda quei casi a una persona e mostra il documento di origine, i dati estratti e la regola non superata. La decisione di chi rivede viene registrata, e i casi difficili entrano nell'insieme di prova.

Con il tempo, la quota di casi che va in revisione dovrebbe scendere, man mano che regole ed esempi migliorano. Se non scende, anche questa è un'informazione: il processo potrebbe essere più vario di quanto qualcuno abbia mai messo per iscritto.

Insiemi di prova e monitoraggio

Prima della produzione, costruisci un insieme di esempi reali con le risposte corrette, compresi quelli difficili. Eseguilo prima di ogni rilascio e di ogni cambio di modello o di istruzioni. In produzione, segui tre numeri: la quota di casi che va in revisione, le correzioni fatte dalle persone e il costo per caso. Una lenta deriva in uno di questi è il primo segnale d'allarme che riceverai.

Tracciabilità, identità e permessi

Per ogni caso conserva ciò che è entrato, ciò che il modello ha prodotto, quali regole sono state applicate, chi ha approvato e cosa è stato scritto in quale sistema. Metti l'applicazione dietro l'accesso unificato aziendale e assegnale dei ruoli, così un assistente mostra a ciascuno solo ciò che è autorizzato a vedere. Sono le domande che faranno i revisori, e le stesse che pongono il GDPR e l'AI Act europeo.

Controllo dei costi

Misura il costo per documento o per conversazione fin dal primo giorno del pilota. Usa il modello più piccolo che raggiunge l'accuratezza richiesta, evita di mandare al modello ciò che non ha bisogno di leggere e mantieni la possibilità di cambiare fornitore. Un'architettura indipendente dal modello è anche una scelta di costo. E conta tutto: tentativi ripetuti, allegati lunghi e le rielaborazioni che seguono un cambio di modello.

Un responsabile con un nome

Ogni sistema in produzione ha bisogno di due nomi: un responsabile operativo, che decide che cosa significa “corretto” e gestisce le segnalazioni, e un responsabile tecnico, che risponde di disponibilità, sicurezza e modifiche. Senza di loro il sistema ha utenti, ma nessuno che ne risponda.

Una lista di controllo pratica

Prima di dichiarare pronto per la produzione un sistema di AI, verifichiamo che ciascuno di questi punti abbia una risposta:

1. Il processo, i suoi volumi e il costo di svolgerlo a mano sono messi per iscritto.
2. Il sistema legge dati reali attraverso accessi concordati e autorizzati.
3. I risultati arrivano al sistema di riferimento attraverso le sue interfacce, e ogni importazione si può ripetere senza rischi.
4. Regole deterministiche validano ogni valore che conta, e una regola non superata ferma il caso.
5. I casi incerti vanno a una persona, con il documento di origine e il motivo in evidenza.
6. Un insieme di prova di esempi reali viene eseguito prima di ogni rilascio e di ogni cambio di modello.
7. Accuratezza, quota di revisione e costo per caso sono monitorati in produzione.
8. Ogni passaggio è registrato, e gli accessi seguono l'accesso unificato e i ruoli.
9. I dati restano nella regione concordata, e ogni responsabile del trattamento è documentato.
10. Esistono un responsabile operativo e un responsabile tecnico, con nome e cognome.

Quanto tempo serve

La risposta onesta è che dipende meno dal modello che dall'organizzazione: quanto in fretta si ottiene l'accesso ai dati, quanto sono pulite le anagrafiche, quante eccezioni ha davvero il processo. Quello che possiamo dire è dove va il tempo. Il passaggio di AI è di solito la prima parte a funzionare. Integrazione, validazione, schermate di revisione e monitoraggio richiedono più tempo, e sono ciò che fa durare il sistema.

Da dove partire

Scegli un processo con un costo chiaro e un responsabile chiaro — fatture passive registrate a mano, ordini ricopiati dalle email — e progetta il sistema di produzione fin dall'inizio, anche se il primo rilascio è piccolo. Un pilota costruito così non deve essere rifatto per andare in produzione. Deve solo crescere. Parti dal caso di cui puoi misurare i risultati, non da quello più spettacolare.

È così che lavoriamo nell'AI per le imprese, con l'architettura e la gestione che mantengono il sistema in funzione dopo l'avvio.