Этика и комплаенс: 152-ФЗ, NDA и границы ORM-аналитики

Почему комплаенс — это не бюрократия, а часть методологии

ORM-аналитика всегда про живых людей. Авторы отзывов, участники обсуждений, те, кого упомянули в публикациях. Без чёткой правовой рамки такая работа легко перескакивает из законного мониторинга в нарушение частной жизни. Поэтому комплаенс у нас — не проверка перед сдачей проекта, а условие, вшитое в сбор данных с первого дня.

Что конкретно требует 152-ФЗ в контексте ORM

Закон о персональных данных ограничивает сбор, хранение и обработку информации, по которой можно узнать конкретного человека. Для ORM вывод такой: следить за публичными упоминаниями бренда можно, а копить лишние персональные данные упомянутых людей дольше нужного или без основания — уже нарушение. Есть тонкость, о которой часто забывают. Если человек сам выложил данные в открытый доступ, но не давал отдельного согласия на их распространение, доказывать законность их дальнейшей обработки придётся тому, кто их обрабатывает (ч. 2 ст. 10.1 152-ФЗ). «Это же было в открытом профиле» — не аргумент. Практический вывод простой: берите ровно столько данных, сколько нужно для задачи. Не больше.

Зачем нужен NDA и что он реально ограничивает

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

Что такое двойная анонимизация

Первый уровень — обезличивание данных на этапе сбора: там, где для анализа не нужна привязка к конкретному имени или аккаунту (например, для статистики по паттернам формулировок), данные обезличиваются сразу. Второй уровень — повторное обезличивание при формировании отчётности клиенту: в финальные материалы попадают агрегированные выводы и необходимые для работы конкретные ссылки, а не сырой массив персональных данных всех, кто упоминался в ходе исследования.

Где проходит граница между мониторингом и слежкой

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

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

Как устроен доступ к данным внутри команды

NDA задаёт внешний контур. Но внутри команды тоже нужна дисциплина. Доступ делится по ролям. Аналитик, который собирает и чистит упоминания, видит сырые данные — ровно в том объёме, который нужен для его части. Менеджер проекта и клиент получают агрегированный отчёт без лишних персональных деталей. Архив завершённых проектов открывают точечно и с отдельной записью. Утечку предотвращает не запрет на бумаге, а то, что у человека просто нет доступа к данным, которые ему не нужны.

Подрядчики и субисполнители живут по тем же правилам. Доступ — под конкретную задачу и на ограниченный срок, а не ко всей базе проекта навсегда. Этап закрыт — доступ отозван. По умолчанию ничего открытым не остаётся.

Как этические ограничения отражаются в формате отчёта клиенту

Комплаенс должен быть виден не только изнутри. Клиент должен увидеть его в готовом отчёте. Мы строим отчёт так, чтобы выводы можно было проверить, но чтобы он не превращался в досье на авторов. Ссылки и цитаты — в объёме, достаточном для понимания контекста и решения: согласиться с жалобой или обратиться на площадку с обоснованным запросом. Без персональных данных, которые к сути не относятся. Статистика по паттернам — например, доля отзывов с признаками накрутки — даётся в агрегированном виде, без привязки к профилям, если для решения клиенту такая привязка не нужна.

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

Все проекты Кликнет ведутся по этим правилам независимо от бюджета; управление репутацией стоит от 40 000 ₽/мес, на рынке с 2016 года — более 700 проектов.

Чек-лист: как проверить подрядчика по ORM на комплаенс

Задайте эти вопросы до подписания договора. Уклончивый ответ хотя бы на один — повод насторожиться. Если хотите сравнить с нашим подходом, он описан на странице управление репутацией компании.

• Подписываете ли вы NDA и что в нём сказано о сроке хранения данных?
• Кто из ваших сотрудников и подрядчиков увидит сырые выгрузки?
• Какие данные об авторах отзывов вы собираете и зачем?
• Что попадёт в отчёт: агрегированные выводы или списки людей с профилями?
• Как и когда вы удаляете данные после завершения проекта?
• Как поступите, если у вас случится утечка? По закону оператор должен уведомить Роскомнадзор об инциденте в течение 24 часов (ч. 3.1 ст. 21 152-ФЗ).

Готовые шаблоны: пункт в ТЗ, запрос на удаление данных, внутреннее правило

Замените данные в квадратных скобках. Это не юридические документы, а рабочие формулировки — финальный текст договора согласуйте со своим юристом.

Частые ошибки в этике ORM-аналитики

• Считать, что открытые данные можно обрабатывать как угодно. Обязанность доказать законность обработки лежит на том, кто обрабатывает.
• Пытаться «вычислить» автора отзыва и собирать на него досье вместо работы с самой жалобой.
• Пересылать сырые выгрузки всей команде и подрядчикам «на всякий случай».
• Забывать отзывать доступы после завершения этапа.
• Не прописывать срок хранения данных в NDA — тогда они лежат годами.

Какие инструменты SERM/ORM здесь применимы

• Двойная анонимизация данных — обезличивание на этапе сбора и повторное при формировании отчётности клиенту
• Разграничение доступа внутри команды по ролям — каждый участник видит только объём данных, нужный для его части работы
• Ограничение сбора рамками конкретной задачи — данные вне прямой связи с задачей клиента не запрашиваются и не хранятся
• Отчётность без избыточных персональных данных — проверяемые выводы вместо досье на конкретных авторов упоминаний

Часто задаваемые вопросы

❓ Означает ли это, что агентство не может назвать авторов конкретных отзывов?

Публичные данные автора (никнейм, публичный профиль), уже видимые на самой площадке, используются в рамках работы с конкретной жалобой — вопрос в том, чтобы не собирать и не хранить сверх необходимого.

❓ Применяется ли эта рамка и к мониторингу конкурентов?

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

❓ Что происходит с данными после завершения проекта?

Данные, не требуемые для дальнейшего юридического или архивного сопровождения, удаляются по истечении оговорённого в NDA срока хранения.