В выгрузке событий приложения вместо имени пользователя может стоять случайный идентификатор. На вид данные обезличены. Но если по этому идентификатору можно найти учетную запись, номер телефона или рекламный ID, они могут оставаться персональными. Перед передачей выгрузки аналитическому подрядчику важно выяснить, можно ли определить человека с помощью сведений, доступных участникам проекта. Название файла и отсутствие ФИО на этот вопрос не отвечают.
Big Data — не отдельная юридическая категория с едиными правилами. За этим названием могут стоять клиентские записи, логи посещений, геоданные, публикации из открытых источников и статистические модели. Для каждого массива имеют значение его происхождение и состав, цель использования, получатели и страны хранения или обработки. Речь ниже прежде всего о проектах в российской юрисдикции. При выходе на другие рынки применимое право нужно проверять отдельно.
Начните с карты данных, а не с выбора платформы
Аналитический продукт часто собирает сведения из CRM, сайта, мобильного приложения и от внешнего поставщика. Даже если каждый источник использовался законно, после объединения правовая оценка может измениться. Так, история просмотров товаров вместе с адресом доставки позволяет сделать выводы, которых не дает ни один из этих наборов по отдельности.
По каждому потоку стоит зафиксировать:
- источник данных и лицо, которое их собирало;
- конкретные поля, включая технические идентификаторы и метаданные;
- цель первоначального сбора и новую аналитическую задачу;
- основание обработки и условия передачи третьим лицам;
- место хранения, срок использования и получателей результатов;
- способ удаления данных или прекращения доступа после завершения проекта.
Карта данных помогает заметить несовместимость целей до загрузки массивов в хранилище. Согласие на оформление заказа само по себе не разрешает строить поведенческие профили для партнера. При этом внутренней статистике по действительно обезличенным данным не всегда нужны те же процедуры, что работе с профилями клиентов. Оценивать следует конкретную схему обработки.
Персональные данные и проблема повторной идентификации
По российскому праву персональные данные — это информация, относящаяся к прямо или косвенно определенному либо определяемому человеку. Поэтому исключить ФИО недостаточно. Cookie, ID устройства, точные координаты и история действий в совокупности могут позволить выделить пользователя и связать записи с ним. Имеет значение и то, какие дополнительные сведения есть у оператора или получателя набора.
Псевдонимизация не равна обезличиванию
Если заменить имя кодом, доступ к личности станет сложнее. Но связь можно восстановить, когда у компании хранится таблица соответствия. Даже без нее человека иногда выдает редкое сочетание признаков: маршрут, время посещения и возрастная группа. Поэтому заявление поставщика «данные анонимные» нужно сверять с тем, как набор подготовлен, а не принимать за юридическое заключение.
Проверьте прямые идентификаторы, косвенные признаки и возможность сопоставить записи с внешними источниками. В одном случае достаточно убрать точные адреса и укрупнить временные интервалы. В другом — вместо записей по отдельным людям придется передавать только агрегированные показатели. Проверку обезличивания нужно повторить, если появятся новые источники данных или изменится круг получателей.
Основание, цель и срок обработки
Если в массиве есть персональные данные, оператору нужно определить правовое основание для сбора, объединения, анализа и передачи. Согласие не подходит автоматически и не заменяет точного описания целей. Закон может предусматривать и другое основание, но его применимость придется обосновать для конкретной задачи. Отдельной проверки требуют категории данных со специальными ограничениями и сведения о несовершеннолетних.
Цель обработки должна объяснять, зачем нужны именно эти поля. Формулировка «для улучшения сервиса и любых иных целей» не оправдывает сбор избыточных сведений. Если старую базу планируют использовать для новой модели рекомендаций, нужно сопоставить задачу с ранее заявленными целями и выяснить, придется ли менять документы и порядок получения согласий. Сырые данные необязательно хранить столько же, сколько существует модель: исходные записи можно удалить раньше, когда они больше не нужны.
Открытые источники, парсинг и покупные наборы
Открытая страница не дает права свободно использовать все, что на ней размещено. Публичный профиль может содержать персональные данные, а фотографии, тексты и иллюстрации охраняются отдельно. Доступ к сервису также может регулироваться пользовательским соглашением и техническими условиями. При оценке парсинга важны состав собираемых данных, способ сбора и дальнейшая цель использования.
Покупной датасет стоит проверять по всей цепочке происхождения. В договоре с поставщиком нужны не только заверения о законности сбора, но и сведения об источниках, допустимых целях, составе полей, ограничениях на объединение и порядке ответа на запросы субъектов данных. До оплаты полезно запросить образец набора и документацию по его формированию. Фраза «поставщик обладает всеми правами» мало помогает, если неизвестно, что именно он передает.
Сами по себе факты могут не охраняться авторским правом. Но структура базы, подбор материалов или существенные затраты на ее создание могут затрагивать права изготовителя базы данных и иные права. Для статей, изображений и фрагментов карточек товаров в составе набора отдельно проверяют права на контент. А разрешенный доступ к API не означает, что его ответы можно хранить бессрочно или перепродавать.
Роли участников и условия договора
В проекте могут участвовать заказчик, облачный провайдер, разработчик модели и поставщик данных. Слова «партнер» и «подрядчик» не показывают, кто определяет цели обработки и может ли использовать массив для собственных продуктов. Это выясняют по фактическим действиям: кто выбирает поля, дает инструкции, открывает доступ и решает, когда удалить данные.
Если обработку персональных данных поручают другому лицу, договор и связанные документы должны отвечать требованиям применимого законодательства. Для российского оператора, в частности, важны перечень действий с данными, цели обработки, обязанности по конфиденциальности и безопасности, распределение ответственности. Намерение подрядчика обучать общую модель на данных клиента — отдельная цель. Ее нельзя скрывать за общей фразой о «повышении качества услуг».
В техническом приложении к договору стоит закрепить границы доступа и то, что стороны смогут проверить:
- перечень наборов и допустимых операций с каждым из них;
- кто может привлекать субподрядчиков и на каких условиях;
- порядок реагирования на инцидент, сроки уведомления заказчика и состав передаваемой информации;
- правила возврата и удаления данных, включая резервные копии;
- режим доступа к моделям, отчетам, обучающим выборкам и производным наборам.
Нужно также договориться, что заказчик получит после завершения работ: отчет, веса модели, код обработки, подготовленный датасет или их сочетание. Права на программу, базу данных и отчет не переходят к заказчику автоматически из-за оплаты аналитики. Условия об интеллектуальных правах должны учитывать устройство проекта и права на исходные материалы.
Границы автоматизированных решений
Модель может прогнозировать отток клиентов, выявлять подозрительные операции или ранжировать кандидатов. Одно дело, когда ее результат помогает сотруднику; другое — когда он непосредственно влияет на доступ человека к услуге, цену, работу или другие права и интересы. Для решений, основанных исключительно на автоматизированной обработке персональных данных и порождающих юридические последствия либо иным образом затрагивающих права и законные интересы человека, российское законодательство предусматривает специальные условия и гарантии.
В документации стоит отделить прогноз от решения. Кто может изменить вывод модели? По каким данным он получен? Как исправить ошибочную запись? Присутствие сотрудника ничего не меняет по существу, если он всегда утверждает ответ системы без проверки. Для сценариев, затрагивающих права людей, нужны понятный порядок оспаривания, журнал изменений и периодическая проверка качества модели на новых данных.
Даже агрегированный отчет может раскрыть коммерчески чувствительные сведения. Если в группе три клиента, а показатели двух известны, третий показатель можно вычислить. Перед передачей дашборда партнерам следует определить минимальный размер групп, ограничить детализацию срезов и проверить, не восстанавливаются ли исходные значения через последовательные запросы.
Безопасность, локализация и трансграничная передача
Ошибка в настройке большого хранилища затрагивает сразу множество записей: достаточно открытого бакета или учетной записи с избыточными правами. Меры защиты выбирают с учетом применимых требований и модели угроз. На практике нужно разграничивать доступ, вести учет действий, защищать резервные копии, управлять ключами и отзывать доступ после увольнения сотрудника или окончания договора. Псевдонимизированные данные тоже нуждаются в защите.
При работе с зарубежной инфраструктурой проверяйте не только регион основного сервера. Резервные копии, техподдержка, мониторинг и доступ администраторов из других стран могут влиять на оценку трансграничной передачи. Для персональных данных граждан России отдельно учитывают требования к локализации при сборе и действующие правила трансграничной передачи, в том числе предусмотренные законом уведомления и ограничения. Архитектуру лучше согласовать до миграции: переносить копии и журналы постфактум бывает сложнее, чем заранее выбрать подходящее место хранения.
Как проверить конкретный аналитический сценарий
Допустим, медиасервис передает подрядчику историю просмотров для разработки модели рекомендаций. Проверку удобно провести по шагам:
- Отобрать поля, без которых модель не работает. Возможно, хватит категории материала и укрупненного времени просмотра без почты и номера телефона.
- Выяснить, можно ли связать оставшиеся события с пользователем через ID, редкое поведение или другие доступные наборы.
- Сопоставить новую цель с основаниями сбора и документами, действовавшими при получении данных.
- Определить, где подрядчик будет обрабатывать сведения, кто получит доступ и станет ли использовать выборку для собственных задач.
- Закрепить в договоре результат работ, допустимые операции, меры защиты и судьбу исходной выборки после приемки.
Если подрядчику нужен только механизм рекомендаций, тестовый набор можно подготовить отдельно от действующей пользовательской базы. Затем — проверить, достаточно ли такой выборки для модели. Само по себе это не решает юридические вопросы: состав набора и способ его формирования все равно требуют оценки.
Первым документом для согласования может стать таблица с колонками «поле данных», «источник», «зачем нужно модели», «кому доступно» и «когда удаляется». Если команда не может объяснить, зачем ей точная геолокация, это поле не стоит автоматически включать в первую выгрузку. Материал не заменяет индивидуальную юридическую консультацию: оценка зависит от состава данных, юрисдикций и фактической схемы обработки.