Approvazioni umane: le azioni che richiedono sempre un sì esplicito

La regola pratica è una: più un'azione è attiva, difficile da annullare o impattante su persone e produzione, più deve richiedere un sì esplicito, nominativo e registrato. Questa checklist aiuta a classificare gli interventi degli agenti AI in tre categorie — informativo, proposto, attivo — e a fissare per iscritto i punti in cui il consenso non può mai essere presunto.

Classificare gli interventi: informativo, proposto, attivo

Prima di decidere chi approva cosa, serve una classificazione condivisa. Tre categorie coprono la quasi totalità dei casi:

La linea che conta è tra «propone» ed «esegue»: un agente può preparare qualsiasi intervento, ma esegue solo ciò che è stato approvato secondo la policy. La classificazione va adattata alla tua organizzazione: ciò che per un'azienda è un dettaglio, per un'altra è produzione critica. Come quadro di riferimento volontario per organizzare ruoli, responsabilità e gestione del rischio dei sistemi di intelligenza artificiale puoi usare il NIST AI Risk Management Framework del National Institute of Standards and Technology statunitense: non è una legge né una certificazione, ma una base riconosciuta per strutturare proprio questo tipo di decisioni.

Azioni ad alto impatto: sì esplicito sempre

Alcune categorie di intervento dovrebbero richiedere sempre un'approvazione esplicita, senza eccezioni né preautorizzazioni permanenti. Usa questa checklist per verificare la tua policy:

• Azioni sugli account delle persone: blocco, sospensione, modifica dei privilegi di un dipendente. La valutazione coinvolge un giudizio su una persona e non è delegabile.
• Modifiche ai confini di rete: regole firewall, segmentazione, nuove connessioni tra reti. Un errore qui apre o chiude servizi per l'intera azienda.
• Interventi su sistemi di produzione: riavvio, fermo o aggiornamento di ciò che tiene in piedi il lavoro. La finestra e le conseguenze le valuta chi conosce gli impegni operativi.
• Operazioni sui dati: cancellazione, spostamento, condivisione verso l'esterno. La reversibilità è bassa e l'impatto può essere normativo oltre che operativo.
• Modifiche ai controlli di sicurezza: disattivare o indebolire un controllo, cambiare le soglie di allarme, modificare le policy degli agenti stessi. Chi modifica i guardiani non dovrebbe mai essere il guardiato.
• Tutto ciò che esce dal perimetro concordato: un intervento non previsto dal piano va fermato e portato a una decisione umana, sempre.

Per i sistemi industriali vale un vincolo ulteriore: il controllo di processo e la sicurezza dell'impianto restano ai responsabili dell'impianto stesso; qualsiasi proposta su macchine e dispositivi operativi passa dalla loro valutazione, come descritto nell'articolo sui limiti operativi degli agenti sui sistemi critici.

Come evitare che il silenzio diventi consenso

Il modo più subdolo in cui una policy di approvazione fallisce è l'inerzia: la richiesta arriva, nessuno risponde, e dopo un certo tempo il sistema procede «per non bloccare il lavoro». È il momento esatto in cui la supervisione smette di esistere. Quattro regole pratiche lo impediscono:

• Il silenzio non autorizza, per iscritto. La policy deve dichiarare che la mancata risposta non è un'approvazione. Nel modello di OverZeus il principio è esplicito: l'assenza di riscontro non viene interpretata come autorizzazione e l'intervento attivo non parte.
• Le richieste scadono. Un'approvazione ha una durata; una richiesta senza risposta non resta «aperta per sempre» come via laterale, ma viene riproposta o chiusa come non autorizzata.
• La richiesta va a una persona, non a un gruppo generico. Se tutti possono approvare, spesso non approva nessuno: la responsabilità nominativa vale anche per il silenzio.
• Il mancato intervento è uno stato previsto. Cosa succede se nessuno risponde di notte va deciso prima: osservazione rafforzata, misure passive già autorizzate, escalation al mattino. Mai l'esecuzione automatica dell'azione attiva.

Registrare esito, motivazione e responsabile

Un'approvazione che non lascia traccia è un'approvazione a metà. Per ogni decisione — sì o no che sia — il registro dovrebbe conservare almeno: chi ha deciso, cosa è stato approvato o rifiutato, quando, con quale motivazione e quale contesto era stato presentato. Vale anche per i rifiuti e per le attese: la scelta di non intervenire è una decisione, e fra sei mesi deve essere ricostruibile quanto un intervento. La conservazione completa delle evidenze — fonti, timeline, proposte, autorizzazioni ed esiti — è un tema che merita un approfondimento dedicato: lo trovi nell'articolo sulla tracciabilità delle azioni degli agenti.

Esempio illustrativo: l'accesso anomalo del sabato

Esempio illustrativo. Lo scenario seguente è inventato per mostrare il meccanismo; non descrive un evento reale né un cliente.

Una società di servizi ha classificato i suoi interventi con la tabella a tre categorie. Il sabato pomeriggio l'agente segnala un accesso amministrativo fuori orario su un server di fatturazione e propone la sospensione dell'account coinvolto: categoria attiva ad alto impatto, perché riguarda una persona e un sistema di produzione. La policy prevede il sì esplicito del responsabile sicurezza, con sostituto nominato. Il responsabile riceve la proposta nell'app con contesto completo — account, dispositivo, orario, attività recenti — e sceglie una terza via prevista: richiede una verifica prima di sospendere. La verifica mostra una manutenzione pianificata da un fornitore, dimenticata nel registro delle attività. Il rifiuto della sospensione viene registrato con la motivazione, insieme alla lacuna organizzativa emersa. Se invece la verifica avesse confermato l'anomalia, il sì avrebbe autorizzato la sola sospensione descritta nel piano, con durata e verifiche successive. In entrambi i rami, nessuna azione attiva senza una decisione umana esplicita.

Il ruolo di Hermes, Themis e Mnemosyne

In OverZeus tre agenti sostengono questa catena. Hermes, l'app dei responsabili, riceve le segnalazioni dal server locale, spiega gli interventi proposti e raccoglie approvazioni o rifiuti: il responsabile vede piano, risorse coinvolte e conseguenze prima di decidere. Themis applica privilegi, approvazioni e limiti operativi con controlli esterni al modello AI: verifica che l'intervento autorizzato corrisponda a destinatario, risorse, operazioni e durata dell'autorizzazione, e blocca l'avvio di un'operazione che arriva con un'approvazione scaduta o non valida. Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti, e segnala quando una modifica compare senza il riferimento autorizzativo previsto, senza inventare ricostruzioni. La distinzione quotidiana tra notifica, proposta e decisione è approfondita nell'articolo sulla supervisione umana degli agenti.

La policy in una pagina

Una buona policy di approvazione sta in una pagina: le tre categorie, l'elenco delle azioni ad alto impatto che richiedono sempre un sì, i nomi di chi approva per fascia oraria, la dichiarazione che il silenzio non autorizza e le regole di registrazione. Se serve un manuale per capire chi deve approvare cosa, la policy va semplificata prima che gli agenti inizino a lavorare.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus