Certificazione dei dati per agenti AI: governance, compliance e responsabilità legale

Gli agenti AI stanno cambiando il modo in cui le aziende lavorano. Nel settore assicurativo processano richieste di risarcimento in autonomia. Negli studi legali analizzano contratti e producono pareri. Nelle direzioni HR filtrano candidati. In finanza eseguono transazioni e generano report di compliance. La certificazione dell'intelligenza artificiale e i suoi output diventano una priorità. La loro adozione sta accelerando: secondo le stime del settore, il mercato globale dell'AI governance raggiungerà i 15 miliardi di dollari entro la fine del 2026, trainato dall'esplosione dell'IA agentica nelle operazioni aziendali.

Il punto è che più un agente AI diventa autonomo, più il suo processo decisionale diventa opaco. Un agente che oggi analizza documenti, domani negozierà contratti, interagirà con clienti, gestirà processi con margini di errore minimi. Eppure la maggior parte delle aziende che li adotta non ha un sistema per rispondere alla domanda che conta davvero: come dimostrare cosa un agente AI ha ricevuto, cosa ha fatto e cosa ha prodotto?

Un semplice log tecnico non basta. Serve la certificazione dei dati con valore legale, applicata a ogni fase del ciclo di vita dell'agente. Una certificazione che renda i dati immutabili, con data certa e opponibili a terzi, esattamente come prevedono le migliori linee guida internazionali per la gestione di dati con valore probatorio.

Il regolamento europeo sull'intelligenza artificiale (AI Act) impone obblighi di tracciabilità per i sistemi ad alto rischio a partire da agosto 2026. La Product Liability Directive, in vigore da dicembre 2026, estende la responsabilità oggettiva ai software AI. Chi implementa agenti AI senza certificare i propri dati si espone a sanzioni fino a 15 milioni di euro o il 3% del fatturato globale, e a un vuoto probatorio in caso di contenzioso. Non si tratta di un'opzione, ma di un obbligo normativo e di una tutela legale necessaria.

Perché gli agenti AI creano un problema di fiducia nei dati

Gli agenti AI, o IA agentica, sono sistemi autonomi capaci di pianificare, decidere e agire senza intervento umano diretto. A differenza dei chatbot tradizionali, un agente AI può richiamare strumenti esterni, interrogare database, produrre documenti, inviare comunicazioni e prendere decisioni con conseguenze operative e legali concrete. Secondo le stime di settore, oltre il 40% delle grandi imprese europee sta sperimentando agenti AI nei propri processi nel 2026. Il problema è che questa autonomia operativa non è accompagnata da un livello equivalente di tracciabilità dei dati: la maggior parte delle implementazioni aziendali utilizza log applicativi modificabili che non hanno alcun valore probatorio. Il risultato è un gap tra la capacità decisionale dell'agente e la capacità dell'organizzazione di dimostrare come quelle decisioni sono state prese, su quali dati e con quali istruzioni.

Secondo un report di UC Berkeley Sutardja Center, l'agentic AI segna il passaggio dall'intelligenza artificiale come strumento consultivo all'AI come agente operativo. Non è più un sistema che suggerisce: è un sistema che agisce. E quando un sistema agisce, la governance dei dati che lo alimentano e che produce diventa una priorità per l'intera organizzazione.

Questo grado di autonomia genera tre problemi seri.

Il paradosso dell'autonomia

Quanto più un agente opera in modo indipendente, tanto meno è visibile il percorso che lo ha portato a una decisione. Un agente che analizza cinquanta documenti assicurativi e produce una raccomandazione di rigetto non lascia, di default, una traccia verificabile del proprio ragionamento. Il dato di partenza potrebbe essere stato corrotto. Le istruzioni potrebbero essere state ambigue. Il ragionamento interno potrebbe aver generato un'allucinazione. Oppure l'agente potrebbe aver consultato fonti esterne non più disponibili, o combinato informazioni in modo statisticamente plausibile ma fattualmente scorretto. Senza certificazione, nessuna di queste ipotesi è verificabile. L'azienda non ha modo di distinguere tra un errore di configurazione, un dato compromesso e un difetto del modello.

