Data residency e data sovereignty in UE: dove girano i dati del tuo Agente AI

In breve

• La data residency indica dove i dati sono fisicamente archiviati e trattati; è diversa dalla data sovereignty, cioè l’ordinamento giuridico a cui sono soggetti, e dalla conformità GDPR.
• In un Agente AI i dati possono uscire dall’UE in cinque punti: inferenza del modello, embeddings e database vettoriale, log e analytics, backup e disaster recovery, supporto e accesso operativo.
• L’AI Act (Regolamento UE 2024/1689) non impone la data residency europea, ma dal 2 agosto 2026 gli obblighi di trasparenza dell’articolo 50 richiedono di dimostrare come si comporta il sistema.
• Userbot opera con data center nell’Unione europea, a Milano e Francoforte, con audit trail completo delle decisioni degli agenti e un’architettura model-agnostic.

«I nostri server sono in Europa» è una risposta che non basta più. Vediamo dove passano davvero i dati di un Agente AI e quali domande porsi per capire meglio come funziona.

In quasi ogni gara con un ente pubblico o nel confronto con un’azienda regolata arriva il momento in cui il DPO fa una domanda apparentemente semplice: dove risiedono i dati? La risposta standard è «in Unione europea». Ma non basta! La data residency UE di una piattaforma conversazionale non si esaurisce nella posizione geografica dei server applicativi, infatti nella catena di un Agente AI ci sono almeno cinque punti in cui un dato può uscire dall’Europa senza che nessuno lo abbia deciso davvero.

In questo articolo chiariamo cosa significa data residency, perché non coincide con la conformità al GDPR, dove si nascondono i passaggi fuori UE, cos’è invece la data sovregnity e quali domande porre a un fornitore per ottenere risposte verificabili invece che rassicurazioni.

Che cosa significa davvero data residency UE

La data residency indica dove i dati sono fisicamente archiviati e trattati. È un requisito contrattuale e infrastrutturale: si dimostra indicando le region dei data center, i subprocessor coinvolti e i flussi previsti.

Va distinta da due concetti vicini che vengono spesso confusi:

• Data sovereignty. Riguarda a quale ordinamento giuridico i dati sono soggetti. Un dato archiviato a Francoforte ma controllato da un soggetto sottoposto a normative extraeuropee può essere oggetto di richieste di accesso da parte di autorità di quel paese.
• Conformità GDPR. Riguarda come i dati personali vengono trattati: base giuridica, minimizzazione, tempi di conservazione, diritti degli interessati. Si può essere pienamente conformi al GDPR trasferendo dati fuori UE con garanzie adeguate, e si può avere tutto in Europa restando comunque non conformi.

Le tre cose vanno verificate separatamente. Un fornitore che risponde a una domanda sulla residency citando il GDPR ha, nella migliore delle ipotesi, frainteso la domanda.

I cinque punti in cui i dati potrebbero uscire dall’UE

Questa è la parte che raramente compare nelle schede tecniche.

1. L’inferenza del modello linguistico. È il caso più frequente e il meno visibile. La piattaforma può essere ospitata in UE mentre ogni messaggio dell’utente viene inviato all’endpoint di un provider di modelli in un’altra region. Il testo della conversazione, con tutto quello che l’utente ha scritto dentro, transita lì.
2. Gli embeddings e il database vettoriale. I documenti indicizzati per il recupero delle risposte vengono trasformati in vettori. Questa trasformazione richiede a sua volta un modello e il servizio che la esegue può stare altrove.
3. Log, analytics e osservabilità. Gli strumenti di monitoraggio sono spesso servizi di terze parti con storage predefinito fuori UE. I log delle conversazioni contengono gli stessi dati delle conversazioni.
4. Backup e disaster recovery. La region primaria può essere europea e la copia di sicurezza no. È una configurazione più comune di quanto si creda e quasi mai dichiarata spontaneamente.
5. Supporto e accesso operativo. Se il team che fa manutenzione accede ai sistemi da un altro continente, esiste un accesso ai dati che nessun diagramma di rete mostra.

