Hai scelto un data center europeo per la tua API di mappe. I server sono a Francoforte. Il contratto recita "residenza dei dati nell'UE". Chiudi la checklist di conformità GDPR convinto di essere a posto.
Non sei a posto.
Questo è il gap di conformità che coglie di sorpresa gli sviluppatori e i CTO europei ogni anno, ed è diventato ancora più rilevante da quando la sentenza Schrems II ha invalidato il Privacy Shield e ha posto maggiore attenzione sui flussi di dati transatlantici. Se la tua API di mappe è fornita da un'azienda statunitense, indipendentemente da dove si trovino i server, i dati di posizione dei tuoi utenti possono essere accessibili al governo degli Stati Uniti in base al CLOUD Act. Secondo il GDPR, questo è una potenziale violazione. In un audit DPA, è un rilievo.
Questa guida spiega i requisiti effettivi del GDPR per l'uso delle API di mappe, perché la sola residenza dei dati non è sufficiente, cosa significa in pratica il rischio del CLOUD Act e come valutare qualsiasi fornitore di API di mappe rispetto a una rigorosa checklist di conformità. È la guida che le aziende di mappatura statunitensi non possono scrivere in modo credibile, perché non possono superare la propria checklist.
Perché i dati di posizione richiedono seria attenzione al GDPR
I dati di posizione si trovano all'intersezione tra dati personali e dati sensibili secondo il GDPR, a seconda del contesto. L'articolo 4(1) definisce i dati personali come qualsiasi informazione relativa a una persona fisica identificata o identificabile. Un indirizzo IP, che ogni richiesta di tile mappa invia al fornitore API, è un dato personale. Una query di geocoding contenente un indirizzo di casa è un dato personale. Le coordinate GPS, se raccolte, possono essere usate per inferire indirizzo di casa, luogo di lavoro, frequentazione religiosa, appuntamenti medici e attività politica, potenzialmente qualificandosi come dati sensibili ai sensi dell'articolo 9.
Quando la tua applicazione web o app mobile carica una mappa, esegue una ricerca di geocoding o calcola un percorso, invia questi dati al tuo fornitore di API di mappe. I tuoi utenti non hanno acconsentito a condividere la loro posizione con un'azienda a San Francisco: hanno acconsentito a usare il tuo prodotto. Tu, in quanto titolare del trattamento, sei responsabile di garantire che ogni sub-processor che gestisce quei dati soddisfi i requisiti GDPR.
Se il tuo fornitore di API di mappe non supera il test di conformità, nemmeno tu lo superi.
Il problema del CLOUD Act: perché i fornitori statunitensi non possono rivendicare la piena conformità GDPR
Il Clarifying Lawful Overseas Use of Data (CLOUD) Act, approvato dal Congresso degli Stati Uniti nel 2018, richiede alle aziende tecnologiche statunitensi di conformarsi agli ordini legittimi del governo degli Stati Uniti di produrre dati, indipendentemente da dove tali dati siano fisicamente archiviati. Un'azienda statunitense con un server a Francoforte è comunque un'azienda statunitense. Se un tribunale statunitense o un'agenzia federale emette una richiesta CLOUD Act valida, l'azienda deve conformarsi.
Questo crea un conflitto diretto con il GDPR. L'articolo 48 del GDPR vieta il trasferimento di dati personali a autorità o tribunali stranieri senza un'adeguata base giuridica ai sensi della legge dell'UE. Il Comitato europeo per la protezione dei dati è stato esplicito: la conformità a una richiesta CLOUD Act, senza una valida base giuridica dell'UE, costituirebbe una violazione del GDPR.
Le conseguenze pratiche per gli sviluppatori europei sono nette:
- Google Maps Platform, gestito da Google LLC (un'azienda statunitense), è soggetto agli obblighi del CLOUD Act anche quando serve richieste attraverso data center europei.
- Mapbox, incorporata negli Stati Uniti, affronta la stessa esposizione strutturale.
- Nessuna quantità di linguaggio contrattuale o Clausole Contrattuali Standard dell'UE cambia la giurisdizione legale sottostante dell'azienda che fornisce il servizio.
Questo non significa che queste aziende condividano incautamente i tuoi dati. In pratica, le richieste CLOUD Act sono mirate a casi d'uso di forze dell'ordine, non a dati commerciali di routine. Ma l'esposizione legale esiste, e un serio audit DPA la identificherà. I settori regolamentati, come sanità, finanza e servizi legali, non possono accettare questa esposizione.
Residenza dei dati vs. sovranità dei dati: capire la differenza
Questi termini vengono spesso usati in modo intercambiabile nelle conversazioni di vendita, ma significano cose diverse:
Residenza dei dati significa che i tuoi dati sono archiviati in una posizione geografica specifica. Un fornitore statunitense che offre "residenza dei dati nell'UE" archivia i dati su server in Irlanda o Germania. La posizione fisica è nell'UE. La giurisdizione legale non lo è.
Sovranità dei dati significa che i tuoi dati sono soggetti alle leggi di una giurisdizione specifica. Perché i dati dell'UE siano veramente sovrani, devono essere controllati da un'entità soggetta alla legge dell'UE, non solo archiviati sul suolo europeo da una società madre statunitense.
La vera conformità GDPR per le API di mappe richiede la sovranità dei dati, non solo la residenza. La distinzione è più importante quando:
- La tua applicazione gestisce dati per pazienti sanitari, utenti di servizi finanziari o altre categorie regolamentate
- Operi in un settore soggetto ad audit formali da parte dell'Autorità Garante (banche, assicurazioni, settore pubblico)
- Il tuo CISO o il team legale esamina i contratti con i sub-processor con effettiva attenzione
- Devi rispondere a una richiesta di accesso da parte di un interessato o a un obbligo di notifica di violazione
Per la maggior parte delle applicazioni rivolte ai consumatori, il rischio pratico di una richiesta CLOUD Act è basso. Ma la conformità non è un calcolo di probabilità: o sei conforme o non lo sei.
La checklist pratica GDPR per valutare i fornitori di API di mappe
Usa questa checklist quando valuti qualsiasi fornitore di API di mappe per la conformità GDPR:
Entità legale e giurisdizione
- Il fornitore API è incorporato come entità legale nell'UE o nello SEE?
- La società madre (se presente) è anch'essa nell'ambito della giurisdizione UE, senza società madre incorporata negli USA?
- Il fornitore conferma esplicitamente l'assenza di esposizione al CLOUD Act nel suo DPA?
Accordo sul trattamento dei dati
- Il fornitore offre un DPA completo che fa riferimento ad articoli specifici del GDPR?
- Il DPA identifica le categorie di dati personali trattati (indirizzi IP, stringhe di query, coordinate)?
- Il DPA specifica i periodi di conservazione dei dati e gli obblighi di cancellazione?
- I sub-processor sono elencati e sono anch'essi entità nella giurisdizione UE?
- Il DPA affronta i tempi di notifica delle violazioni (il GDPR richiede 72 ore)?
Archiviazione ed elaborazione dei dati
- Tutti i dati sono archiviati ed elaborati nell'UE, con trasferimenti verso paesi terzi documentati come assenti?
- Il trasferimento di dati tra servizi (CDN, analisi, strumenti di supporto) è documentato e conforme al GDPR?
- Il fornitore offre la selezione della residenza dei dati a livello di account?
Certificazioni di sicurezza
- Il fornitore è certificato ISO 27001 (lo standard internazionale per la gestione della sicurezza delle informazioni)?
- Il fornitore è sottoposto a regolari audit di sicurezza di terze parti?
- Esiste un processo documentato di divulgazione delle vulnerabilità e di gestione delle patch?
Diritti degli utenti e controllo
- È possibile configurare l'API per ridurre al minimo la raccolta di dati (ad esempio, IP anonimizzato, nessun tracking analitico)?
- Il fornitore supporta le richieste di accesso e cancellazione degli interessati?
- Esistono processi documentati per rispondere alle richieste di regolatori da parte delle Autorità Garanti dell'UE?
MapAtlas: costruita per la sovranità dei dati dell'UE fin dal primo giorno
MapAtlas è una piattaforma europea di API di mappe, gestita da MapMetrics, un'azienda con sede nell'UE. La nostra infrastruttura opera nell'ambito della giurisdizione dell'UE, senza società madre statunitense e senza esposizione al CLOUD Act. La certificazione ISO 27001 è in atto, e il nostro DPA documenta categorie di dati specifiche, politiche di conservazione e impegni dei sub-processor.
Non si tratta di un'azienda statunitense che ha aggiunto opzioni di data center nell'UE: è un'azienda europea in cui la conformità all'UE è l'architettura predefinita, non un componente aggiuntivo.
La nostra API di visualizzazione e stilizzazione delle mappe elabora le richieste di tile attraverso l'infrastruttura dell'UE. Le query di geocoding, i calcoli dei percorsi e tutte le altre chiamate API rimangono nell'ambito della giurisdizione dell'UE dal momento in cui lasciano la tua applicazione. Il DPA lo riflette: non è un modello adattato da un template legale statunitense.
Per gli sviluppatori che costruiscono applicazioni in settori regolamentati, o per qualsiasi azienda europea che voglia una vera conformità piuttosto che una conformità di facciata, questa distinzione è concreta.
Confronto tra fornitori di API di mappe sulla conformità GDPR
| Criterio | Google Maps | Mapbox | MapAtlas |
|---|---|---|---|
| Entità legale UE | No (Google LLC) | No (corp USA) | Sì |
| Esposizione al CLOUD Act | Sì | Sì | No |
| Elaborazione dati nell'UE | Parziale | Parziale | Completa |
| ISO 27001 | Sì | Sì | Sì |
| Qualità DPA | Completo | Completo | Completo |
| Minimizzazione dati predefinita | Limitata | Limitata | Configurabile |
Per un confronto completo di prezzi e funzionalità, consulta le nostre analisi di MapAtlas vs. Google Maps e Mapbox vs. MapAtlas. Se anche il costo è una preoccupazione, consulta Prezzi dell'API Google Maps nel 2026: il gap di conformità si aggiunge a differenze di prezzo significative.
Passi pratici per gli sviluppatori europei adesso
Se stai attualmente usando un fornitore di API di mappe statunitense e non puoi effettuare immediatamente la migrazione, ecco i passi intermedi per ridurre la tua esposizione:
1. Anonimizza gli indirizzi IP prima che lascino la tua origine. Alcune API di mappe ti consentono di instradare le richieste attraverso il tuo server, eliminando o eseguendo l'hashing degli indirizzi IP prima che raggiungano l'API di terze parti. Questo non risolve completamente il problema del CLOUD Act, ma riduce la superficie dei dati personali.
2. Verifica cosa raccoglie effettivamente la tua API di mappe. Leggi attentamente l'informativa sulla privacy e il DPA del fornitore. Identifica ogni categoria di dati personali che ricevono dai tuoi utenti. Documenta questo nel tuo registro di mappatura dei dati.
3. Aggiorna la tua informativa sulla privacy. La tua informativa sulla privacy deve divulgare i sub-processor che ricevono dati personali. Se usi Google Maps, Google LLC è un sub-processor: i tuoi utenti hanno il diritto di saperlo.
4. Valuta il livello di rischio del tuo caso d'uso. Un sito di marketing che mostra una mappa statica dell'ufficio ha un profilo di rischio molto diverso rispetto a un'applicazione sanitaria che indirizza i pazienti alle cliniche. Calibra la tua urgenza di conseguenza.
5. Valuta realisticamente i costi di migrazione. Cambiare API di mappe è un compito tecnico, non un progetto che trasforma il business. La maggior parte delle migrazioni si completa in uno o due sprint. La nostra pagina dei prezzi mostra il confronto dei costi, e la nostra documentazione copre il percorso di migrazione tecnica da Google Maps e Mapbox.
Il framework europeo per la protezione dei dati è il più completo al mondo ed è attivamente applicato: nel solo 2023 sono state comminate multe GDPR per 1,3 miliardi di euro. I dati di posizione sono dati personali. Le API di mappe elaborano dati di posizione. La catena di conformità va direttamente dai tuoi utenti al tuo fornitore API. Verifica ogni anello di quella catena. E se un anello non supera la checklist sopra, sostituiscilo con uno che può.

