Sie haben ein EU-basiertes Rechenzentrum für Ihre Karten-API gewählt. Die Server stehen in Frankfurt. Der Vertrag sagt "EU-Datenspeicherung". Sie schließen die DSGVO-Compliance-Checkliste ab, überzeugt, dass Sie abgesichert sind.
Sie sind nicht abgesichert.
Das ist die Compliance-Lücke, die EU-Entwickler und CTOs jedes Jahr überrascht, und sie ist seit dem Schrems-II-Urteil, das Privacy Shield für ungültig erklärt hat, folgenreicher geworden und hat die Aufmerksamkeit auf transatlantische Datenflüsse erhöht. Wenn Ihre Karten-API von einem US-Unternehmen bereitgestellt wird, unabhängig davon, wo ihre Server stehen, können die Standortdaten Ihrer Nutzer dem US-Staat unter dem CLOUD Act zugänglich sein. Nach der DSGVO ist das ein potenzieller Verstoß. Bei einem AVV-Audit ist das ein Befund.
Dieser Leitfaden erklärt die tatsächlichen DSGVO-Anforderungen für die Karten-API-Nutzung, warum Datenspeicherung allein nicht ausreicht, was das CLOUD-Act-Risiko in der Praxis bedeutet und wie Sie jeden Karten-API-Anbieter anhand einer strengen Compliance-Checkliste bewerten können. Es ist der Leitfaden, den US-basierte Kartografieunternehmen nicht glaubwürdig schreiben können, weil sie ihre eigene Checkliste nicht bestehen.
Warum Standortdaten ernste DSGVO-Aufmerksamkeit erfordern
Standortdaten befinden sich je nach Kontext an der Schnittstelle von personenbezogenen Daten und sensiblen Daten nach DSGVO. Artikel 4(1) definiert personenbezogene Daten als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Eine IP-Adresse, die jede Karten-Tile-Anfrage an den API-Anbieter sendet, ist ein personenbezogenes Datum. Eine Geocoding-Anfrage, die eine Heimadresse enthält, ist ein personenbezogenes Datum. GPS-Koordinaten, wenn erhoben, können verwendet werden, um Heimadresse, Arbeitsplatz, Religionsausübung, Arzttermine und politische Aktivitäten zu inferieren und fallen potenziell unter sensible Daten nach Artikel 9.
Wenn Ihre Webanwendung oder mobile App eine Karte lädt, eine Geocoding-Suche auslöst oder eine Route berechnet, sendet sie diese Datenpunkte an Ihren Karten-API-Anbieter. Ihre Nutzer haben nicht zugestimmt, ihren Standort mit einem Unternehmen in San Francisco zu teilen. Sie haben zugestimmt, Ihr Produkt zu nutzen. Sie, als Verantwortlicher, sind dafür verantwortlich, dass jeder Auftragsverarbeiter, der diese Daten verarbeitet, die DSGVO-Anforderungen erfüllt.
Wenn Ihr Karten-API-Anbieter den Compliance-Test nicht besteht, bestehen Sie ihn auch nicht.
Das CLOUD-Act-Problem: Warum US-Anbieter keine vollständige DSGVO-Konformität beanspruchen können
Der Clarifying Lawful Overseas Use of Data (CLOUD) Act, der 2018 vom US-Kongress verabschiedet wurde, verpflichtet US-Technologieunternehmen dazu, rechtmäßigen US-Regierungsanordnungen zur Herausgabe von Daten nachzukommen, unabhängig davon, wo diese Daten physisch gespeichert sind. Ein US-Unternehmen mit einem Server in Frankfurt ist immer noch ein US-Unternehmen. Wenn ein US-Gericht oder eine Bundesbehörde eine gültige CLOUD-Act-Forderung stellt, muss das Unternehmen dieser nachkommen.
Das schafft einen direkten Konflikt mit der DSGVO. Artikel 48 der DSGVO verbietet die Übermittlung personenbezogener Daten an ausländische Behörden oder Gerichte ohne eine angemessene Rechtsgrundlage nach EU-Recht. Der Europäische Datenschutzausschuss war eindeutig: Die Erfüllung einer CLOUD-Act-Forderung ohne gültige EU-Rechtsgrundlage würde einen DSGVO-Verstoß darstellen.
Die praktische Konsequenz für EU-Entwickler ist eindeutig:
- Google Maps Platform, betrieben von Google LLC (einem US-Unternehmen), unterliegt CLOUD-Act-Verpflichtungen auch bei der Verarbeitung von Anfragen über europäische Rechenzentren.
- Mapbox, in den Vereinigten Staaten eingetragen, hat dieselbe strukturelle Exposition.
- Kein Maß an Vertragssprache oder EU-Standardvertragsklauseln ändert die zugrundeliegende Rechtsprechung des Unternehmens, das den Service bereitstellt.
Das bedeutet nicht, dass diese Unternehmen Ihre Daten rücksichtslos teilen. In der Praxis sind CLOUD-Act-Forderungen auf Strafverfolgungsanwendungsfälle ausgerichtet, nicht auf routinemäßige kommerzielle Daten. Aber die rechtliche Exposition besteht, und ein ernsthafter AVV-Audit wird sie identifizieren. Regulierte Branchen, Gesundheitswesen, Finanzen, Rechtsdienstleistungen, können diese Exposition überhaupt nicht akzeptieren.
Datenspeicherung vs. Datensouveränität: Den Unterschied verstehen
Diese Begriffe werden in Vertriebsgesprächen oft synonym verwendet, bedeuten aber unterschiedliche Dinge:
Datenspeicherung bedeutet, dass Ihre Daten an einem bestimmten geografischen Ort gespeichert werden. Ein US-Anbieter, der "EU-Datenspeicherung" anbietet, speichert Daten auf Servern in Irland oder Deutschland. Der physische Standort ist EU. Die Rechtsprechung ist es nicht.
Datensouveränität bedeutet, dass Ihre Daten den Gesetzen einer bestimmten Rechtsprechung unterliegen. Damit EU-Daten wirklich souverän sind, müssen sie von einer Entität kontrolliert werden, die EU-Recht unterliegt, nicht nur auf EU-Boden von einer US-Muttergesellschaft gespeichert werden.
Echte DSGVO-Konformität für Karten-APIs erfordert Datensouveränität, nicht nur Datenspeicherung. Der Unterschied ist am wichtigsten, wenn:
- Ihre Anwendung Daten für Gesundheitspatienten, Nutzer von Finanzdienstleistungen oder andere regulierte Kategorien verarbeitet
- Sie in einem Sektor tätig sind, der formellen DPB-Audits unterliegt (Banken, Versicherungen, öffentlicher Sektor)
- Ihr CISO oder Ihr Rechtsteam Auftragsverarbeiterverträge mit tatsächlicher Sorgfalt prüft
- Sie einer Anfrage betroffener Personen oder einer Meldepflicht bei Datenverstößen gegenüberstehen
Für die meisten verbraucherorientierten Anwendungen ist das praktische Risiko einer CLOUD-Act-Forderung gering. Compliance ist jedoch keine Wahrscheinlichkeitsrechnung. Entweder Sie sind konform oder Sie sind es nicht.
Die praktische DSGVO-Checkliste zur Bewertung von Karten-API-Anbietern
Verwenden Sie diese Checkliste bei der Bewertung eines Karten-API-Anbieters auf DSGVO-Konformität:
Rechtliche Einheit und Rechtsprechung
- Ist der API-Anbieter als juristische Person in der EU oder dem EWR eingetragen?
- Befindet sich die Muttergesellschaft (falls vorhanden) ebenfalls im EU-Rechtssystem, ohne US-eingetragene Muttergesellschaft?
- Bestätigt der Anbieter in seinem AVV ausdrücklich keine CLOUD-Act-Exposition?
Auftragsverarbeitungsvertrag (AVV)
- Bietet der Anbieter einen umfassenden AVV an, der spezifische DSGVO-Artikel referenziert?
- Identifiziert der AVV die Kategorien verarbeiteter personenbezogener Daten (IP-Adressen, Abfragestrings, Koordinaten)?
- Legt der AVV Datenspeicherungsfristen und Löschverpflichtungen fest?
- Sind Unterauftragsverarbeiter aufgeführt, und sind auch sie EU-Rechtsprechungsentitäten?
- Behandelt der AVV Fristen für Meldungen bei Datenverstößen (DSGVO erfordert 72 Stunden)?
Datenspeicherung und -verarbeitung
- Werden alle Daten innerhalb der EU gespeichert und verarbeitet, mit dokumentierten Nulldrittländertransfers?
- Ist der Datentransfer zwischen Services (CDN, Analytics, Support-Tools) dokumentiert und DSGVO-konform?
- Bietet der Anbieter Datenspeicherungsauswahl auf Kontoebene an?
Sicherheitszertifizierungen
- Ist der Anbieter ISO 27001 zertifiziert (der internationale Standard für Informationssicherheitsmanagement)?
- Unterzieht sich der Anbieter regelmäßigen Third-Party-Sicherheitsaudits?
- Gibt es einen dokumentierten Prozess zur Offenlegung von Sicherheitslücken und Patch-Management?
Nutzerrechte und Kontrolle
- Können Sie die API so konfigurieren, dass die Datenerfassung minimiert wird (z.B. anonymisierte IP, kein Analytics-Tracking)?
- Unterstützt der Anbieter Anfragen betroffener Personen auf Auskunft und Löschung?
- Gibt es dokumentierte Prozesse für die Beantwortung von Regulierungsanfragen von EU-Datenschutzbehörden?
MapAtlas: Von Anfang an für EU-Datensouveränität entwickelt
MapAtlas ist eine europäische Karten-API-Plattform, betrieben von MapMetrics, einem in der EU eingetragenen Unternehmen. Unsere Infrastruktur läuft innerhalb der EU-Rechtsprechung ohne US-Muttergesellschaft und ohne CLOUD-Act-Exposition. Die ISO-27001-Zertifizierung ist vorhanden, und unser AVV dokumentiert spezifische Datenkategorien, Aufbewahrungsrichtlinien und Unterauftragsverarbeiterverpflichtungen.
Das ist kein US-Unternehmen, das EU-Rechenzentrumsoptionen hinzugefügt hat. Es ist ein EU-Unternehmen, bei dem EU-Compliance die Standard-Architektur ist, keine Add-on-Option.
Unsere Karten-Visualisierungs- und Styling-API verarbeitet Tile-Anfragen über EU-Infrastruktur. Geocoding-Anfragen, Routenberechnungen und jeder andere API-Aufruf verbleiben in EU-Rechtsprechung, sobald sie Ihre Anwendung verlassen. Der AVV spiegelt das wider, es ist kein Boilerplate, das aus einer US-Rechtsvorlage übernommen wurde.
Für Entwickler, die Anwendungen in regulierten Sektoren erstellen, oder für jedes EU-Unternehmen, das echte Compliance statt performativer Compliance möchte, ist diese Unterscheidung wesentlich.
Vergleich von Karten-API-Anbietern auf DSGVO-Konformität
| Kriterium | Google Maps | Mapbox | MapAtlas |
|---|---|---|---|
| EU-juristische Person | Nein (Google LLC) | Nein (US-Corp) | Ja |
| CLOUD-Act-Exposition | Ja | Ja | Nein |
| EU-Datenverarbeitung | Teilweise | Teilweise | Vollständig |
| ISO 27001 | Ja | Ja | Ja |
| AVV-Qualität | Umfassend | Umfassend | Umfassend |
| Standard-Datenminimierung | Begrenzt | Begrenzt | Konfigurierbar |
Für einen vollständigen Preis- und Funktionsvergleich lesen Sie unsere Analysen zu MapAtlas vs. Google Maps. Wenn Kosten auch ein Anliegen sind, lesen Sie Google Maps API-Preise 2026. Die Compliance-Lücke kommt noch zu erheblichen Preisunterschieden hinzu.
Praktische Schritte für EU-Entwickler jetzt
Wenn Sie derzeit einen US-Karten-API-Anbieter verwenden und nicht sofort wechseln können, sind hier Zwischenschritte zur Reduzierung Ihrer Exposition:
1. Anonymisieren Sie IP-Adressen, bevor sie Ihren Origin verlassen. Einige Karten-APIs ermöglichen es Ihnen, Anfragen über Ihren eigenen Server zu leiten, dabei IP-Adressen zu entfernen oder zu hashen, bevor sie die Third-Party-API erreichen. Das löst das CLOUD-Act-Problem nicht vollständig, reduziert aber die personenbezogene Datenoberfläche.
2. Prüfen Sie, was Ihre Karten-API tatsächlich sammelt. Lesen Sie die Datenschutzrichtlinie und den AVV des Anbieters sorgfältig. Identifizieren Sie jede Kategorie personenbezogener Daten, die sie von Ihren Nutzern erhalten. Dokumentieren Sie das in Ihrem eigenen Datenverarbeitungsregister.
3. Aktualisieren Sie Ihre Datenschutzerklärung. Ihre Datenschutzerklärung muss Unterauftragsverarbeiter offenlegen, die personenbezogene Daten erhalten. Wenn Sie Google Maps verwenden, ist Google LLC ein Unterauftragsverarbeiter. Ihre Nutzer haben das Recht, das zu wissen.
4. Bewerten Sie das Risikoniveau Ihres Anwendungsfalls. Eine Marketing-Website, die eine statische Bürostandortkarte anzeigt, hat ein völlig anderes Risikoprofil als eine Gesundheitsanwendung, die Patienten zu Kliniken leitet. Kalibrieren Sie Ihre Dringlichkeit entsprechend.
5. Bewerten Sie Migrationskosten realistisch. Den Karten-API-Wechsel durchzuführen ist eine technische Aufgabe, kein geschäftstransformierendes Projekt. Die meisten Migrationen werden in einem oder zwei Sprints abgeschlossen. Unsere Preisseite zeigt den Kostenvergleich, und unsere Dokumentation deckt den technischen Migrationspfad von Google Maps und Mapbox ab.
Das EU-Datenschutzrahmen ist das umfassendste der Welt und wird aktiv durchgesetzt. 2023 allein wurden 1,3 Milliarden Euro an DSGVO-Bußgeldern verhängt. Standortdaten sind personenbezogene Daten. Karten-APIs verarbeiten Standortdaten. Die Compliance-Kette verläuft direkt von Ihren Nutzern zu Ihrem API-Anbieter. Verifizieren Sie jedes Glied in dieser Kette. Und wenn ein Glied die obige Checkliste nicht bestehen kann, ersetzen Sie es durch eines, das das kann.