Il punto uno è quello decisivo ed è anche il motivo per cui un’architettura model-agnostic ha un valore di compliance oltre che tecnico: poter scegliere quale modello usare, e dove gira, significa poter allineare il livello di riservatezza del caso d’uso alla collocazione dell’elaborazione. Abbiamo raccontato come confrontiamo i modelli tra loro nell’articolo sulle differenze tra modelli LLM.

Data residency e AI Act: cosa cambia davvero

Qui serve una precisazione che raramente viene fatta, perché fa comodo a chi vende: l’AI Act non impone la data residency europea. Il Regolamento (UE) 2024/1689 disciplina rischi, trasparenza e governance dei sistemi di AI, non la geografia dello storage. Chiunque presenti i data center europei come «un obbligo dell’AI Act» sta forzando la mano.

Detto questo, i due temi si incontrano nella pratica. Dal 2 agosto 2026 diventano applicabili gli obblighi di trasparenza dell’articolo 50, quelli che impongono di far sapere all’utente che sta interagendo con un sistema di intelligenza artificiale, e diventa pienamente operativo il regime sanzionatorio. Il pacchetto di semplificazione noto come Digital Omnibus, approvato dal Consiglio dell’Unione europea il 29 giugno 2026, ha rinviato gli obblighi sui sistemi ad alto rischio al 2 dicembre 2027 e al 2 agosto 2028, ma non ha toccato la scadenza sulla trasparenza. Abbiamo dedicato al tema due approfondimenti: il quadro generale in AI Act e customer service e la parte operativa nella checklist di trasparenza sull’articolo 50.

Il collegamento reale con la residency passa da qui: gli obblighi di trasparenza e la piena operatività delle autorità di controllo rendono necessario poter dimostrare come il sistema si comporta. E dimostrare significa avere log, tracciabilità delle decisioni e un percorso dei dati documentato. Una catena che attraversa quattro giurisdizioni è più difficile da documentare, non illegale per definizione.

Parla con un esperto Userbot → È gratuito

Serve davvero? A chi serve e cosa valutare

Non tutti i progetti hanno bisogno di questo livello di attenzione; se il vostro Agente AI risponde a domande su orari di apertura o stato di una spedizione, la geografia dei server difficilmente cambia qualcosa di sostanziale.

Il tema diventa determinante quando nella conversazione passano dati sanitari, finanziari, HR, o comunque dati che qualcuno, dentro o fuori l’azienda, potrebbe voler proteggere da un accesso non previsto dal diritto europeo: qui il problema non è solo la privacy, è la possibilità che una legge di un Paese terzo dia a un’autorità straniera un accesso che secondo il solo diritto UE non esisterebbe. È il motivo per cui oggi si parla sempre più spesso di data sovereignty come concetto distinto, e più esigente, della semplice conformità GDPR.

Tutto bello e tutto giusto, ma vale la pena essere onesti su un punto: nella vita digitale di ogni azienda, anche la più attenta, ci sono già oggi decine di strumenti che hanno piena data residency europea, o quasi, ma non una vera data sovereignty. La posta elettronica aziendale su Microsoft 365 o Google Workspace, buona parte dei CRM in cloud, molti strumenti di videoconferenza: i dati possono essere archiviati in region europee, ma il fornitore resta una società soggetta a leggi extra-UE, con personale di supporto che può operare da un altro continente e chiavi di cifratura che spesso restano nelle sue mani. Questo non li rende automaticamente fuori norma: possono essere, e nella maggior parte dei casi sono, pienamente conformi al GDPR grazie a Standard Contractual Clauses, misure supplementari o altre garanzie previste dal regolamento.

Il punto è un altro: l’azienda che li usa ha già, di fatto, accettato un certo livello di esposizione giuridica extra-UE, magari senza averlo mai formalizzato come scelta.

Cosa valutare, quindi, prima di decidere quanto la data residency e la data sovereignty debbano pesare nella scelta di un fornitore per l’Agente AI?

