Компания закрывает требования GDPR, обновляет баннер на сайте, подписывает SCC и решает, что самое сложное позади. А потом регулятор спрашивает, где хранятся данные сотрудников, клиент подаёт запрос на доступ по местному закону, который юристы вообще не учитывали, а инженеры признаются, что логи по умолчанию реплицировались сразу в три региона. Так обычно и проявляются типичные ошибки в глобальном комплаенсе по защите данных — не одним громким провалом, а цепочкой мелких допущений, которые рассыпаются под трансграничной проверкой.
Для основателей, юридических директоров, руководителей по комплаенсу и продуктовых команд, работающих в США, ЕС, России, Латинской Америке и Азии, провал в защите данных почти никогда не связан с безразличием. Чаще он связан с тем, что глобальный бизнес проектируют на местной правовой модели. Этот разрыв создаёт риск санкций, блокирует корпоративные сделки, тормозит экспансию и подрывает доверие инвесторов в самый неподходящий момент.
Почему типичные ошибки в глобальном комплаенсе повторяются
Большинство международных программ по защите данных проваливаются по структурной причине: бизнес растёт быстрее, чем его комплаенс-архитектура. Подключаются новые подрядчики, масштабируются облачные среды, меняются стеки аналитики, процессы поддержки расползаются по юрисдикциям. А программа защиты данных остаётся перегруженной документами и слабой в практической части.
Библиотека политик — это не система контроля. Баннер согласия — это не управление передачей. Разовый аудит — это не доказательство непрерывного соответствия. Регуляторы всё чаще смотрят сквозь бумажный комплаенс — на реальные операции обработки, происхождение данных, управление обработчиками, логику хранения и готовность к реагированию на инциденты.
Проблема обостряется, когда руководство воспринимает защиту данных как региональный юридический вопрос, а не как операционную систему всего предприятия. GDPR может быть отправной точкой, но он не заменяет ни CCPA и CPRA, ни бразильский LGPD, ни китайский PIPL, ни российские правила локализации по 152-ФЗ, ни отраслевые требования к данным в здравоохранении, телекоме, финансах или к данным детей.
Ошибка 1. Считать один закон глобальным шаблоном
Многие строят всё вокруг GDPR и пытаются растянуть его на остальные рынки. GDPR влиятелен, но он не отвечает на каждое требование отдельной юрисдикции. Американский бизнес под действием законов штатов может столкнуться с обязанностями по уведомлению, отказу от обработки и работе с чувствительными данными, сформулированными иначе, чем европейские стандарты. В России требования локализации меняют архитектуру систем, а не только документацию. В Китае правила трансграничной передачи и пороги обязательной оценки безопасности способны изменить и стратегию по подрядчикам, и план вывода продукта.
Именно здесь юристы часто недооценивают масштаб. Они описывают обязательства на уровне политик, но не проверяют, способны ли сам продукт и инфраструктура удовлетворить конфликтующие местные нормы. В итоге комплаенс выглядит цельным в презентации для совета и рассыпается при развёртывании.
Ошибка 2. Игнорировать реальные потоки данных
Если вы не знаете, где персональные данные поступают, где обогащаются, где хранятся, кто к ним имеет доступ и куда они уходят, то у вас нет программы защиты данных. У вас есть допущения.
Эта ошибка остаётся одной из самых дорогих, потому что потоки данных редко ограничиваются самим продуктом. Персональные данные проходят через CRM, инструменты поддержки, аналитические платформы, антифрод-движки, adtech-подрядчиков, внутренние мессенджеры, среды разработки и слои резервных копий. Инженеры могут локализовать продакшен-хранилище, а поддержка — выгружать записи в другой регион. Юристы могут согласовать обработчика, а закупки позже добавят путь к субобработчику без повторной оценки.
По статье 30 GDPR реестр операций обработки задуман не как формальность. Это поверхность контроля. Та же логика работает и за пределами ЕС, потому что права на доступ, удаление, анализ передачи, правила хранения и реагирование на инциденты зависят от знания фактического движения данных.
Ошибка 3. Переоценивать значение согласия
Компании часто опираются на согласие, потому что так спокойнее и проще объяснить внутри. На практике согласие — одно из самых неправильно используемых правовых оснований в глобальном комплаенсе.
В трудовых отношениях согласие может быть недействительным из-за неравенства сторон. В продуктовой среде оно бывает связанным, расплывчатым или несвободным. В ряде юрисдикций даже действительное согласие не снимает отдельных обязательств по прозрачности, минимизации, хранению или трансграничной передаче. Для маркетинга правила могут зависеть и от законодательства о защите данных, и от норм об электронной коммуникации или телеком-правил.
Более зрелый подход — сначала оценить цель обработки, затем определить правовое основание, местные требования к уведомлению и техническую реализацию. И этот анализ должен отражаться в дизайне продукта, а не только в юридическом тексте.
Ошибка 4. Считать SCC и договоры готовым решением для передачи
Стандартные договорные положения могут быть необходимы. Но сами по себе они не являются стратегией передачи.
После Schrems II управление передачей требует большего, чем подпись под шаблоном. Компании должны понимать, влияет ли юрисдикция назначения на эффективность договорных гарантий, какие дополнительные технические или организационные меры существуют, кто владеет ключами шифрования, происходит ли удалённый доступ и контролируются ли дальнейшие передачи. В отдельных случаях зрелым группам имеет смысл взяться за обязательные корпоративные правила (BCR), но они тоже требуют управленческой дисциплины, которую многие недооценивают.
Для России, Китая и других регулируемых сред анализ передачи может включать местную регистрацию, локализацию, проверку безопасности или вопросы операционной последовательности, которые одними договорами не решить. Несовпадение юридического текста и реальной инфраструктуры — один из самых быстрых способов создать риск во время due diligence или расследования.
Ошибка 5. Забывать, что хранение — это и юридический, и технический вопрос
Многие собирают данные широко и удаляют их редко. Такой подход порождает риск, которого можно избежать.
Ограничение хранения по GDPR, права на удаление в разных режимах защиты данных, отраслевые сроки хранения, обязательства по сохранению доказательств в спорах, потребности антифрод-мониторинга, налоговые и бухгалтерские правила — всё это пересекается. Ответ почти никогда не сводится к тому, чтобы быстро удалить всё или хранить всё вечно. Он зависит от категории данных, правовой цели, юрисдикции и архитектуры систем.
Ошибка — не превратить хранение в исполнимый график с поддержкой на уровне продукта и инфраструктуры. Если помеченные на удаление данные бесконечно остаются в бэкапах, если удаление пользователем затрагивает только видимость во фронтенде, а старые выборки копируются в среды обучения AI без повторной правовой оценки, то политика хранения не работает.
Типичные ошибки в глобальном комплаенсе при масштабировании продукта
Растущие компании часто ломают контроль над данными в периоды быстрых релизов. Новые функции выходят раньше, чем проводится правовая проверка. SDK добавляются ради growth-аналитики без оценки передачи. Инженеры дублируют среды для тестирования и случайно затягивают туда продакшен-данные. AI-функции поглощают тикеты поддержки, расшифровки разговоров или поля, связанные со здоровьем, без ясного правового основания и проверки границ подрядчика.
Privacy by design по статье 25 GDPR часто воспринимают как лозунг, но регуляторы всё чаще ждут доказательств того, что риски для данных учитывались на стадии проектирования. Схожие ожидания формируются и в других странах, даже там, где формулировки закона отличаются. Операционный вопрос прост: происходит ли правовая проверка раньше, чем решения по коду, закупкам и развёртыванию станет дорого разворачивать назад?
Для технологического бизнеса ответ зависит от процессов. Правовую проверку нужно встроить в управление релизами, подключение подрядчиков, классификацию данных и управление изменениями. Если она начинается после запуска, она уже опоздала.
Ошибка 6. Слабое реагирование на инциденты в разных юрисдикциях
План реагирования на утечку, работающий в одной стране, может провалиться в трёх других. Пороги уведомления, сроки, ожидания регуляторов и обязанности по коммуникации заметно различаются. Правило 72 часов из GDPR известно всем, но трансграничный инцидент может одновременно запускать договорные обязательства по уведомлению, местные требования по кибербезопасности, законы об уведомлении потребителей, трудовые последствия и взаимодействие с правоохранительными органами.
Важно не только то, есть ли у компании план, но и то, отражает ли он реальное распределение владения системами и путей принятия решений. Кто подтверждает охват инцидента? Кто способен сохранить доказательства? Кто оценивает, действительно ли зашифрованные данные были недоступны? Кто координирует адвокатскую тайну между юрисдикциями? Эти вопросы нельзя закрыть универсальным шаблоном инцидента во время живого кризиса.
Ошибка 7. Размытое распределение ответственности за защиту данных
Глобальные программы защиты данных проваливаются, когда ни у кого нет полномочий, охватывающих юристов, продукт, безопасность, закупки и операции. Юристы пишут правила, безопасность управляет средствами защиты, продукт выпускает функции, закупки подписывают подрядчиков. Если никто не отвечает за всю цепочку, пробелы гарантированы.
Это не всегда означает наём полноценной внутренней команды в каждом регионе. Это означает назначение ответственного управления с достаточным техническим и бизнес-контекстом, чтобы принимать решения, устойчивые к аудиту и проверке. Для многих растущих компаний сюда может входить внешняя поддержка, структурированная функция DPO там, где она требуется, и протоколы эскалации, завязанные на топ-менеджмент.
В DATA-lawyer именно здесь чаще всего и наступает момент, когда компании просят о помощи — не потому что им не хватает политик, а потому что им нужна исполнимая международная архитектура комплаенса, работающая на стыке облачных сред, продуктовых команд и рисков перед регуляторами.
Как выглядит работающая программа
Защитимая программа начинается с точного картирования данных и определения применимых юрисдикций. Затем она превращает правовые обязательства в операционные средства контроля: матрицы правовых оснований, механизмы передачи, правила хранения, управление подрядчиками, процессы обработки запросов субъектов и сценарии реагирования на инциденты. После этого ей нужна поддержка. Меняются рынки, меняются продукты, регуляторы пересматривают позиции, а инфраструктура меняется тихо.
Самые сильные программы защиты данных — не самые многословные. Это те, что способны быстро и последовательно отвечать на практические вопросы регулятора. Какие данные вы обрабатываете? Зачем? Куда они уходят? На каком правовом основании? Как долго хранятся? Кто к ним имеет доступ? Что происходит, когда пользователь возражает, удаляет данные или подаёт жалобу? Если эти ответы требуют, чтобы пять подразделений сводили противоречащие друг другу таблицы, риск уже стал операционным.
Глобальный рост вознаграждает скорость, но комплаенс по защите данных наказывает за догадки. Компании, которые справляются с этим хорошо, — не те, у кого самые длинные политики. Это те, кто встраивает правовые требования в системы, договоры и продуктовые решения достаточно рано, чтобы экспансия не порождала скрытых обязательств.