La cascata delle allucinazioni

Negli ambienti multi-agente, dove più agenti collaborano su un processo complesso, un singolo errore si propaga a catena. Un agente che classifica erroneamente una transazione alimenta un secondo agente che produce un report di compliance scorretto. Quel report attiva un terzo agente che invia una comunicazione al regolatore con dati falsi. Secondo un'analisi di Lumenova AI, una singola allucinazione in un sistema multi-agente può innescare violazioni di compliance a cascata difficili da ricostruire a posteriori.

L'assenza di prove

Quando si arriva in tribunale, l'azienda che ha implementato l'agente AI deve dimostrare cosa è accaduto. Ma un log applicativo modificabile non ha valore probatorio. Può essere alterato dopo i fatti, cancellato per errore, manipolato intenzionalmente. Un database di log è una ricostruzione interna, non una prova. E la differenza pesa: una prova ha data certa, è immutabile, ed è opponibile a terzi in giudizio. Senza certificazione, l'azienda si presenta in tribunale con argomentazioni, non con evidenze. In un regime di responsabilità oggettiva come quello della Product Liability Directive, le argomentazioni non sono sufficienti.

Cos'è la certificazione dei dati per agenti AI?

La certificazione dei dati per agenti AI è il processo che applica un sigillo digitale qualificato e una marca temporale certificata a ogni dato prodotto, elaborato o utilizzato da un sistema di intelligenza artificiale agentica, conferendogli valore legale e probatorio ai sensi del regolamento eIDAS. A differenza del semplice logging applicativo, la certificazione rende ogni dato immutabile, con certezza temporale giuridica e opponibilità a terzi.

I 4 livelli di certificazione per l'IA agentica

La certificazione dei dati degli agenti AI si articola in quattro livelli distinti, ciascuno corrispondente a una fase del ciclo di vita dell'agente: i dati in ingresso (knowledge base), le istruzioni ricevute (prompt), le azioni compiute (operazioni) e i risultati generati (output). Ogni livello copre un rischio normativo preciso e risponde a una domanda specifica in caso di contenzioso. L'Art. 12 del Regolamento UE 2024/1689 (AI Act) richiede la registrazione automatica degli eventi per i sistemi ad alto rischio, ma non specifica che i log debbano avere valore probatorio. La certificazione dell'intelligenza artificiale con valore legale colma questo gap, trasformando ogni dato nel ciclo di vita dell'agente in una prova opponibile a terzi. Se anche un solo livello manca, l'intera catena probatoria ne risente e l'organizzazione si espone a contestazioni che non è in grado di confutare con evidenze certificabili.

Livello 1: la knowledge base

I dati che alimentano un agente AI ne determinano il comportamento. Se un'azienda utilizza un agente per analizzare contratti e la knowledge base contiene una versione non aggiornata del regolamento di riferimento, ogni analisi prodotta è potenzialmente errata. Certificare la knowledge base significa registrare lo stato esatto dei dati al momento in cui l'agente li ha consultati, con data certa e immutabilità garantita. Se qualcuno contesta, l'azienda può dimostrare che i dati erano corretti e integri in quel preciso momento.

Livello 2: i prompt e le istruzioni

Chi ha dato istruzioni all'agente? Quando? Con quale contenuto? In azienda, le istruzioni possono provenire da un system prompt configurato dal team tecnico, da un prompt inserito da un operatore, o da entrambi. Certificarle significa creare una prova immutabile di cosa è stato chiesto all'agente in un determinato momento. Un aspetto spesso sottovalutato: quando una decisione errata finisce in contenzioso, la responsabilità potrebbe ricadere su chi ha configurato l'agente piuttosto che su chi lo ha sviluppato. E senza certificazione del prompt, non c'è modo di distinguere i due scenari.

Livello 3: le operazioni

