Livelli di autonomia degli agenti AI: cosa approvare

Un agente AI con human in the loop chiede a una persona di approvare un’azione prima di eseguirla, ma solo per le azioni in cui un errore costa caro, è difficile da annullare o è delicato sul piano legale. Nel customer care rispondere a una FAQ o cambiare un indirizzo può avvenire in autonomia, un rimborso oltre il suo limite richiede un’approvazione e cancellare i dati di un cliente non dovrebbe mai essere una decisione dell’agente.

In breve

• Decida l’autonomia per azione, non per agente: lo stesso agente AI può rispondere da solo, rimborsare entro un limite e passare a una persona la chiusura di un account.
• Valuti ogni azione su quattro conseguenze (reversibilità, denaro, aspetti legali o di compliance, danno al cliente) da 0 a 3, e lasci che il punteggio più alto stabilisca il livello.
• Cinque livelli coprono il lavoro di assistenza: informare (solo rispondere), agire da solo, agire entro un limite, agire con approvazione, mai.
• Un’approvazione è un controllo solo se chi approva vede i fatti giusti, risponde in tempo e a volte dice di no.
• Allarghi o restringa l’autonomia un motivo di contatto alla volta, sulla base delle prove: conversazioni valutate, storni e approvazioni verificate.

Che cosa significa human in the loop per un agente AI?

Human in the loop significa che una persona deve approvare, modificare o rifiutare l’azione proposta da un agente AI prima che venga eseguita. Human on the loop significa che l’agente agisce e una persona lo sorveglia e può intervenire dopo. Il customer care ha bisogno di entrambi: in the loop per le poche azioni rischiose, on the loop per tutto il resto.

La maggior parte delle guide tratta la persona come un unico punto di controllo per l’intero agente. Nell’assistenza questo fallisce in entrambe le direzioni: un controllo su ogni azione sommerge i team leader di approvazioni, e nessun controllo permette all’agente di disdire subito un abbonamento quando il cliente voleva solo fermare il rinnovo automatico.

Le piattaforme per agenti costruiscono il meccanismo al posto suo. Microsoft Agent Framework, per esempio, mette in pausa un workflow ed emette una richiesta di approvazione quando l’agente prova a chiamare uno strumento contrassegnato come soggetto ad approvazione, e riprende quando arriva una risposta (Microsoft Learn, in inglese). Quello che la piattaforma non decide è quali azioni ricevono quel contrassegno. Questa decisione spetta all’Head of CX, al responsabile dell’agente AI e ai responsabili delle policy.

OWASP chiama l’errore che questo previene “excessive agency” (autonomia eccessiva) e tra le misure di mitigazione indica il controllo human in the loop “per richiedere che una persona approvi le azioni ad alto impatto prima che vengano eseguite” (OWASP LLM06:2025, in inglese). La parte difficile è definire “ad alto impatto” per le sue azioni di assistenza. La nostra guida alla governance degli agenti AI presenta 15 controlli; questo articolo approfondisce il controllo 5 (livelli delle azioni) e i controlli 6 e 7 (le approvazioni e la supervisione di chi approva).

Quali sono i cinque livelli di autonomia per le azioni di un agente AI?

I cinque livelli sono: 0, informare (rispondere solo da contenuti approvati); 1, agire da solo su azioni reversibili senza denaro; 2, agire entro un limite su denaro o impegni; 3, agire con l’approvazione di una persona; 4, non agire mai e passare il caso. Ogni azione appartiene a un solo livello.

Sono gli stessi livelli della guida alla governance, quindi una sola matrice serve sia al suo registro di governance sia alla configurazione della piattaforma. I guardrail applicano poi i limiti dentro ciascun livello.

Come si decide quali azioni di un agente AI richiedono l’approvazione di una persona?

Valuti ogni azione su quattro conseguenze, da 0 (nessuna) a 3 (grave): reversibilità, denaro, esposizione legale o di compliance e danno al cliente se l’azione è sbagliata. Il livello lo stabilisce il punteggio singolo più alto, non il totale, perché un’azione economica che non si può annullare resta un’azione che non si può annullare.

Segue la logica del Model AI Governance Framework for Agentic AI di Singapore, secondo cui le organizzazioni dovrebbero definire punti di controllo che richiedono l’approvazione umana per le azioni ad alto rischio, le azioni irreversibili (tra gli esempi la cancellazione definitiva di dati e l’esecuzione di pagamenti), i comportamenti anomali e i limiti fissati dagli utenti stessi (IMDA, versione 1.5, sezione 2.2.2, in inglese; veda la nostra sintesi del quadro). Chi guida l’assistenza lo dice in modo semplice: si automatizza in base alle conseguenze, non in base a quanto sembra complessa la conversazione. La scala qui sotto rende la valutazione ripetibile, così due persone che valutano la stessa azione arrivano alla stessa risposta.

