GDPR для узбекских стартапов: когда европейские правила касаются вас

Если узбекский стартап целенаправленно работает с людьми, находящимися в ЕС, GDPR может применяться к обработке их персональных данных даже без европейского офиса. То же касается определённых случаев мониторинга поведения пользователей в ЕС. Поэтому для founders важнее не страна регистрации, а фактическая архитектура продукта, аудитория и потоки данных.

Главное:

• Сам факт того, что пользователь — гражданин ЕС, ещё не делает GDPR применимым: важны обстоятельства и его нахождение в ЕС в момент соответствующей деятельности.
• Таргетинг на европейский рынок, например продажа SaaS пользователям в ЕС, — один из основных триггеров.
• Для AI-продукта нужно отдельно проверить, какие данные собираются, зачем они нужны, кто имеет к ним доступ и куда они передаются.
• GDPR лучше проектировать вместе с продуктом, а не пытаться «дописать» его после запуска.

Когда GDPR касается стартапа из Узбекистана

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

Здесь есть важная продуктовая деталь. EDPB отдельно подчёркивает, что простая обработка данных человека, который оказался в ЕС, сама по себе ещё не означает применение GDPR. Для неевропейской компании важен элемент целенаправленного обращения к людям в ЕС или мониторинга их поведения. Например, если узбекский сервис работает исключительно на рынке Узбекистана, а его пользователь приехал в Париж в отпуск и продолжил пользоваться сервисом, это не автоматически превращает компанию в субъект GDPR.

На практике я бы смотрел на продукт как инженер на систему: какие пользователи входят в scope, какие события запускают обработку, какие сервисы получают данные и где физически находятся инфраструктура и подрядчики.

Что считается «европейским пользователем»

Не стоит строить compliance на простом поле `country = EU`. Юридический анализ сложнее.

Представим три сценария:

Поэтому смотрите не только на IP-адрес. Я бы проверил язык и содержание сайта, валюты, маркетинговые кампании, условия доставки, onboarding, географию рекламы, настройки продукта и то, какие пользователи фактически являются целевой аудиторией. Само наличие европейских пользователей в базе ещё не отвечает на вопрос о применимости GDPR.

Где чаще всего ломается GDPR у IT и AI-продуктов

Первая ошибка — считать privacy policy документом для юриста, а не частью продукта. GDPR требует прозрачного объяснения того, кто обрабатывает данные, для каких целей, на каком правовом основании, какие категории данных используются, сколько они хранятся и кому передаются.

Вторая ошибка — собирать данные «на будущее». GDPR исходит из принципов ограничения цели и минимизации данных: нужно собирать только то, что необходимо для конкретной цели, и не хранить персональные данные дольше необходимого.

Третья — забывать о подрядчиках. CRM, cloud-провайдер, аналитика, support-система, email-сервис и AI API могут участвовать в обработке персональных данных. Нужно понимать, кто controller, кто processor, какие договорные условия действуют и какие данные передаются каждому поставщику.

Для AI-продуктов я советую добавить ещё один слой: отдельно документировать, используются ли пользовательские данные для обучения, evaluation, персонализации или улучшения модели. Это должно соответствовать заявленной цели обработки, а не появляться незаметно после запуска.

Передача данных из ЕС в Узбекистан

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

Это означает, что фраза «данные лежат в нашем сервере» недостаточна. Нужно составить реальную карту потоков: пользователь → приложение → база данных → cloud → analytics → CRM → AI-провайдер → support.

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

Что сделать на этой неделе

Я бы не начинал с покупки очередного шаблона privacy policy. Начните с inventory.

Чек-лист:

• Составьте список всех персональных данных, которые собирает продукт.
• Отметьте, какие пользователи находятся в ЕС и действительно ли продукт их целенаправленно привлекает.
• Нарисуйте карту всех передач данных и подключённых SaaS/API-поставщиков.
• Для каждого типа обработки определите цель и правовое основание.
• Проверьте privacy notice, consent flows и механизм обработки запросов пользователей.
• Проверьте сроки хранения и возможность удаления данных.
• Для AI отдельно зафиксируйте, используются ли пользовательские данные для обучения или других вторичных целей.
• Проверьте необходимость дополнительных GDPR-роли и документов с учётом характера и риска обработки.

Такой аудит быстро показывает, где юридический риск возникает из архитектуры продукта, а не из текста договора.

FAQ

Если у стартапа нет офиса в Европе, GDPR не применяется?

Не обязательно. Отсутствие европейского офиса само по себе не исключает GDPR. Правила могут применяться к компании за пределами ЕС при определённых условиях, связанных с предложением товаров или услуг людям в ЕС или мониторингом их поведения.

Достаточно ли того, что пользователь — гражданин ЕС?

Нет. Для территориального scope важны фактические обстоятельства, включая нахождение человека в ЕС в момент соответствующей деятельности. Гражданство само по себе не является решающим критерием.

Нужно ли получать согласие на любые данные?

Нет. GDPR предусматривает разные правовые основания обработки; согласие — только одно из них. Выбор основания зависит от конкретной цели и обстоятельств обработки.

GDPR касается только больших компаний?

Нет. Подход GDPR учитывает риск обработки, а базовые принципы защиты данных применяются независимо от размера компании. При этом конкретные дополнительные обязанности могут зависеть от характера, масштаба и риска обработки.

Нужно ли учитывать GDPR уже на стадии MVP?

Если вы с самого начала планируете европейский рынок — да. Privacy by design предполагает внедрение защитных мер ещё на этапе проектирования обработки данных.

Вывод

Для узбекского стартапа GDPR — это прежде всего вопрос product scope и data architecture. Если европейские пользователи входят в целевую аудиторию, не ждите первого enterprise-клиента или инвестиционного due diligence: заранее разложите по полкам данные, цели обработки, поставщиков, международные передачи и пользовательские права.

В Pactum мы как раз смотрим на legal как на часть продукта: разбираем бизнес-модель и data flows, а затем переводим требования в конкретные документы и процессы. Если хотите проверить, попадает ли ваш продукт в scope GDPR и что нужно исправить до выхода на европейский рынок, запишитесь на консультацию.

*Это общая информация, а не индивидуальная юридическая консультация.*