GDPR Uyumlu Harita API'leri İçin AB Geliştirici Rehberi

AB tabanlı bir veri merkezi seçtiniz harita API'niz için. Sunucular Frankfurt'ta. Sözleşme "AB veri kalıntısı" diyor. GDPR uyum kontrol listesini kapatıp güvenle sahibi olduğunuza inanmışsınız.

Değilsiniz.

Bu uyum boşluğu her yıl AB geliştiricilerini ve CTO'larını basıl alır ve Schrems II hükmü Privacy Shield'ı geçersiz kıldığından ve transatlantik veri akışları üzerinde artan inceleme yerleştirdiğinden daha sonuçlu hale geldi. Harita API'niz ABD şirketi tarafından sağlanırsa, sunucuları nerede otursa olsun, kullanıcılarının konum verilerine CLOUD Yasası kapsamında ABD hükümeti erişebilir. GDPR kapsamında bu potansiyel bir ihlaldir. DPA denetimi altında bu bir bulgu.

Bu rehber harita API'si kullanımı için gerçek GDPR gerekliliklerini, veri kalıntısının neden yeterli olmadığını, CLOUD Yasası riskinin pratikte ne anlama geldiğini ve herhangi bir harita API'si satıcısını katı uyum kontrol listesine karşı değerlendirmeyi açıklar. Bu ABD merkezli haritalama şirketlerinin inandırıcı şekilde yazamayacağı bir rehberdir, çünkü kendi kontrol listesini geçemezler.

Konum Verisi Neden Ciddi GDPR Dikkati Gerektirir

Konum verisi, bağlama göre GDPR kapsamında kişisel veri ile hassas veri arasında yer alır. Madde 4(1) kişisel veriyi tanımlanmış veya tanımlanabilir doğal kişiyle ilişkili herhangi bir bilgi olarak tanımlar. Her harita kiremit isteğinin API sağlayıcısına gönderdiği IP adresi kişisel verisidir. Ev adresi içeren bir geocoding sorgusu kişisel verisidir. GPS koordinatları toplanırsa, ev adresini, işyerini, dini katılımı, tıbbi randevuları ve siyasi faaliyetleri çıkarmak için kullanılabilir ve potansiyel olarak Madde 9 kapsamında hassas veri olarak nitelendirilebilir.

Web uygulaması veya mobil uygulaması harita yüklediğinde, geocoding araması yaptığında veya rota hesapladığında, bu veri noktalarını harita API'si sağlayıcısına gönderir. Kullanıcılarınız San Francisco'daki bir şirketle konum paylaşımına rıza vermedi. Ürün kullanımına rıza verdiler. Veri denetleyicisi olarak, bu verileri işleyen her alt işlemcinin GDPR gerekliliklerini karşıladığından emin olmaktan sorumlusunuz.

Harita API'si sağlayıcınız uyum testi başarısız olursa, siz de başarısız olursunuz.

CLOUD Yasası Sorunu: ABD Sağlayıcıları Neden Tam GDPR Uyumluluğu İddia Edemez

2018'de ABD Kongresi tarafından çıkartılan Yasal Denizaşırı Veri Kullanımını Netleştirme (CLOUD) Yasası, ABD teknoloji şirketlerinin yasal ABD hükümeti siparişlerine uymasını gerektirir, bu veri nerede fiziksel olarak depolanırsa depolanmış olsun. Frankfurt'ta sunucusu olan ABD şirketi hala ABD şirketidir. Bir ABD mahkemesi veya federal kurumu geçerli bir CLOUD Yasası talebini yayınlarsa, şirket uyum sağlamalıdır.

Bu GDPR ile doğrudan bir çatışma yaratır. GDPR'nin 48. Maddesi, kişisel verileri AB yasası kapsamında uygun yasal dayanak olmadan yabancı makamlar veya mahkemelere aktarılmasını yasaklar. Avrupa Veri Koruma Kurulu açık olmuştur: geçerli AB yasal dayanağı olmadan CLOUD Yasası talebine uyum GDPR ihlali oluşturur.

AB geliştiricileri için pratik sonuç belgindir:

• Google LLC (ABD şirketi) tarafından işletilen Google Haritalar Platformu, Avrupa veri merkezleri aracılığıyla talepleri sunmaya devam ederken bile CLOUD Yasası yükümlülüklerine tabidir.
• ABD'de kurulmuş Mapbox aynı yapısal maruziyetle karşı karşıyadır.
• Hiçbir sözleşme diline veya AB Standart Sözleşme Maddelerine hizmet sağlayan şirketin temel yasal yetki alanını değiştirmez.

Bu şirketlerin verilerinizi pervasız şekilde paylaştığı anlamına gelmez. Pratikte, CLOUD Yasası talepleri rutin ticari verileri değil, yasal yaptırım kullanım örneklerini hedeflenir. Ancak yasal maruziyeti vardır ve ciddi DPA denetimi onu belirleyecektir. Düzenlenen endüstriler, sağlık, finans, yasal hizmetler bu maruziyeti hiç kabul edemez.

