Персональные данные в РФ для вайбкодеров: что нужно знать перед запуском AI-продукта

Простая инструкция для вайбкодеров, стартаперов и создателей AI-продуктов: какие персональные данные собирает продукт, что нужно разместить на сайте, где хранить данные и как снизить риски по 152-ФЗ.

А
Антон БодокияОснователь QuboLab7 июня 2026 г.8 мин
AIMVPпродукт

Почему вайбкодеру вообще нужно думать о персональных данных

Когда ты создаёшь продукт на AI, no-code, vibe coding или с помощью Claude Code, кажется, что главное — быстрее собрать MVP.

Лендинг. Форма заявки. Telegram-бот. Личный кабинет. Оплата. AI-чат. База пользователей.

Но почти в каждом таком элементе появляются персональные данные.

И проблема не только в том, чтобы поставить в футер сайта ссылку «Политика конфиденциальности». Персональные данные — это часть архитектуры продукта. Их нужно учитывать до запуска, а не после того, как пользователи уже начали оставлять email, телефоны, запросы и файлы.

Главная мысль простая:

Если продукт помогает пользователю что-то сделать, зарегистрироваться, оплатить, отправить заявку или пообщаться с AI — скорее всего, он уже обрабатывает персональные данные.

Что считается персональными данными

Персональные данные — это не только паспорт, адрес и номер телефона.

В продукте персональными данными могут быть:

  • имя;
  • фамилия;
  • email;
  • телефон;
  • Telegram ID;
  • username;
  • IP-адрес;
  • cookie;
  • город;
  • место работы;
  • должность;
  • история заказов;
  • переписка с поддержкой;
  • текст запроса в AI-чат;
  • загруженный документ;
  • фотография;
  • голосовое сообщение;
  • данные из CRM;
  • номер договора;
  • номер бронирования;
  • данные об оплате.

Важный принцип:

Если по данным можно прямо или косвенно понять, о каком человеке идёт речь, относись к ним как к персональным данным.

Даже если ты собираешь только email в форме «получить ранний доступ», это уже повод подумать о 152-ФЗ.

Почему AI-продукты особенно чувствительны к ПДн

Обычный сайт чаще всего собирает данные в понятных местах: форма заявки, регистрация, оплата, чат поддержки.

AI-продукт сложнее.

Пользователь может сам вставить в запрос:

  • своё ФИО;
  • телефон;
  • паспортные данные;
  • договор;
  • данные клиента;
  • медицинскую информацию;
  • переписку;
  • коммерческие документы;
  • данные сотрудников;
  • персональные данные третьих лиц.

Например:

«Составь письмо клиенту Ивану Петрову. Его телефон +7..., договор №..., он купил апартамент...»

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

Поэтому для AI-продуктов важно думать не только о форме регистрации, но и о том, что уходит в модель.

Читайте также: Как использовать OpenAI, Claude, Gemini и другие зарубежные LLM без передачи персональных данных.

Кто такой оператор персональных данных

Если ты создаёшь продукт, собираешь пользователей и сам решаешь:

  • какие данные собирать;
  • зачем их собирать;
  • где их хранить;
  • кому передавать;
  • сколько хранить;

то ты или твоя компания становитесь оператором персональных данных.

Это касается не только крупных компаний. Небольшой MVP, Telegram-бот, SaaS, mini app или лендинг с формой заявки тоже могут обрабатывать персональные данные.

No-code-сервисы, хостинг, CRM, email-рассыльщик, платёжный сервис, аналитика и LLM API обычно не снимают с тебя ответственность. Они могут быть внешними сервисами, через которые ты обрабатываешь данные.

Простыми словами:

Если пользователь оставил данные тебе, отвечаешь за них ты, даже если технически они лежат в стороннем сервисе.

Что нужно сделать перед запуском продукта

Перед публикацией сайта или MVP не нужно сразу писать огромный юридический том. Начни с практического мини-аудита.

Сделай таблицу:

Где собираем данныеКакие данныеЗачемГде хранимКому передаём
Форма раннего доступаemailсвязаться с пользователембаза/CRMemail-сервис
Telegram-ботTelegram ID, usernameавторизациябаза данныхнет
AI-чаттекст запросагенерация ответаистория чатаLLM API
Оплатаemail, заказдоступ к продуктуплатёжный сервисбанк/касса
Аналитикаcookie, IPстатистикасервис аналитикианалитика

Эта таблица сразу показывает слабые места:

  • не собираем ли мы лишнее;
  • не отправляем ли данные за рубеж;
  • не лежат ли заявки в Google Sheets или Notion;
  • не попадают ли персональные данные в логи;
  • понятно ли пользователю, что происходит с его данными.

Минимальный набор документов для сайта

Для простого продукта обычно нужны:

1. Политика обработки персональных данных

Это документ, где объясняется:

  • кто оператор;
  • какие данные собираются;
  • зачем они собираются;
  • как обрабатываются;
  • кому могут передаваться;
  • сколько хранятся;
  • как пользователь может обратиться по своим данным.

Политику нужно разместить на сайте так, чтобы пользователь мог легко её найти.

2. Согласие на обработку персональных данных

Если пользователь оставляет заявку, регистрируется или отправляет данные через форму, под формой должно быть понятное согласие.

Плохой вариант:

Нажимая кнопку, вы соглашаетесь со всем.

Лучше:

Я даю согласие на обработку персональных данных в соответствии с Политикой обработки персональных данных.

3. Согласие на рекламную рассылку

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

Например:

