Agenti AI in azienda: come scegliere il primo processo da automatizzare

Un’automazione tradizionale esegue passaggi predefiniti: quando accade A, il sistema fa B. Un agente AI lavora invece verso un obiettivo, interpreta un contesto, sceglie tra più azioni e può utilizzare strumenti come CRM, documenti, posta, calendario o database. Questa flessibilità lo rende utile nei processi in cui le richieste cambiano e serve ragionare, ma introduce anche una nuova responsabilità progettuale. Non basta che il modello sappia rispondere: deve sapere quando agire, quando fermarsi e quali informazioni può utilizzare.

Per questo la domanda iniziale non è quale modello acquistare. È quale decisione operativa vogliamo rendere più veloce o più coerente. Qualificare una richiesta commerciale, preparare una bozza di risposta, riassumere un ticket e proporre la prossima azione sono obiettivi osservabili. Dire invece che l’agente deve occuparsi del marketing è troppo ampio: non definisce un risultato, non stabilisce un perimetro e rende impossibile distinguere un test riuscito da una demo convincente.

Il primo criterio è la frequenza. Un’attività che avviene una volta ogni tre mesi produce pochi esempi e rende lento l’apprendimento. Il secondo è il valore unitario o cumulato: minuti risparmiati su centinaia di richieste possono pesare più di un’attività rara e prestigiosa. Il terzo è la disponibilità dei dati. Se regole, documenti e casi precedenti sono dispersi o contraddittori, l’agente eredita quella confusione. Il quarto è la reversibilità dell’errore. Una bozza può essere corretta; un rimborso o una promessa contrattuale richiedono controlli molto più rigidi.

Il quinto criterio è la presenza di un proprietario del processo. Serve una persona che sappia spiegare come si lavora oggi, riconoscere un risultato corretto e decidere le eccezioni. Senza questa figura il progetto diventa una discussione astratta tra tecnologia e aspettative. Una buona matrice assegna a ogni processo un punteggio da uno a cinque per frequenza, impatto, qualità dei dati, reversibilità e ownership. Il candidato iniziale non è necessariamente quello con il totale più alto: è quello con il miglior rapporto tra apprendimento, valore e rischio.

Le istruzioni descrivono ruolo, obiettivo, vincoli e criteri di successo. Gli strumenti definiscono ciò che l’agente può realmente fare. La conoscenza comprende documenti, dati e contesto recuperati nel momento utile. Separare questi tre livelli evita di concentrare tutto in un prompt enorme. Se una politica commerciale cambia, dovrebbe essere aggiornata nella fonte ufficiale; se un permesso viene revocato, va rimosso dallo strumento; se cambia il comportamento atteso, si aggiorna l’istruzione. Questa architettura rende il sistema più verificabile e meno fragile.

All’inizio è prudente concedere permessi di sola lettura e far produrre proposte, non azioni definitive. L’agente può individuare il record corretto nel CRM, preparare una risposta e indicare il motivo della scelta; una persona approva l’invio. Dopo un numero sufficiente di casi corretti, alcune azioni a basso rischio possono diventare automatiche. L’autonomia non è quindi un interruttore acceso o spento, ma una scala costruita con evidenze.

Un controllo efficace non consiste nel chiedere a qualcuno di rileggere tutto per sempre. Occorre stabilire quali condizioni impongono l’escalation: bassa confidenza, dati mancanti, cliente sensibile, importo oltre soglia, eccezione non prevista o azione irreversibile. L’agente deve segnalare il motivo e raccogliere gli elementi necessari alla decisione umana. In questo modo il passaggio di mano non azzera il vantaggio ottenuto e il team può concentrarsi sui casi che richiedono davvero giudizio.

È utile registrare input, fonti consultate, strumenti chiamati, output e approvazioni. Il log permette di ricostruire un errore, trovare pattern ricorrenti e aggiornare regole o dati. Non serve conservare indiscriminatamente informazioni personali: tempi di conservazione, accessi e minimizzazione vanno definiti insieme alla funzione privacy. La tracciabilità è un requisito operativo prima ancora che normativo, perché senza di essa ogni correzione resta basata su impressioni.

Un pilota utile parte da un set di casi storici rappresentativo: semplici, ambigui, incompleti e fuori policy. Il team definisce in anticipo la risposta attesa o almeno i criteri con cui valutarla. Si esegue poi l’agente in un ambiente separato, senza conseguenze reali, e si misura quante volte arriva a un risultato accettabile, quante volte chiede aiuto e quali errori produce. I casi di fallimento diventano test permanenti, così una modifica successiva non reintroduce problemi già risolti.

Dopo la fase offline si passa a una modalità assistita su un gruppo ristretto di utenti o richieste. La durata non dovrebbe essere decisa solo a calendario, ma in base al numero di casi necessario per osservare il comportamento. Ogni settimana si confrontano qualità, tempi e costo con il processo precedente. Se l’agente sposta semplicemente il lavoro dalla compilazione alla correzione, il valore è inferiore a quanto appare nella demo.

Le metriche minime sono tempo medio per pratica, percentuale di output approvati senza modifiche, tasso di escalation, costo tecnico per caso e numero di errori rilevanti. A queste si aggiunge una metrica di risultato legata al processo: tempo di risposta ai lead, ticket risolti, appuntamenti confermati o completezza dei dati nel CRM. Misurare solo il numero di attività svolte incentiva volume, non qualità.

La decisione di scalare dovrebbe essere esplicita. Si amplia l’ambito quando il sistema supera una soglia concordata, gli errori residui sono compresi e il team sa intervenire. Se il valore non emerge, il pilota può comunque aver prodotto un risultato utile: dati più ordinati, regole finalmente documentate o la prova che il processo va riprogettato prima di essere automatizzato. Un buon progetto di agenti AI migliora il lavoro anche quando suggerisce di fermarsi.