← Tutte le risposte

Come si costruisce un sistema RAG con audit trail?

L’audit trail di un sistema RAG non è un log delle richieste. È tutto ciò che serve per ricostruire una risposta specifica a distanza di mesi: la domanda, l’identità che l’ha posta, l’esatto insieme di chunk recuperati e le versioni dei documenti da cui provenivano, il prompt assemblato, il modello e i parametri che hanno generato il testo, l’output e cosa ne ha fatto un essere umano. Due scelte di progetto lo rendono possibile o impossibile, ed entrambe si prendono presto: i documenti devono avere identificativi di versione immutabili con intervalli di validità, e il record deve essere scritto nella stessa transazione della risposta, su uno storage che l’applicazione non può riscrivere. Tutto il resto è dettaglio.

Di Corrado Patierno · aggiornato a

Cosa deve contenere il record

Il test è semplice e non perdona: prendi una risposta di sei mesi fa e ricostruiscila. Se manca anche uno solo degli elementi seguenti, non ci riesci.

Domanda
L’input così come è stato ricevuto, con l’identità di chi ha chiesto e i diritti di accesso che quell’identità aveva in quel momento.
Insieme recuperato
Quali chunk sono stati restituiti, da quali documenti, in quale versione, con quali punteggi. Non solo quelli citati nella risposta: quelli presi in considerazione.
Stato del documento
Per ogni fonte: l’identificativo di versione e il suo intervallo di validità, così che ‘in vigore alla data della domanda’ sia un’affermazione calcolabile e non un’ipotesi.
Prompt
Il prompt assemblato, oppure un suo hash insieme all’identificativo del template e alle variabili. Un template cambiato in silenzio è la causa più comune di una risposta che non si riesce a riprodurre.
Identità del modello
Fornitore, nome del modello, versione e parametri di generazione. Se l’endpoint è esterno, questa è l’unica traccia che avrai di cosa ha risposto davvero.
Output
La risposta così come è stata restituita, prima di qualsiasi post-elaborazione, e la forma post-elaborata se le due differiscono.
Esito
Chi l’ha vista, se un essere umano l’ha approvata e cosa è successo dopo — la parte che la maggior parte dei sistemi dimentica, e quella su cui un ispettore fa la prima domanda.

A prova di manomissione, non semplicemente archiviato

Un log che l’applicazione può modificare non prova nulla, perché la prima domanda che chiunque gli pone è se sia stato modificato. La soglia pratica è l’evidenza di manomissione: storage append-only, record concatenati tramite hash in modo che alterarne uno invalidi i successivi, e credenziali di scrittura separate da quelle dell’applicazione. La marcatura temporale crittografica alza ulteriormente l’asticella dove il record potrebbe finire in una controversia.

È qui che un substrato event-sourced ripaga: il registro di ciò che è accaduto è l’artefatto primario e le viste interrogabili ne derivano, invece di un registro che è il sottoprodotto di uno stato mutabile che qualcuno può aggiornare. I compromessi di questa scelta, compresi quelli che si sottovalutano, sono in event sourcing nella pratica.

La conservazione va decisa nello stesso momento. Un registro di audit conservato per sempre è un rischio ai sensi del GDPR, e uno cancellato dopo novanta giorni per default è inutile per un obbligo che dura anni. Il periodo di conservazione è una decisione di governance con un responsabile con nome e cognome, non un default dell’infrastruttura.

Il problema dei dati personali dentro il log di audit

Il registro di audit è l’unico componente che per scelta conserva tutto, e questo lo rende il componente con più probabilità di trasformarsi in un trattamento illecito. Tre mosse lo mantengono difendibile. Conservare le identità come riferimenti pseudonimizzati stabili, risolvibili tramite una tabella di corrispondenza separata e ad accesso controllato, invece di nomi nel log. Conservare la domanda alla lettera solo dove l’obbligo lo richiede, e altrimenti un hash più la classificazione. Ed escludere i dati personali dall’indice fin dall’inizio, così che i record di retrieval non possano accumularli — la scelta di progetto alla base del deployment per Federfarma, dove i dati personali sono esclusi in fase di ingestion anziché filtrati al momento della risposta.

A cosa serve davvero l’audit trail

A tre cose, in ordine crescente di valore. Ti permette di rispondere a un ispettore: cosa ha detto il sistema, su quale base e chi ha agito di conseguenza. Ti permette di fare il debug di una regressione: una risposta che è cambiata quando non sono cambiati né la domanda né i documenti significa che si è mosso il modello o il template, e senza il record stai tirando a indovinare. E ti permette di migliorare il retrieval in modo onesto — l’insieme dei chunk considerati ma non citati è il dataset che ti dice dove l’indice è debole.

Le organizzazioni che fanno questo bene trattano il record come un requisito di prodotto con un responsabile, non come observability. L’observability ti dice che il sistema è in piedi. L’audit trail ti dice cosa ha fatto.

Fonti

Fonti primarie per le affermazioni normative qui sopra. Dove questa pagina descrive cosa richiede un obbligo, fa fede il testo dell’atto, non questa pagina.

Questa pagina è un orientamento tecnico e architetturale, scritto a partire da incarichi svolti in ambienti regolati. Non è una consulenza legale e non stabilisce la classificazione normativa di alcun sistema specifico.

La ricostruibilità si progetta, non si aggiunge

Se un sistema esistente non sa rispondere a ‘cosa ha detto il 14 marzo, e su quale base’, è un rilievo che conviene avere per iscritto prima che lo trovi qualcun altro.