API карт, соответствующие GDPR: руководство для EU-разработчиков

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

Это не так.

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

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

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

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

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

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

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

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

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

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

• Большинство клиентов из ЕЭЗ заключают договор на Google Maps Platform с Google Cloud EMEA Limited в Ирландии, но как часть группы со штаб-квартирой в США платформа остаётся в зоне действия CLOUD Act даже при обработке запросов через европейские центры обработки данных.
• Mapbox зарегистрирована в США и имеет ту же структурную уязвимость.
• Никакие формулировки договора и стандартные договорные условия ЕС не меняют правовую юрисдикцию компании, которая предоставляет сервис.

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

Хранение данных и суверенитет данных: в чём разница

В разговорах с отделами продаж эти термины часто используют как синонимы, но означают они разное.

Хранение данных (data residency) означает, что данные хранятся в определённом географическом месте. Американский поставщик, предлагающий «хранение данных в ЕС», держит их на серверах в Ирландии или Германии. Физическое расположение находится в ЕС. Правовая юрисдикция нет.

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

Настоящее соответствие GDPR для API карт требует суверенитета данных, а не только их хранения в ЕС. Особенно это различие важно, когда:

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

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

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

Используйте этот чек-лист при оценке любого поставщика API карт на соответствие GDPR.

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

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

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

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

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

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

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

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

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

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

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

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

Это не американская компания, которая добавила опцию центров обработки данных в ЕС. Это европейская компания, для которой соответствие требованиям ЕС заложено в архитектуру по умолчанию, а не добавлено сверху. Более широкие аргументы, включая хранение данных, предсказуемые цены и свободу экспортировать свои данные и уйти без штрафов, изложены на странице почему разработчики выбирают MapAtlas.

Наш 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 (для большинства клиентов из ЕЭЗ в лице Google Cloud EMEA Limited). Пользователи имеют право об этом знать.

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

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

Система защиты данных ЕС самая всеобъемлющая в мире, и её активно применяют: европейские регуляторы наложили штрафы по GDPR на 1,78 миллиарда евро за двенадцать месяцев до января 2024 года. Данные о местоположении являются персональными данными. API карт обрабатывают данные о местоположении. Цепочка соответствия ведёт напрямую от ваших пользователей к поставщику API. Проверьте каждое звено этой цепочки. А если какое-то звено не проходит чек-лист выше, замените его тем, которое проходит.