Руководство EU-разработчика по соответствию API карт требованиям GDPR

Вы выбрали центр обработки данных в ЕС для вашего API карт. Серверы находятся во Франкфурте. В контракте указано «Постоянное размещение данных в ЕС». Вы закрыли контрольный список соответствия GDPR с уверенностью, что всё покрыто.

Вы не покрыты.

Это разрыв в соответствии, который застаёт разработчиков и CTO врасплох каждый год, и он стал более значительным с момента, когда решение Schrems II аннулировало Privacy Shield и поместило более пристальный контроль на трансатлантические потоки данных. Если ваш API карт предоставляется американской компанией, независимо от того, где их серверы находятся, данные о местоположении ваших пользователей могут быть доступны правительству США в соответствии с Законом CLOUD Act. В соответствии с GDPR это потенциальное нарушение. При аудите DPA это является выводом.

В этом руководстве объясняются фактические требования GDPR для использования API карт, почему только размещения данных недостаточно, что означает риск Закона CLOUD Act на практике и как оценить любого поставщика API карт в соответствии с строгим контрольным списком соответствия. Это руководство, которое американские компании картографии не могут достоверно написать, потому что они не могут пройти свою собственную проверку.

Почему данные о местоположении требуют серьёзного внимания GDPR

Данные о местоположении находятся на пересечении личных данных и конфиденциальных данных в соответствии с GDPR, в зависимости от контекста. Статья 4(1) определяет личные данные как любую информацию, относящуюся к идентифицированному или идентифицируемому физическому лицу. IP-адрес, который каждый запрос плитки карты отправляет поставщику API, является личными данными. Запрос геокодирования, содержащий домашний адрес, является личными данными. Координаты GPS, если собраны, могут использоваться для вывода домашнего адреса, места работы, религиозного посещения, медицинских назначений и политической деятельности, потенциально квалифицируясь как конфиденциальные данные в соответствии со статьёй 9.

Когда ваше веб-приложение или мобильное приложение загружает карту, инициирует поиск геокодирования или вычисляет маршрут, оно отправляет эти точки данных вашему поставщику API карт. Ваши пользователи не дали согласия на совместное использование своего местоположения с компанией в Сан-Франциско. Они согласились использовать ваш продукт. Вы, как контроллер данных, отвечаете за обеспечение того, чтобы каждый подпроцессор, обрабатывающий эти данные, соответствовал требованиям GDPR.

Если ваш поставщик API карт не пройдёт проверку соответствия, вы её тоже не пройдёте.

Проблема CLOUD Act: почему поставщики США не могут претендовать на полное соответствие GDPR

Закон об уточнении законного использования данных за границей (CLOUD Act), принятый Конгрессом США в 2018 году, требует от американских технологических компаний соответствия законным приказам американского правительства по производству данных, независимо от того, где физически хранятся эти данные. Американская компания с сервером во Франкфурте — это всё ещё американская компания. Если американский суд или федеральное агентство издаст действительный приказ в соответствии с Законом CLOUD Act, компания должна соответствовать.

Это создаёт прямой конфликт с GDPR. Статья 48 GDPR запрещает передачу личных данных иностранным органам или судам без надлежащего правового основания в соответствии с правом ЕС. Европейский совет по защите данных был явен: соответствие приказу в соответствии с Законом CLOUD Act без надлежащего правового основания ЕС будет представлять нарушение GDPR.

Практические последствия для разработчиков ЕС очевидны:

• Google Maps Platform, управляемая Google LLC (американской компанией), подпадает под обязательства Закона CLOUD Act даже при обслуживании запросов через центры обработки данных в Европе.
• Mapbox, зарегистрированная в Соединённых Штатах, сталкивается с таким же структурным воздействием.
• Никакой язык контракта или Стандартные договорные условия ЕС не изменяют основную юридическую юрисдикцию компании, предоставляющей услугу.

Это не означает, что эти компании безрассудно делятся вашими данными. На практике приказы в соответствии с Законом CLOUD Act нацелены на правоохранительные действия, а не на плановый обмен коммерческими данными. Но юридическое воздействие существует, и серьёзный аудит DPA его выявит. Регулируемые отрасли, здравоохранение, финансы, юридические услуги, вообще не могут принять это воздействие.

Размещение данных vs. Суверенитет данных: понимание разницы

Эти термины часто используются взаимозаменяемо в разговорах о продажах, но они означают разные вещи:

