L'AI che si spiega: come Labyrinthum affronta GDPR, xAI e AI Act
“Agisci solo secondo quella massima che puoi volere diventi una legge universale.”
Immanuel Kant, Critica della ragion pratica
C'è una domanda che chiunque costruisca un sistema di intelligenza artificiale dovrebbe saper rispondere senza esitare: perché ha deciso così? Non è una domanda filosofica. È una domanda tecnica, giuridica e, a ben guardare, etica. Il GDPR la pone dal 2018. L'AI Act europeo (Reg. UE 2024/1689) la trasforma in obbligo esplicito. E il Considerando 71 del Regolamento, spesso citato e raramente applicato davvero, parla chiaro: chi tratta dati con sistemi automatizzati deve poter fornire spiegazioni specifiche della decisione presa. Quando abbiamo progettato il sottosistema AI di Labyrinthum, abbiamo scelto di prendere questi requisiti sul serio, non come vincoli da soddisfare a minimo sindacale, ma come criteri di qualità architetturale. Quello che segue è la storia di come ci siamo arrivati.
Privacy by design, non by accident.Il punto di partenza è semplice: un sistema che gestisce appunti, libri e pensieri personali lavora su dati intrinsecamente sensibili. La prima domanda non è come usare l'AI, ma dove gira e chi vede cosa. Labyrinthum è progettato per funzionare completamente offline, con modelli locali eseguiti via Ollama sul proprio server. Nessun dato lascia il perimetro, nessuna query finisce su server di terze parti. La modalità cloud è disponibile per i task di ragionamento più complessi, ma richiede consenso esplicito dell'utente prima di qualunque chiamata: un middleware intercetta ogni richiesta verso le rotte /AI/* e, se manca il cookie di consenso, blocca il flusso e mostra una modale informativa. Un solo retry consentito: niente dark pattern, niente opt-out nascosto. C'è poi una seconda linea di difesa: il flag IsSensitive. Qualunque appunto o testo marcato come riservato non raggiunge mai un provider cloud, indipendentemente da qualsiasi altra configurazione. Non è una scelta dell'utente da fare ogni volta: è un blocco architetturale, a livello di routing, che restituisce HTTP 403 prima ancora di inizializzare il modello. La privacy non come impostazione, ma come struttura.
Il diritto di sapere cosa è successo. Il GDPR all'art. 15 garantisce all'interessato il diritto di accesso a ogni trattamento automatizzato che lo riguarda. Labyrinthum implementa questo diritto con un portale DSAR self-service su /AI/MyData: un elenco paginato di tutte le invocazioni AI effettuate, filtrabili per periodo, per funzionalità, per solo-cloud. Ogni record espone provider usato, latenza, numero di chunk recuperati, se i dati hanno lasciato il perimetro. Il diritto all'oblio (art. 17) si esercita con una cancellazione granulare — tutto, o solo i record più vecchi di N giorni, o quelli di una specifica funzionalità — protetta da doppio meccanismo: token antiforgery e una parola di conferma esplicita. La portabilità (art. 20) è coperta da un export JSON che include un wrapper metadata con base giuridica dichiarata e retention policy: il file è autoconsistente, riutilizzabile, pensato per essere consegnato all'interessato o a un'Autorità Garante. Le query testuali sono pseudonimizzate via hash SHA-256 troncato e conservate per soli 90 giorni: poi restano solo i metadati aggregati, utili per le statistiche ma non più riconducibili al contenuto originale.
XAI: spiegare ogni citazione, non solo il risultato. La spiegabilità — XAI, Explainable AI — è il punto dove la maggior parte dei sistemi RAG commerciali si ferma. Danno una risposta e citano le fonti. Non spiegano perché quella fonte e non un'altra, né come ci sono arrivati. In Labyrinthum ogni citazione [Fonte N] nella Chat RAG e ogni risultato della Ricerca Semantica espongono un pannello di dettaglio che mostra tutti i segnali che hanno portato quel documento nel top-K: la posizione nel ranking lessicale BM25, la posizione nel ranking vettoriale con la percentuale di affinità semantica, lo score RRF che li fonde, l'eventuale riordino dell'LLM reranker con la sua giustificazione testuale in italiano (massimo 140 caratteri), e se il documento è arrivato perché era nel pool ibrido già prima, o perché è stato scoperto attraverso il grafo dei concetti. Quest'ultima distinzione merita un momento di attenzione. Un documento arrivato via grafo porta un segnale diverso da uno arrivato per similarità vettoriale: il primo è stato collegato esplicitamente dall'utente a un concetto pertinente, il secondo è affine testualmente. Entrambi sono utili, ma non sono la stessa cosa. Renderlo visibile non è solo trasparenza formale ma informazione genuinamente utile per valutare la risposta.
L'analisi controfattuale: e se avessimo fatto diversamente? C'è un secondo livello di spiegabilità, ispirato metodologicamente a SHAP e LIME ma implementato senza dipendenze da framework ML: l'analisi controfattuale. Dopo ogni ricerca o risposta della Chat, un link apre una modale che consente di disattivare selettivamente i moduli della pipeline — HyDE, il reranker LLM, il grafo dei concetti — e vedere come cambierebbe il ranking. Il server esegue baseline e variante in parallelo e restituisce un diff categoriale: per ogni documento, se è solo nella baseline (il modulo lo stava includendo), solo nella variante (lo stava escludendo), spostato (stesso documento, posizione diversa) o invariato. Due metriche sintetizzano l'impatto globale: il coefficiente di Jaccard misura quanto i due insiemi di risultati si sovrappongono, ovvero il contributo al recall del modulo disattivato; il tau di Kendall misura la concordanza nell'ordinamento delle coppie comuni, ovvero il contributo al ranking. Non è la stessa cosa che capire perché un singolo documento è in prima posizione: è capire quanto ogni componente della pipeline conta sulla risposta complessiva. Un appiglio concreto, come dice letteralmente l'art. 22(3) GDPR, su cui basare una contestazione della decisione automatizzata.
Log inviolabili: l'accountability che si può dimostrare. Sapere cosa è successo non basta se il log stesso può essere alterato. L'art. 5(2) del GDPR richiede che il titolare possa dimostrare la conformità, non solo dichiararla. L'AI Act all'art. 12 prescrive la registrazione degli eventi by design and by default nei sistemi ad alto rischio. Ogni record di AILog in Labyrinthum viene firmato al momento della scrittura con HMAC-SHA256 e collegato in catena al record precedente attraverso il campo PrevSignature. La struttura è quella di una blockchain minimalista: modificare un record in mezzo alla catena invalida la firma del record manomesso e, per effetto a cascata, quella di tutti i successivi. Farlo senza essere rilevati richiederebbe accesso al segreto HMAC, che non è mai committed nel repository e vive esclusivamente in variabili d'ambiente o Key Vault. La dashboard /AI/Privacy ha un pulsante Verifica integrità che esegue la scansione e restituisce il contatore dei record problematici, classificati per tipo di anomalia. Non è un sistema pensato per la paranoia, ma per l'accountability: quando — non se — qualcuno chiede una prova, la prova c'è.
Model Card: sapere con chi si parla, prima di parlare. L'ultimo tassello è la trasparenza dichiarativa. Prima di attivare qualunque funzionalità che invia dati a un provider cloud, Labyrinthum mostra una Model Card: provider, versione del modello, una nota chiara se i dati escono dal server locale, la retention, la base giuridica del trattamento e un link al system prompt integrale. Non nelle note legali in fondo alla pagina: nella modale di consenso, al momento esatto in cui la scelta va fatta. Tutti i system prompt sono anche consultabili liberamente in /AI/SystemPrompts, una pagina pubblica che espone il testo integrale di ogni prompt di sistema. È una scelta insolita — la maggior parte dei sistemi tratta i propri prompt come segreti industriali — ma coerente con i principi dell'art. 13 GDPR e dell'art. 50 dell'AI Act sui sistemi general-purpose. Una nota onesta: la Model Card è dichiarativa. Non garantisce per sé il rispetto delle retention policy da parte del provider, né sostituisce una DPIA o un contratto DPA. È la fonte di verità lato applicazione ma va tenuta allineata alle policy contrattuali esterne. La trasparenza, anche quella ben fatta, ha i suoi limiti.
Perché questo conta. Non costruiamo sistemi AI per soddisfare checklist normative. Ma quando le norme puntano nella direzione giusta — e GDPR, XAI e AI Act, nelle loro parti migliori, ci puntano — seguirle con rigore produce sistemi migliori. Un'AI che sa spiegare le proprie decisioni è un'AI di cui ci si può fidare di più. Un log che non si può alterare è una garanzia reale, non una promessa. Un utente che può vedere, contestare e cancellare ogni traccia del proprio uso è un utente che ha controllo effettivo dei propri dati non solo sulla carta. Questi non sono obiettivi separati dall'architettura. Sono l'architettura!
Se siete curiosi dell'architettura tecnica completa, siamo disponibili a condividere ulteriori dettagli. Nel frattempo, continuate a seguirci su verdelab.info!
Immanuel Kant, Critica della ragion pratica
C'è una domanda che chiunque costruisca un sistema di intelligenza artificiale dovrebbe saper rispondere senza esitare: perché ha deciso così? Non è una domanda filosofica. È una domanda tecnica, giuridica e, a ben guardare, etica. Il GDPR la pone dal 2018. L'AI Act europeo (Reg. UE 2024/1689) la trasforma in obbligo esplicito. E il Considerando 71 del Regolamento, spesso citato e raramente applicato davvero, parla chiaro: chi tratta dati con sistemi automatizzati deve poter fornire spiegazioni specifiche della decisione presa. Quando abbiamo progettato il sottosistema AI di Labyrinthum, abbiamo scelto di prendere questi requisiti sul serio, non come vincoli da soddisfare a minimo sindacale, ma come criteri di qualità architetturale. Quello che segue è la storia di come ci siamo arrivati.
Privacy by design, non by accident.Il punto di partenza è semplice: un sistema che gestisce appunti, libri e pensieri personali lavora su dati intrinsecamente sensibili. La prima domanda non è come usare l'AI, ma dove gira e chi vede cosa. Labyrinthum è progettato per funzionare completamente offline, con modelli locali eseguiti via Ollama sul proprio server. Nessun dato lascia il perimetro, nessuna query finisce su server di terze parti. La modalità cloud è disponibile per i task di ragionamento più complessi, ma richiede consenso esplicito dell'utente prima di qualunque chiamata: un middleware intercetta ogni richiesta verso le rotte /AI/* e, se manca il cookie di consenso, blocca il flusso e mostra una modale informativa. Un solo retry consentito: niente dark pattern, niente opt-out nascosto. C'è poi una seconda linea di difesa: il flag IsSensitive. Qualunque appunto o testo marcato come riservato non raggiunge mai un provider cloud, indipendentemente da qualsiasi altra configurazione. Non è una scelta dell'utente da fare ogni volta: è un blocco architetturale, a livello di routing, che restituisce HTTP 403 prima ancora di inizializzare il modello. La privacy non come impostazione, ma come struttura.
Il diritto di sapere cosa è successo. Il GDPR all'art. 15 garantisce all'interessato il diritto di accesso a ogni trattamento automatizzato che lo riguarda. Labyrinthum implementa questo diritto con un portale DSAR self-service su /AI/MyData: un elenco paginato di tutte le invocazioni AI effettuate, filtrabili per periodo, per funzionalità, per solo-cloud. Ogni record espone provider usato, latenza, numero di chunk recuperati, se i dati hanno lasciato il perimetro. Il diritto all'oblio (art. 17) si esercita con una cancellazione granulare — tutto, o solo i record più vecchi di N giorni, o quelli di una specifica funzionalità — protetta da doppio meccanismo: token antiforgery e una parola di conferma esplicita. La portabilità (art. 20) è coperta da un export JSON che include un wrapper metadata con base giuridica dichiarata e retention policy: il file è autoconsistente, riutilizzabile, pensato per essere consegnato all'interessato o a un'Autorità Garante. Le query testuali sono pseudonimizzate via hash SHA-256 troncato e conservate per soli 90 giorni: poi restano solo i metadati aggregati, utili per le statistiche ma non più riconducibili al contenuto originale.
XAI: spiegare ogni citazione, non solo il risultato. La spiegabilità — XAI, Explainable AI — è il punto dove la maggior parte dei sistemi RAG commerciali si ferma. Danno una risposta e citano le fonti. Non spiegano perché quella fonte e non un'altra, né come ci sono arrivati. In Labyrinthum ogni citazione [Fonte N] nella Chat RAG e ogni risultato della Ricerca Semantica espongono un pannello di dettaglio che mostra tutti i segnali che hanno portato quel documento nel top-K: la posizione nel ranking lessicale BM25, la posizione nel ranking vettoriale con la percentuale di affinità semantica, lo score RRF che li fonde, l'eventuale riordino dell'LLM reranker con la sua giustificazione testuale in italiano (massimo 140 caratteri), e se il documento è arrivato perché era nel pool ibrido già prima, o perché è stato scoperto attraverso il grafo dei concetti. Quest'ultima distinzione merita un momento di attenzione. Un documento arrivato via grafo porta un segnale diverso da uno arrivato per similarità vettoriale: il primo è stato collegato esplicitamente dall'utente a un concetto pertinente, il secondo è affine testualmente. Entrambi sono utili, ma non sono la stessa cosa. Renderlo visibile non è solo trasparenza formale ma informazione genuinamente utile per valutare la risposta.
L'analisi controfattuale: e se avessimo fatto diversamente? C'è un secondo livello di spiegabilità, ispirato metodologicamente a SHAP e LIME ma implementato senza dipendenze da framework ML: l'analisi controfattuale. Dopo ogni ricerca o risposta della Chat, un link apre una modale che consente di disattivare selettivamente i moduli della pipeline — HyDE, il reranker LLM, il grafo dei concetti — e vedere come cambierebbe il ranking. Il server esegue baseline e variante in parallelo e restituisce un diff categoriale: per ogni documento, se è solo nella baseline (il modulo lo stava includendo), solo nella variante (lo stava escludendo), spostato (stesso documento, posizione diversa) o invariato. Due metriche sintetizzano l'impatto globale: il coefficiente di Jaccard misura quanto i due insiemi di risultati si sovrappongono, ovvero il contributo al recall del modulo disattivato; il tau di Kendall misura la concordanza nell'ordinamento delle coppie comuni, ovvero il contributo al ranking. Non è la stessa cosa che capire perché un singolo documento è in prima posizione: è capire quanto ogni componente della pipeline conta sulla risposta complessiva. Un appiglio concreto, come dice letteralmente l'art. 22(3) GDPR, su cui basare una contestazione della decisione automatizzata.
Log inviolabili: l'accountability che si può dimostrare. Sapere cosa è successo non basta se il log stesso può essere alterato. L'art. 5(2) del GDPR richiede che il titolare possa dimostrare la conformità, non solo dichiararla. L'AI Act all'art. 12 prescrive la registrazione degli eventi by design and by default nei sistemi ad alto rischio. Ogni record di AILog in Labyrinthum viene firmato al momento della scrittura con HMAC-SHA256 e collegato in catena al record precedente attraverso il campo PrevSignature. La struttura è quella di una blockchain minimalista: modificare un record in mezzo alla catena invalida la firma del record manomesso e, per effetto a cascata, quella di tutti i successivi. Farlo senza essere rilevati richiederebbe accesso al segreto HMAC, che non è mai committed nel repository e vive esclusivamente in variabili d'ambiente o Key Vault. La dashboard /AI/Privacy ha un pulsante Verifica integrità che esegue la scansione e restituisce il contatore dei record problematici, classificati per tipo di anomalia. Non è un sistema pensato per la paranoia, ma per l'accountability: quando — non se — qualcuno chiede una prova, la prova c'è.
Model Card: sapere con chi si parla, prima di parlare. L'ultimo tassello è la trasparenza dichiarativa. Prima di attivare qualunque funzionalità che invia dati a un provider cloud, Labyrinthum mostra una Model Card: provider, versione del modello, una nota chiara se i dati escono dal server locale, la retention, la base giuridica del trattamento e un link al system prompt integrale. Non nelle note legali in fondo alla pagina: nella modale di consenso, al momento esatto in cui la scelta va fatta. Tutti i system prompt sono anche consultabili liberamente in /AI/SystemPrompts, una pagina pubblica che espone il testo integrale di ogni prompt di sistema. È una scelta insolita — la maggior parte dei sistemi tratta i propri prompt come segreti industriali — ma coerente con i principi dell'art. 13 GDPR e dell'art. 50 dell'AI Act sui sistemi general-purpose. Una nota onesta: la Model Card è dichiarativa. Non garantisce per sé il rispetto delle retention policy da parte del provider, né sostituisce una DPIA o un contratto DPA. È la fonte di verità lato applicazione ma va tenuta allineata alle policy contrattuali esterne. La trasparenza, anche quella ben fatta, ha i suoi limiti.
Perché questo conta. Non costruiamo sistemi AI per soddisfare checklist normative. Ma quando le norme puntano nella direzione giusta — e GDPR, XAI e AI Act, nelle loro parti migliori, ci puntano — seguirle con rigore produce sistemi migliori. Un'AI che sa spiegare le proprie decisioni è un'AI di cui ci si può fidare di più. Un log che non si può alterare è una garanzia reale, non una promessa. Un utente che può vedere, contestare e cancellare ogni traccia del proprio uso è un utente che ha controllo effettivo dei propri dati non solo sulla carta. Questi non sono obiettivi separati dall'architettura. Sono l'architettura!
Se siete curiosi dell'architettura tecnica completa, siamo disponibili a condividere ulteriori dettagli. Nel frattempo, continuate a seguirci su verdelab.info!

Commenti
Posta un commento