Scenario illustrativo. Uno studio contabile vuole che un agente riconcili gli incassi dei clienti. Chiede a Marta, che lo fa da dodici anni, come procede. «È facile — dice — fai combaciare l'estratto conto con le fatture.» L'agente viene costruito su quella descrizione e, nelle prime settimane, fallisce proprio dove Marta non si fermava mai a pensare: il cliente che salda tre fatture con un unico bonifico, l'importo che arriva sempre scontato di uno sconto concordato a voce, la chiusura del trimestre in cui non si tocca nulla finché non arriva una mail. Niente di tutto questo era scritto. Marta non sapeva nemmeno di saperlo.
La tesi in una riga: prima di automatizzare un processo bisogna tirare fuori dalla testa di chi lo esegue ciò che non è mai stato scritto, e spesso questo passaggio rende già più dell'automazione stessa.
Perché documentare i processi prima di automatizzare con l'IA?
Perché un agente esegue ciò che gli racconti, non ciò che l'azienda fa davvero. La differenza tra le due cose è la conoscenza tacita: criteri, eccezioni e scorciatoie che chi fa il lavoro applica senza accorgersene e che, proprio per questo, non sa spiegare. Se gli chiedi «come fai?», ti restituisce la versione ufficiale, quella che sta in una frase. L'agente si costruisce su quella versione e si rompe su tutto il resto.
Non è un dettaglio di implementazione. L'analisi di RAND sul perché falliscono i progetti di IA, basata su interviste a ingegneri e data scientist, indica tra le cause più frequenti che il problema da risolvere sia stato capito o comunicato male (RAND, 2024). È lo stesso schema che descriviamo in perché falliscono i progetti di automazione con l'IA: il progetto non fallisce nella demo, fallisce nello spazio tra ciò che ciascuno dava per scontato.
Come capire se un processo esiste solo nella testa di una persona?
Ci sono segnali abbastanza affidabili, e non serve un audit per vederli.
- Due persone lo fanno in modo diverso e dicono entrambe di farlo bene. Ognuna applica il proprio criterio e nessuno li ha mai messi uno accanto all'altro.
- Quando manca quella persona, il processo si ferma o peggiora. Se le ferie di qualcuno sono un rischio operativo, il processo vive nella sua testa (lo stesso problema, visto dal lato dell'agente, in cosa succede al tuo agente quando se ne va chi l'ha montato).
- La spiegazione comincia con «dipende». Quando ogni passaggio porta con sé un «dipende» e nessuno sa da cosa, ci sono regole non scritte.
- Le eccezioni si risolvono per telefono o per messaggio. Ciò che si decide fuori dal sistema non entra nel sistema, e l'agente vede solo il sistema.
Come si estrae il processo reale in una settimana?
Non con un questionario né con una riunione di due ore. Con casi reali, osservati da qualcuno che non sia chi svolge il lavoro. Un metodo che sta in cinque giorni:
- Lunedì: scegli un processo e una persona. Un solo processo, quello che gira di più, e chi lo esegue ogni giorno. Dille fin dall'inizio che non viene valutata: si tratta di capire, non di fare un audit.
- Martedì: osserva i casi, non chiedere come si fa. Siediti accanto a lei mentre risolve casi reali, compresi quelli strani, e annota ogni decisione. Un campione degli ultimi casi vale più di qualsiasi descrizione.
- Mercoledì: chiedi il perché a ogni decisione. «Perché questo e non quello?», «cosa sarebbe successo con un altro importo?». Qui escono i criteri che lei riteneva ovvi.
- Giovedì: scrivi la regola di business, non i clic. Condizione, eccezione e chi si avvisa, una pagina per processo. Il formato è in come documentare le automazioni.
- Venerdì: verifica con casi che non ha visto. Dalle casi nuovi senza mostrarle la regola e confronta la sua decisione con ciò che hai scritto. Ogni differenza è una regola che mancava.
| Cosa dice la versione ufficiale | Cosa fa davvero la persona | Come emerge |
|---|---|---|
| «Faccio combaciare l'estratto con le fatture» | Raggruppa i pagamenti, applica sconti concordati a voce e mette in attesa certi clienti | Osservando casi reali, non sentendoli descrivere |
| «Si approva se rispetta la policy» | Approva cose fuori policy quando conosce il cliente | Chiedendo il perché a ogni eccezione |
| «Si controlla prima di inviare» | Controlla solo ciò che sembra strano, a fiuto, senza saperlo nominare | Dandole casi nuovi e confrontando la sua decisione con la regola scritta |
Guarda l'ultima colonna: in nessun caso la soluzione è chiedere di più, è guardare di più. Chi descrive il proprio lavoro descrive l'ideale; chi lo fa davanti a te mostra il reale. E il reale è l'unico che un agente incontrerà lunedì mattina, con i casi che nessuno aveva previsto alla riunione di avvio.
E se documentando scopri che non conviene automatizzarlo?
Succede più di quanto si ammetta. Documentando emergono incoerenze tra persone, passaggi di cui nessuno ricorda il motivo e decisioni che dipendono da un giudizio non riducibile a regole. Le uscite sono tre: semplificare il processo prima di toccare qualsiasi cosa, automatizzare solo la parte che è già una regola e lasciare la parte di giudizio a una persona, oppure decidere che quel processo non è per un agente (il ragionamento di fondo è in quando non automatizzare con l'IA). Una qualsiasi delle tre costa meno che scoprirlo con l'agente già in produzione.
E la parte di giudizio non sparisce: stabilisce quanta autonomia puoi dare all'agente. Lo si decide con i livelli di autonomia di un agente, e si può decidere solo se prima sai dove sta il giudizio.
Quando non vale la pena documentare prima il processo?
Quando il processo è breve, reversibile e poco costoso da sbagliare: tre passaggi, niente soldi né dati personali di mezzo. Lì si prova direttamente e si corregge strada facendo. Non vale la pena nemmeno documentare con tanto dettaglio un processo che cambia ogni mese; in quel caso si scrivono i principi stabili, non ogni passaggio (di più in automatizzare un processo che cambia ogni mese).
Se hai più candidati e non sai da quale partire, auditare i tuoi processi per l'IA risponde prima a quale merita lo sforzo; l'esercizio di questa settimana è ciò che fai dopo, con quello scelto.
La riga da portarti via: il processo che stai per automatizzare non è quello del manuale, è quello che esegue la persona, e finché non è scritto, l'agente si costruisce su un'ipotesi.
Fonti (consultate il 28 ottobre 2026): «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed», RAND Corporation (2024), usata in modo qualitativo. Lo scenario iniziale è illustrativo, non un caso reale.