Размещение данных означает, что ваши данные хранятся в определённом географическом месте. Поставщик из США, предлагающий «размещение данных в ЕС», хранит данные на серверах в Ирландии или Германии. Физическое местоположение — это ЕС. Юридическая юрисдикция — это не так.

Суверенитет данных означает, что ваши данные подпадают под законы определённой юрисдикции. Чтобы данные ЕС были действительно суверенны, они должны контролироваться субъектом, подпадающим под действие европейского права, а не просто храниться на европейской почве американской материнской компанией.

Истинное соответствие GDPR для API карт требует суверенитета данных, а не просто размещения данных. Различие наиболее важно, когда:

• Ваше приложение обрабатывает данные пациентов здравоохранения, пользователей финансовых услуг или других регулируемых категорий
• Вы работаете в секторе, который сталкивается с формальными аудитами DPA (банки, страхование, государственный сектор)
• Ваш CISO или юридическая команда тщательно проверяют соглашения о подпроцессорах
• Вы сталкиваетесь с запросом на доступ субъекта данных или с обязательством по уведомлению о нарушении

Для большинства приложений, обращённых к потребителям, практический риск приказа в соответствии с Законом CLOUD Act низок. Но соответствие — это не расчёт вероятности. Либо вы соответствуете, либо нет.

Практический контрольный список GDPR для оценки поставщиков API карт

Используйте этот контрольный список при оценке любого поставщика API карт для соответствия GDPR:

Юридическое лицо и юрисдикция

• Зарегистрирован ли поставщик API как юридическое лицо в ЕС или ЕЭЗ?
• Является ли материнская компания (если есть) также в юрисдикции ЕС, без американской материнской компании?
• Явно ли подтверждает поставщик отсутствие воздействия Закона CLOUD Act в своём DPA?

Соглашение об обработке данных

• Предлагает ли поставщик комплексное DPA, которое ссылается на конкретные статьи GDPR?
• Идентифицирует ли DPA категории личных данных, обрабатываемых (IP-адреса, строки запросов, координаты)?
• Указывает ли DPA периоды хранения данных и обязательства по удалению?
• Перечислены ли подпроцессоры и являются ли они также субъектами юрисдикции ЕС?
• Обращается ли DPA к временной шкале уведомления о нарушениях (GDPR требует 72 часов)?

Хранение и обработка данных

• Хранятся ли и обрабатываются ли все данные в ЕС с задокументированным отсутствием передачи в третьи страны?
• Задокументирована ли передача данных между сервисами (CDN, аналитика, инструменты поддержки) и соответствует ли GDPR?
• Предлагает ли поставщик выбор размещения данных на уровне учётной записи?

Сертификаты безопасности

• Сертифицирован ли поставщик по ISO 27001 (международному стандарту управления информационной безопасностью)?
• Подвергается ли поставщик регулярным независимым аудитам безопасности?
• Существует ли задокументированный процесс раскрытия уязвимостей и управления исправлениями?

Права пользователя и контроль

• Можно ли настроить API для минимизации сбора данных (например, анонимизированный IP, отсутствие отслеживания аналитики)?
• Поддерживает ли поставщик запросы на доступ субъекта данных и запросы на удаление?
• Существуют ли задокументированные процессы для ответа на нормативные запросы от органов защиты данных ЕС?

MapAtlas: разработан для суверенитета данных ЕС с первого дня

MapAtlas — это платформа картографического API европейского происхождения, управляемая MapMetrics, компанией, зарегистрированной в ЕС. Наша инфраструктура работает в юрисдикции ЕС без материнской компании из США и без воздействия Закона CLOUD Act. Сертификация ISO 27001 находится на месте, и наш DPA документирует конкретные категории данных, политики хранения и обязательства подпроцессорам.

Это не американская компания, которая добавила опции центра обработки данных в ЕС. Это компания ЕС, где соответствие GDPR — это архитектура по умолчанию, а не дополнение.

Наш API визуализации и стилизации карт обрабатывает запросы плиток через инфраструктуру ЕС. Запросы геокодирования, вычисления маршрутов и каждый другой вызов API остаются в юрисдикции ЕС с момента, когда они покидают ваше приложение. DPA отражает это, это не шаблон, адаптированный из американского юридического шаблона.

Для разработчиков, создающих приложения в регулируемых секторах, или для любого европейского бизнеса, который хочет истинного соответствия вместо показного соответствия, это различие существенно.

Сравнение поставщиков API карт по соответствию GDPR

