Когда пользователь общается с чат-ботом — оставляет телефон при оформлении заяки/авторизации, подтверждает получение рассылки, соглашается с правилами акции — с точки зрения 152-ФЗ «О персональных данных» в этот момент происходит юридически значимое действие. Закон требует, чтобы оператор персональных данных мог доказать: согласие было получено, было информированным, относилось к конкретной цели обработки и могло быть отозвано. Для чат-бота, который ведёт тысячи диалогов одновременно, это требование превращается в инженерную задачу — нужен механизм, который фиксирует не факт «согласие есть», а полную картину обстоятельств, в которых оно было дано.
В этой статье разбирается, как устроена модель согласий в Fasttrack: почему она построена именно так, какие принципы 152-ФЗ стоят за каждым техническим полем и как реестр согласий и журнал событий вместе образуют доказательную базу, которую можно предъявить регулятору.
Что закон считает согласием
152-ФЗ не требует «галочки» самой по себе — он требует, чтобы согласие было:
- конкретным — относилось к определённой цели обработки, а не к обработке данных «вообще»;
- информированным — пользователь понимал, на что соглашается, и мог ознакомиться с документом (политикой, соглашением, правилами);
- подтверждаемым — оператор может доказать сам факт согласия, а не просто заявить, что оно было получено;
- отзываемым — пользователь вправе отозвать согласие, и это тоже должно быть зафиксировано.
Из этих четырёх требований прямо следует, что для соответствия закону недостаточно один раз спросить «согласны?» и забыть об этом. Нужна система, которая различает цели согласия, способы его получения и события его жизненного цикла — и хранит это как структурированные, а не текстовые данные.
Как платформа моделирует согласие
Fasttrack регистрирует каждый акт согласия через процедуру consent.register, но важнее не синтаксис вызова (он описан в справочной документации), а то, какие сущности эта процедура различает и почему.
Тип согласия (consent_type) отвечает на вопрос «согласие на что». Платформа разводит политику конфиденциальности, обработку персональных данных, рекламные рассылки, сервисные уведомления, передачу данных третьим лицам, cookies и трекинг, обработку платежей, подтверждение возраста — как отдельные категории. Это прямое следствие принципа конкретности: согласие на получение сервисных уведомлений о статусе заказа юридически не тождественно согласию на рекламную рассылку, и закон не позволяет получить одно вместо другого.
Режим получения (consent_mode) фиксирует, как именно пользователь выразил согласие: явным нажатием кнопки или чекбокса, отправкой формы, продолжением использования сервиса при уведомлении об условиях, через API от внешней системы, либо подтверждением кодом (SMS, email, telegram gateway). Это отвечает на требование подтверждаемости — при проверке важно не только «было ли согласие», но и «каким образом оно было получено», потому что разные способы имеют разный юридический вес.
Тип документа (document_type) и его метаданные — название, версия, дата, ссылка — обеспечивают требование информированности. Если политика конфиденциальности меняется, версия документа, под которой было дано согласие, зафиксирована навсегда: платформа не «переписывает» прошлое согласие задним числом при обновлении документа.
Тип события (event_type) — CONSENT_GIVEN, CONSENT_WITHDRAWN, CONSENT_UPDATED, CONSENT_EXPIRED, ACKNOWLEDGED — превращает согласие из статичного факта в жизненный цикл. Согласие может быть дано, отозвано, обновлено новой версией документа или истечь автоматически. Каждое из этих состояний — отдельная запись, а не перезапись предыдущей, поэтому история согласия сохраняется целиком.
Наконец, платформа автоматически связывает согласие с источником: web_source_info фиксирует IP-адрес и User-Agent, если согласие получено через веб-форму, chat_source_info — UUID чата и канал, если через диалог с ботом. Это отвечает на вопрос «где и в каком контексте» было получено согласие — без этого запись согласия юридически менее убедительна.
Важно: часть полей (
document_title,document_version,document_date,document_url) в процедуре не обязательны технически, но именно они делают запись согласия информативной с точки зрения закона. Согласие без привязки к конкретной версии документа сложнее защитить при проверке — рекомендуется заполнять их последовательно во всех сценариях, где регистрируется согласие.
Реестр согласий как единая точка проверки
Все данные, зафиксированные процедурой consent.register, доступны оператору в разделе Настройки → История согласий — это не отдельное хранилище, а витрина поверх тех же записей.
Каждая строка раскрывается в карточку с полным набором атрибутов: UUID профиля, внешний ID, UUID чата, тип и режим согласия, метаданные документа, IP-адрес, User-Agent, канал.
Это и есть ответ на требование подтверждаемости: если пользователь или регулятор спрашивает «когда и на каком основании было получено согласие на обработку данных», оператору не нужно поднимать логи чат-бота вручную — достаточно найти запись по UUID чата, внешнему ID или UUID профиля.
Осторожно: поле «Дата документа» показывает
Invalid date, еслиdocument_dateне был передан при регистрации согласия. Технически запись согласия при этом остаётся действительной, но с точки зрения полноты доказательной базы такие пробелы стоит устранять на уровне сценария — не оставлять параметр незаполненным там, где дата документа известна.
Отзыв согласия и удаление данных
152-ФЗ обязывает не только фиксировать согласие, но и обеспечивать возможность его отзыва, а также — по требованию субъекта данных или закона — уничтожать персональные данные. На платформе это два разных, но связанных механизма.
Отзыв согласия — это отдельное событие CONSENT_WITHDRAWN, зарегистрированное той же процедурой consent.register, с указанием типа согласия и документа, к которому оно относится. Прежнее согласие при этом не удаляется из истории — оно остаётся как часть жизненного цикла, дополненная записью об отзыве.
Удаление данных — операция другого уровня: удаление клиента (подписчика чат-бота) с платформы. При удалении оператор обязан указать причину — это не опциональное поле в интерфейсе, а часть самой процедуры удаления.
Журнал событий как аудиторский след
Каждое такое действие — удаление, объединение дублирующихся профилей и другие операции над данными клиента — попадает в Журнал событий (раздел Аудитория → Журнал событий).
Запись журнала фиксирует не просто факт действия, а его полные обстоятельства: тип операции (typeOf, например PURGED для удаления или MERGED для объединения профилей), причину (reason), кто выполнил действие и на каком основании (performedBy, performedCode, например OPERATOR_INSTRUCTION), когда (performedAt), какие поля и атрибуты были затронуты, а также срок хранения самой записи об удалении (retentionUntil).
Это прямо закрывает статью 21 152-ФЗ — обязанность оператора уничтожить персональные данные по основаниям, предусмотренным законом, и быть готовым подтвердить это. Журнал событий — не журнал в разговорном смысле, а именно доказательство: он показывает, что данные были удалены, когда, кем и по какой причине, и хранит эти сведения отдельно от самих удалённых данных.
При необходимости запись журнала выгружается в формате CSV и может быть передана в Роскомнадзор как подтверждение факта и обстоятельств удаления персональных данных.
Как это складывается в общую картину
Модель согласий и журнал событий решают на платформе разные, но дополняющие друг друга задачи 152-ФЗ:
- Реестр согласий отвечает за начало жизненного цикла данных — доказывает, что обработка началась на законном основании, с конкретной целью и в конкретных обстоятельствах.
- Журнал событий отвечает за его завершение — доказывает, что данные были удалены по требованию, с указанием причины и исполнителя.
Вместе эти два механизма превращают требования закона — конкретность, информированность, подтверждаемость, отзываемость — из юридических формулировок в структурированные записи, которые можно найти, экспортировать и предъявить в любой момент жизненного цикла персональных данных пользователя.