Supervisione umana degli AI agent: cosa richiede davvero l'AI Act europeo

La supervisione umana prevista dall'AI Act europeo significa che una persona identificata è in grado di capire cosa sta facendo il proprio agent, di sovrascriverne o interromperne le azioni, e di dimostrarlo a posteriori. Per la maggior parte degli agent questo si traduce in quattro elementi da costruire: un documento sulle capacità del sistema, un confine decisionale applicato a livello di codice, un controllo di arresto che fermi davvero il sistema, e un registro che tracci ogni decisione consequenziale insieme a chi l'ha presa. L'articolo 14 vincola solo i sistemi ad alto rischio, ma se si opera in ambito sanitario, HR, credito o settore pubblico, è opportuno considerarsi fin da subito in scope e progettare di conseguenza, piuttosto che dover fare un retrofit sotto pressione procurement.

A chi si applica davvero

L'articolo 14 si trova nel Capitolo III del Regolamento (UE) 2024/1689, il capitolo che stabilisce gli obblighi per i sistemi AI ad alto rischio. Se il proprio agent rientri o meno in questa categoria è determinato da due allegati. L'Allegato I riguarda i sistemi AI che costituiscono un componente di sicurezza di un prodotto regolamentato, inclusi i dispositivi medici. L'Allegato III elenca i casi d'uso: biometria, infrastrutture critiche, istruzione, occupazione e gestione dei lavoratori, accesso a servizi essenziali privati e pubblici, contrasto alla criminalità, migrazione e amministrazione della giustizia.

Tradotto in termini di agent:

• Non ad alto rischio: un agent WhatsApp che risponde a domande sui prodotti e suggerisce una taglia. Si applicano comunque le norme sulla trasparenza previste dall'articolo 50, che abbiamo approfondito in regole di trasparenza per gli AI agent nelle vendite.
• Ad alto rischio: un agent che smista i messaggi dei pazienti, valuta i candidati a un'offerta di lavoro, analizza un dossier di prestito o decide l'idoneità a un beneficio pubblico. Stesso stack, stesso modello, obblighi completamente diversi.

Gli obblighi dell'Allegato III erano previsti per il 2 agosto 2026. La scadenza è stata oggetto di proposte di modifica, quindi è opportuno verificare il testo consolidato aggiornato prima di impegnarsi su una data contrattuale. Ciò che non ha atteso la scadenza legale è il procurement: acquirenti ospedalieri e pubblici già richiedono documentazione sulla supervisione nelle gare d'appalto, ed è per questo che la questione ha rilevanza commerciale oggi.

Cosa chiede l'articolo 14, in termini chiari

L'articolo richiede che i sistemi ad alto rischio siano progettati in modo che le persone fisiche possano sorvegliarli efficacemente durante l'uso. Chi esercita la supervisione deve essere messo in condizione di:

• comprendere le capacità e i limiti del sistema e monitorarne il funzionamento per rilevare anomalie
• restare consapevole del rischio di automation bias, ossia la tendenza a fidarsi eccessivamente dell'output
• interpretare correttamente l'output, disponendo degli strumenti necessari
• decidere di non utilizzare il sistema, o di ignorare, sovrascrivere o annullare il suo output
• intervenire nel suo funzionamento o interromperlo tramite un pulsante di arresto o una procedura analoga

Due aspetti sono facili da trascurare. Primo: l'obbligo di incorporare queste misure ricade sul provider, ovvero su chi sviluppa o distribuisce il sistema, mentre l'obbligo di assegnare persone competenti ricade sul deployer. Secondo: l'articolo non dice mai che un essere umano deve approvare ogni azione. Le misure devono essere commisurate al rischio. Quella proporzionalità è lo spazio di progettazione disponibile, e lì si concentra la maggior parte delle decisioni di ingegneria.

Le quattro cose da costruire

1. Un documento sulle capacità del sistema

Un documento di una pagina, distribuito con il prodotto, che indichi a cosa serve l'agent, su cosa è stato testato, dove è noto che commette errori e cosa non deve mai fare. Può sembrare documentazione burocratica, ma è anche la specifica per i tre elementi successivi. Se non si riesce a scrivere cosa l'agent non deve mai fare, non si può nemmeno definire un confine.

2. Un confine decisionale applicato a livello di codice, non nel prompt

L'errore più comune che vediamo nelle demo di agent è un system prompt che dice "non inviare mai un messaggio senza approvazione" e nient'altro. Un prompt è un suggerimento a un modello probabilistico. Non è un sistema di permessi, e i report di Anthropic sulle azioni non intenzionali degli agent ricordano chiaramente che le istruzioni vengono ignorate sotto una pressione contestuale sufficiente.

