Reliability score per agenti AI: come certificare metriche e errori per la conformità all’AI Act
Le aziende stanno integrando agenti AI dentro flussi operativi quotidiani: customer support, scoring del credito, screening di candidati, classificazione di documenti, automazione di back office. Ogni decisione presa dall'agente è un'azione che produce conseguenze reali su persone, contratti e bilanci, e che un'autorità di vigilanza o un giudice può chiedere di ricostruire a distanza di mesi o anni.
Il Regolamento UE 2024/1689 (AI Act) ha trasformato questa dinamica in un obbligo strutturato. L'articolo 12 impone a chi sviluppa o utilizza sistemi AI ad alto rischio di mantenere registrazioni automatiche degli eventi rilevanti per tutto il ciclo di vita del sistema. L'articolo 13 chiede trasparenza operativa verso utenti e autorità. Ma per dimostrare conformità in un audit del 2026 e oltre i log da soli non bastano. Serve un reliability score operativo che misuri quanto l'agente lavora bene, dove sbaglia, dove devia. E serve che quello score sia certificato in modo opponibile in giudizio, perché senza una metrica difendibile dell'affidabilità dell'agente, ogni contestazione di danno o richiesta di responsabilità diventa una battaglia persa in partenza.
Questo approfondimento fa parte della guida: Certificazione dei dati per agenti AI: governance, compliance e responsabilità legale
Cosa misura davvero un reliability score per agenti AI
Un reliability score non è un numero unico astratto. È un indice composito che aggrega quattro metriche distinte, ciascuna delle quali risponde a una domanda diversa che un'autorità di vigilanza, un giudice o un cliente danneggiato può legittimamente porre all'azienda che ha messo l'agente in produzione.
Le quattro metriche fondamentali
La prima metrica è l'accuratezza: la percentuale di output dell'agente che corrispondono a una verità di riferimento, calcolata su un set di valutazione rappresentativo del traffico reale. Un agente di scoring del credito con accuratezza dell'87% sbaglia 13 decisioni su 100, e quelle 13 decisioni hanno conseguenze patrimoniali su persone reali. La seconda metrica è il bias: la differenza di prestazione fra sottogruppi protetti (genere, età, area geografica). L'AI Act all'articolo 10 chiede valutazioni mirate alla discriminazione, e la metrica deve essere calcolata su dati post-deployment, non solo in fase di test.
La terza metrica è il drift: lo scostamento progressivo della distribuzione degli input o degli output rispetto alla baseline di addestramento. Un agente che a gennaio gestiva il 70% di richieste su un certo prodotto e ad aprile ne gestisce il 30% sta operando in un contesto diverso da quello per cui è stato validato, e la sua accuratezza dichiarata non vale più. La quarta metrica è il refusal rate: la percentuale di richieste in cui l'agente si astiene dal rispondere o invoca l'escalation umana. Un refusal rate del 2% può essere ottimo o pessimo a seconda del contesto: in un agente medico è fisiologico, in un agente di customer support indica che l'agente è sotto-coperto sui casi reali.
Granularità temporale e finestre di osservazione
Le quattro metriche vanno calcolate su finestre temporali diverse, perché rispondono a logiche di osservazione diverse:
| Metrica | Finestra di calcolo | Frequenza di aggiornamento |
|---|---|---|
| Accuratezza | 7 giorni rolling | Giornaliera |
| Bias per sottogruppo | 30 giorni rolling | Settimanale |
| Drift input/output | 7 e 30 giorni a confronto | Giornaliera |
| Refusal rate | 24 ore rolling | Oraria |
Queste finestre vanno fissate ex ante e mai modificate retroattivamente: cambiare la finestra di calcolo dopo aver visto i risultati invalida la metrica e in audit viene contestato come manipolazione.
AI Act articolo 12 e articolo 13: cosa deve dimostrare un'azienda in audit
Il record-keeping ex articolo 12 dell'AI Act non è un obbligo generico di "tenere log". È un dovere specifico di mantenere registrazioni automatiche, conservate per la durata appropriata al ciclo di vita del sistema, che permettano a un'autorità di vigilanza nazionale (in Italia AGID e Garante per la protezione dei dati personali, secondo i ruoli) di ricostruire a posteriori il funzionamento del sistema. L'articolo 13 affianca a questo l'obbligo di trasparenza operativa: chi mette in uso l'agente deve fornire al destinatario informazioni chiare, complete e accessibili sul funzionamento del sistema.
Cosa significa "audit-ready" in pratica
Un'autorità di vigilanza che apre un'istruttoria su un agente AI ad alto rischio chiede tipicamente quattro cose. Vuole i log delle decisioni in un certo intervallo temporale. Vuole prova che quei log non siano stati alterati dopo la generazione. Vuole le metriche di prestazione misurate nello stesso intervallo. Vuole prova che le metriche derivino dai log e non siano calcolate su un dataset diverso. Senza queste quattro evidenze, il record-keeping dichiarato vale poco: il testo ufficiale dell'AI Act all'articolo 12 parla esplicitamente di tracciabilità lungo l'intero ciclo di vita.
L'allineamento agli standard internazionali di AI governance
L'AI Act non è isolato. Si interseca con il NIST AI Risk Management Framework, che nella funzione "Measure" chiede esplicitamente la misurazione continua di accuratezza, bias e robustezza, e con lo standard ISO/IEC 42001 sulla gestione dei sistemi di intelligenza artificiale, che nei controlli A.6 e A.9 prescrive registrazioni di prestazione misurabili e verificabili. Costruire il reliability score con queste quattro metriche e renderlo certificato significa coprire in un colpo solo gli obblighi dell'AI Act e gli standard di buona pratica internazionale: in audit, dimostrare allineamento a NIST e ISO è un'attenuante di responsabilità riconosciuta.
Certificazione runtime delle metriche: come TrueScreen costruisce un tracciato di audit forense
Il punto debole del record-keeping classico è che i log sono file, e i file possono essere modificati, riscritti, aggregati a posteriori, persino generati ad hoc dopo che è arrivata la richiesta di accesso agli atti. In tribunale o in audit, un log esportato dal database aziendale ha lo stesso valore di una pagina di Word: zero, se la controparte ne contesta l'autenticità. Per dare valore probatorio a metriche e log occorre un livello di certificazione che renda matematicamente impossibile la modifica a posteriori.
Il flusso di certificazione di TrueScreen per agenti AI
TrueScreen opera sul punto critico: cattura output, prompt, contesto e metriche dell'agente AI nel momento esatto in cui vengono generati, calcola un'impronta crittografica di ogni elemento, e applica al pacchetto certificato una marca temporale qualificata e un sigillo elettronico erogati da un QTSP qualificato terzo integrato in piattaforma. Il risultato è un tracciato di audit forense in cui ogni decisione dell'agente, ogni metrica calcolata nelle finestre dichiarate, ogni anomalia rilevata è cristallizzata con valore legale e impossibile da alterare retroattivamente, perché qualunque modifica successiva al sigillo invaliderebbe la prova in modo verificabile da chiunque.
Per chi gestisce agenti AI in produzione il vantaggio è triplo. Primo, conformità documentata all'obbligo di record-keeping previsto dall'AI Act per i sistemi ad alto rischio: in caso di ispezione l'azienda non porta in audit un export di log, ma un pacchetto certificato la cui integrità è verificabile da terzi. Secondo, uno score di affidabilità difendibile in giudizio: se un cliente contesta una decisione dell'agente, l'azienda può produrre l'evidenza certificata che in quel momento il modello operava entro le metriche dichiarate. Terzo, protezione contro contestazioni di responsabilità per danno da prodotti AI: la nuova direttiva europea sulla responsabilità da prodotto include esplicitamente i sistemi di intelligenza artificiale, e la presunzione di difetto si applica a chi non sa documentare il proprio sistema.
Cosa cambia rispetto a un MLOps tradizionale
Le piattaforme MLOps standard (MLflow, Weights & Biases, Arize) misurano e archiviano metriche, ma non le certificano: un audit interno può fidarsi di MLflow, un giudice no. La marca temporale qualificata e il sigillo elettronico erogati da QTSP integrati in TrueScreen aggiungono al monitoring esistente il livello che lo trasforma da strumento di osservabilità interna a evidenza opponibile a terzi. Non sostituisce MLflow: lo completa con il livello di certificazione che la legge ora richiede.
