Баланс между извлечением ценности и соблюдением прав на данные во время DataOps

Растет число нормативных актов о правах на данные, таких как GDPR, CCPA, Общий закон Бразилии о защите данных, Закон о защите личных данных Индии и ряд других, как показано на рисунке. Эти законы требуют, чтобы данные клиентов собирались, использовались и удалялись в зависимости от их предпочтений. Существуют разные аспекты прав на данные, а именно:

Сбор прав на данные

Право на получение информации о сборе персональных данных и категориях собираемой информации

Использование прав на данные

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

Удаление прав на данные

Право на удаление личных данных, переданных в приложение, а также данных, переданных третьим лицам.

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

Право на доступ к личным данным клиента; право на исправление, если данные неточные или неполные; право на переносимость данных, которое позволяет физическим лицам получать и повторно использовать личные данные

Болевые точки

Обеспечение соответствия требует совместной работы пользователей данных и инженеров по обработке данных. Специалистам по данным и другим пользователям данных нужен простой способ найти все доступные данные для конкретного варианта использования, не беспокоясь о нарушениях нормативных требований. Инженеры по обработке данных должны убедиться, что они правильно расположили все копии данных клиентов и выполняют права пользователей комплексным, своевременным и контролируемым образом.

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

Сегодня существует несколько болевых точек, связанных с управлением данными. Во-первых, сложно гарантировать, что данные клиента используются только для правильных вариантов использования, поскольку эти варианты использования становятся все более детализированными. Пользователи данных должны понимать, какие данные клиентов могут использоваться для каких сценариев использования. Во-вторых, отслеживание применимых данных о клиентах нетривиально, учитывая разрозненность данных и отсутствие единого идентификатора, который можно было бы сопоставить как ключ клиента (особенно те, которые были получены с течением времени). Без строгой координации с пользователями данных поиск производных данных затруднен. Требуется полный каталог исходных данных, исторических копий, производных данных и сторонних наборов данных. В-третьих, выполнение запросов о защите данных клиентов должно быть своевременным и проверяться. Требуются соответствующие меры, чтобы запросы не были мошенническими. Нетривиально упаковать все личные данные клиента в совместимый формат, при этом не допуская, чтобы внутренняя схема подвергалась обратному проектированию.

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

Примеры использования для управления правами на данные

Предприятия, использующие свои приложения, несут ответственность за сбор, управление и предоставление доступа к данным клиентов и определяются как контроллеры данных . Если предприятие использует сторонние инструменты для электронного маркетинга, SEO и т. д., эти поставщики являются обработчиками данных. Контроллер также несет ответственность за соблюдение прав на данные для процессоров.

Выполнение запросов о правах на данные

Клиенты могут запросить защиту своих прав на данные. У клиентов есть разные ожидания в отношении защиты своих прав на данные:

  • Персональные данные следует хранить только в случае необходимости.
  • Персональные данные следует удалять по запросу или при закрытии аккаунта.
  • Персональные данные должны обрабатываться только с согласия пользователя.

Сегодня на большинстве предприятий обработка запросов является полуавтоматической и включает в себя специальные группы инженеров по обработке данных. Автоматизация этих запросов требует определения того, какие данные были собраны от клиента, как они идентифицированы, где они расположены во всех источниках данных и в озере данных, как сохраняются предпочтения клиентов, как данные используются для генерации аналитических данных, как данные передаются партнерам, и какие варианты использования обрабатывают данные и происхождение полученных идей. Затем инженерам по обработке данных необходимо систематизировать рабочие процессы для выполнения запроса клиента.

Обнаружение наборов данных

Качество информации, полученной на основе необработанных данных, зависит от имеющихся данных. Специалисты по обработке данных, аналитики и более широкие пользователи должны понимать, какие данные доступны для конкретного варианта использования. В частности, пользователи данных хотят проанализировать как можно больше данных, чтобы модели были точными. Они хотят как можно быстрее обнаруживать и получать доступ к данным, которые доступны для анализа на основе предпочтений клиентов. Сегодня проблема состоит в том, чтобы сохранить эти детальные предпочтения, которые можно рассматривать как матрицу элементов данных о клиентах и ​​различных сценариях использования. Для каждого варианта использования необходимо создать отфильтрованное представление данных о клиентах, а также необходимо встроить логику в сбор данных и подготовку набора данных для фильтрации данных для вариантов использования.

