Chi paga i danni di un agente AI: la risposta arriva da due testi europei e da un file di log. Il Regolamento UE 2024/1689 chiede la registrazione degli eventi ai sistemi ad alto rischio. La direttiva (UE) 2024/2853 sulla responsabilità per prodotti difettosi porta invece a presumere il difetto quando le prove richieste restano fuori dal processo.
In mezzo sta la pratica di ogni giorno: un agente che tocca contabilità e pagamenti lascia una traccia, oppure lascia un vuoto.
Il registro delle azioni è l'unico testimone
Il Regolamento UE 2024/1689, articolo 12, chiede ai sistemi ad alto rischio la registrazione automatica degli eventi per tutta la durata di vita del sistema. La norma tocca la progettazione, prima delle scelte operative: il sistema deve essere capace di registrare.
Quando un agente sbaglia un pagamento, il suo registro resta l'unico testimone della sequenza.
Le persone ricordano l'esito. Il registro conserva l'ordine dei passaggi: quale documento è entrato, quale strumento è stato chiamato, con quale parametro, a quale ora. Chi vuole ricostruire la catena della decisione ha bisogno di quella traccia, leggibile anche da terzi.
Sei mesi di conservazione, e chi risponde
L'articolo 19 mette in capo ai fornitori la conservazione dei log generati dai loro sistemi ad alto rischio. Il periodo minimo è di sei mesi, salvo termini diversi fissati dal diritto dell'Unione o nazionale.
L'articolo 26, paragrafo 6, ripete l'obbligo per i deployer, cioè per le aziende che usano il sistema nella propria attività.
Le istituzioni finanziarie hanno una regola in più: tengono i registri dentro la documentazione già richiesta dal diritto dell'Unione sui servizi finanziari. Per una banca il log dell'agente diventa quindi documentazione di vigilanza. Cambiano i tempi, cambia il formato, cambia chi lo può chiedere.
Ad alto rischio: il perimetro e la data del 2 dicembre 2027
Questi obblighi valgono per i sistemi ad alto rischio, quindi il perimetro va definito prima di tutto il resto. Un assistente che riassume email interne resta fuori; un sistema che valuta il merito creditizio di una persona fisica rientra nell'allegato III.
Per i casi dell'allegato III l'Omnibus digitale ha spostato l'applicazione al 2 dicembre 2027.
Quella data è una finestra di progetto. Chi firma oggi un contratto di tre anni su una piattaforma agentica compra un sistema che dovrà risultare conforme prima della scadenza del contratto. La domanda per il comitato acquisti diventa quindi contrattuale: il fornitore garantisce il logging a norma entro quella data, con quale penale?
La direttiva 2024/2853 presume il difetto
La direttiva (UE) 2024/2853[1] tratta il software come prodotto. L'articolo 9 permette al giudice di ordinare al convenuto la divulgazione delle prove rilevanti in suo possesso.
L'articolo 10, paragrafo 2, lettera a), aggiunge la conseguenza: il difetto si presume quando il convenuto omette quella divulgazione.
Qui sta il punto che interessa a chi costruisce. Un'architettura priva di log verificabili crea un'impossibilità di prova, e la norma la legge a sfavore di chi la subisce. Il debito tecnico sull'osservabilità diventa debito processuale.
Fra imprese decide il contratto
Fra imprese la partita si gioca sul contratto. La direttiva protegge la persona danneggiata; il rapporto fra cliente e fornitore di piattaforma corre invece su clausole, livelli di servizio e limiti di responsabilità. In quella lite il registro dice chi ha causato l'errore.
Tre casi tipici, con esiti opposti. Il modello ha prodotto un output errato su dati corretti. L'orchestratore ha passato all'agente un contesto già sporco. L'operatore ha approvato una proposta segnalata come dubbia.
Ognuno di questi casi sposta la responsabilità su un soggetto diverso. E ognuno si distingue dagli altri unicamente con la traccia di esecuzione, campo per campo. Una perizia che arriva due anni dopo lavora su ciò che il sistema ha scritto allora.
Le polizze sulla prestazione dell'AI chiedono misure
Il mercato assicurativo ha iniziato a scrivere coperture dedicate alla prestazione dei sistemi di AI, accanto alle polizze classiche di responsabilità civile e cyber. L'oggetto cambia: si assicura lo scostamento fra il risultato promesso e il risultato prodotto.
Una copertura di questo tipo vive di misurazione. Per liquidare un sinistro serve mostrare l'errore, la sua data e il suo effetto economico.
L'underwriting segue la stessa logica. Chi vende la polizza guarda il disegno dei controlli, la qualità del logging e i tempi di conservazione. Chi porta registri parziali paga di più, oppure resta escluso dalla copertura. Il logging esce così dal capitolo compliance ed entra nel prezzo del rischio.
Cosa deve registrare un agente su contabilità e pagamenti
Un agente che opera su contabilità e pagamenti va disegnato intorno a una domanda sola: chi ha deciso cosa, con quale delega, su quali dati, in quale momento. Ogni campo del registro risponde a un pezzo di quella domanda.
- Identità dell'agente: credenziale propria, mai quella condivisa dell'utente umano.
- Delega attiva: ambito, soglie di importo, controparti ammesse, scadenza del mandato.
- Versione: modello, prompt di sistema, catalogo degli strumenti, con impronta di ciascuno.
- Input recuperati: identificativo e hash di ogni documento entrato nel contesto.
- Chiamate agli strumenti: parametri, esito, codice di errore, tentativi ripetuti.
- Approvazione umana: chi ha approvato, cosa ha visto a schermo, in quale istante.
- Ora: marca temporale sincronizzata, sorgente dichiarata, fuso espresso in UTC.
- Integrità: scrittura in append, catena di hash, supporto immodificabile.
Due dettagli separano un registro utile da un file di debug. Il primo è il legame fra la proposta dell'agente e il movimento contabile, tenuto con un identificativo comune che regge anche a valle, dentro il sistema di pagamento. Il secondo è la registrazione delle azioni respinte: la difesa passa spesso dal mostrare ciò che il controllo ha fermato.
Il registro deve poi restare leggibile anche da chi è estraneo al codice. Un revisore esterno apre il file e deve capire, riga per riga, quale mandato copriva l'azione. Questo requisito cambia il formato: nomi di campo stabili, valori espliciti, versioni dichiarate.
Tre domande per il team che porta agenti in produzione
Le domande utili prima del prossimo rilascio su processi finanziari sono tre.
- Il registro regge come prova davanti a un terzo, oppure serve un ingegnere per leggerlo?
- La conservazione arriva ai sei mesi minimi, e per le attività finanziarie ai tempi della documentazione di vigilanza?
- Il fornitore esporta i log in formato aperto, oppure li tiene dentro il proprio ambiente?
La terza pesa più delle altre. Un log che vive unicamente nella console del fornitore crea lock-in architetturale sulla prova: al momento della lite l'azienda dipende dalla controparte tecnologica per dimostrare la propria diligenza.
Decisioni per il prossimo ciclo di pianificazione: export dei log come requisito contrattuale, catena di hash su ogni operazione che muove denaro, identità nominativa per ogni agente. Va rivista anche la clausola di responsabilità, alla luce della direttiva 2024/2853.
Il registro è infrastruttura di difesa. Si costruisce prima del danno, perché dopo resta soltanto ciò che è stato scritto.
Questo articolo è stato redatto da un autore editoriale AI con supervisione umana, in conformità agli obblighi di trasparenza del Regolamento (UE) 2024/1689 (AI Act, Art. 50). Le fonti sono linkate nel testo.
Article by LEON
Fonti
- direttiva (UE) 2024/2853 (publications.europa.eu)