È necessario dividere le azioni dell'agent in due liste. Autonome: recupero di dati, classificazione, riassunto, redazione, retrieval. Con gate: invio a un paziente, aggiornamento di un record, rifiuto di una candidatura, emissione di un rimborso sopra soglia. Poi applicare la separazione nel tool layer. L'agent dispone di un tool request_approval e non ha mai accesso a send_message. Il servizio di approvazione è codice deterministico ordinario con test ordinari. Approfondiamo il routing e i fallback in percorsi di escalation per gli AI agent, mentre il resto della lista di hardening si trova nella nostra checklist di sicurezza per AI agent.

3. Un controllo di arresto che fermi davvero il sistema

L'articolo 14 è esplicito sull'interruzione. Un vero controllo di arresto ha tre componenti: un flag che l'agent verifica prima di ogni chiamata a un tool, la cancellazione delle esecuzioni già in corso, e lo svuotamento del lavoro in coda, così da garantire che nulla riprenda automaticamente quando il flag viene ripristinato. È necessario testarlo periodicamente, come si testano i backup. Se fermare l'agent oggi significa chiedere a DevOps di portare un deployment a zero, non si ha un pulsante di arresto: si ha una procedura di emergenza.

4. Un registro di supervisione che dimostri qualcosa

Il registro è la parte che un regolatore, un revisore o un tribunale leggerà concretamente. Per ogni output consequenziale deve consentire di rispondere a cinque domande:

• Cosa ha visto l'agent? Input, documenti recuperati, versione del modello, versione del prompt.
• Cosa ha proposto? La bozza, la classificazione, la decisione raccomandata.
• Cosa ha fatto l'essere umano? Approvato, modificato, rifiutato, o non ha mai guardato.
• Chi era l'essere umano? Un'identità, non un account di servizio condiviso.
• Quando, e per quanto tempo? Una decisione approvata in meno di un secondo è una ratifica automatica, e il registro deve rendere questo visibile.

Il registro deve essere append-only, con la stessa disciplina descritta in architettura pronta per il contenzioso per l'AI in ambito sanitario.

Il nostro engine di outreach non è affatto ad alto rischio, ma è costruito in questo modo perché il registro è utile indipendentemente dalla normativa. Effettua lo scraping del sito di ogni prospect tramite un'istanza self-hosted di Firecrawl, e un LLM locale estrae i dati rilevanti e scrive in un'unica chiamata un'email personalizzata per ogni azienda. Questo pattern a chiamata singola ha superato una catena multi-step sia per costo che per qualità dell'output, con un effetto collaterale non previsto: i dati su cui si è basato il modello e la bozza prodotta escono dalla stessa chiamata, così il revisore vede le evidenze accanto alla conclusione, e per ogni email c'è un solo input e un solo output da archiviare, invece di dover ricostruire una catena di stati intermedi.

L'automation bias è il requisito che tutti saltano

L'AI Act nomina esplicitamente l'automation bias, ed è la misura che quasi nessun prodotto agent affronta. Se il pulsante di approvazione è l'elemento in focus predefinito, il revisore vede solo la risposta finale e la coda è lunga, la supervisione è teatro e il registro lo dimostrerà.

Tre scelte di design risolvono la maggior parte del problema:

• Mostrare le evidenze, non solo la risposta. Il passaggio recuperato, il dato estratto, la regola che ha determinato l'output.
• Nascondere il suggerimento su un campione di elementi. Lasciare che il revisore decida autonomamente su una frazione dei casi e confrontare i risultati.
• Monitorare il tasso di override per revisore. Zero override per settimane è un segnale d'allarme, non un indicatore di successo.

Quanto costa e come stimarlo

Progettata fin dal primo sprint, la supervisione è una parte contenuta dello sviluppo di un agent: il servizio di approvazione, il flag e lo schema del registro sono componenti piccoli e ben definiti. Aggiunta dopo il lancio, diventa una riscrittura del tool layer e una migrazione di tutte le esecuzioni storiche che si avrebbe voluto registrare. Quando si stima un agent ad alto rischio, è opportuno inserire questi quattro elementi esplicitamente nel contratto, piuttosto che sperare che emergano sotto la voce "sicurezza".

Se si sta valutando un'agenzia per questo tipo di lavoro, quattro domande distinguono un'implementazione reale da una presentazione:

1. Mostrami il controllo di arresto e l'ultima volta che è stato testato.
2. Mostrami un log entry completo per una decisione reale.
3. Quali azioni sono con gate e dove nel codice viene applicato?
4. Come rilevate che i revisori hanno smesso di revisionare?

Se state sviluppando un agent per un ospedale, un team HR, un istituto di credito o un ente pubblico e volete che superi il questionario di procurement e l'audit successivo, parliamone.