La scala delle conseguenze

La regola di punteggio

Applichi le regole in quest’ordine e si fermi alla prima che corrisponde:

1. L’azione non cambia nulla (si limita a rispondere): livello 0, informare.
2. Aspetti legali o danno al cliente valgono 3: livello 4, mai. Il caso lo prende una persona responsabile di quel processo.
3. Una qualsiasi dimensione vale 2 o 3: livello 3, agire con approvazione.
4. Denaro vale 1: livello 2, agire entro un limite.
5. Tutto il resto (tutti i punteggi a 0 o 1, nessun denaro): livello 1, agire da solo.

Poi applichi tre eccezioni legate al contesto, qualunque sia il livello dell’azione. Se l’identità non è verificata, l’agente non può agire sull’account in nessun modo. Se il cliente mostra segnali di vulnerabilità, parla di vie legali o presenta un reclamo formale, la conversazione passa a una persona (livello 4). Se la richiesta è insolita per quel cliente, come un terzo rimborso nello stesso mese, sale di un livello. Quest’ultima è il punto di controllo sui comportamenti “anomali” dell’IMDA, tradotto nel linguaggio dell’assistenza.

Quali azioni di assistenza richiedono l’approvazione di una persona? La matrice di autonomia

Il cambio di indirizzo e la disattivazione del rinnovo automatico possono avvenire in autonomia; piccoli rimborsi, storni di penali e crediti di cortesia avvengono entro un limite; rimborsi più alti, disdette immediate e chiusure di account richiedono approvazione; la cancellazione dei dati e la modifica delle coordinate bancarie restano a una persona.

I limiti (L1 = 50 dollari, L2 = 250 dollari) e i punteggi qui sotto sono un’illustrazione per un team che gestisce abbonamenti ed e-commerce. Copi le colonne, non i numeri.

Definisca l’azione con precisione. “Disdire l’abbonamento” sono due azioni con livelli diversi. Un agente che disdice subito quando il cliente ha chiesto di fermare il prossimo rinnovo ha eseguito correttamente l’azione sbagliata.

Separi la richiesta dall’esecuzione. L’agente può accettare e registrare una richiesta di cancellazione dei dati (livello 1) mentre la cancellazione vera e propria resta al team privacy (livello 4). Ai sensi del GDPR, l’azienda deve informare il cliente sulle azioni intraprese su una richiesta di questo tipo “senza ingiustificato ritardo e, comunque, al più tardi entro un mese dal ricevimento della richiesta stessa” (articolo 12, paragrafo 3, del GDPR), quindi il compito dell’agente è un passaggio pulito, con un ticket e una scadenza.

Verifichi la colonna legale con i suoi consulenti. L’articolo 22 del GDPR dà alle persone il diritto di non essere sottoposte a una decisione basata unicamente sul trattamento automatizzato che produca effetti giuridici o incida in modo analogo significativamente sulla loro persona, con alcune eccezioni; dove si applica un’eccezione, l’azienda deve garantire almeno il diritto di ottenere l’intervento umano. Se la chiusura di un account o un rifiuto rientrino in questo caso dipende dalla sua situazione, ed è per questo che la matrice manda queste azioni a una persona. Per gli obblighi specifici dell’UE, veda la nostra guida sull’AI Act nel servizio clienti.

Come funziona in pratica un workflow di approvazione per un agente AI?

L’agente propone l’azione, la piattaforma la mette in pausa e invia una scheda di approvazione alla persona giusta, che approva, modifica o rifiuta entro un tempo stabilito, e l’agente dice al cliente che cosa succede dopo. Se nessuno risponde in tempo, l’azione viene negata e il caso passa a una persona.

Chi approva

Assegni ogni azione di livello 3 al ruolo che già prende quella decisione per gli operatori, non a un ruolo nuovo.

Quanto devono essere rapide le approvazioni

Il tempo di approvazione deve corrispondere al canale. In chat il cliente sta aspettando, quindi serve una risposta in pochi minuti o un messaggio chiaro che l’azione seguirà via email. Per email e ticket qualche ora va spesso bene. Fissi un obiettivo per canale e lo misuri.

Quando la scadenza passa, la risposta predefinita è no. L’IMDA indica tra le sue misure di monitoraggio il “negare l’azione per impostazione predefinita quando l’infrastruttura di approvazione non funziona”, per esempio quando i supervisori umani non sono raggiungibili (sezione 2.2.2). Il cliente deve allora sentirsi dire che una persona lo ricontatterà, mai ricevere silenzio.

Che cosa vede chi approva