Gli agenti AI non producono output dal nulla. Ragionano, consultano strumenti, compiono passaggi intermedi. Un agente che analizza una richiesta di risarcimento può consultare un database di precedenti, chiamare un'API esterna per verificare la copertura, generare un ragionamento interno, produrre una valutazione intermedia prima della decisione finale. Certificare le operazioni significa registrare ogni passaggio con valore legale, trasformando il log in una certificazione opponibile a terzi. L'Art. 12 dell'AI Act richiede proprio questo: la registrazione automatica degli eventi rilevanti durante l'intero ciclo di vita del sistema.

Livello 4: gli output

L'output è il risultato finale del lavoro dell'agente: un documento generato, una decisione formalizzata, un'analisi, una comunicazione inviata. Certificare l'output significa congelare il risultato con data certa e valore legale nel momento esatto in cui viene prodotto. Se tre mesi dopo un cliente contesta il contenuto di un report generato dall'agente, l'organizzazione può esibire il certificato dell'output originale, dimostrando esattamente cosa l'agente ha prodotto e quando. Senza certificazione, l'output è un file modificabile la cui autenticità è indifendibile in giudizio.

Il framework legale: perché certificare i dati AI non è opzionale

Il quadro normativo europeo converge verso un principio netto: chi utilizza sistemi di intelligenza artificiale deve poter dimostrare cosa quei sistemi hanno fatto e su quali dati hanno operato. Quattro normative principali definiscono gli obblighi, con scadenze ravvicinate e sanzioni pesanti. L'AI Act (Regolamento UE 2024/1689) impone il logging obbligatorio per i sistemi ad alto rischio dal 2 agosto 2026, con sanzioni fino a 15 milioni di euro o il 3% del fatturato globale. La Product Liability Directive (Direttiva UE 2024/2853) estende la responsabilità oggettiva al software AI dal 9 dicembre 2026, includendo una presunzione di difettosità a favore del danneggiato. La NIS2 richiede integrità dei dati e incident reporting per i servizi essenziali. Il GDPR Art. 22 garantisce il diritto alla spiegazione per le decisioni automatizzate. Le aziende che operano con agenti AI devono rispondere simultaneamente a tutti questi obblighi.

AI Act Art. 12: il logging obbligatorio

L'Art. 12 del Regolamento UE 2024/1689 richiede che i sistemi AI ad alto rischio siano dotati di funzionalità di registrazione automatica degli eventi (logging) durante l'intero ciclo di vita. I log devono consentire la tracciabilità del funzionamento del sistema e il monitoraggio post-commercializzazione. La norma stabilisce l'obbligo di registrare, ma non richiede esplicitamente che i log abbiano valore probatorio: un vuoto che la certificazione con marca temporale qualificata colma, trasformando ogni registrazione in una prova opponibile a terzi.

Product Liability Directive: l'AI come prodotto

La Direttiva 2024/2853, che gli Stati membri devono recepire entro il 9 dicembre 2026, include esplicitamente il software e i sistemi AI nella definizione di "prodotto" soggetto a responsabilità oggettiva. Secondo un'analisi dello studio Gibson Dunn, chi sviluppa, integra o distribuisce sistemi AI si espone alla stessa responsabilità di un produttore di beni fisici difettosi. Se un agente AI produce un output errato che causa un danno, il deployer può essere chiamato a rispondere anche in assenza di colpa, salvo dimostrare di aver adottato tutte le misure ragionevoli. La certificazione dei dati a ogni livello diventa la documentazione di quelle misure.

NIS2: l'integrità dei dati AI nei servizi essenziali

Le organizzazioni che utilizzano sistemi AI all'interno di servizi essenziali o importanti ricadono sotto la Direttiva NIS2. L'Art. 21 richiede misure di sicurezza che comprendono la protezione dell'integrità dei dati e il reporting degli incidenti. Un fallimento di un agente AI che compromette disponibilità, integrità o riservatezza delle informazioni va trattato come incidente critico. Il data poisoning, cioè la manipolazione dei dati di contesto di un agente, è a tutti gli effetti una minaccia cyber sotto NIS2.

