Спарсил — ещё не значит можно: согласие на распространение до запуска автоматизации

Каждый раз, когда я собираю пайплайн для холодного аутрича, разговор упирается в одну фразу: «данные же открытые». Открытая страница говорит ровно об одном — скрипт до неё дотянулся. Правовой режим данных от этого не меняется. Ниже — то, что я прогоняю по своим проектам до того, как автоматизация начнёт что-то отправлять наружу.

Сразу оговорюсь: я не юрист. Всё это я проверял руками на своих сборках и объяснял заказчикам, которые хотели «просто спарсить и разослать».

Открытые данные остаются персональными

ФЗ-152 отдельно описывает персональные данные, разрешённые субъектом для распространения. Статья 10.1 появилась именно затем, чтобы убрать удобную для маркетинга презумпцию: человек выложил телефон в профиль — значит, согласен на любое использование. Что из неё важно для автоматизации:

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

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

Отдельная тема — когда это самое отдельное согласие вообще обязательно. На Право.ру есть разбор от корпоративного юриста по делу «Арсеналъ», там как раз обсуждается граница применения ст. 10.1. Такие материалы стоит читать до запуска: практика по этой статье всё ещё складывается.

Три источника данных — три разных набора рисков

Свои формы. Самый управляемый случай. Проверяю одно: что в тексте согласия реально написано про передачу третьим лицам и совпадает ли этот текст с тем, что делает пайплайн. Обычно расходится — форму писали три года назад под рассылку, а сейчас данные уходят в LLM-провайдера и в CRM партнёра.

Чужая площадка. Здесь поверх закона ложится договорный слой — пользовательское соглашение площадки. Свежий пример: LinkedIn Corporation v. Nubela Pte Ltd (Northern District of California, дело 5:25-cv-00828), иск платформы к поставщику данных о профилях. Для меня как для сборщика это прежде всего инженерный риск. Вендор данных попадает под удар — встаёт мой пайплайн, и запасного источника в этот момент нет.

Закупленная база. Фраза «у нас всё легально» в письме продавца документом не считается. Прошу показать, какое именно согласие собрано и в каком виде оно хранится. Ответа нет — дальше можно не идти.

Чек-лист до запуска

• Происхождение каждого поля. Конкретно: этот телефон откуда, эта должность откуда. Ответ «из базы» не принимается.
• Основание обработки для каждого сценария использования, включая обогащение и скоринг.
• Отдельное согласие на распространение там, где данные уходят наружу или публикуются.
• Карта следов. Логи, промпты, кэш скрейпера, векторная база, история в мессенджере команды. Данные оседают в куда большем числе мест, чем основная таблица.
• Процедура отзыва. Сколько минут занимает полное удаление конкретного человека из всех этих мест. Ответ «надо подумать» означает, что процедуры нет.
• Трансграничка. Где физически крутится модель, которой вы скармливаете карточки лидов.
• ToS источника и план Б на случай, если доступ закроют завтра.

Зачем на выходе человек

Показательная деталь из открытого кода. Репозиторий kaymen99/sales-outreach-automation-langgraph — 344 звезды, последнее обновление 15 января 2025 года. Пайплайн доводит цепочку до черновиков писем, а отправку оставляет человеку. Автор поставил ручной шлюз в самом чувствительном месте. Архитектурно это верно: до отправки любую ошибку в данных ещё можно отыграть назад.

Заодно этот же репозиторий иллюстрирует основную мысль статьи с другой стороны. Лицензии у него нет. Код лежит в открытом доступе и прекрасно читается, но без лицензии права на использование в коммерческом продукте вам никто не выдавал. Логика та же, что и с персональными данными: видимость и разрешение — разные вещи.

Что я делаю на практике

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

Это добавляет к сборке день работы. Зато потом на вопрос «откуда у вас мои данные» есть ответ в одно предложение.