L’IMDA consiglia di mantenere le richieste di approvazione “contestuali e facili da assimilare”, brevi e chiare invece di lunghi log, rendendo evidente il rischio e includendo dati utili come il rischio dell’azione (sezione 2.2.2). Per un rimborso nell’assistenza significa una sola scheda:

• L’azione, l’importo e la regola che l’ha attivata (“rimborso di 120 dollari, oltre il limite di 50 dollari”).
• Lo stato dell’identità e lo storico rilevante, come i rimborsi degli ultimi 12 mesi.
• La policy su cui si basa l’agente, con link e versione.
• La motivazione dell’agente in una frase, una sintesi di due righe e il link alla trascrizione.
• I punteggi delle conseguenze, così chi approva sa che cosa è in gioco.
• Approva, modifica o rifiuta, con una motivazione obbligatoria per modifica e rifiuto e una giustificazione scritta per le approvazioni oltre L2.

Esempio di calcolo: quante approvazioni può gestire il suo team?

Illustrazione, con numeri scelti per l’esempio. Un agente AI gestisce 40.000 conversazioni al mese e il 6% si conclude con un’azione di livello 3. Sono 2.400 approvazioni al mese, circa 109 per giorno lavorativo su 22 giorni. A 90 secondi per approvazione, sono circa 2,7 ore di tempo dei team leader ogni giorno, prima che qualcuno abbia letto a fondo una sola trascrizione.

Le approvazioni sono una voce di organico, quindi le pianifichi come tale. Se la quota di livello 3 sale al 15%, lo stesso team si trova davanti a circa 273 approvazioni al giorno e la qualità della revisione cala. È il momento di spostare alcune azioni al livello 2 con un limite, sulla base delle prove, invece di chiedere alle persone di cliccare più in fretta.

Come si evitano la fatica da approvazione e le approvazioni automatiche?

Misuri chi approva, non solo l’agente. Tenga traccia del tasso di override di ogni approvatore (quanto spesso modifica o rifiuta) e del suo tempo di revisione. L’IMDA osserva che un tasso di override basso può indicare approvazioni date senza controllo e un tempo di revisione più breve può indicare automation bias o fatica da revisione (sezione 2.2.2). Poi verifichi un campione delle azioni approvate.

L’automation bias, cioè accettare il suggerimento di un sistema senza verificarlo, cresce quando le richieste sono quasi sempre giuste. Quindi il problema peggiora man mano che l’agente migliora.

Illustrazione di ciò che il report può mostrare, con numeri inventati:

Il team leader A è il caso “anomalo” descritto dall’IMDA, un approvatore le cui decisioni si discostano dalla norma. Quattro secondi non bastano per leggere una scheda. Non è un rilievo disciplinare: di solito significa che A copre il turno più carico.

Quattro abitudini mantengono le approvazioni significative:

1. Tenga piccolo il livello 3. Se un approvatore gestisce più di un certo numero di richieste all’ora, sposti le azioni chiaramente sicure un livello più in basso, con un limite.
2. Verifichi le azioni approvate. Ogni settimana il team QA rivede un campione di azioni approvate rispetto alla policy. Il tasso di approvazione non dice nulla; il tasso di approvazioni corrette sì.
3. Formi gli approvatori sui modi in cui sbagliano gli agenti, come citare una policy superata, l’esempio che fa l’IMDA. Il nostro articolo sul perché le conversazioni AI falliscono elenca i più comuni.
4. Ruoti e ponga un tetto. Distribuisca le approvazioni tra i team leader e fissi un massimo per turno, così nessuno approva centinaia di richieste di fila.

Quali prove dovrebbero allargare o restringere i permessi di un agente AI?

Allarghi l’autonomia per un motivo di contatto quando le sue conversazioni valutate superano i criteri, le sue approvazioni risultano quasi sempre corrette alla verifica e le sue azioni vengono stornate o contestate raramente. La restringa quando uno di questi segnali peggiora. Cambi un passo alla volta: alzi un limite o sposti un’azione di un livello, poi osservi le settimane successive.

Le prove per motivo di contatto:

Un tasso di override basso può significare che l’agente ha ragione, oppure che chi approva ha smesso di leggere. Solo la verifica e i tempi di revisione distinguono i due casi, quindi usi tutti e tre i segnali prima di allargare. Poi allarghi per gradi: porti L1 da 50 a 75 dollari per i rimborsi su un motivo di contatto, lasci invariato tutto il resto e confronti le quattro settimane successive con le quattro precedenti. La guida alla governance contiene esempi di soglie per far salire di livello un motivo di contatto e una regola di retrocessione. Per verificare che le azioni abbiano fatto ciò di cui il cliente aveva bisogno, veda come condurre un audit del tasso di risoluzione degli agenti AI, e tenga aggiornate le policy dietro ogni limite con la gestione delle policy per gli agenti AI.

