U heeft een EU-gebaseerd datacenter gekozen voor uw kaart-API. De servers staan in Frankfurt. Het contract vermeldt "EU-gegevenslocatie". U sluit de GDPR-nalevingschecklist tevreden dat u gedekt bent.
U bent niet gedekt.
Dit is het nalevingsgat dat EU-ontwikkelaars en CTO's elk jaar verrast, en het is consequenter geworden sinds het Schrems II-arrest Privacy Shield ongeldig verklaarde en het transatlantische dataverkeer onder verhoogde toetsing bracht. Als uw kaart-API wordt geleverd door een Amerikaans bedrijf, ongeacht waar hun servers staan, kan de locatiedata van uw gebruikers toegankelijk zijn voor de Amerikaanse overheid onder de CLOUD Act. Onder de GDPR is dat een potentiële inbreuk. Onder een DPA-audit is het een bevinding.
Deze gids legt de werkelijke GDPR-vereisten voor kaart-API-gebruik uit, waarom datalocatie alleen niet voldoende is, wat het CLOUD Act-risico in de praktijk betekent, en hoe u elke kaart-API-leverancier kunt beoordelen aan de hand van een rigoureuze nalevingschecklist. Het is de gids die in de VS gevestigde kartografiebedrijven niet geloofwaardig kunnen schrijven, omdat ze hun eigen checklist niet doorstaan.
Waarom locatiedata serieuze GDPR-aandacht vereist
Locatiedata bevindt zich op het snijvlak van persoonsgegevens en gevoelige gegevens onder de GDPR, afhankelijk van de context. Artikel 4(1) definieert persoonsgegevens als alle informatie over een geïdentificeerde of identificeerbare natuurlijke persoon. Een IP-adres, dat elk tegelverzoek naar de API-aanbieder stuurt, is een persoonsgegeven. Een geocoding-zoekopdracht met een thuisadres is een persoonsgegeven. GPS-coördinaten kunnen, als ze worden verzameld, worden gebruikt om het thuisadres, de werkplek, kerkbezoek, medische afspraken en politieke activiteiten af te leiden, en kunnen daarmee kwalificeren als gevoelige gegevens onder Artikel 9.
Wanneer uw webapplicatie of mobiele app een kaart laadt, een geocoding-zoekopdracht uitvoert of een route berekent, stuurt het deze gegevens naar uw kaart-API-aanbieder. Uw gebruikers hebben geen toestemming gegeven om hun locatie te delen met een bedrijf in San Francisco. Ze hebben ingestemd met het gebruik van uw product. U, als de verwerkingsverantwoordelijke, bent verantwoordelijk voor het waarborgen dat elke subverwerker die die data behandelt, voldoet aan de GDPR-vereisten.
Als uw kaart-API-aanbieder de nalevingstoets niet doorstaat, doet u dat ook niet.
Het CLOUD Act-probleem: waarom Amerikaanse aanbieders geen volledige GDPR-naleving kunnen claimen
De Clarifying Lawful Overseas Use of Data (CLOUD) Act, aangenomen door het Amerikaanse Congres in 2018, verplicht Amerikaanse technologiebedrijven te voldoen aan rechtmatige Amerikaanse overheidsverzoeken om data te overleggen, ongeacht waar die data fysiek is opgeslagen. Een Amerikaans bedrijf met een server in Frankfurt is nog steeds een Amerikaans bedrijf. Als een Amerikaanse rechtbank of federaal agentschap een geldig CLOUD Act-verzoek uitvaardigt, moet het bedrijf voldoen.
Dit creëert een direct conflict met de GDPR. Artikel 48 van de GDPR verbiedt de overdracht van persoonsgegevens aan buitenlandse autoriteiten of rechtbanken zonder een passende rechtsgrondslag naar EU-recht. De Europese Gegevensbeschermingsraad is expliciet: naleving van een CLOUD Act-verzoek, zonder geldige EU-rechtsgrondslag, vormt een GDPR-schending.
De praktische consequentie voor EU-ontwikkelaars is duidelijk:
- Google Maps Platform, beheerd door Google LLC (een Amerikaans bedrijf), valt onder CLOUD Act-verplichtingen ook wanneer verzoeken via Europese datacenters worden afgehandeld.
- Mapbox, opgericht in de Verenigde Staten, staat voor dezelfde structurele blootstelling.
- Geen enkele contractuele taal of EU-standaardcontractbepalingen verandert de onderliggende juridische jurisdictie van het bedrijf dat de dienst levert.
Dit betekent niet dat deze bedrijven uw data roekeloos delen. In de praktijk zijn CLOUD Act-verzoeken gericht op rechtshandhavingsgevallen, niet op routinematige commerciële data. Maar de juridische blootstelling bestaat, en een serieuze DPA-audit zal dit identificeren. Gereguleerde sectoren, gezondheidszorg, financiën, juridische dienstverlening, kunnen deze blootstelling helemaal niet accepteren.
Datalocatie vs. datasouvereiniteit: het verschil begrijpen
Deze termen worden in salesgesprekken vaak door elkaar gebruikt, maar ze betekenen verschillende dingen:
Datalocatie betekent dat uw data is opgeslagen op een specifieke geografische locatie. Een Amerikaanse aanbieder die "EU-datalocatie" biedt, slaat data op servers in Ierland of Duitsland op. De fysieke locatie is EU. De juridische jurisdictie is dat niet.
Datasouvereiniteit betekent dat uw data onderworpen is aan de wetten van een specifieke jurisdictie. Om EU-data werkelijk soeverein te laten zijn, moet het worden beheerd door een entiteit die onderworpen is aan het EU-recht, niet alleen opgeslagen op EU-grond door een Amerikaans moederbedrijf.
Echte GDPR-naleving voor kaart-APIs vereist datasouvereiniteit, niet alleen datalocatie. Het onderscheid is het belangrijkst wanneer:
- Uw applicatie data verwerkt voor zorgpatiënten, gebruikers van financiële diensten of andere gereguleerde categorieën
- U actief bent in een sector die formele DPA-audits ondergaat (bankwezen, verzekeringen, publieke sector)
- Uw CISO of juridisch team subverwerkersovereenkomsten met echte kritische blik beoordeelt
- U te maken krijgt met een verzoek om inzage van betrokkenen of een meldplicht datalekken
Voor de meeste consumentgerichte applicaties is het praktische risico van een CLOUD Act-verzoek laag. Maar naleving is geen kansberekening. U bent er aan of u bent het niet.
De praktische GDPR-checklist voor het evalueren van kaart-API-leveranciers
Gebruik deze checklist bij het evalueren van elke kaart-API-aanbieder op GDPR-naleving:
Rechtspersoon en jurisdictie
- Is de API-aanbieder als rechtspersoon opgericht in de EU of EER?
- Valt het moederbedrijf (indien aanwezig) ook onder EU-jurisdictie, zonder in de VS geïncorporeerd moederbedrijf?
- Bevestigt de aanbieder expliciet dat er geen CLOUD Act-blootstelling is in hun DPA?
Gegevensverwerkingsovereenkomst
- Biedt de aanbieder een uitgebreide DPA die verwijst naar specifieke GDPR-artikelen?
- Identificeert de DPA de categorieën verwerkte persoonsgegevens (IP-adressen, zoekopdrachten, coördinaten)?
- Specificeert de DPA bewaartermijnen en verwijderingsverplichtingen?
- Zijn subverwerkers vermeld, en zijn dit ook EU-jurisdictie-entiteiten?
- Behandelt de DPA de meldingstermijnen bij datalekken (GDPR vereist 72 uur)?
Dataopslag en -verwerking
- Wordt alle data opgeslagen en verwerkt binnen de EU, met gedocumenteerde afwezigheid van overdrachten naar derde landen?
- Is de datatransfer tussen diensten (CDN, analytics, ondersteuningstools) gedocumenteerd en GDPR-conform?
- Biedt de aanbieder selectie van datalocatie op accountniveau?
Beveiligingscertificeringen
- Is de aanbieder ISO 27001-gecertificeerd (de internationale norm voor informatiebeveiligingsbeheer)?
- Ondergaat de aanbieder regelmatige externe beveiligingsaudits?
- Is er een gedocumenteerd proces voor het bekendmaken van kwetsbaarheden en patchbeheer?
Gebruikersrechten en -controle
- Kunt u de API configureren om de dataverzameling te minimaliseren (bijv. geanonimiseerd IP, geen analyticstracking)?
- Ondersteunt de aanbieder verzoeken om inzage van betrokkenen en verzoeken om verwijdering?
- Zijn er gedocumenteerde processen voor het beantwoorden van regulatoire verzoeken van EU-toezichthouders?
MapAtlas: vanaf dag één gebouwd voor EU-datasouvereiniteit
MapAtlas is een Europees kaart-API-platform, beheerd door MapMetrics, een in de EU geïncorporeerd bedrijf. Onze infrastructuur draait binnen EU-jurisdictie zonder Amerikaans moederbedrijf en zonder CLOUD Act-blootstelling. ISO 27001-certificering is van kracht, en onze DPA documenteert specifieke datacategorieën, bewaartermijnen en verplichtingen van subverwerkers.
Dit is geen Amerikaans bedrijf dat EU-datacenteropties heeft toegevoegd. Het is een EU-bedrijf waar EU-naleving de standaardarchitectuur is, geen aanvulling.
Onze kaartvisualisatie- en styling-API verwerkt tegelverzoeken via EU-infrastructuur. Geocoding-zoekopdrachten, routeberekeningen en elke andere API-aanroep blijven binnen EU-jurisdictie vanaf het moment dat ze uw applicatie verlaten. De DPA weerspiegelt dit, het is geen standaardtekst aangepast vanuit een Amerikaans juridisch sjabloon.
Voor ontwikkelaars die applicaties bouwen in gereguleerde sectoren, of voor elk EU-bedrijf dat echte naleving wil in plaats van schijnnaleving, is dit onderscheid wezenlijk.
Vergelijking van kaart-API-aanbieders op GDPR-naleving
| Criteria | Google Maps | Mapbox | MapAtlas |
|---|---|---|---|
| EU-rechtspersoon | Nee (Google LLC) | Nee (VS-bedrijf) | Ja |
| CLOUD Act-blootstelling | Ja | Ja | Nee |
| EU-dataverwerking | Gedeeltelijk | Gedeeltelijk | Volledig |
| ISO 27001 | Ja | Ja | Ja |
| DPA-kwaliteit | Uitgebreid | Uitgebreid | Uitgebreid |
| Standaard dataminimalisatie | Beperkt | Beperkt | Configureerbaar |
Voor een volledige prijs- en functievergelijking, zie onze analyses van MapAtlas vs. Google Maps en Mapbox vs. MapAtlas. Als kosten ook een zorg zijn, zie Google Maps API-prijzen in 2026, het nalevingsgat komt bovenop aanzienlijke prijsverschillen.
Praktische stappen voor EU-ontwikkelaars nu
Als u momenteel een Amerikaanse kaart-API-aanbieder gebruikt en niet onmiddellijk kunt overstappen, zijn hier tussentijdse stappen om uw blootstelling te verminderen:
1. Anonimiseer IP-adressen voordat ze uw origin verlaten. Sommige kaart-APIs staan toe dat u verzoeken via uw eigen server stuurt, waarbij IP-adressen worden verwijderd of gehashed voordat ze de externe API bereiken. Dit lost het CLOUD Act-probleem niet volledig op, maar vermindert het persoonsgegevensoppervlak.
2. Controleer wat uw kaart-API daadwerkelijk verzamelt. Lees het privacybeleid en de DPA van de aanbieder zorgvuldig. Identificeer elke categorie persoonsgegevens die ze van uw gebruikers ontvangen. Documenteer dit in uw eigen gegevensregister.
3. Werk uw privacyverklaring bij. Uw privacyverklaring moet subverwerkers vermelden die persoonsgegevens ontvangen. Als u Google Maps gebruikt, is Google LLC een subverwerker. Uw gebruikers hebben het recht dit te weten.
4. Beoordeel het risiconiveau van uw gebruik. Een marketingwebsite die een statische kantoorlocatiekaart weergeeft heeft een heel ander risicoprofiel dan een zorgapplicatie die patiënten naar klinieken routeert. Stem uw urgentie hierop af.
5. Beoordeel migratiekosten realistisch. Van kaart-API wisselen is een technische taak, geen bedrijfstransformerende operatie. De meeste migraties worden voltooid in een of twee sprints. Onze prijspagina toont de kostenvergelijking, en onze documentatie behandelt het technische migratiepad vanuit Google Maps en Mapbox.
Het gegevensbeschermingskader van de EU is het meest uitgebreide ter wereld en wordt actief gehandhaafd, in 2023 alleen al werden er GDPR-boetes van 1,3 miljard euro opgelegd. Locatiedata zijn persoonsgegevens. Kaart-APIs verwerken locatiedata. De nalevingsketen loopt rechtstreeks van uw gebruikers naar uw API-aanbieder. Controleer elke schakel in die keten. En als een schakel de bovenstaande checklist niet doorstaat, vervang hem door een die dat wel kan.
Veelgestelde vragen
Maakt opslag op EU-servers een Amerikaanse kaart-API GDPR-conform?
Niet noodzakelijk. Amerikaanse bedrijven die EU-datacenters exploiteren, vallen nog steeds onder de CLOUD Act, die hen verplicht data uit te leveren die overal ter wereld is opgeslagen als een Amerikaanse rechtbank of overheidsinstantie daarom verzoekt. Echte GDPR-naleving vereist een EU-rechtspersoon, EU-dataopslag en geen blootstelling aan de CLOUD Act, niet alleen een EU-serverlocatie.
Waar moet ik op letten bij een GDPR-conforme kaart-API?
Controleer of de aanbieder een rechtspersoon is die is opgericht in de EU of EER, of data wordt opgeslagen en verwerkt binnen EU-jurisdictie zonder overdrachten naar derde landen, of de aanbieder ISO 27001-gecertificeerd is, of hun DPA gedetailleerd is en verwijst naar specifieke GDPR-artikelen, en of er geen moedermaatschappij-relaties bestaan die CLOUD Act-blootstelling creëren.
Welke locatiedata verzamelt een kaart-API doorgaans van eindgebruikers?
Kaart-APIs kunnen IP-adressen verzamelen (gebruikt voor tegelverzoekroutering), apparaatidentificatoren, zoekopdrachten (geocoding-verzoeken) en, als de gebruiker toestemming geeft, GPS-coördinaten. Elk van deze gegevens vormt persoonsgegevens onder de GDPR. Uw DPA met de API-aanbieder moet specificeren hoe deze data wordt verwerkt, bewaard en beveiligd.

