Autonomia limitata degli agenti AI: il prerequisito per assicurare la governance
Un agente AI che prenota voli, firma ordini di acquisto o muove fondi senza una mano umana su ogni passaggio non è più uno scenario da laboratorio: è già in produzione in molte aziende. La promessa è seducente, ma chi deve coprire il rischio (il consiglio di amministrazione prima, l'assicuratore poi) si pone una domanda molto concreta: fino a dove può spingersi quell'agente da solo, e cosa succede quando supera il limite?
Qui nasce il problema. La maggior parte dei team tratta l'autonomia come una manopola da girare verso il massimo, perché "più autonomo" sembra sinonimo di "più efficiente". Per chi valuta il rischio assicurativo, invece, un agente senza confini documentati è semplicemente non quotabile: manca l'elemento che permette di stimare la perdita massima probabile. Il sottoscrittore non chiede se l'agente è intelligente, chiede dove si ferma.
La risposta governante di questo approfondimento è netta: l'autonomia limitata (bounded autonomy) non è una rinuncia alla potenza dell'AI agentica, ma il prerequisito che rende l'agente governabile e, soprattutto, assicurabile. Vincoli documentati, soglie di escalation verso l'umano e un registro di eventi certificato compongono un quadro unico che soddisfa in un colpo solo l'articolo 12 dell'AI Act sulla conservazione dei log e i criteri con cui un assicuratore valuta il rischio. Senza questo strato, la responsabilità resta sospesa e la copertura diventa impossibile da prezzare.
Questo approfondimento fa parte della guida: Responsabilità legale dell'AI agentica: chi risponde quando l'agente sbaglia
Cos'è l'autonomia limitata e perché l'assicuratore la pretende
L'autonomia limitata (bounded autonomy) è un modello di progettazione in cui l'agente AI opera con piena libertà decisionale solo dentro un perimetro definito a priori. Oltre quel perimetro l'azione non viene eseguita: viene sospesa, registrata e passata a un essere umano. Non è un freno alla capacità dell'agente, ma la trasformazione di un sistema imprevedibile in un sistema con un comportamento limite noto, e quindi quantificabile.
La differenza pesa proprio sul tavolo del sottoscrittore. Un assicuratore non assicura ciò che non può misurare. Per quotare una polizza serve una stima della perdita massima probabile: l'importo peggiore che un singolo malfunzionamento può generare. Con un agente a autonomia piena questo numero tende all'infinito, perché una catena di decisioni errate può propagarsi senza limite. Con un agente a autonomia limitata, invece, il tetto di spesa per transazione, il numero massimo di operazioni e l'ambito d'azione fissano un soffitto preciso al danno potenziale. Il rischio diventa una grandezza finita, e ciò che è finito si può prezzare.
Il principio non è nuovo per chi viene dal mondo assicurativo: è la stessa logica del massimale e della franchigia, applicata al comportamento di un software. Come abbiamo già visto nella guida sulla responsabilità legale degli agenti AI, il nodo non è "di chi è la colpa" in astratto, ma chi può dimostrare cosa è realmente accaduto, entro quali limiti e con quali prove.
I tre vincoli che rendono un agente quotabile
Un quadro di autonomia limitata difendibile poggia su tre componenti che l'assicuratore esamina uno per uno:
- Vincoli documentati: limiti espliciti e versionati su cosa l'agente può fare. Tetto economico per operazione, lista chiusa di azioni consentite, dati a cui può accedere. Devono essere scritti, non impliciti nel codice.
- Soglie di escalation: regole che obbligano l'agente a fermarsi e a chiamare un umano quando un parametro supera un valore critico. Una transazione sopra una certa cifra, un'anomalia rispetto allo storico, un'azione fuori dall'orario operativo.
- Registro certificato degli eventi: la prova, conservata e immodificabile, che i primi due elementi hanno effettivamente funzionato. Senza questa traccia, vincoli e soglie restano dichiarazioni di intenti.
I primi due elementi riguardano la progettazione. Il terzo riguarda la dimostrabilità, ed è il punto dove la maggior parte delle implementazioni cade.
Perché l'articolo 12 dell'AI Act e il sottoscrittore chiedono la stessa cosa
L'articolo 12 del Regolamento UE sull'intelligenza artificiale impone ai sistemi ad alto rischio la registrazione automatica degli eventi (logging) lungo l'intero ciclo di vita, con un livello di tracciabilità adeguato alla finalità del sistema. Tradotto: il sistema deve tenere traccia di cosa ha fatto, quando e in quali condizioni, in modo che gli eventi rilevanti per la sicurezza e per la conformità siano ricostruibili a posteriori.
Il sottoscrittore assicurativo, dal canto suo, chiede esattamente lo stesso, solo con un altro vocabolario. Per valutare il rischio e, soprattutto, per liquidare un sinistro, ha bisogno di sapere se l'agente operava dentro i propri limiti nel momento del danno. Se il registro mostra che l'agente ha rispettato vincoli e soglie, il caso è un malfunzionamento coperto. Se mostra che li ha violati, o se il registro non esiste o è contestabile, la copertura può saltare. La traccia degli eventi è la cerniera tra la conformità normativa e la liquidazione del danno.
Questa convergenza è la leva strategica dell'autonomia limitata: un solo strato di evidenze serve due padroni. Lo stesso registro che dimostra al regolatore il rispetto dell'articolo 12 dimostra all'assicuratore che il rischio è rimasto dentro i confini pattuiti. Non sono due adempimenti separati, ma due letture dello stesso fatto certificato.
Cosa rende un registro opponibile a un terzo
Non tutti i log sono uguali. Un file di log che vive nello stesso sistema che ha generato l'azione, modificabile da chiunque abbia accesso amministrativo, ha scarso valore davanti a un giudice o a un perito assicurativo: chi lo contesta dirà che è stato alterato dopo il fatto. Perché una traccia regga davvero servono tre proprietà:
- Integrità all'origine: l'evento viene fissato nel momento esatto in cui accade, prima che chiunque possa intervenire.
- Marca temporale qualificata: una data e un'ora certe, riconosciute legalmente, che nessuno può retrodatare.
- Immodificabilità verificabile: chiunque, anche una controparte ostile, deve poter verificare che il registro non è stato toccato dopo la creazione.
Senza queste proprietà, il registro racconta una storia che la controparte può riscrivere. Con queste proprietà, diventa una prova. È la differenza tra annotare e certificare.
Come TrueScreen trasforma i vincoli in prove certificate
Definire vincoli e soglie è un esercizio di progettazione che il team tecnico può affrontare da solo. Renderli dimostrabili a un terzo (un regolatore, un giudice, un sottoscrittore) è un problema diverso, ed è qui che entra TrueScreen. La piattaforma non decide al posto dell'agente: certifica ciò che l'agente fa, nel momento in cui lo fa, con valore legale.
Attraverso il connettore MCP, TrueScreen si collega all'agente AI e acquisisce ogni evento rilevante (la decisione, il superamento di una soglia, l'escalation verso l'umano) applicando la propria metodologia forense: acquisizione dell'evento all'origine, verifica della sua integrità e certificazione con un sigillo digitale e una marca temporale qualificata. Il sigillo e la marca non sono prodotti da TrueScreen: la piattaforma integra il sigillo di un QTSP qualificato terzo via API, così la certificazione ha valore legale riconosciuto a livello internazionale. Il risultato è un registro degli eventi dell'agente che nasce già immodificabile e opponibile, non un log che speriamo regga.
Per il responsabile della conformità questo significa poter dimostrare il rispetto dell'articolo 12 con prove che non si possono contestare. Per chi presenta il rischio all'assicuratore significa portare al tavolo un fascicolo di evidenze che fissa il perimetro dell'agente e ne dimostra il rispetto operazione per operazione. La stessa logica che applichiamo alla certificazione dei dati prodotti dagli agenti AI vale qui per le decisioni: ciò che non è certificato all'origine resta contestabile per sempre.
Vale la pena chiarire cosa TrueScreen non fa. Non sostituisce il giudizio umano nelle escalation, non impedisce all'agente di sbagliare e non rileva se un modello "mente". Garantisce un'altra cosa, più solida: che esista una versione dei fatti certificata e incontestabile su cui regolatore, azienda e assicuratore possono ragionare con gli stessi dati. È la base su cui si costruisce la provenienza digitale delle azioni di un agente.
Dal log tecnico al fascicolo assicurabile
La tabella seguente mette a confronto le due letture dello stesso strato di evidenze, mostrando perché un unico registro certificato chiude due esigenze diverse.
| Elemento del quadro | Lettura conformità (AI Act Art. 12) | Lettura assicurativa (sottoscrizione) |
|---|---|---|
| Vincoli documentati | Definizione della finalità e dei limiti del sistema ad alto rischio | Tetto alla perdita massima probabile per operazione |
| Soglie di escalation | Tracciabilità degli eventi che richiedono supervisione umana | Trigger che separano l'errore coperto dalla negligenza esclusa |
| Registro certificato | Conservazione automatica dei log lungo il ciclo di vita | Prova opponibile dello stato dell'agente al momento del sinistro |
| Marca temporale qualificata | Ricostruibilità cronologica degli eventi rilevanti | Data certa che impedisce la retrodatazione in fase di liquidazione |
Letta in questo modo, l'autonomia limitata smette di essere un vincolo subito e diventa un asset negoziale: l'azienda che porta all'assicuratore un agente con confini certificati ottiene una copertura quotabile, mentre chi presenta una scatola nera resta non assicurabile a qualunque premio.