Quando questa matrice non fa per lei

Se il suo agente AI si limita a rispondere alle domande, è interamente al livello 0: le servono una buona knowledge base, una regola per il passaggio a una persona e la revisione delle conversazioni, non un workflow di approvazione. Costruisca la matrice la settimana prima di collegare l’agente a rimborsi o modifiche dell’account. E con poche decine di azioni a settimana, un team leader può leggerle tutte a posteriori, quindi i report sugli override aggiungono poco.

Il ruolo di Kaizo

Kaizo offre QA e supervisione della governance per i team di assistenza in cui persone e agenti AI si dividono il lavoro. AutoPilot valuta ogni conversazione risolta con la sua scheda di valutazione, così i punteggi delle conversazioni nella tabella delle prove vengono da tutte le sue conversazioni, non da un campione, e ogni punteggio rimanda alle righe che lo giustificano. Veda come funziona il controllo qualità degli agenti AI.

Lo veda sulle sue conversazioni. Kaizo valuta il 100% delle sue conversazioni di assistenza, del suo team e dei suoi agenti AI, e mostra dove si rompe la qualità. Prenoti una demo.

Come iniziare questa settimana

Può costruire la prima matrice di autonomia in un pomeriggio, con il responsabile dell’agente AI e un team leader, partendo dalla configurazione della piattaforma, dal registro delle approvazioni del mese scorso e dalla regola di punteggio qui sopra.

1. Elenchi tutte le azioni che il suo agente AI può compiere oggi, partendo dalla configurazione della piattaforma, non dalla memoria.
2. Valuti ogni azione, poi applichi la regola di punteggio e le tre eccezioni di contesto.
3. Confronti con la piattaforma. Verifichi che ogni limite di livello 2 e ogni contrassegno di approvazione di livello 3 sia applicato nella piattaforma, non solo nel prompt.
4. Nomini chi approva e la scadenza per ogni azione di livello 3, e imposti il rifiuto predefinito alla scadenza.
5. Recuperi i numeri del mese scorso: approvazioni al giorno, tasso di override e tempo mediano di revisione per approvatore. È il suo punto di partenza per la prima revisione dell’autonomia.

La nostra guida sull’assistenza clienti agentica mostra dove si collocano questi livelli nel percorso complessivo.

Domande frequenti

Che cos’è l’autorizzazione human in the loop per gli agenti AI?

È una regola per cui un agente AI non può eseguire determinate azioni finché una persona nominata non le approva. L’agente propone l’azione, la piattaforma la mette in pausa e chi approva la approva, la modifica o la rifiuta. L’autorizzazione vale per azione e per importo, non è un permesso generale all’agente.

ChatGPT è human in the loop?

Da solo, un assistente in chat è human in the loop in senso semplice: produce testo e una persona decide che cosa farne. Quando viene collegato a strumenti che compiono azioni, come emettere rimborsi, deve decidere quali azioni avvengono in autonomia e quali aspettano una persona.

A che cosa serve un kill switch per un agente AI?

Un kill switch ferma rapidamente un agente AI, o una sua azione, quando qualcosa va storto, come un rilascio difettoso o un errore di policy che si ripete su larga scala. Completa le approvazioni: le approvazioni fermano le singole azioni rischiose prima che accadano, e un meccanismo di arresto limita il danno quando uno schema sfugge. Verifichi che cosa offre la sua piattaforma per mettere in pausa un agente o una singola azione, e chi può usarlo.

I limiti di rimborso devono essere uguali per tutti i clienti?

Non necessariamente. Fissi un limite per azione, poi lo abbassi o richieda l’approvazione in caso di rimborsi recenti, identità non verificata o richieste insolite. L’IMDA cita anche i limiti fissati dagli utenti stessi, come l’approvazione per gli acquisti oltre un certo importo.

Che cosa dice l’agente AI al cliente mentre aspetta l’approvazione?

Deve dire chiaramente che un collega deve confermare l’azione, quanto tempo richiede di solito e come il cliente riceverà la risposta. Non deve mai promettere l’esito prima dell’approvazione: una promessa poi rifiutata è peggio di una breve attesa.

Un human in the loop riduce la responsabilità dell’azienda per gli errori dell’agente AI?

No. Un’approvazione dimostra che una persona ha controllato l’azione, ma la responsabilità resta all’azienda, e un registro di approvazioni date senza controllo può dimostrare che la supervisione non era reale. Conservi il registro delle approvazioni, i tassi di override e le verifiche, così può dimostrare che i controlli hanno funzionato.