Для полного сравнения цен и функций см. наши разбор MapAtlas vs. Google Maps и Mapbox vs. MapAtlas. Если стоимость также важна, см. Цены Google Maps API в 2026, разрыв в соответствии приходит в дополнение к значительным различиям в цене.

Практические шаги для разработчиков ЕС прямо сейчас

Если вы в настоящее время используете поставщика API карт США и не можете сразу переключиться, вот промежуточные шаги для снижения воздействия:

1. Анонимизируйте IP-адреса перед их отправкой из вашего источника. Некоторые API карт позволяют передавать запросы через ваш собственный сервер, удаляя или хэшируя IP-адреса перед тем, как они достигнут стороннего API. Это не полностью решает проблему CLOUD Act, но уменьшает поверхность личных данных.

2. Проверьте, что фактически собирает ваш API карт. Внимательно прочитайте политику конфиденциальности и DPA поставщика. Определите каждую категорию личных данных, которые они получают от ваших пользователей. Задокументируйте это в своём реестре отображения данных.

3. Обновите уведомление о конфиденциальности. Ваше уведомление о конфиденциальности должно раскрывать подпроцессоры, которые получают личные данные. Если вы используете Google Maps, Google LLC является подпроцессором. Ваши пользователи имеют право знать это.

4. Оцените уровень риска вашего сценария использования. Маркетинговый веб-сайт с отображением статического местоположения офиса имеет очень отличающийся профиль риска от приложения здравоохранения, маршрутизирующего пациентов в клиники. Калибруйте вашу срочность соответственно.

5. Реалистично оцените затраты на миграцию. Переключение поставщиков API карт — это техническая задача, а не преобразующий бизнес-проект. Большинство миграций завершаются за спринт или два. Наша страница цен показывает сравнение затрат, а наша документация охватывает технический путь миграции с Google Maps и Mapbox.

Рамка по защите данных ЕС является наиболее комплексной в мире и активно применяется, 1,3 миллиарда евро штрафов GDPR были выданы только в 2023 году. Данные о местоположении — это личные данные. API карт обрабатывают данные о местоположении. Цепь соответствия проходит напрямую от ваших пользователей к вашему поставщику API. Проверьте каждую ссылку в этой цепи. И если ссылка не может пройти контрольный список выше, замените её на ту, которая может.

Why Location Data Requires Serious GDPR Attention

Location data sits at the intersection of personal data and sensitive data under GDPR, depending on context. Article 4(1) defines personal data as any information relating to an identified or identifiable natural person. An IP address, which every map tile request sends to the API provider, is personal data. A geocoding query containing a home address is personal data. GPS coordinates, if collected, can be used to infer home address, workplace, religious attendance, medical appointments, and political activity, potentially qualifying as sensitive data under Article 9.

When your web application or mobile app loads a map, fires a geocoding search, or calculates a route, it sends these data points to your map API provider. Your users did not consent to sharing their location with a company in San Francisco. They consented to using your product. You, as the data controller, are responsible for ensuring that every sub-processor handling that data meets GDPR requirements.

If your map API provider fails the compliance test, you fail it too.

The CLOUD Act Problem: Why US Providers Cannot Claim Full GDPR Compliance

The Clarifying Lawful Overseas Use of Data (CLOUD) Act, passed by the US Congress in 2018, requires US technology companies to comply with lawful US government orders to produce data, regardless of where that data is physically stored. A US company with a server in Frankfurt is still a US company. If a US court or federal agency issues a valid CLOUD Act demand, the company must comply.

This creates a direct conflict with GDPR. Article 48 of GDPR prohibits transferring personal data to foreign authorities or courts without an appropriate legal basis under EU law. The European Data Protection Board has been explicit: compliance with a CLOUD Act demand, without a valid EU legal basis, would constitute a GDPR violation.

The practical consequence for EU developers is stark:

• Google Maps Platform, operated by Google LLC (a US company), is subject to CLOUD Act obligations even when serving requests through European data centres.
• Mapbox, incorporated in the United States, faces the same structural exposure.
• No amount of contractual language or EU Standard Contractual Clauses changes the underlying legal jurisdiction of the company providing the service.

This does not mean these companies are recklessly sharing your data. In practice, CLOUD Act demands are targeted at law enforcement use cases, not routine commercial data. But the legal exposure exists, and a serious DPA audit will identify it. Regulated industries, healthcare, finance, legal services, cannot accept this exposure at all.

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.