Dove gli agenti IA richiedono l’approvazione umana

01Gli agenti agiscono, quindi la domanda cambia

Un assistente conversazionale redige un testo e una persona decide che cosa farne. Un agente va oltre: richiama strumenti. Aggiorna un record, prenota uno slot, instrada una pratica, invia un messaggio o predispone un pagamento. Quando il software compie azioni, la domanda utile non è più soltanto «questa risposta è corretta?», ma «chi risponde di questa azione, e quando l’ha autorizzata?».

Chi si occupa di sicurezza ha già un nome per l’errore opposto. La OWASP Top 10 per le applicazioni basate su modelli linguistici di grandi dimensioni elenca l’excessive agency (apre un sito esterno) tra i rischi principali: un agente con più funzionalità, più permessi o più autonomia di quanto il compito richieda. L’approvazione umana è uno dei controlli possibili. Applicata ovunque, rallenta il lavoro e abitua le persone a cliccare «approva». Applicata da nessuna parte, lascia azioni che nessuno ha deciso. Il lavoro sta nel collocarla al posto giusto.

02Partire dalle azioni, non dal modello

Faccia l’inventario di tutti gli strumenti che l’agente può richiamare. Per ciascuno risponda a quattro domande. Riguardano volutamente l’azione e il suo effetto, non il modello.

1. 01Si può annullare? E a quale costo: un clic, una lettera di rettifica, un rimborso, una causa?
2. 02Chi ne è toccato? Una bozza interna, un collega, un cliente o un cittadino, del denaro, un terzo?
3. 03Crea un impegno o un effetto giuridico? Una decisione su una persona, un pagamento, un contratto, un messaggio inviato a nome della Sua organizzazione.
4. 04Con quale frequenza e a quale velocità? Un’azione che si ripete migliaia di volte al giorno richiede un controllo diverso da una che avviene due volte a settimana.

Le risposte collocano ogni azione in uno di quattro livelli. La maggior parte delle organizzazioni scopre che poche azioni concentrano quasi tutto il rischio, ed è una buona notizia: è lì che va investito lo sforzo di approvazione.

I livelli sono uno strumento di progettazione, non una classificazione giuridica. Li verifichi rispetto alle norme che si applicano alla Sua organizzazione. Il GDPR riconosce alle persone diritti specifici rispetto alle decisioni basate unicamente sul trattamento automatizzato (apre un sito esterno) che producono effetti giuridici o incidono in modo analogo significativamente su di loro (articolo 22). Per i sistemi ad alto rischio, il regolamento europeo sull’IA (AI Act) richiede che possano essere efficacemente supervisionati da persone fisiche (apre un sito esterno) (articolo 14). È di solito al livello 4 che questi obblighi trovano applicazione.

03I segnali che devono sempre arrivare a una persona

Alcune situazioni dovrebbero spostare un’azione al livello superiore, qualunque sia la sua collocazione abituale. Le preveda come controlli espliciti nel flusso di lavoro, in modo che non dipendano dalla capacità dell’agente di accorgersene.

• L’input esce da ciò su cui l’agente è stato testato: un nuovo tipo di documento, una lingua insolita, campi mancanti o contraddittori.
• Le fonti recuperate dall’agente sono in conflitto, oppure l’azione proposta si basa su qualcosa che l’agente non è in grado di citare.
• L’importo, la portata o il numero di record interessati supera una soglia da Lei stabilita.
• La pratica riguarda una categoria sensibile: dati sanitari, minori, un reclamo, una controversia o un ricorso in corso.
• L’agente ha già effettuato nuovi tentativi, oppure un sistema a valle ha restituito un errore.

Da questo elenco manca di proposito un segnale: la fiducia che il modello dichiara in sé stesso. I modelli linguistici possono affermare cose sbagliate con grande scioltezza, un fenomeno che il National Institute of Standards and Technology statunitense chiama confabulation (apre un sito esterno) nel suo profilo di rischio per l’IA generativa. Un punteggio autodichiarato può essere uno degli input, ma deve affiancare controlli esterni, come regole di validazione e il confronto con il sistema di riferimento, mai sostituirli.

04Progettare un’approvazione che le persone possano davvero dare

Una raffica di richieste «approvare?» insegna alle persone ad approvare. L’AI Act nomina il rischio in modo esplicito: chi sorveglia un sistema ad alto rischio deve poter restare consapevole della distorsione dell’automazione.

Quattro scelte di progettazione rendono concreta questa consapevolezza.

Mostrare le evidenze, non solo la risposta

