L’agente ha capito la richiesta, recuperato il cliente dal CRM, preparato il preventivo e proposto uno sconto dell’8% per volume. Il testo è buono. I numeri sembrano plausibili. Manca un solo passaggio: inviare.
Proprio quel passaggio cambia la natura del processo. Prima l’agente stava preparando lavoro. Dopo l’invio l’azienda ha comunicato un prezzo reale a un cliente reale.
Nelle PMI il concetto di human-in-the-loop viene spesso implementato male: o una persona approva ogni dettaglio, oppure dovrebbe genericamente “sorvegliare” un agente che in realtà può già agire. Una struttura più utile è Draft → Approve → Execute. L’agente prepara una transazione concreta; una persona autorizzata verifica la parte che conta; il sistema esegue solo dopo.
È una raccomandazione di architettura e governance, non una regola di legge universale. Serve a rendere visibili le conseguenze prima che escano dall’azienda.
Draft Approve Execute separa preparazione e autorità
Un modello linguistico può raccogliere dati, proporre testo e suggerire un’azione. L’autorità aziendale di promettere un prezzo, emettere un rimborso, cancellare un record o confermare definitivamente una prenotazione è un’altra cosa.
L’AI Risk Management Framework di NIST include governance e gestione continuativa del rischio. La Convenzione del Consiglio d’Europa sull’IA richiama principi di supervisione, responsabilità, trasparenza e affidabilità. Nessuno dei due dice che ogni attività di una PMI debba essere approvata manualmente. La lezione operativa è che il livello di controllo dovrebbe seguire la conseguenza.
Una buona bozza deve quindi includere la base decisionale: fatti usati, regola applicata, calcolo, eventuale deviazione e azione prevista.
Il revisore non dovrebbe ricostruire il ragionamento partendo da zero.
L’approvazione va messa sul confine della transazione
Se una persona approva ogni correzione ortografica, l’human-in-the-loop diventa una tassa sull’automazione. Se viene informata dopo che l’offerta è partita, non sta approvando nulla.
Il confine utile si trova normalmente subito prima di un effetto verso cliente, denaro, contratto o dati difficili da ripristinare.
Un tag interno può essere automatico sotto regole strette. Una proposta di appuntamento può restare bozza. Uno sconto fuori standard, un rimborso, un export di dati o una prenotazione definitiva meritano invece una decisione esplicita.
Raccomandazione: create tre classi: basso rischio e reversibile; conseguenza significativa ma controllabile; impegno o azione difficile da annullare. Le soglie devono riflettere il vostro business.
Esempio: un’officina può inviare automaticamente “abbiamo ricevuto la richiesta”. L’agente può proporre una fascia oraria. Non dovrebbe promettere costo e diagnosi sulla base di una foto senza il professionista che dovrà realmente eseguire il lavoro.
Il pulsante Approva senza contesto diventa un’abitudine
Un’interfaccia che dice soltanto “L’agente vuole agire. Approva?” crea velocemente rubber-stamping.
La scheda utile mostra cosa succede, quali dati contano, cosa è fuori standard, chi riceverà l’effetto e quanto è reversibile.
Preventivo: prezzo standard CHF 4'800; proposta CHF 4'416; motivo: regola volume; soglia automatica: 5%; sconto attuale: 8%; quindi richiesta approvazione.
Il venditore controlla il punto decisionale, non rilegge l’intero CRM.
Servono inoltre più scelte: approva, modifica ed esegui, rifiuta, escalation. Se il sistema accetta solo sì/no, le eccezioni finiranno in chat ed email fuori dal processo.
Un flusso abbastanza piccolo da essere adottato
La prima versione può concentrarsi su una sola transazione.
- Scegliete l’azione. Invio preventivo, conferma appuntamento o variazione di stato.
- Separate bozza e commit tecnicamente. Generare il risultato non deve chiamare automaticamente l’endpoint che produce l’effetto reale.
- Definite i trigger di approvazione. Importo, sensibilità dei dati, deviazione, tipo cliente o irreversibilità.
- Mostrate il contesto minimo utile. I fatti necessari alla decisione e l’eccezione, non l’intero trace.
- Registrate la scelta. Chi ha approvato, modificato, rifiutato o escalato?
- Verificate l’esecuzione. Il sistema target deve confermare che l’azione approvata è stata realmente completata.
L’approvazione da sola non significa “lavoro fatto”. Se l’API fallisce, il caso deve restare visibile come pendente o errore.
Quando l’umano può uscire dalla loop
Un buon processo non cerca di massimizzare per sempre il lavoro manuale. Dopo uso reale, una classe precisa di azioni può risultare stabile, facilmente reversibile e con impatto limitato. Quella classe può passare all’esecuzione automatica.
Un tag interno da una lista chiusa è un buon candidato. Nuove coordinate bancarie, cancellazioni, impegni contrattuali o prezzi insoliti non sono equivalenti.
Misurate approval rate, modifiche prima dell’esecuzione, rifiuti/escalation, tempo dalla bozza alla decisione, errori dopo esecuzione approvata e casi in cui manca contesto al revisore.
Un approval rate del 99% può significare bozze eccellenti oppure persone che cliccano senza leggere. Campionate le decisioni e osservate le correzioni reali.
human-in-the-loop non significa mettere una persona in un punto qualsiasi del diagramma. Mettetela dove una proposta diventa un impegno, mostrate ciò che serve a decidere e conservate una vera possibilità di modificare o fermare. Così l’agente può fare molto lavoro senza acquisire per sbaglio l’autorità dell’azienda.
Un dettaglio spesso dimenticato è la scadenza dell’approvazione. Se una bozza è stata approvata alle 09:10 ma l’esecuzione avviene alle 15:00, nel frattempo prezzo, disponibilità o destinatario possono essere cambiati. Per le azioni con effetto esterno, l’oggetto approvato dovrebbe quindi contenere i dati essenziali che verranno realmente eseguiti — destinatario, importo, slot, testo finale — e una regola che renda l’approvazione non più valida quando questi dati cambiano.
Questo evita il falso controllo in cui una persona approva “l’idea” e l’agente esegue una versione successiva diversa. Se il payload cambia in modo materiale, si torna allo stato draft e serve una nuova approvazione. Le modifiche puramente tecniche, come un retry con la stessa idempotency key, non dovrebbero invece chiedere una seconda decisione umana.
I permessi e audit log definiscono l'azione. Un arresto d'emergenza con rollback protegge l'operatività.
Fonti
FAQ
Ogni azione dell’agente deve essere approvata?
No. Azioni strette, reversibili e a basso impatto possono essere automatiche. L’approvazione va riservata alle conseguenze importanti.
Cosa deve mostrare la schermata di approvazione?
Azione prevista, dati decisivi, deviazione dalla regola, conseguenza e motivazione essenziale.
È un obbligo legale?
Non come regola universale per tutte le automazioni IA. È un pattern operativo; obblighi specifici dipendono dal caso.
Cosa succede se l’esecuzione fallisce dopo l’approvazione?
Il caso resta visibile come fallito o pendente e va verificato nel sistema target prima di un retry.
Quando si può eliminare l’approvazione?
Quando una categoria molto precisa è stata testata in produzione ed è sufficientemente prevedibile, reversibile e poco critica.