ИИ в Data Governance: как мы ускорили маркировку персональных данных

Меня зовут Антон, я аналитик в команде разработки продукта RT.DataGovernance (далее — DG) компании TData.

В этой статье я расскажу, как мы c командой определяли, где и как будем использовать искусственный интеллект, как тестировали обученные модели и как интегрировали их в DG.

Пару слов о нашем продукте

Каждая компания, использующая data-driven подход, нуждается в качественном и эффективном управлении данными. Практики управления данными основаны на теоретических и практических рекомендациях, разработанных профессиональной ассоциацией DAMA (Data Management Association). Зафиксированы и описаны они в известной DAMA DMBOK. Одной из ключевых областей в управлении данными является Data Governance (в честь него и назван наш продукт). Она включает:

• Определение политики и процедур управления данными

• Назначение ролей и ответственности за управление данными

• Разработка планов управления данными

• Мониторинг и контроль качества данных

• Обеспечение безопасности и конфиденциальности данных

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

В DG реализованы механизмы дополнительного бизнес-описания отсканированных объектов: пользователи могут закрепить за объектом конкретную роль, задать произвольный атрибутивный состав, связать его с другими объектами в DG (например, с терминами) и проставить теги. Это позволяет агрегировать объекты не только по атрибутам, но и по тегам.

Процесс первичного документирования объектов трудоемок. Пользователям требуется задавать описание для таблиц или представлений, назначать ответственных за качество метаданных, устанавливать связи с другими объектами, проставлять теги. Все это требует ручных действий.

Именно к этому процессу мы решили применить алгоритмы искусственного интеллекта.

Пару слов об искусственном интеллекте

Под искусственным интеллектом мы понимаем систему, которая оптимизирует задачи, обычно требующие человеческого внимания.

Рост интереса к ИИ связан с тем, что его применение открывает новые возможности развития продукта. Сами алгоритмы ИИ можно разделить на две большие группы: классические модели (или «классический ML») и генеративные модели. Первая группа приносит бизнес-пользу компаниям через предсказания вероятности какого-либо события. Вторая группа направлена на снижение рутинизации рабочих активностей: алгоритмы берут на себя повторяющиеся задачи, высвобождая время специалистов и делая работу с продуктом заметно комфортнее.

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

Искусственный интеллект в инструментах Data Governance

Конечно, мы не первые, кто решил интегрировать ИИ в инструменты Data Governance. Рассмотрим несколько примеров.

Известный open-source инструмент OpenMetadata интегрировал AI-компаньона — чат-бот “MetaPilot”. Он позволяет составлять SQL-запросы на основе естественного языка.

Примеры впечатляют. Но как нам доказать бизнес-эффект от внедрения AI-помощника? Нашей команде хотелось увидеть результат здесь и сейчас без использования трудоемких решений, которые потребуют фундаментальной переработки архитектуры продукта. Решение должно было быть простым, эффективным и оправдывать вложенные ресурсы.

Выбор процесса для автоматизации

Сценарий для автоматизации должен быть востребован пользователями и не перегружать сервера, на которых развернут наш продукт. Поэтому идея использовать генеративные модели для автогенерации описаний на основе их содержания отпала почти сразу: на тот момент даже “легковесные” модели оставались ресурсоемкими.

Выше я упоминал, что процесс первичного документирования объектов трудоемок. Но максимальной точки рутины он достигает, когда пользователям необходимо вручную отметить объекты, в которых содержатся персональные данные. В этом случае, пользователи должны проверить каждую таблицу вручную, посмотреть на сэмпл данных и определить, содержатся ли в них персональные данные. Если персональные данные есть, то в колонке таблицы (или представления) нужно поставить соответствующий тег. В дальнейшем данные с выбранным тегом маскируются. Это долго, сложно и рискованно — всегда есть шанс пропустить важные данные: в сэмпл просто могут не попасть данные, которые указали бы на принадлежность к ним…

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

Поскольку обеспечение безопасности и конфиденциальности — важная часть процесса управления данными, мы решили автоматизировать именно этот ручной процесс в DG.

Разработка и тестирование первой модели

Постановки задачи было недостаточно. Требовалась ее декомпозиция для направления на разработку в отдел — центр компетенций по разработке ИИ-решений. Изначально ожидалось, что модель будет определять только 4 вида ПДн: адрес, ФИО, дату рождения и мобильный телефон.

Подготовленное MVP показало низкие метрики. Например, витрина с названиями фильмов была ошибочно отмечена как содержащая в себе ПДн с тегом ФИО, так как в выборку попал фильм с названием “Патти Кейкс”.

