Il problema della privacy nell’intelligenza artificiale generativa viene ancora raccontato con una semplificazione quasi infantile: mando un prompt a un modello, il modello risponde, la conversazione finisce. In produzione non funziona così. Un prompt aziendale può attraversare framework agentici, sistemi di telemetria, piattaforme di tracing, vector database, gateway, sistemi DLP, cache, provider di inference e infrastrutture GPU; in ciascun passaggio può essere letto, registrato, copiato o conservato. La questione quindi non è semplicemente sapere se OpenAI, Anthropic o un altro vendor “usa i dati per addestrare il modello”. La domanda tecnologicamente seria è molto più scomoda: chi può vedere il prompt, dove viene elaborato, dove viene scritto, per quanto tempo rimane e sotto quale giurisdizione?
La distinzione fondamentale è tra vedere e conservare. Un componente può avere accesso al testo senza necessariamente scriverlo su disco; al contrario, un sistema può conservare dati per mesi senza essere coinvolto nell’inferenza vera e propria. Nei sistemi agentici questo diventa particolarmente rilevante perché il prompt può essere intercettato prima ancora di arrivare al modello. Framework, tracing, observability, memory store e strumenti di analytics possono infatti registrare input e output; un vector store può conservare la memoria conversazionale; una console di gateway può archiviare i payload per consentire il debugging. Nel frattempo il model provider può applicare una retention di pochi giorni o settimane. La situazione apparentemente paradossale è che l’azienda può avere cancellato il prompt dal provider e conservarlo tranquillamente nel proprio stack, magari in un sistema che nessuno considera parte dell’infrastruttura AI.
Questo modifica anche il significato operativo della Zero Data Retention, spesso venduta come se fosse una cintura di sicurezza universale. Non lo è. La ZDR riguarda normalmente un determinato soggetto, determinate funzionalità e un determinato tipo di dato. Non cancella automaticamente i log del gateway, il tracing SaaS, la memoria vettoriale, le cache o i file caricati. Non impedisce inoltre che una funzionalità stateful richieda storage. Synthorai cita, per esempio, differenze tra caching, batch processing, container e file nella gestione Anthropic: alcune funzionalità possono essere compatibili con ZDR, mentre altre richiedono conservazione temporanea. La sicurezza dei dati non può quindi essere certificata con una singola casella verde chiamata “ZDR”. Bisogna ricostruire l’intero percorso del dato.
Il punto diventa ancora più interessante quando si sposta l’attenzione dall’LLM all’inference provider. Un modello non possiede una geografia propria. Lo stesso open model può essere eseguito su un’infrastruttura americana, europea, cinese o direttamente sulle GPU dell’azienda. Il modello è il software; la giurisdizione appartiene all’infrastruttura che lo esegue e al soggetto che la controlla. È una differenza concettuale che dovrebbe essere ormai banale, ma nel mercato dell’AI viene spesso trattata come una sottigliezza legale. Non lo è. È architettura.
Qui entra in gioco Regolo.ai, piattaforma europea di inference sviluppata nell’ecosistema Seeweb, che rappresenta un caso interessante proprio perché porta la discussione dalla promessa di “AI europea” all’infrastruttura che effettivamente esegue i modelli. Regolo dichiara di utilizzare data center europei, con infrastrutture principali in Lazio e Lombardia, e GPU come AMD MI300X, NVIDIA H200, H100 e A100. La piattaforma viene proposta come servizio di inference, senza che il cliente debba gestire direttamente l’hardware GPU.
La differenza rispetto alla semplice scelta di un modello europeo è sostanziale. Un modello open weights eseguito attraverso un’infrastruttura europea può mantenere il trattamento dei prompt all’interno dell’ambiente europeo, mentre lo stesso modello chiamato attraverso un provider situato altrove segue la geografia e le policy di quel provider. Regolo dichiara inoltre una politica di Zero Data Retention per la propria infrastruttura, descrivendo un’architettura nella quale prompt e output vengono processati in memoria volatile e non vengono persistiti come contenuto nei log applicativi. La documentazione tecnica pubblicata da Regolo descrive un percorso RAM-only, con payload ricevuti attraverso un gateway mTLS, elaborati in memoria e nella VRAM delle GPU, mentre la telemetria conserva metadati operativi come timestamp, token, latenza e codice di risposta, senza registrare prompt e completion.
Questo è esattamente il tipo di distinzione che manca in molte discussioni sulla sovranità digitale. Dire “il modello è open source” non significa che il dato sia sovrano. Dire “non utilizziamo i prompt per il training” non significa che i prompt non vengano conservati. Dire “il servizio è europeo” non significa automaticamente che ogni subprocessor, backup o sistema di osservabilità sia europeo. La sovranità dell’AI nasce dall’intersezione tra modello, inference, infrastruttura, storage, rete, logging, contratti e giurisdizione. Il logo sulla homepage viene molto dopo.
Regolo è interessante anche per un’altra ragione: formalizza il proprio ruolo contrattuale come inference service e reverse proxy tecnico che instrada le richieste verso modelli sottostanti ospitati sull’infrastruttura Seeweb, occupandosi di autenticazione, gestione del traffico e misurazione dell’utilizzo. Il relativo accordo enterprise identifica Seeweb S.r.l., con sede in Italia, come provider del servizio e prevede anche un Data Processing Agreement ai sensi dell’articolo 28 del GDPR. Questo è un livello di dettaglio che conta molto più di qualsiasi slogan sulla “European AI”.
Naturalmente, anche qui serve evitare l’errore speculare. Regolo non dimostra che il problema della retention sia stato risolto universalmente. Dimostra piuttosto come può essere affrontato a livello di inference infrastructure. Se il cliente utilizza un tracing SaaS che conserva ogni prompt, la ZDR dell’inference provider non elimina quella copia. Se il browser registra la conversazione, il dato esiste prima di arrivare a Regolo. Se l’agent memory salva ogni messaggio in un database, la cancellazione del payload sulla GPU non cancella quella memoria. La sicurezza deve quindi essere end-to-end, non provider-to-provider.
Il self-hosting presenta esattamente lo stesso problema in forma più domestica. Mettere un modello su una GPU aziendale elimina diversi intermediari, ma non elimina automaticamente i log dell’inference server, gli access log del reverse proxy, i trace, i backup o i file temporanei. Anzi, può produrre un sistema nel quale il team infrastrutturale registra tutto “per sicurezza” e scopre sei mesi dopo di avere costruito involontariamente il più efficiente archivio aziendale di prompt riservati mai concepito. La privacy non migliora semplicemente perché il server è nel proprio rack.
La stessa logica vale per la compliance europea. GDPR, AI Act, requisiti contrattuali, data residency e sicurezza non sono sinonimi. Un’organizzazione può avere un trattamento GDPR-compliant e contemporaneamente una retention eccessiva; può avere dati residenti nell’Unione Europea e un’architettura con accessi di terze parti non adeguatamente governati; può avere ZDR presso il model provider e una copia completa delle conversazioni nel sistema di observability. L’errore nasce dal cercare una certificazione unica per un problema che è strutturalmente composto da più livelli.
La conseguenza economica è interessante. La scelta dell’inference provider non riguarda più soltanto prezzo per milione di token e velocità del modello. Entrano nel calcolo latenza, localizzazione geografica, rischio regolatorio, gestione dei dati, retention, costo dell’osservabilità e capacità di dimostrare cosa accade durante ogni inferenza. Regolo, con infrastruttura GPU europea e un modello dichiarato di zero retention, si inserisce precisamente in questo spazio: non come sostituto concettuale di tutti i grandi model provider, ma come possibile livello infrastrutturale per organizzazioni che vogliono ridurre il numero di soggetti che vedono i propri prompt e mantenere l’inference in Europa.
C’è poi un dettaglio che potrebbe diventare più importante del modello stesso: il routing. Se un’organizzazione dispone di diversi LLM, la domanda non dovrebbe essere soltanto quale modello produce la risposta migliore, ma quale modello è appropriato per quel determinato dato, quel determinato rischio e quel determinato costo. L’ecosistema Regolo ha sviluppato anche Brick, un sistema di semantic routing open source che seleziona il modello in funzione della complessità della richiesta e del rapporto tra qualità, costo e latenza. È un passaggio interessante perché sposta il concetto di governance dal modello singolo alla decisione dinamica su dove mandare ogni richiesta.
La vera architettura enterprise dell’AI, quindi, assomiglia sempre meno a una semplice API call e sempre più a una catena di custodia del dato. Il prompt entra dall’interfaccia, attraversa l’agent, può essere osservato dal tracing, eventualmente memorizzato dalla memoria, filtrato dal gateway, instradato verso un inference provider, trasformato in token, caricato nella VRAM, elaborato dalla GPU e restituito al chiamante. Ogni segmento introduce una possibilità di retention. Ogni possibilità di retention introduce una responsabilità. Ogni responsabilità richiede una policy verificabile.
La ZDR rimane dunque uno strumento importante, ma va collocata nel posto corretto della mappa. Non significa “nessuno vede il mio prompt”. Significa, più precisamente, che un determinato provider non conserva determinati payload secondo le condizioni previste dal relativo accordo e dalle funzionalità utilizzate. È molto meno spettacolare come frase commerciale, ma molto più utile come principio architetturale.
La domanda che un CTO dovrebbe fare prima di approvare un’infrastruttura LLM non è quindi “questo provider usa i miei dati per addestrare il modello?”. È: mostrami il percorso completo di un prompt, dal browser alla GPU e dalla GPU al log, indicami ogni punto in cui può essere copiato, dimmi chi lo controlla, dove si trova, quanto resta e quale contratto disciplina quella copia. Se la risposta richiede una presentazione PowerPoint di cinquanta slide, probabilmente la risposta è ancora no. Se invece il percorso è tracciabile fino alla memoria volatile della GPU, con logging limitato ai metadati e giurisdizione chiaramente definita, allora finalmente stiamo parlando di architettura AI e non di marketing.
In questo senso, la partita europea sulla sovranità dell’intelligenza artificiale non si giocherà soltanto costruendo modelli continentali. Si giocherà costruendo infrastrutture nelle quali sia possibile dimostrare, tecnicamente e contrattualmente, chi ha visto il dato, dove è stato elaborato e perché non è rimasto da qualche parte. È un obiettivo meno glamour di una nuova superintelligenza, ma decisamente più utile a un’azienda che deve spiegare a un cliente, a un DPO o a un regolatore dove sia finito il suo contratto riservato.