Oltre all'AI Act e alla NIS2, il Regolamento DORA (Digital Operational Resilience Act, UE 2022/2554) impone agli istituti finanziari requisiti stringenti di tracciabilità e resilienza operativa per tutti i sistemi ICT, inclusi gli agenti AI utilizzati per trading automatico, analisi del credito e compliance. La certificazione dei dati degli agenti AI diventa un requisito operativo anche sotto DORA, poiché il regolamento richiede la capacità di ricostruire ogni operazione digitale con prove verificabili.

GDPR Art. 22: le decisioni automatizzate

Quando un agente AI prende decisioni con effetti significativi su persone fisiche, come rifiutare una richiesta assicurativa, valutare un candidato o attribuire un punteggio di credito, si applica l'Art. 22 del GDPR. L'interessato ha diritto a una spiegazione della logica utilizzata. La certificazione delle operazioni dell'agente (Livello 3) è il presupposto tecnico per fornire quella spiegazione in modo verificabile.

Un ulteriore riferimento è lo standard ISO/IEC 42001, il sistema di gestione per l'intelligenza artificiale. Pubblicato nel 2023, fornisce un framework per governare i processi AI a livello organizzativo: dalla valutazione dei rischi alla documentazione, dal monitoraggio al miglioramento continuo. È complementare alla certificazione dei dati. ISO 42001 definisce i processi e le policy; la certificazione garantisce che i dati prodotti e consumati da quei processi siano integri e verificabili. Un'organizzazione conforme a ISO 42001 che non certifica i propri dati AI ha processi solidi ma prove deboli. Chi certifica i dati senza processi governati ha prove solide ma governance fragile. Servono entrambi.

C'è poi un elemento che spesso sfugge: il vuoto normativo lasciato dal ritiro della AI Liability Directive. La Commissione Europea ha ritirato la proposta all'inizio del 2025, dopo critiche sulla complessità e sul potenziale effetto anti-innovazione. La conseguenza è che la responsabilità per danni causati da AI non difettosa ma operante in modo autonomo resta disciplinata dai diritti nazionali, non armonizzati a livello europeo. Per le aziende il messaggio è diretto: in assenza di un framework comunitario sulla responsabilità extracontrattuale dell'AI, l'auto-protezione attraverso la certificazione dei dati non è solo una buona prassi, è una necessità.

La catena di responsabilità nell'AI agentica: chi paga quando l'agente sbaglia

Chi è responsabile quando un agente AI autonomo causa un danno?

La responsabilità si distribuisce tra tre soggetti: lo sviluppatore del modello risponde per i difetti intrinseci, il deployer è soggetto a responsabilità oggettiva ai sensi della Product Liability Directive 2024/2853 per errori operativi e di configurazione, e l'utente finale si assume il rischio per istruzioni manifestamente inadeguate. Senza audit trail certificati su tutti e quattro i livelli, determinare quale soggetto abbia causato il danno diventa impossibile in sede giudiziaria.

Un agente AI non ha personalità giuridica. Non può essere citato in giudizio, non risponde dei propri errori, non ha un patrimonio aggredibile. Quando un agente AI causa un danno, la responsabilità ricade interamente sulle persone fisiche e giuridiche che lo hanno progettato, implementato e autorizzato a operare. Secondo un'analisi dello studio internazionale Clifford Chance, la catena di responsabilità nell'IA agentica coinvolge tre soggetti principali: il developer del modello, il deployer che lo implementa e l'utente che lo istruisce. La Product Liability Directive 2024/2853 complica ulteriormente il quadro: dal dicembre 2026, il software AI è un "prodotto" soggetto a responsabilità oggettiva, con presunzioni probatorie che ribaltano l'onere della prova a carico dell'azienda. Senza una certificazione dei dati che copra tutti e 4 i livelli del ciclo di vita dell'agente, ricostruire la catena causale e attribuire le responsabilità specifiche diventa impossibile.

Il developer risponde del modello AI e delle sue capacità di base. Se il danno deriva da un difetto intrinseco del modello, ad esempio un bias sistematico o un'architettura che produce allucinazioni in certe condizioni, la responsabilità è del fornitore.