• La natura dei dati trattati. Un conto è un catalogo prodotti, un altro un fascicolo clinico o una pratica di credito. Più il dato è sensibile, più conta sapere non solo dove sta ma chi può davvero accedervi, da dove e secondo quale legge.
• La coerenza con gli strumenti già in uso. Se l’azienda usa già piattaforme cloud extra-UE per l’operatività quotidiana, la domanda non è “possiamo permetterci un fornitore non pienamente sovrano”, ma “questo caso d’uso specifico richiede un livello di controllo superiore a quello che accettiamo già altrove”. Non è un’incoerenza avere standard diversi per dati diversi.
• I vincoli contrattuali o normativi specifici. Alcuni bandi e alcuni settori impongono la residenza, o addirittura la sovranità, europea per contratto, indipendentemente da cosa basterebbe secondo il GDPR in generale. Va verificato a monte, non scoperto in fase di collaudo.
• Il costo dell’alternativa. Un’architettura vincolata a un’unica region o a un unico modello ha spesso un costo in termini di prestazioni o di scelta tecnologica. Vale la pena chiedersi se quel costo è giustificato dal rischio reale del caso d’uso, o se si sta pagando una rassicurazione che nessuno vi chiederà mai.

In sintesi: la data residency, e ancora di più la data sovereignty, non sono requisiti universali da spuntare per principio, tanto più in un’azienda che probabilmente le sta già ignorando altrove senza problemi. Ma nei settori e nei casi d’uso dove il dato è davvero sensibile, la domanda giusta da farsi per prima non è “abbiamo bisogno della residenza UE?”, ma “cosa succede se un giorno dobbiamo dimostrare chi ha potuto accedere a questi dati, e siamo in grado di farlo?”.

Le domande da fare al fornitore

Sei domande che producono risposte verificabili invece che rassicurazioni generiche.

• In quali region si trovano archiviazione primaria, backup e ambienti di test?
• Dove avviene l’inferenza del modello linguistico? Posso scegliere un modello ospitato in UE?
• Qual è l’elenco completo e aggiornato dei subprocessor, con la loro collocazione?
• I contenuti delle conversazioni vengono usati per addestrare modelli? Se sì, come si esclude?
• Per quanto tempo restano i log e chi vi può accedere, con quale tracciamento degli accessi?
• In caso di richiesta di un’autorità extraeuropea al fornitore, qual è la procedura prevista?

La formulazione che consigliamo di usare, letteralmente: «Mi mandate il diagramma del percorso di un singolo messaggio utente, dall’ingresso nel widget fino alla risposta, con indicata la region di ogni componente attraversato?» Chi ha davvero governato il tema quel diagramma ce l’ha. Gli altri rispondono con una slide sulla sicurezza.

Alla luce di queste informazioni e in base ai dati trattati, ai processi coinvolti e al progetto specifico, sarà quindi possibile valutare il livello di data residency UE o di data sovregnity in UE da applicare.

Come lo affrontiamo in Userbot

Userbot opera attraverso data center situati nell’Unione europea, a Milano e Francoforte, con audit trail completo delle decisioni prese dagli agenti. L’architettura è model-agnostic, quindi il modello linguistico è una scelta di progetto e non un vincolo della piattaforma, e la parte di osservabilità è pensata per ricostruire il percorso di una conversazione passaggio per passaggio, che è poi la condizione pratica per rispondere a un audit.

Non lo presentiamo come una garanzia assoluta, perché nessuna architettura lo è: in ogni progetto restano scelte che dipendono dai sistemi del cliente e dai modelli selezionati. Ma è il livello a cui riteniamo si debba rispondere quando qualcuno chiede dove finiscono i suoi dati.

Una domanda che vale la pena fare presto

Il momento peggiore per scoprire che l’inferenza gira fuori dall’Unione europea è la settimana prima del go-live, quando l’ufficio legale legge il contratto con attenzione per la prima volta. È una domanda che costa dieci minuti in fase di scouting e può costare mesi se rimandata. Vale la pena metterla nella prima chiamata, non nell’ultima.

Team Userbot, La redazione di Userbot

Le persone di Userbot che seguono l’adozione dell’AI nelle aziende: prodotto, governance e formazione.