Клиенты могут захотеть быть исключенными из определенных вариантов использования. Например, в случае профессиональных сетевых порталов, таких как LinkedIn, пользователь может захотеть использовать данные своего профиля, чтобы рекомендовать новые связи, но не рекомендации по работе. Есть еще один аспект предпочтений клиентов, который нельзя полностью учитывать. Рассмотрим сценарий мошенничества с онлайн-платежами, когда судебное расследование может потребовать доступа к удаленным записям данных для установления следа транзакции.

Переподготовка модели

Настройки прав клиентов на данные постоянно меняются. Эти изменения необходимо учитывать при обновлении моделей и других аналитических материалах. В настоящее время обучение модели постепенно добавляет новые образцы для обучения и отбрасывает старые образцы на основе временного окна удержания. Обычно проблема упрощается с помощью крупномасштабного программного соглашения. Альтернативный подход заключался в том, чтобы замаскировать данные PII в процессе обучения, исключив необходимость их отбрасывать. Маскирование не всегда может быть вариантом из-за риска повторной идентификации.

Внедрение управления правами на данные

Реализация прав на данные клиентов включает время, затрачиваемое на отслеживание жизненного цикла данных и предпочтений клиентов, выполнение запросов о правах на данные клиентов и обеспечение использования правильных данных в соответствии с предпочтениями клиентов.

Отслеживание жизненного цикла данных клиента

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

Сегодня отслеживание данных о клиентах представляет собой несколько ключевых задач. Во-первых, клиенты идентифицируются по нескольким различным идентификаторам. Это особенно верно для корпоративных продуктов, интегрированных через поглощения. Для данных, совместно используемых службами, очень важно определить зависимости, удаление записей которых может повлиять на функциональность продукта. Во-вторых, данные PII должны обрабатываться с соответствующими уровнями шифрования и контроля доступа. Данные PII необходимо классифицировать на основе понимания семантики данных (а не только схемы).

Выполнение запросов о защите данных клиентов

Это включает в себя реализацию прав на данные клиента, связанных со сбором, использованием, удалением и доступом к данным. Помимо задач управления данными, для минимизации времени на выполнение запросов клиентов необходимо решить несколько задач. Во-первых, запросы должны быть проверены, чтобы предотвратить мошеннические запросы. Это включает в себя идентификацию пользователя и обеспечение того, чтобы у него была правильная роль для отправки запроса. Во-вторых, вам нужна возможность удалять определенные данные, связанные с клиентами, из всех систем данных. Учитывая неизменные форматы хранения, удаление данных затруднено и требует понимания форматов и организации пространства имен. Операция удаления должна асинхронно перебирать наборы данных в соответствии с соглашением об уровне обслуживания, не влияя на производительность выполняемых заданий. Записи, которые нельзя удалить, необходимо помещать в карантин, а записи об исключениях нужно отсортировать вручную. Эта обработка должна масштабироваться до десятков ПБ данных, а также для сторонних данных. В-третьих, вы должны убедиться, что не разглашаете секреты интеллектуальной собственности в рамках запросов на переносимость, чтобы предотвратить обратное проектирование внутренних форматов.

Ограничение доступа к данным

Ограничение доступа к данным включает в себя обеспечение использования данных клиентов для правильных вариантов использования в зависимости от их предпочтений. Это требует понимания того, какие элементы данных требуются для варианта использования, типа понимания, которое будет генерироваться вариантом использования, и того, передаются ли данные партнерам.

Сопоставление предпочтений клиентов с вариантами использования требует сложного лабиринта политик доступа. Метаданные для сохранения предпочтений использования должны соответствовать детализированным вариантам использования. Метаданные должны быть эффективными и соответствовать изменяющимся предпочтениям клиентов, и их необходимо оценивать каждый раз. Например, если пользователь отказался от электронного маркетинга, при следующей отправке электронных писем клиент должен быть исключен.

Дополнительное обсуждение этой темы и шаблонов для самообслуживания управления данными см. В моей книге Дорожная карта самообслуживания.