Il deployer è l'azienda che mette l'agente AI al lavoro nei propri processi. L'Art. 26 dell'AI Act gli impone obblighi specifici: usare il sistema secondo le istruzioni, garantire la supervisione umana, monitorare il funzionamento. Se il danno nasce da una configurazione errata, da un prompt inadeguato o dalla mancata supervisione, la responsabilità è sua.

L'utente finale, quando è un operatore aziendale che interagisce direttamente con l'agente, può essere coinvolto se le istruzioni fornite erano manifestamente inadeguate o se ha ignorato segnalazioni di rischio prodotte dal sistema.

C'è poi una zona grigia: i provider di dati di training e contesto. Chi fornisce i dataset utilizzati nella knowledge base dell'agente può essere chiamato in causa se quei dati sono errati, obsoleti o manipolati. La certificazione della knowledge base (Livello 1) è l'unico modo per dimostrare la qualità dei dati al momento dell'uso.

Nella realtà, la responsabilità spesso non è attribuibile a uno solo di questi soggetti. Un agente che produce una decisione errata potrebbe averlo fatto per un difetto del modello, una configurazione sbagliata, un dato corrotto nella knowledge base, o una combinazione di tutto questo. Senza certificazione dei dati ai 4 livelli, ricostruire la catena causale e attribuire la responsabilità diventa impossibile.

Le compagnie assicurative stanno già prendendo nota. Secondo Lumenova AI, nel 2026 gli assicuratori richiedono con frequenza crescente prove verificabili di "bounded autonomy": la dimostrazione documentata che l'agente AI opera entro limiti controllati e tracciabili, come condizione per coprire i rischi legati al suo utilizzo.

La certificazione funziona quindi come prova difensiva: documenta con data certa e valore legale cosa l'agente ha ricevuto (knowledge base e prompt certificati), cosa ha fatto (operazioni certificate), e cosa ha prodotto (output certificato). In un contenzioso, questa catena permette di ricostruire il processo decisionale e individuare con precisione dove si è generato il problema, proteggendo chi ha operato correttamente.

Per rendere concreta la dinamica: se un agente AI prende una decisione errata perché la knowledge base conteneva un regolamento obsoleto, la certificazione del Livello 1 dimostra che il dato era già obsoleto al momento dell'acquisizione. La responsabilità si sposta su chi ha fornito o aggiornato quel dato, non su chi ha configurato l'agente. Senza certificazione, questa distinzione è impossibile da provare, e tutti i soggetti nella catena rischiano di rispondere in solido.

TrueScreen: come certificare i dati degli agenti AI con valore legale

I problemi descritti sopra (opacità decisionale, cascata di allucinazioni, vuoto probatorio, responsabilità frammentata) convergono su un'unica esigenza operativa: ogni dato nel ciclo di vita di un agente AI deve essere certificato con valore legale, in modo automatico e su scala. Questo è quello che fa TrueScreen.

TrueScreen è la Data Authenticity Platform che certifica i dati alla fonte: non applica un sigillo a file preesistenti, ma verifica l'origine dei dati, li acquisisce con metodologia forense, e produce un certificato digitale con marca temporale qualificata emessa da un Qualified Trust Service Provider conforme al Regolamento eIDAS. Il risultato non è una voce di log, ma una prova con valore legale: immutabile, con certezza temporale giuridica, opponibile a terzi in tutti gli Stati membri dell'UE.

Ciò che distingue TrueScreen dai servizi generici di timestamping o logging è la profondità del processo di certificazione. Per ogni dato, TrueScreen:

• Verifica l'origine dei dati: la fonte del dato viene autenticata e registrata come parte del certificato, stabilendo la provenienza.
• Genera reporting strutturato: ogni certificazione produce un report dettagliato che documenta il contesto di acquisizione, i controlli di integrità effettuati e la catena dei metadati. Questo report è progettato per audit, revisione di conformità e procedimenti giudiziari.
• Organizza e indicizza i dati acquisiti: i dati certificati sono ricercabili e analizzabili all'interno della data room certificata di TrueScreen, consentendo il recupero sistematico per agente, workflow e periodo temporale.
• Si integra programmaticamente: API REST e il TrueScreen MCP ufficiale (Model Context Protocol) consentono l'integrazione nativa in qualsiasi workflow di agenti AI, inclusi LangChain, AutoGen, CrewAI, Claude Code, ChatGPT e Gemini. Un team tecnico può aggiungere checkpoint di certificazione con modifiche minime al codice.