Я согласен получать информационные и рекламные сообщения о продукте.

Не смешивай согласие на обработку данных и согласие на рекламу в одну непонятную галочку.

Где хранить данные

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

Практический принцип:

Основная база персональных данных российских пользователей должна храниться на инфраструктуре в России.

Поэтому для продакшена рискованно бездумно использовать:

  • Google Sheets как базу заявок;
  • Notion как CRM;
  • Airtable как хранилище пользователей;
  • зарубежный Supabase/Firebase как основную базу;
  • иностранные облака для файлов пользователей;
  • зарубежные сервисы логирования, куда попадают email, телефоны и тексты запросов.

Более безопасный подход:

  • backend и база данных в РФ;
  • внешним сервисам передавать минимум данных;
  • не хранить лишнее;
  • не писать персональные данные в логи;
  • для AI-запросов использовать маскирование, токенизацию или локальную обработку.

Читайте также: Где хранить персональные данные: Supabase, Firebase, Notion, Airtable и Google Sheets в российских AI-продуктах.

Что делать с зарубежными LLM

Многие AI-продукты используют OpenAI, Claude, Gemini и другие зарубежные модели.

Главное правило:

LLM должна знать задачу, а не личность пользователя.

Плохо:

Составь ответ Ивану Петрову, телефон +7..., договор №123, апартамент №305.

Лучше:

Составь деловой ответ клиенту по вопросу договора. Тон: спокойный, уверенный. Аргументы: сроки, порядок оплаты, условия возврата.

Для этого в продукте можно использовать Privacy Proxy или LLM Gateway — отдельный слой между пользователем и моделью.

Он должен:

  • находить персональные данные;
  • удалять или маскировать их;
  • заменять реальные данные на токены;
  • отправлять в LLM только очищенный текст;
  • хранить таблицу токенов на сервере в РФ;
  • не допускать передачу чувствительных данных во внешнюю модель.

Пример:

Было:

Иван Петров, телефон +7 918..., просит вернуть оплату по бронированию №345.

Стало:

Клиент [PERSON_1] просит вернуть оплату по бронированию [BOOKING_ID_1].

Модель получает смысл задачи, но не получает реальные персональные данные.

Что делать с cookies и аналитикой

Если на сайте стоят:

  • Яндекс Метрика;
  • Google Analytics;
  • пиксели рекламных систем;
  • call tracking;
  • виджеты чатов;
  • session replay;
  • сквозная аналитика;

то это тоже зона персональных данных.

Минимум, который стоит сделать:

  • указать использование cookies в политике;
  • добавить cookie-баннер;
  • не подключать лишние трекеры;
  • понимать, куда уходит аналитика;
  • не передавать в аналитику email, телефоны и другие явные персональные данные.

Простой текст для баннера:

Мы используем cookies и сервисы аналитики, чтобы улучшать работу сайта и анализировать посещаемость. Продолжая пользоваться сайтом, вы соглашаетесь с обработкой данных в соответствии с Политикой обработки персональных данных.

Частые ошибки вайбкодеров

Ошибка 1. «Сначала запущу, потом разберусь»

Если форма уже собирает email и телефоны, обработка данных уже началась.

Ошибка 2. «У меня только MVP, закон пока не важен»

Для закона не так важно, MVP это или большая платформа. Важно, собираешь ли ты данные людей.

Ошибка 3. «Поставлю политику с чужого сайта»

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

Ошибка 4. «Буду хранить заявки в Google Sheets»

Для российских пользователей это может быть рискованным решением с точки зрения хранения и передачи данных.

Ошибка 5. «AI сам разберётся»

AI не понимает юридические риски за тебя. Если пользователь вставил в промт персональные данные, продукт должен уметь их обработать безопасно.

Минимальный чек-лист перед запуском

Перед тем как выкатывать продукт, проверь:

  • какие персональные данные собираются;
  • зачем собирается каждый тип данных;
  • где физически хранится база;
  • есть ли политика обработки персональных данных;
  • есть ли согласие под формами;
  • отдельно ли оформлено согласие на рекламную рассылку;
  • есть ли cookie-уведомление;
  • используется ли зарубежная LLM;
  • уходят ли персональные данные во внешние сервисы;
  • можно ли удалить данные пользователя;
  • кто имеет доступ к базе;
  • попадают ли персональные данные в логи;
  • нужно ли уведомление Роскомнадзора.

Главное, что нужно запомнить

Персональные данные — это не тормоз для запуска продукта.

Это просто ещё один слой нормальной продуктовой архитектуры.

Как авторизация. Как оплата. Как база данных. Как безопасность. Как аналитика.

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

Формула простая:

Собирай меньше данных. Храни их аккуратно. Объясняй пользователю, что происходит. Не отправляй лишнее во внешние сервисы. Для AI используй очистку, маскирование и токенизацию.

Такой подход помогает запускать AI-продукты быстрее — и не ломаться на персональных данных уже после первых пользователей.

Читайте также в серии:

  • Как использовать OpenAI, Claude, Gemini и другие зарубежные LLM без передачи персональных данных
  • Политика, согласие и оферта: какие документы нужны для MVP
  • Лендинг и форма заявки: чек-лист по персональным данным
  • Telegram-бот и персональные данные: что учесть перед запуском
  • Где хранить данные: Supabase, Firebase, Notion, Airtable и Google Sheets
  • Privacy by Design для SaaS и AI-продукта

Новые статьи — прямо в почту

Подпишитесь на журнал QuboLab и получайте лучшие материалы первыми.