Data Residency vs. Data Sovereignty: Understanding the Difference

These terms are often used interchangeably in sales conversations, but they mean different things:

Data residency means your data is stored in a specific geographic location. A US provider offering "EU data residency" stores data on servers in Ireland or Germany. The physical location is EU. The legal jurisdiction is not.

Data sovereignty means your data is subject to the laws of a specific jurisdiction. For EU data to be truly sovereign, it must be controlled by an entity subject to EU law, not just stored on EU soil by a US parent company.

True GDPR compliance for map APIs requires data sovereignty, not just data residency. The distinction matters most when:

• Your application handles data for healthcare patients, financial service users, or other regulated categories
• You operate in a sector that faces formal DPA audits (banking, insurance, public sector)
• Your CISO or legal team reviews sub-processor agreements with actual scrutiny
• You face a data subject access request or a breach notification obligation

For most consumer-facing applications, the practical risk of a CLOUD Act demand is low. But compliance is not a probability calculation. Either you are compliant or you are not.

The Practical GDPR Checklist for Evaluating Map API Vendors

Use this checklist when evaluating any map API provider for GDPR compliance:

Legal Entity and Jurisdiction

• Is the API provider incorporated as a legal entity in the EU or EEA?
• Is the parent company (if any) also within EU jurisdiction, with no US-incorporated parent?
• Does the provider explicitly confirm no CLOUD Act exposure in their DPA?

Data Processing Agreement

• Does the provider offer a comprehensive DPA that references specific GDPR articles?
• Does the DPA identify the categories of personal data processed (IP addresses, query strings, coordinates)?
• Does the DPA specify data retention periods and deletion obligations?
• Are sub-processors listed, and are they also EU-jurisdiction entities?
• Does the DPA address breach notification timelines (GDPR requires 72 hours)?

Data Storage and Processing

• Is all data stored and processed within the EU, with documented no third-country transfers?
• Is data transfer between services (CDN, analytics, support tools) documented and GDPR-compliant?
• Does the provider offer data residency selection at the account level?

Security Certifications

• Is the provider ISO 27001 certified (the international standard for information security management)?
• Does the provider undergo regular third-party security audits?
• Is there a documented vulnerability disclosure and patch management process?

User Rights and Control

• Can you configure the API to minimise data collection (e.g., anonymised IP, no analytics tracking)?
• Does the provider support data subject access requests and deletion requests?
• Are there documented processes for responding to regulatory enquiries from EU DPAs?

MapAtlas: Built for EU Data Sovereignty from Day One

MapAtlas is a European mapping API platform, operated by MapMetrics, an EU-incorporated company. Our infrastructure runs within EU jurisdiction with no US parent company and no CLOUD Act exposure. ISO 27001 certification is in place, and our DPA documents specific data categories, retention policies, and sub-processor commitments.

This is not a US company that has added EU data centre options. It is an EU company where EU compliance is the default architecture, not an add-on.

Our map visualisation and styling API processes tile requests through EU infrastructure. Geocoding queries, route calculations, and every other API call stay within EU jurisdiction from the moment they leave your application. The DPA reflects this, it is not boilerplate adapted from a US legal template.

For developers building applications in regulated sectors, or for any EU business that wants genuine compliance rather than performative compliance, this distinction is material.

Comparing Map API Providers on GDPR Compliance

For a full pricing and feature comparison, see our breakdowns of MapAtlas vs. Google Maps and Mapbox vs. MapAtlas. If cost is also a concern, see Google Maps API pricing in 2026, the compliance gap comes on top of significant price differences.

Practical Steps for EU Developers Right Now

If you are currently using a US map API provider and cannot immediately switch, here are interim steps to reduce your exposure:

1. Anonymise IP addresses before they leave your origin. Some map APIs allow you to pass requests through your own server, stripping or hashing IP addresses before they reach the third-party API. This does not fully resolve the CLOUD Act issue, but it reduces the personal data surface.

2. Audit what your map API actually collects. Read the provider's privacy policy and DPA carefully. Identify every category of personal data they receive from your users. Document this in your own data mapping register.

3. Update your privacy notice. Your privacy notice must disclose sub-processors who receive personal data. If you use Google Maps, Google LLC is a sub-processor. Your users are entitled to know this.

4. Assess the risk level of your use case. A marketing website displaying a static office location map has a very different risk profile from a healthcare application routing patients to clinics. Calibrate your urgency accordingly.

5. Evaluate migration costs realistically. Switching map APIs is a technical task, not a business-transforming project. Most migrations complete in a sprint or two. Our pricing page shows the cost comparison, and our documentation covers the technical migration path from Google Maps and Mapbox.

The EU's data protection framework is the most comprehensive in the world, and it is being actively enforced, €1.3 billion in GDPR fines were issued in 2023 alone. Location data is personal data. Map APIs process location data. The compliance chain runs directly from your users to your API provider. Verify every link in that chain. And if a link cannot pass the checklist above, replace it with one that can.