Игнорирование требований ФЗ-152 и GDPR в No-code проектах ведет к штрафам до 18 млн рублей (для РФ) или 20 млн евро (для ЕС), при этом 70% разработчиков ошибочно полагают, что ответственность за данные полностью лежит на вендоре платформы.
Локализация данных и выбор инфраструктуры
Критическая точка отказа в No-code — физическое расположение серверов. Согласно ФЗ-152, первичный сбор и хранение ПДн граждан РФ должны осуществляться на территории России. Если вы используете Bubble или Glide с серверами в США/ЕС, вы нарушаете закон с первого клика пользователя. Решение: использование прокси-серверов или переход на российские аналоги (например, Directual или специализированные low-code решения с локальными ЦОД).
Кейс: Финтех-сервис на Bubble перенес базу данных на локальный PostgreSQL через API, чтобы соответствовать требованиям регулятора. Срок миграции составил 12 рабочих дней, стоимость разработки прослойки — около 80 000 рублей, но это полностью сняло риск блокировки ресурса Роскомнадзором.
Экспертный вывод: Никогда не храните ПДн напрямую в облачных БД западных No-code платформ, если ваш рынок — РФ. Используйте схему «Интерфейс (No-code) → API-шлюз → Локальная БД».
Контроль доступа и изоляция записей
Типичная ошибка новичков — фильтрация данных на уровне интерфейса (Client-side filtering), когда данные пользователя приходят в браузер, а скрываются только визуально. Это грубое нарушение приватности: любой пользователь через консоль разработчика (F12) может выгрузить всю таблицу клиентов. Необходимо внедрять Row-Level Security (RLS) или строгие серверные правила доступа (Privacy Rules), где запрос к БД содержит жесткий фильтр по UserID на уровне сервера.
Сравнение: фильтрация в интерфейсе работает мгновенно, но небезопасна; RLS добавляет 50–200 мс к ответу сервера, но гарантирует, что пользователь увидит только свои 0.1% данных от общего объема базы. В приложениях с базой от 10 000 записей разница в безопасности становится критической.
Экспертный вывод: Любая настройка «видимости» в No-code, не подкрепленная серверным правилом доступа, — это дыра в безопасности. Только серверная валидация прав соответствует стандартам GDPR.
Жизненный цикл данных и право на забвение
GDPR требует реализации «права на удаление данных» (Right to be Forgotten). В No-code приложениях часто забывают о логах, бэкапах и связанных таблицах. Если пользователь удаляет аккаунт, а его email остается в таблице «История транзакций» или в логах интеграции с Zapier/Make, аудит будет провален. Необходимо настраивать каскадное удаление или анонимизацию (замену ПДн на случайный хеш).
Пример: В CRM-системе на базе Airtable реализован скрипт, который при деактивации пользователя за 24 часа заменяет ФИО и телефон на строку «Deleted User». Это позволяет сохранить финансовую отчетность (суммы сделок), не нарушая закон о хранении персональных данных.
Экспертный вывод: Автоматизируйте процесс удаления через Webhooks. Ручное удаление данных при масштабировании до 1000+ пользователей неизбежно приведет к ошибкам и утечкам.
Аудит интеграций и сторонних сервисов
No-code приложения — это конструктор из API. Каждый коннектор (SendPulse, Stripe, Google Sheets) является точкой утечки. При аудите проверяйте, какие именно поля передаются во внешние сервисы. Передача полного профиля пользователя там, где нужен только email, увеличивает риск компрометации данных на 40-60%.
Мини-кейс: При интеграции формы заявки с Google Sheets через Make (бывший Integromat) данные хранились в логах платформы-посредника. В результате ПДн клиентов оказались в системе, которую компания даже не считала основным хранилищем. Решение: включение опции «Disable logging of sensitive data» в настройках сценария.
Экспертный вывод: Сокращайте объем передаваемых данных до абсолютного минимума. Используйте токены вместо реальных ПДн везде, где это возможно.
Вывод
Для обеспечения соответствия регламентам в No-code приложении начните с внедрения Row-Level Security и выноса ПДн на локальный сервер. Избегайте хранения чувствительных данных в Google Sheets или встроенных БД западных конструкторов. Оптимальный стек для РФ сегодня: No-code интерфейс + локальный PostgreSQL + API-прослойка. Это единственный способ пройти юридический аудит и избежать штрафов, сохранив скорость разработки.