Agenti AI in azienda: quali attività possono svolgere e dove serve ancora il controllo umano
Un assistente AI risponde a una domanda o prepara un testo. Un agente può ricevere un obiettivo, scegliere alcuni passaggi, consultare strumenti e compiere azioni: leggere una pratica, interrogare il CRM, creare una bozza, aggiornare uno stato o aprire un ticket. Questa capacità riduce lavoro manuale, ma cambia il problema da controllare. Non basta più valutare la qualità di una risposta; bisogna stabilire che cosa il sistema può vedere, decidere e modificare.
Il punto di partenza è l’incarico. Scrivi in una frase quale risultato deve produrre l’agente e indica l’evento che lo attiva. “Gestire le richieste clienti” è troppo ampio. “Classificare le email ricevute nella casella assistenza, proporre una risposta basata sulla documentazione approvata e inoltrare a un operatore i casi non riconosciuti” definisce invece un perimetro verificabile. Ogni verbo corrisponde a un’autorizzazione e a un controllo.
Separa poi quattro livelli. Al primo l’agente legge, riassume e suggerisce senza modificare sistemi. Al secondo prepara una bozza che una persona approva. Al terzo esegue azioni reversibili e a basso impatto entro regole precise. Al quarto incontra operazioni critiche o irreversibili, come pagamenti, cancellazioni, variazioni contrattuali o comunicazioni sensibili: qui deve fermarsi, chiedere un’approvazione oppure non avere affatto lo strumento necessario.
La supervisione umana non consiste nel controllare ogni schermata dopo un incidente. Deve essere progettata nel flusso: proprietario del processo, responsabile dell’agente, soglie di arresto, coda delle approvazioni, registro delle attività e comando di sospensione. Le architetture Microsoft per gli agenti e le indicazioni OWASP convergono su identità distinte, privilegi minimi, tracciabilità e approvazione esplicita per le operazioni ad alto rischio.
Crea un contratto operativo prima della configurazione. Elenca trigger, obiettivo, fonti autorizzate, strumenti, azioni ammesse, output atteso, limiti e responsabile. Se l’agente lavora nel CRM, specifica quali oggetti può leggere e quali campi può modificare. Non concedere accesso amministrativo perché è più rapido: assegna un’identità tecnica propria, riconoscibile nei registri, con i soli permessi necessari al compito.
Dividi lettura e scrittura. Un agente che deve riassumere una trattativa può leggere note e attività, ma non ha bisogno di cancellare contatti o cambiare il proprietario dell’opportunità. Se deve aggiornare uno stato, limita i valori consentiti e richiedi condizioni verificabili. Le autorizzazioni devono essere applicate dal sistema che espone lo strumento, non affidate a una frase nel prompt: un’istruzione testuale non sostituisce un controllo di accesso.
Considera email, allegati, pagine web e documenti esterni come dati non attendibili. Un testo può contenere istruzioni costruite per deviare l’agente o indurlo a usare uno strumento in modo improprio. Il flusso deve distinguere le istruzioni definite dall’azienda dal contenuto che l’agente sta analizzando, validare gli input e impedire che una fonte esterna estenda i permessi disponibili. OWASP indica questa separazione come difesa essenziale contro prompt injection e abuso degli strumenti.
Imposta limiti tecnici: numero massimo di passaggi, durata, costo, tentativi, volume di record e frequenza delle chiamate. Dopo un errore, l’agente non deve ripetere all’infinito la stessa azione. Usa chiavi di idempotenza o controlli equivalenti per evitare che un nuovo tentativo crei due ordini, due ticket o due email. Alla scadenza del limite, il caso deve passare a una coda visibile con il motivo dell’interruzione.
Il controllo deve seguire l’impatto. Per ogni azione valuta danno possibile, reversibilità, sensibilità dei dati e facilità di verifica. Una bozza interna può richiedere un controllo a campione; un’offerta inviata a un cliente richiede approvazione prima dell’invio; un pagamento o una modifica dei permessi non dovrebbe essere eseguibile dall’agente senza un passaggio autorizzativo forte. Documenta queste regole in una matrice, non lasciarle alla valutazione occasionale dell’operatore.
La schermata di approvazione deve mostrare ciò che serve a decidere: richiesta originale, dati utilizzati, azione proposta, record interessati, eventuali anomalie e conseguenza prevista. I pulsanti devono distinguere approvazione, rifiuto e rinvio a un responsabile. Una domanda generica come “Vuoi continuare?” non consente un controllo informato. Conserva anche identità e orario di chi autorizza.
Definisci le condizioni di escalation. L’agente si ferma quando mancano dati obbligatori, le fonti sono in conflitto, il caso non appartiene alle categorie note, la confidenza scende sotto la soglia, viene superato un importo o compare un dato sensibile non previsto. Evita di usare una sola percentuale per qualsiasi situazione: la soglia può essere diversa per una classificazione correggibile e per una comunicazione che produce effetti esterni.
Prepara una sospensione reale. Il responsabile deve poter disattivare l’agente, revocare credenziali, bloccare uno strumento o fermare soltanto una determinata azione senza attendere una modifica del modello. La procedura deve indicare chi può intervenire, dove si trova il comando, come vengono gestiti i lavori in corso e come si verifica che nessun processo sia rimasto in uno stato intermedio.
Costruisci un ambiente di prova con copie autorizzate dei dati e strumenti che non producano conseguenze reali. Prepara casi normali, eccezioni, dati incompleti, richieste contraddittorie e contenuti ostili. Verifica non soltanto il risultato finale, ma anche gli strumenti scelti, i parametri inviati, il numero di tentativi e il rispetto delle condizioni di arresto. Un agente può arrivare a una risposta plausibile seguendo un percorso non consentito.
Inizia in modalità osservazione: l’agente elabora casi reali ma non scrive nei sistemi. Confronta proposta e decisione dell’operatore. Passa poi alla preparazione di bozze, quindi a poche azioni reversibili. Ogni estensione richiede evidenze: tasso di completamento corretto, falsi positivi, escalation, tempo recuperato, incidenti e costo per pratica. Non aumentare autonomia soltanto perché la dimostrazione iniziale è riuscita.
Registra versione delle istruzioni, modello o servizio, identità, input ammessi, chiamate agli strumenti, output, approvazioni, errori e modifiche effettuate. I registri devono permettere di ricostruire una singola esecuzione e di confrontare periodi diversi. Proteggi i log secondo la natura dei dati: tracciare tutto senza regole di conservazione può creare un nuovo archivio di informazioni personali o riservate.
Organizza una revisione periodica. Controlla permessi non più necessari, strumenti aggiunti, variazioni del processo, nuove categorie di errore e casi che gli operatori correggono spesso. Ogni agente deve avere un proprietario umano e una data di riesame. Se il processo scompare, cambia sistema o non produce più il valore previsto, disattiva identità, credenziali, trigger e code invece di lasciare un’automazione dimenticata in esecuzione.
Prendi un solo caso d’uso e disegna il percorso su una pagina. Nella prima colonna scrivi l’evento iniziale; nelle successive inserisci dati letti, decisioni, strumenti e azioni. Accanto a ogni azione assegna una classe: sola lettura, bozza, esecuzione reversibile o operazione critica. Indica inoltre il sistema proprietario del dato e la persona responsabile del risultato.
Apri quindi la console di identità usata dall’azienda e crea un’identità dedicata all’agente. Assegna soltanto i ruoli richiesti dalla mappa. Nel CRM limita oggetti e campi; nel documentale limita raccolte e cartelle; nella posta usa una casella o un ambito dedicato. Non riutilizzare account personali e non memorizzare password nel prompt. Conserva i segreti nel gestore previsto dall’infrastruttura e stabilisci una scadenza o rotazione.
Configura gli strumenti uno alla volta. Per ogni chiamata definisci schema degli input, valori accettati, dimensione massima e risposta agli errori. Interponi una regola deterministica prima delle scritture: il componente autorizzativo verifica identità, azione, record, soglia e approvazione. Se una condizione non è soddisfatta, restituisce un rifiuto e apre un caso per l’operatore; l’agente non può aggirare il controllo scegliendo parole diverse.
Realizza la coda di revisione con informazioni sufficienti. Mostra richiesta, fonti consultate, proposta, record coinvolti e differenze che verranno applicate. Aggiungi approva, rifiuta ed escalazione. Collega ogni decisione all’identità della persona. Prova il rifiuto, la scadenza e l’indisponibilità dell’approvatore, non soltanto il percorso positivo.
Esegui una batteria di test in ambiente isolato: casi corretti, dati mancanti, allegati alterati, istruzioni ostili, duplicati, timeout, servizio non disponibile e superamento dei limiti. Controlla che l’agente non esponga dati, non ampli l’ambito, non ripeta azioni e si fermi nel punto previsto. Attiva poi la modalità osservazione su un campione reale e misura gli indicatori concordati.
Concedi l’esecuzione soltanto alle azioni reversibili che hanno superato le soglie. Mantieni approvazione preventiva per quelle esterne o ad alto impatto. Prima del rilascio prova il comando di sospensione e la revoca dell’identità. Chiudi con un verbale che elenchi proprietario, perimetro, permessi, soglie, registri, procedure d’incidente, frequenza di revisione e criterio con cui l’agente verrà esteso oppure dismesso.
Lunedì – Sabato : 9:30 am – 21:00 pm
Lunedì – Sabato : 9:30 am – 21:00 pm
Studierò la strategia più adeguata per le tue esigenze e insieme al mio staff individueremo la Buyer Personas migliore per trasformare il tuo processo commerciale offline nella più efficace macchina di vendita online, e la strategia di comunicazione più convincente per convincere il pubblico che il tuo prodotto è quello che stanno cercando, anche se costa di più della concorrenza.
Lunedì – Sabato : 9:30 am – 21:00 pm