{
  "samples": [
    {
      "value": "Время покажет"
    },
    {
      " value": "Девушка с татуировкой дракона"
    },
    {
      " value": "Не в себе"
    },
    {
      " value": "Морской тв"
    },
    {
      " value": "Мстители"
    },
    {
      " value": "На льду"
    },
    {
      " value": "Девочки из Эквестрии. Радужный рок"
    },
    {
      " value": "JimJam"
    },
    {
      " value": "Патти Кейкс"
    },
    {
      " value": "Капитан Немо"
    }
}

Выше показан пример сэмпла в формате JSON

Оценка качества модели производилась на датасете из 554 объектов. Он отражал: названия таблицы и колонки, тип данных; название тега, полученный из анализатора; примеры; score. На признаке «score» стоит остановиться подробнее. Этот признак отражает условную метрику Accuracy для загруженного списка примеров. Например, колонка, отмеченная тегом «ФИО», будет иметь «score», равный 0.2, если 20% значений примеров были помечены тегом «ФИО».

После получения датасета, мы решили его дополнить атрибутом «Флаг» (особенность этого атрибута в том, что заполняли мы его вручную). У него было всего два значения: 0 и 1. Если «score» не соответствовал действительности, то ставили «0». Для иллюстрации, если из 10 примеров, которые анализатор отметил тегом «Адрес», восемь действительно, содержали какой-то адрес и их «score» был равен 0.8, то во «Флаге» ставилась единица. Эта работа может показаться кропотливой, но именно такая «двойная» валидация модели «глазами» показала, что для разработки по-настоящему качественной модели потребуется более детальные спецификации и четкое техническое задание.

По усредненным результатам, метрика Accuracy была равна около 0.3. Это означало, что только 3 значения из 10 были верно отмечены. С таким результатом модель в бой отпускать было нельзя.

Разработка и тестирование второй модели

Второй подход позволил учесть дополнительные требования к алгоритмам. Теперь к основным 4 тегам были добавлены еще 4: номер СНИЛС, номер паспорта, номер ИНН и почтовый индекс.

Мы более тщательно подготовили и разметили данные, сосредоточились на изучении структуры типов ПДн и их нестандартных форматов. Дополнительно разработали кастомные словари. В рамках этого процесса были определены примеры очевидного наличия персональных данных (полные ФИО, email в формате user@user.com) и их скрытые формы. Например, в нескольких колонках данные были представлены как пара числового кода и префикса «#EMAIL». Это явно указывает на связь с электронной почтой.

Параллельным процессом было преодоление ряда противоречий. Например, данным с «ФИО» мог проставиться тег «Адрес» и наоборот. Организации с аббревиатурами “ООО” и “ЗАО” тоже могли отмечаться таким же тегом. Сложностью при разметке стали случаи, когда компоненты адреса (номера домов, корпусов и квартир) были распределены по разным строкам. Анализ же результатов работы первой модели позволил выявить нестандартные форматы представления ФИО, среди них: слитное написание ФИО, использование латинской раскладки, применение символа «_» в качестве разделителя между фамилией и именем.

Помимо более тщательного анализа данных с ПДн были применены дополнительные манипуляции. Для определения тега “ФИО” был добавлен дополнительный препроцессинг и создан кастомный словарь, в который попадали “необычные” имена и фамилии. Тоже самое было сделано и для тега “Адрес”.

По сути перед командой стояла задача NER (Named Entity Recognition). Требовалось из текстовых данных (в нашем случае из адресов, имен и фамилий) выделить именованные сущности: имена, адреса, названия организаций, даты. А уже на основе этих сущностей, проставлять соответствующие теги.

Полученная модель была создана на основе регулярных выражений. Она решает задачу мультиклассовой классификации — то есть пока модель проставляет только один тег. Решение оценивалось метрикой F-1 (ожидается, что в дальнейшем модель будет решать уже задачу мультилейблинга (когда данные будут помечаться уже более чем одним тегом). Но для этого уже будет нужно внедрять генеративные модели, а точнее LLM). Натренированную модель обернули в docker и направили разработчикам нашей команды.

Интеграция алгоритмов искусственного интеллекта в RT.DataGovernance

Кроме модели, мы подготовили интерфейс: добавили цветовой индикатор (цвет информирует о наличии ПДн) и специальный дашборд для визуализации количества, объектов, содержащих ПДн. Также был подготовлен специальный функционал для запуска скрипта анализа проверки содержания персональных данных.

Добавление нового функционала в RT.DataGovernance будет способствовать выполнению требований информационной безопасности (далее – ИБ) в части обработки и хранения ПДн.

Первые результаты

Теперь верификация уже размеченных данных занимает не годы, а вполне осязаемые сроки в 2-3 недели. Результаты разметки сразу используются в прикладных активностях ИБ – настройке мониторингов и контроля доступа к данным объектам. Это позволило ускорить процесс демократизации данных в компании.

Заключительное слово

Внедрив доработку в продакшн, мы расширили функциональность продукта, решили прикладную бизнес-задачу и показали осязаемые результаты, оптимизировав рутинные операции и сократив воронку объектов, требующих человеческого участия.

Хочу отметить, что проект был кросс-командным. В разработке решения участвовали продуктовая команда, команда ИИ и ответственные от ИБ. Это координация нескольких направлений принесла несомненную пользу развитию нашего продукта.

Планы на будущее

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

Надеюсь, было интересно. А как вы внедряли алгоритмы искусственного интеллекта в Вашу компанию?