Supervisione umana nei workflow AI: come progettare un controllo che funziona davvero
- Governance
- 7 settembre 2026
- 8 min di lettura
- Lucia Cenetiempo
- AI Advisor, DOABLE

“C’è sempre un controllo umano” è la frase più frequente nei progetti AI e spesso la meno vera. Cosa serve perché il controllo esista: criteri scritti, tempo dentro il processo, il potere di fermare. Con una matrice per scegliere il livello di verifica.
Se stai introducendo un workflow AI in un processo aziendale, progetta la supervisione umana come un passaggio del processo, con criteri scritti, tempo assegnato e una persona che può fermare o escalare un caso. Il controllo “implicito”, quello che tutti danno per scontato e nessuno descrive, è il punto in cui la maggior parte dei progetti diventa fragile.
Nelle presentazioni dei progetti AI la frase arriva puntuale: “ovviamente c’è sempre un controllo umano”.
Poi si va a vedere. Chi controlla non sa esattamente cosa cercare. Il tempo per farlo non è previsto da nessuna parte. Se qualcosa non va, non è chiaro chi possa bloccare l’output prima che arrivi al cliente. Il controllo esiste sulla carta e sparisce nel lavoro quotidiano, soprattutto quando i volumi crescono.
Il tema è anche regolatorio. Il Regolamento europeo sull’intelligenza artificiale, all’articolo 14, richiede per i sistemi ad alto rischio una sorveglianza umana efficace, con persone in grado di comprendere le capacità e i limiti del sistema, di interpretarne gli output e di intervenire o interromperne il funzionamento. L’articolo 26 affida a chi usa il sistema il compito di assegnare quella sorveglianza a persone con competenza, formazione e autorità adeguate. La maggior parte dei workflow aziendali non rientra nell’alto rischio, ma il principio è un buon standard di progettazione per qualsiasi processo.
Un controllo senza criteri è una firma. Un controllo con criteri è un passaggio del workflow.
Che cosa intendiamo per controllo umano
Intendiamo un passaggio esplicito del processo in cui una persona, con criteri definiti e tempo assegnato, verifica l’output prodotto con l’AI prima che abbia effetti, e può correggerlo, fermarlo o escalarlo.
Tre elementi lo rendono reale: sapere cosa cercare, avere il tempo per farlo dentro il processo e avere l’autorità per intervenire. Se ne manca uno, il controllo è nominale.
Il NIST AI Risk Management Framework colloca la supervisione nella funzione “Manage”: i rischi individuati vanno gestiti con meccanismi documentati, e la risposta agli incidenti deve essere pianificata prima che accadano. Tradotto in un workflow aziendale: il controllo si progetta insieme al processo, non si aggiunge dopo la prima segnalazione.
1. Decidi prima cosa può andare storto
Ogni workflow AI ha modi tipici di sbagliare: informazioni inventate, dati non aggiornati, un caso fuori perimetro trattato come normale, un tono inadatto, un’informazione riservata che finisce dove non dovrebbe.
Prima di progettare il controllo, elencali. Per ciascuno chiediti quanto è probabile, quanto costa se sfugge e quanto è facile riconoscerlo. Da questa lista nascono i criteri di verifica: non un generico “controlla che vada bene”, ma “verifica che ogni riferimento normativo citato esista nel documento sorgente”.
2. Scrivi i criteri di verifica
I criteri devono stare in una pagina e permettere a chi controlla di rispondere sì o no. Completezza: ci sono tutti gli elementi richiesti? Correttezza: le informazioni coincidono con le fonti autorizzate? Perimetro: il caso rientra tra quelli previsti? Forma: tono, lingua e formato rispettano lo standard?
Una checklist scritta rende il controllo trasferibile: chi sostituisce il collega in ferie sa cosa fare. E rende possibile misurarlo: quanti output sono stati corretti, per quale criterio, con quale frequenza.
3. Dai tempo al controllo dentro il processo
Un controllo che non ha tempo non esiste. Se il workflow AI produce un output in trenta secondi e la verifica ne richiede dieci minuti, quei dieci minuti devono essere nel processo, non a fine giornata.
Questo cambia anche il calcolo del beneficio: il tempo risparmiato è quello dell’intero processo, verifica inclusa. Un workflow che fa risparmiare venti minuti di produzione e ne aggiunge quindici di controllo vale cinque minuti, non venti.
4. Scegli il livello di controllo
Non tutti gli output richiedono lo stesso trattamento. Il livello dipende da due variabili: quanto costa un errore che sfugge e quanto spesso il caso si presenta.
| Costo dell’errore | Frequenza alta | Frequenza bassa |
|---|---|---|
| Basso e intercettabile dopo | Controllo a campione, con soglia di errore oltre la quale si passa al controllo totale | Controllo a campione o verifica dell’utente finale |
| Medio, recuperabile con costo | Approvazione prima dell’uso, con checklist | Approvazione prima dell’uso |
| Alto o irreversibile | Escludere il caso dal workflow AI finché non esistono controlli automatici affidabili | Escludere il caso e gestirlo con il processo tradizionale |
Matrice indicativa: va adattata al processo e rivista dopo le prime settimane di utilizzo.
La terza riga è quella che nelle demo si dimentica. Alcuni casi non vanno affidati al workflow AI, almeno all’inizio. Escluderli non è un fallimento del progetto: è una decisione di perimetro che lo rende sostenibile.
5. Stabilisci chi può fermare
La persona che controlla deve poter bloccare un output, escalare un caso e segnalare un problema senza chiedere permesso. Se per fermare un invio serve l’approvazione di un responsabile che non c’è, il controllo arriva tardi.
Va detto in modo esplicito anche il contrario: chi controlla non è responsabile degli errori del sistema, ma dell’applicazione dei criteri. Una supervisione che scarica sulla persona tutta la responsabilità dell’AI produce controlli difensivi e lentissimi, oppure firme automatiche.
6. Registra le eccezioni
Ogni caso fermato, corretto o escluso va annotato: cosa è successo, quale criterio ha fatto scattare il controllo, come è stato risolto. Un registro delle eccezioni di poche righe per caso è il materiale più prezioso del progetto.
Dopo un mese dice quali errori si ripetono, quali criteri non servono, quali casi vanno esclusi in modo permanente e quali si possono riportare dentro il perimetro. È così che il controllo migliora invece di restare fermo alla versione della demo.
Esempio: le offerte tecniche
Riprendiamo l’azienda B2B dell’articolo sulla scelta del primo processo: un workflow AI prepara la prima bozza delle offerte tecniche partendo dal CRM, dal catalogo e dalle offerte approvate. Esempio dimostrativo.
I modi di sbagliare individuati con il team: un prezzo non aggiornato, una specifica tecnica riferita a un prodotto diverso, una condizione contrattuale copiata da un’offerta non più valida. Il costo dell’errore è medio-alto: un’offerta sbagliata inviata al cliente si corregge, ma con un danno di credibilità.
Il livello scelto è l’approvazione prima dell’invio, con una checklist di sette punti compilata dal commerciale e, per le offerte oltre una certa soglia, una seconda verifica dell’ufficio tecnico. I casi con prodotti a catalogo da meno di tre mesi sono esclusi dal workflow, perché le fonti non sono ancora consolidate.
Dopo sei settimane il registro delle eccezioni mostra che l’errore più frequente riguarda le condizioni di pagamento copiate da offerte vecchie. La soluzione non è un controllo in più: è togliere dalle fonti le offerte con più di dodici mesi. Il controllo ha fatto il suo lavoro, indicando dove correggere il processo.
Segnali che il controllo esiste solo sulla carta
- Nessuno sa dire quanti output sono stati corretti nell’ultimo mese
- La verifica avviene “quando c’è tempo”, tipicamente a fine giornata
- Chi controlla non ha una checklist e usa il proprio giudizio caso per caso
- Per fermare un invio serve l’approvazione di qualcuno che non è nel processo
- Non esiste un registro delle eccezioni
- Il tempo di verifica non è conteggiato nel beneficio del workflow
Se riconosci tre o più di questi segnali, il progetto ha un problema di progettazione, non di tecnologia.
Dal controllo al playbook
Tutto quello che abbiamo descritto sta in un documento breve, il playbook del workflow: chi controlla, con quali criteri, in quanto tempo, quali casi sono esclusi, chi può fermare, dove si registrano le eccezioni e ogni quanto si rivede il tutto.
È uno dei materiali che consegniamo alla fine di un AI Adoption Program, insieme alla verifica a 30 giorni: la supervisione umana si progetta con il processo, si prova sui casi reali e si aggiusta con i dati del registro.
Fonti utilizzate
- Regolamento (UE) 2024/1689 sull’intelligenza artificiale, articoli 14 “Sorveglianza umana” e 26 “Obblighi dei deployer”.
- National Institute of Standards and Technology, AI Risk Management Framework 1.0, funzione Manage.
- ISO/IEC 42001:2023, sistema di gestione per l’intelligenza artificiale, requisiti su controlli operativi e miglioramento continuo.
Domande frequenti
Le domande che ci fanno più spesso su questo tema.
Un passaggio esplicito del processo in cui una persona, con criteri scritti e tempo assegnato, verifica l’output prima che abbia effetti e può correggerlo, fermarlo o escalarlo. Senza uno di questi tre elementi il controllo è solo nominale.
Chi conosce il processo e può giudicarne il risultato: di solito la persona che svolge il lavoro, con criteri condivisi con il responsabile della funzione. Per i casi a costo d’errore più alto si aggiunge un secondo livello di approvazione.
Dipende dal costo dell’errore e dalla frequenza. Errori a basso costo e intercettabili si controllano a campione con una soglia; errori a costo medio richiedono approvazione prima dell’uso; casi a costo alto o irreversibile vanno esclusi dal workflow AI.
Per i sistemi ad alto rischio sì: l’articolo 14 richiede una sorveglianza umana efficace e l’articolo 26 chiede a chi li usa di affidarla a persone con competenza, formazione e autorità adeguate. Per gli altri sistemi non è un obbligo specifico, ma resta un buon standard di progettazione.
Con il registro delle eccezioni: quanti output sono stati corretti, per quale criterio, con quale frequenza. Se dopo un mese nessuno sa rispondere, il controllo non sta avvenendo.