Presenti l’azione proposta in parole semplici, le fonti su cui si basa (con link che si aprono al passaggio giusto), la regola o la policy applicata e che cosa cambierà esattamente, e in quale sistema. Un revisore che deve aprire tre applicazioni per controllare una proposta, sotto pressione, smetterà di controllare.

Rendere il «no» facile quanto il «sì»

Respingere e modificare sono esiti normali, non eccezioni. Li collochi accanto ad «approva», chieda una breve motivazione quando qualcuno respinge e utilizzi quelle motivazioni nella valutazione. Se modificare una proposta è più faticoso che scriverla da zero, le persone finiranno per approvare proposte imperfette.

Affidare l’approvazione a un ruolo con autorità

L’approvazione spetta a un ruolo designato, con la competenza, la formazione e l’autorità necessarie per scavalcare il sistema; per i sistemi di IA ad alto rischio l’AI Act chiede esattamente questo ai deployer (articolo 26, paragrafo 2 (apre un sito esterno)). Preveda un sostituto e un percorso di escalation, e misuri quanto a lungo le richieste restano in attesa. Una coda che non appartiene a nessuno diventa il collo di bottiglia che spinge i team ad aggirare il controllo.

Raggruppare solo ciò che è davvero a basso rischio

Esaminare uno per uno quaranta elementi quasi identici non rende nessuno più attento. Per le azioni di livello 2 consenta una revisione cumulativa con campionamento casuale. Mantenga individuali le azioni di livello 3 e 4.

05Applicare il controllo nel sistema, non nel prompt

Un’istruzione nel prompt non è un controllo degli accessi. I testi che l’agente legge, come un’e-mail, un documento o una pagina web, possono contenere istruzioni proprie, ciò che OWASP descrive come prompt injection (apre un sito esterno). Se tra un agente e un’azione irreversibile c’è soltanto una frase nelle sue istruzioni, dia per scontato che un giorno quella frase verrà scavalcata.

• Assegni all’agente un’identità propria con i privilegi minimi richiesti da ciascuno strumento e, dove la piattaforma lo consente, lo faccia operare entro i diritti dell’utente che ha fatto la richiesta.
• Applichi le approvazioni nel livello di integrazione: il servizio che invia la lettera rifiuta la chiamata se non esiste un’approvazione valida per quella precisa azione.
• Imponga agli strumenti limiti di valore, di volume e di frequenza, indipendenti dall’agente.
• Tenga separati gli strumenti di lettura da quelli di scrittura, così da poter ampliare ciò che l’agente può vedere senza ampliare ciò che può fare.

06Registrare ciò che bisognerà spiegare in seguito

Per ogni esecuzione dell’agente conservi la richiesta, le fonti recuperate, ogni chiamata a uno strumento con i relativi parametri, l’azione proposta, l’approvatore, la decisione, le eventuali modifiche e gli orari. Per i sistemi di IA ad alto rischio, i deployer devono conservare i log generati automaticamente per almeno sei mesi, salvo diversa disposizione di legge (articolo 26, paragrafo 6 (apre un sito esterno)). Dove nessuna norma lo impone, li conservi comunque: il log è il modo in cui si impara.

Analizzi i log a cadenza fissa. Le azioni approvate sempre senza modifiche sono candidate a scendere di livello. Le azioni modificate spesso indicano un punto debole dell’agente, oppure appartengono a un livello superiore. I rifiuti che si concentrano su una fonte, un modulo o un team rivelano di solito un problema di processo che nessun modello potrà risolvere.

07Partire in modo circoscritto, poi far scendere le azioni di livello

Avvii il servizio con le azioni più rilevanti ai livelli 3 e 4. Stabilisca in anticipo che cosa significa «funzionare bene»: quali esiti sono corretti, quali errori sono accettabili e quali no. Poi misuri rispetto a quei criteri, usando per esempio come lista di controllo le funzioni di misurazione del NIST AI Risk Management Framework (apre un sito esterno).

Sposti un’azione a un livello più leggero solo sulla base di evidenze: un periodo in cui le approvazioni non hanno richiesto modifiche sostanziali, test sui casi andati male e il via libera del responsabile del processo. Registri quella decisione come qualsiasi altra modifica al sistema e mantenga la possibilità di tornare indietro.

Gli output dell’IA possono essere sbagliati. Non è un motivo per tenere gli agenti lontani dal lavoro reale: è il motivo per progettare dove le persone restano al comando. Gli agenti sono utili perché possono agire. Collocare con criterio i punti di approvazione è ciò che permette di affidare loro, nel tempo, sempre più compiti.