Штраф до 20 млн евро или 4% мирового годового оборота по GDPR — не единственный риск для сервиса, который ранжирует клиентов, продавцов, кандидатов или лиды. Часто критичнее оказываются приостановка обработки, требование удалить массив данных, претензия субъекта данных и срыв сделки с инвестором или корпоративным заказчиком. Кейс аудита скоринга нужен, чтобы увидеть эти риски до того, как алгоритм станет частью критического бизнес-процесса.
Скоринг обычно воспринимают как техническую задачу. Команда обсуждает источники, качество признаков, скорость расчета и точность сегментации. Юридическая проблема начинается раньше — в момент, когда компания получает сведения о человеке, связывает их с идентификатором и на их основе принимает или рекомендует решение, влияющее на его интересы.
Почему проверка скоринга начинается не с модели
Для юриста не имеет решающего значения, называется ли продукт антифродом, оценкой надежности продавца, лид-скорингом или системой приоритизации заявок. Значение имеет фактическая цепочка обработки. Откуда пришли сведения, можно ли использовать их для этой цели, кто определяет параметры обработки, кому передается результат и какие последствия наступают для конкретного человека.
Например, e-commerce агрегатор собирает публичные данные о магазинах, отзывы, контакты представителей и историю взаимодействия с площадкой. Затем сервис формирует рейтинг риска и ограничивает доступ к отдельным функциям. Если рейтинг строится только по информации о юридическом лице, режим персональных данных может не возникнуть. Но как только профиль привязан к индивидуальному предпринимателю, директору, владельцу аккаунта или сотруднику, требуется проверить применимое privacy-законодательство.
Отдельная ошибка — считать публичность информации универсальным разрешением. Публично доступные сведения не отменяют обязанности определить правовое основание, цель, срок хранения и содержание уведомления. При сборе данных не у самого субъекта особенно важны требования статьи 14 GDPR об информировании, если нет применимого исключения.
Разбор кейса аудита скоринга в компании-агрегаторе
Рассмотрим типовую ситуацию, составленную по распространенной структуре проектов без раскрытия данных клиентов. Международный агрегатор поставщиков оценивал деловую надежность контрагентов для внутреннего ранжирования и предоставлял часть рейтинга корпоративным пользователям. Информация поступала из открытых сайтов, партнерских выгрузок, форм регистрации и закрытого API, к которому команда обращалась через техническую интеграцию.
На старте бизнес считал, что обрабатывает только корпоративные сведения. В ходе проверки выяснилось, что в профилях хранились имена контактных лиц, рабочие email-адреса, номера телефонов, история коммуникаций и отметки менеджеров. В нескольких юрисдикциях такие данные прямо относятся к персональным. Наличие рабочего адреса не выводит его автоматически из-под действия GDPR или иных применимых режимов защиты информации.
Аудит не сводился к перечню документов. Мы выстроили карту движения данных от каждого источника до интерфейса клиента, журналов доступа и резервных копий. Это позволило отделить информацию, необходимую для договорных отношений, от сведений, добавленных «на будущее» без понятной цели и срока хранения.
Источники данных оказались главным риском
Первый блок касался правомерности сбора. Для веб-источников проверялись условия использования сайта, технические ограничения, robots.txt как индикатор позиции владельца ресурса, интенсивность запросов и наличие обхода авторизации или защитных механизмов. Robots.txt сам по себе не является лицензией или запретом, но игнорирование явных ограничений вместе с агрессивной нагрузкой усиливает риск претензий и блокировки IP-адресов.
Для закрытого API анализировались договорные условия и фактический способ доступа. Использование ключа партнера не означает, что данные разрешено сохранять в собственной базе, объединять с другими массивами или передавать заказчикам. Такие права должны следовать из договора, условий API или отдельного разрешения правообладателя.
В партнерских выгрузках обнаружилась другая проблема. Поставщик передавал контакты без ясного распределения ролей и гарантий, что у него есть законное основание на передачу. Здесь потребовались проверка статуса сторон, договор обработки данных и гарантии по источнику. Если одна сторона определяет цели и существенные средства обработки, формального названия договора недостаточно: роли нужно описывать по факту.
Скоринговый результат тоже может быть персональными данными
Команды нередко защищают только исходную базу, но не результат расчета. Оценка «высокий риск», «низкая надежность», «приоритетная проверка» или «ограничить доступ» может быть персональными данными, если ее можно связать с идентифицируемым человеком. Это относится и к объяснениям, причинам снижения рейтинга, журналам корректировок и истории решений.
Далее проверялась степень автоматизации. Статья 22 GDPR устанавливает специальный режим для решений, основанных исключительно на автоматизированной обработке и порождающих юридические или сопоставимо значимые последствия. Не каждый рейтинг подпадает под эту норму. Внутренняя рекомендация менеджеру и автоматический отказ в существенной услуге — разные сценарии.
Если человек фактически лишь утверждает решение, а не способен оспорить вывод системы и изменить его по существу, формальная «ручная проверка» не снимает риск. Компании необходимо определить, есть ли законное исключение для такой обработки, обеспечить meaningful human intervention, возможность выразить позицию и оспорить решение там, где это требуется.
Особое внимание уделяется признакам, из которых формируется оценка. Использование данных о здоровье, политических взглядах, религии, профсоюзном членстве или иных специальных категориях из статьи 9 GDPR требует отдельного анализа и в большинстве коммерческих сценариев создает чрезмерный риск. Косвенные маркеры также нельзя игнорировать, если они позволяют сделать вывод о таких характеристиках.
Что меняется после правового аудита
В описанном сценарии целью не было остановить продукт. Задача заключалась в том, чтобы сохранить коммерчески ценные функции, убрать неподтвержденные источники и разделить допустимые сценарии использования данных. В результате часть полей была исключена из профиля, часть — переведена в режим краткосрочного хранения, а для ряда источников были согласованы новые договорные основания.
Для клиентского интерфейса подготовили понятное описание логики рейтинга на уровне, достаточном для выполнения обязанностей по прозрачности, но без раскрытия коммерчески чувствительных деталей. Privacy Policy и уведомления при сборе были приведены в соответствие с реальными потоками данных. Для корпоративных заказчиков были обновлены условия передачи результатов и ограничения на повторное использование.
Когда обработка способна создавать высокий риск для прав и свобод физических лиц, проводится оценка воздействия на защиту данных по статье 35 GDPR. DPIA не является формальной анкетой. В ней фиксируются цели, необходимость и соразмерность обработки, риски для субъектов и меры их снижения. Документ особенно важен для профилирования в крупном масштабе, систематического мониторинга и сценариев, где решение влияет на доступ к услугам или экономическим возможностям человека.
Если сервис работает с жителями Калифорнии, параллельно оцениваются требования CCPA и CPRA. Здесь нужно проверить корректность уведомления при сборе, категории раскрываемой информации, права на доступ и удаление, а также наличие продажи или передачи данных в юридическом смысле этих актов. Термины GDPR и CCPA не совпадают, поэтому копирование европейского шаблона для американского продукта обычно оставляет пробелы.
Как провести проверку без остановки продукта
Эффективный проект идет параллельно с работой инженерной и коммерческой команд. Сначала фиксируется фактическая архитектура: источники, API, базы, доступы, регионы хранения, получатели и сроки. Затем юрист сопоставляет эту схему с применимыми требованиями GDPR, CCPA, ФЗ-152, договорными ограничениями и правами на базы данных.
После этого стоит ранжировать меры по срочности. Немедленного исправления требуют незаконный доступ к закрытому источнику, сбор специальных категорий данных без основания, отсутствие уведомлений при непрямом сборе и передача массива третьей стороне без договорного контроля. Менее критичные, но обязательные задачи — настройка сроков удаления, журналов обработки, процедуры ответов на запросы субъектов и обучение сотрудников, которые вручную корректируют оценки.
Практический результат аудита должен быть понятен не только DPO или юристу. Руководителю нужен реестр рисков с финансовым и операционным эффектом. Технической команде — конкретные изменения в источниках, полях, правах доступа и логировании. Отделу продаж — правила, какие данные и результаты можно показывать заказчику, а какие требуют отдельного согласования или лицензии.
Правовой аудит особенно полезен перед масштабированием в ЕС или США, подключением нового провайдера данных, запуском B2B-кабинета либо продажей аналитических отчетов. Чем раньше проверить основание сбора и границы использования, тем меньше вероятность, что дорого построенный продукт придется срочно перестраивать после жалобы, блокировки источника или проверки контрагента.
Дата-юристы Data Lawyer Agency помогают провести проверку скоринговых процессов, легализовать источники данных, подготовить договоры передачи и документацию по privacy-комплаенсу. Начните с карты потоков данных и перечня решений, которые влияет на клиентов или партнеров: именно там обычно скрывается риск, который можно устранить до запуска следующего рынка.