L'effetto pratico: quando un agente AI consulta una knowledge base, riceve istruzioni, esegue operazioni o genera output, TrueScreen certifica ogni passaggio automaticamente. Se la decisione di quell'agente viene contestata tre mesi dopo, l'organizzazione produce una catena probatoria completa e con valore legale: non una ricostruzione da log applicativi, ma una sequenza di certificati ciascuno con marca temporale qualificata e valore probatorio.

Questo risponde direttamente ai requisiti normativi descritti sopra. L'Art. 12 dell'AI Act richiede la registrazione automatica degli eventi: l'audit trail certificato di TrueScreen soddisfa questo requisito aggiungendo il valore probatorio che la norma non impone ma i tribunali richiedono. L'inversione dell'onere della prova della Product Liability Directive diventa gestibile: l'organizzazione può dimostrare, con prove legalmente vincolanti, che il proprio agente AI ha operato su dati corretti, con istruzioni documentate, attraverso operazioni tracciabili.

Roadmap: da dove iniziare per certificare i dati dei propri agenti AI

Fase 1: assessment e mappatura (AI risk management)

Identificare dove gli agenti AI toccano dati critici nell'organizzazione. Per ogni agente, mappare quattro dimensioni: quali dati consulta (knowledge base), chi gli dà istruzioni e in che forma (prompt), quali operazioni esegue (tool call, accesso a sistemi esterni, ragionamento, decisioni intermedie), quali output produce (documenti, decisioni, comunicazioni, report). Poi classificare ogni agente secondo il sistema di rischio dell'AI Act (inaccettabile, alto, limitato, minimo). Gli agenti in settori regolamentati come finanza, sanità, assicurazioni e pubblica amministrazione sono quasi certamente ad alto rischio. Ma attenzione: anche agenti in contesti apparentemente a basso rischio possono rientrare nella classificazione alta se le loro decisioni toccano persone fisiche. Un agente AI che filtra candidature produce effetti giuridici concreti sugli interessati, e ricade sotto il GDPR Art. 22.

Fase 2: implementazione progressiva

Partire dal Livello 4 (output) e dal Livello 1 (knowledge base): sono i più rapidi da implementare e i più rilevanti in contenzioso. L'output certificato dimostra cosa l'agente ha prodotto; la knowledge base certificata dimostra su quali dati ha operato. Insieme coprono il "cosa entra e cosa esce", che è la prima informazione richiesta in qualsiasi contestazione.

Poi integrare il Livello 2 (prompt) e il Livello 3 (operazioni) per chiudere la catena di certificazione. Il Livello 2 conta soprattutto dove più operatori interagiscono con lo stesso agente: certificare chi ha dato quale istruzione e quando permette di attribuire responsabilità precise. Il Livello 3 richiede un'integrazione più profonda nel codice dell'agente, ma è quello che soddisfa direttamente l'Art. 12 dell'AI Act.

Fase 3: monitoraggio continuo

La certificazione non è un'attività una tantum. I dati cambiano, le knowledge base si aggiornano, le configurazioni evolvono, nuovi agenti entrano in produzione. Serve un processo continuo che operi in tempo reale, generando un audit trail certificato per ogni operazione.

Audit periodici, almeno trimestrali, servono a verificare la completezza della catena: ogni agente ha tutti e 4 i livelli coperti? Ci sono lacune nelle operazioni? I dati certificati vengono conservati per il periodo minimo richiesto (sei mesi per l'AI Act, potenzialmente di più per normative nazionali)?

Questo approccio prepara l'organizzazione alla scadenza dell'AI Act di agosto 2026, ma anche alla compliance continuativa richiesta da NIS2 e GDPR. La provenienza digitale dei dati diventa un asset aziendale verificabile, non un costo di compliance.