Localizzazione del trattamento, inferenza distribuita e accountability: cosa deve sapere, scegliere e documentare un titolare quando l’elaborazione AI può avvenire in una region UE diversa da quella di origine
Ing. Elena Colombo | Responsabile della Sede — Consulente Privacy | DPO/RPD | Componente OdV | I&P Partners, Milano
Giugno 2026
Quando un’organizzazione adotta un servizio di intelligenza artificiale in cloud, la domanda che si pone quasi sempre è una sola: il dato resta in Europa? È la domanda giusta, ma è incompleta. Restare nel perimetro UE non esaurisce gli obblighi del titolare. La domanda più precisa — quella che un DPO dovrebbe porsi prima dell’adozione — è un’altra: dove, esattamente, avviene il trattamento, chi lo esegue per mio conto, e sono in grado di dimostrarlo?
Il problema: l’inferenza AI non avviene sempre dove pensi
Nei servizi di AI generativa erogati in cloud, l’elaborazione di una richiesta — l’inferenza, ossia il momento in cui il modello produce la risposta — non avviene necessariamente nel data center più vicino o in quello che l’organizzazione ha scelto come riferimento. Per ragioni di capacità, latenza e bilanciamento del carico, l’infrastruttura del provider può instradare l’elaborazione verso una region diversa da quella di origine.
Per molte organizzazioni questa è una scoperta tardiva. Si sceglie un fornitore, si verifica che i dati siano «in Europa», e si considera chiusa la questione della localizzazione. Ma il trattamento è un’operazione dinamica: avviene in un luogo fisico, su un’infrastruttura gestita da un soggetto preciso, in un momento determinato. Se quel luogo può cambiare in funzione di logiche tecniche del provider, il titolare deve sapere entro quali confini quel cambiamento può avvenire — e deve poterlo documentare.
Cosa dice il GDPR sulla localizzazione del trattamento
Il GDPR non impone, in via generale, che il trattamento avvenga in un luogo fisico determinato all’interno dell’Unione. Impone qualcosa di diverso e più sostanziale: che il titolare sappia dove e come avviene il trattamento, che lo abbia regolato con chi lo esegue per suo conto, e che sia in grado di rendere conto delle proprie scelte. La localizzazione, in questa logica, non è un vincolo geografico astratto: è un elemento del governo del trattamento.
Trattamento intra-UE: non è un trasferimento, ma resta un trattamento
Qui va fatta una distinzione che molte analisi confondono. Un’inferenza che avviene in una region UE diversa da quella di origine — ma sempre all’interno dell’Unione — non è un trasferimento internazionale di dati. Le garanzie del Capo V del GDPR, che disciplinano i trasferimenti verso Paesi terzi, non si attivano: non c’è alcun Paese terzo coinvolto.
Questo, però, non significa che l’operazione sia irrilevante. Resta un trattamento a tutti gli effetti, con i suoi obblighi: deve avere una base giuridica, deve essere mappato nel registro, deve essere coperto dalle misure di sicurezza adeguate, deve rientrare — quando ne ricorrono i presupposti — nella valutazione d’impatto. Il fatto che il dato non lasci l’Unione semplifica il piano dei trasferimenti, ma non sospende il piano dell’accountability. Sono due piani distinti, e confonderli è un errore di sostanza: si finisce per credere che «il dato resta in UE» sia una risposta di conformità, quando è soltanto il punto di partenza.
Il ruolo del responsabile (art. 28) e l’accountability (art. 5.2)
Il provider cloud che esegue l’inferenza per conto dell’organizzazione è, nella quasi totalità dei casi, un responsabile del trattamento. L’art. 28 GDPR richiede che il rapporto sia regolato da un atto giuridico che vincoli il responsabile al titolare, che specifichi oggetto, durata, natura e finalità del trattamento, e che disciplini gli aspetti operativi — inclusa la collocazione delle operazioni e il ricorso a eventuali sub-responsabili. Le condizioni in cui l’inferenza può essere instradata verso una region diversa rientrano in questo perimetro contrattuale: non sono un dettaglio tecnico esterno all’accordo, ma una caratteristica del servizio che il titolare deve conoscere e accettare consapevolmente.
A monte di tutto opera l’art. 5(2): il principio di accountability. Non è sufficiente che il trattamento sia conforme; il titolare deve essere in grado di dimostrarlo. Sapere dove può avvenire l’inferenza, averlo regolato contrattualmente, averlo documentato nel registro e averne valutato i rischi è ciò che trasforma una scelta tecnologica in una scelta governata.
Un esempio concreto: l’inferenza cross-region nei servizi cloud
Alcuni servizi cloud di AI generativa offrono funzionalità di inferenza distribuita su più region — un meccanismo che instrada automaticamente la richiesta verso la region in grado di servirla, per migliorare disponibilità e prestazioni. È una soluzione tecnicamente sensata, e può essere configurata per mantenere l’elaborazione all’interno di un insieme definito di region UE.
L’esempio è utile non per promuovere una soluzione specifica, ma perché illustra con precisione il punto di governance: la flessibilità tecnologica è uno strumento, non un esonero. Ciò che conta, dal punto di vista del titolare, è che quei confini siano noti, configurati intenzionalmente e documentati.
Quando il dato resta nel perimetro UE
Se la funzionalità è configurata in modo da limitare l’instradamento a region situate all’interno dell’Unione, il dato non lascia il perimetro UE. Sul piano dei trasferimenti internazionali, dunque, non si pone un problema: non si applica il Capo V. Resta però aperto, e tutt’altro che secondario, il piano della documentazione: l’organizzazione deve poter dimostrare quale configurazione ha scelto, perché, e con quali garanzie il provider mantiene l’elaborazione entro quei confini. Una configurazione corretta non è un fatto che si presume: è un fatto che si prova.
Cosa cambia per logging, audit e tracciabilità
Quando l’inferenza può avvenire in una region diversa da quella di ingresso, occorre verificare dove vengono conservati i log dell’attività e con quali strumenti il titolare può ricostruirla. In architetture di questo tipo, i log dell’inferenza tendono a restare associati alla region di origine della richiesta, e il provider mette a disposizione strumenti di audit per tracciare le operazioni. Per il DPO, questo è il punto operativo decisivo: la tracciabilità non è un automatismo da dare per acquisito, ma una capacità da verificare in concreto. Se in caso di incidente o di richiesta dell’autorità non si è in grado di ricostruire dove e come è avvenuto un trattamento, il problema non è tecnico: è di accountability.
La checklist per il DPO: cosa valutare prima di adottare un servizio AI
- Mappare il perimetro reale del trattamento. Identificare in quali region il provider può eseguire l’inferenza e verificare se la configurazione consente di vincolarla a region UE.
- Verificare l’atto ex art. 28. Accertare che il contratto con il provider qualifichi correttamente il ruolo di responsabile, disciplini la collocazione delle operazioni e regoli i sub-responsabili.
- Aggiornare il registro (art. 30). Riflettere nel registro dei trattamenti la natura distribuita dell’elaborazione e i confini geografici entro cui può avvenire.
- Valutare le misure di sicurezza (art. 32). Verificare cifratura, gestione degli accessi e isolamento adeguati alla natura del servizio e alla sensibilità dei dati.
- Verificare la necessità di una DPIA (art. 35). Quando il trattamento presenta rischi elevati — per scala, categorie di dati o automazione decisionale — la valutazione d’impatto va condotta prima dell’adozione, non dopo.
- Accertare la tracciabilità. Confermare dove sono conservati i log e con quali strumenti è possibile ricostruire le operazioni in caso di incidente o di verifica.
- Documentare la scelta di configurazione. Conservare evidenza della configurazione adottata e delle ragioni che l’hanno motivata: è ciò che rende la scelta dimostrabile.
PA e sanità: perché la posta in gioco è più alta
Per la Pubblica Amministrazione e per il settore sanitario, il margine di tolleranza è strutturalmente più basso. Si trattano dati che ricadono spesso nelle categorie particolari dell’art. 9 — dati sulla salute, in primo luogo — e il contesto è soggetto a vincoli ulteriori sulla collocazione e sul governo dei dati. Qui la natura distribuita dell’elaborazione non è un dettaglio architetturale: è una variabile che incide direttamente sulla legittimità del trattamento e sulla fiducia degli interessati.
Per questi soggetti, la documentazione della configurazione e la dimostrabilità del perimetro non sono buone pratiche facoltative. Sono la condizione perché l’adozione di un servizio AI in cloud sia difendibile davanti a un’autorità di controllo — e, prima ancora, davanti ai cittadini e ai pazienti i cui dati vengono trattati. In questi contesti, adottare una tecnologia senza poterne governare il perimetro non è un rischio gestito: è un rischio subìto.
Conclusione: la flessibilità tecnologica non sospende l’accountability
L’inferenza distribuita è una risposta efficace a problemi reali di capacità e prestazioni. Non è, di per sé, un problema di conformità. Diventa un problema quando viene adottata senza essere governata: quando il titolare non sa entro quali confini può muoversi il trattamento, non lo ha regolato contrattualmente, non lo ha documentato e non è in grado di ricostruirlo.
Il punto non è se la tecnologia consenta di restare nel perimetro UE — spesso lo consente. Il punto è che restare nel perimetro UE non è una risposta di conformità: è un presupposto. La conformità nasce dalle scelte che il titolare compie e dalla sua capacità di dimostrarle. La flessibilità tecnologica amplia le opzioni a disposizione; non riduce gli obblighi. Chi adotta l’AI in cloud non deve chiedersi soltanto dove sono i miei dati, ma sono in grado di dimostrare dove vengono trattati, da chi e con quali garanzie. La risposta a questa domanda è ciò che distingue un trattamento governato da uno semplicemente avviato.
Se la tua organizzazione sta valutando l’adozione di servizi AI in cloud e vuole farlo in conformità al GDPR, [placeholder contatti / WhatsApp].
Ing. Elena Colombo
Responsabile della Sede — Consulente Privacy | DPO/RPD | Componente OdV
I&P Partners — Milano
Articolo destinato alla pubblicazione — Riproduzione consentita con citazione della fonte
