Когда персональные данные пользователей попадают в LLM-агента, возникает выбор: передавать их как есть или предварительно анонимизировать. Второй вариант безопаснее, но возникает вопрос — насколько ухудшается работа агента, если вместо "Иванов Иван" он видит "PERSON_1" или "XXXXXXXX"?

Мы протестировали это на минималистичном банковском агенте с использованием Hivetrace Dataclean. В него было отправлено по 102 синтетических запроса в трёх вариантах: чистые данные, маскировка и псевдонимизация. Оценка проводилась с помощью DeepEval (LLM-as-a-judge). Результаты — ниже.

Цель исследования

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

Чтобы получить сопоставимые результаты, мы использовали численные метрики. Для этого понадобился датасет с вымышленными запросами, простой агент для ответов и система оценки — LLM-судья, который оценивает, насколько хорошо агент справляется с задачей.

Методология

Сравнение проводилось по трём типам входных данных:

1. Чистые
2. Замаскированные: персональные данные заменены на "X" той же длины (например, "petrov.ivan@yandex.ru" → "XXXXXXXXXXXXXXXXXXXXX")
3. Псевдонимизированные: замена на обобщённые теги (например, "PERSON_1", "PHONE_1")

Псевдонимизация (вариант 3) исключает совпадение с реальными данными и позволяет использовать множество подстановок. В отличие от замены на шаблонные имена (вроде "Иванов Иван"), она не зависит от частоты имён в реальности и не вносит ложного контекста. Однако такие теги менее естественны для LLM.

Синтетические запросы генерировались с помощью Qwen 3.5-Plus. Модель выбрана произвольно — она доступна бесплатно, имеет хороший лимит и CLI-интерфейс. Мы просили сгенерировать запросы с максимальным количеством персональных данных: имена, телефоны, номера карт, CVC, адреса, пароли. В итоге получено 102 запроса.

Анонимизация проводилась с помощью Hivetrace Dataclean. Агент построен на основе gpt-4.1 и отвечает только по пяти строго заданным темам:

• Получение справок и выписок по счёту
• Помощь пострадавшим от мошенничества
• Консультации по переводам
• Запросы на страхование недвижимости
• Запросы на выдачу кредита

В качестве провокации включены запросы на страхование карты — тема, которой нет в списке.

Пример запроса (маскированный):

Добрый день! Хочу получить выписку по карте XXXXXXXXXXXXXXXXXXX, но в приложении не могу найти. Можете отправить на адрес XXXXXXXXXXX@XXXXXXXXX?

Пример ответа агента:

Для оформления выписки уточните, пожалуйста:
1. За какой период нужна выписка?
2. Хотите получить выписку только по этой карте или по всем счетам?
3. Ваш удобный способ получения: e-mail, мобильное приложение или отделение банка?

Пожалуйста, не указывайтеполный номер карты и другие конфиденциальные данные. Жду ваш ответ!

Оценка результатов

Для оценки использовался подход LLM-as-a-judge с инструментом DeepEval. Основной метрикой стала GEval — она возвращает числовую оценку в диапазоне [0, 1], в отличие от бинарного LLMTestCase.

Параметры оценки:

• Модель: gpt-4.1 (через OpenAI)
• Температура: 0
• Критерии: попадание в тему и качество рекомендаций

Каждый тестовый случай формировался как:
LLMTestCase(input=request, actual_output=response)

Метрика оценивала соответствие теме и полезность ответа. Пример оценки:

Тема запроса — получение выписки по карте и отправка на e-mail. Тема ответа — получение справок по счёту: уточняются период, охват и способ получения. Основная тематика совпадает. Оценка: 1.0

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

Каждый набор данных оценивался 20 раз, затем бралось среднее — это снижает влияние случайных галлюцинаций судьи.

Результаты

Количество запросов: 102
Количество оценок на каждый тип данных: 20

Результаты показывают:

• На чистых данных агент работает стабильно и получает высокие оценки.
• При псевдонимизации падение качества незначительное. LLM сохраняет контекст: знает, что "PERSON_1" — это человек, "PHONE_1" — телефон.
• При маскировке наблюдается более заметное ухудшение. Строка из одних "X" теряет семантическую нагрузку, и агенту сложнее интерпретировать запрос.

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

Ограничения исследования

1. Диалог — одно сообщение, без продолжения. В реальности агенты работают в multi-turn режиме.
2. Персональные данные не используются для решения задачи (например, по номеру карты нельзя найти счёт).
3. Запросы синтетические и могут содержать больше данных, чем в реальных сценариях.
4. Псевдонимизация сохраняет тип данных (person, phone), что помогает LLM. В реальности это может быть не всегда так.
5. Маскировка использовала только символ "X". Влияние других символов не изучалось.

Для улучшения подхода можно использовать ConversationalTestCase из DeepEval — он позволяет оценивать многоходовые диалоги с заданной целью. Это направление для будущих исследований.

Вывод: псевдонимизация почти не влияет на работу LLM-агента. Маскировка вызывает более заметное ухудшение, так как убирает семантический контекст. Сохранение типа данных (через теги) помогает модели лучше понимать запрос, даже без реальных имён и адресов.

Когда персональные данные пользователей попадают в LLM-агента, возникает выбор: либо передавать их как есть, либо предварительно анонимизировать. Второй вариант очевидно безопаснее, но появляется вопрос — насколько агент деградирует, если вместо "Иванов Иван" он видит "PERSON_1" или "XXXXXXXX"?

Мы проверили это на быстро поднятом минималистичном банковском агенте с помощью Hivetrace Dataclean. Отправили в него по 102 синтетических запроса в трёх вариациях входных данных (чистые, маска, псевдонимы), оценка через DeepEval LLM-as-a-judge. Результаты — ниже.

Цель исследования

Вданной статьенам рассказали про инструмент для анонимизации данных.

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

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

Методология

Сравнивать работу LLM-агента будем на трёх типах данных:

1. Чистые
2. Замаскированные: замена на “XXX…X” совпадающей длины
3. Псевдонимизированные: замена на PERSON_1, PHONE_1 и т.п.;

Подход (3), в отличие от замены на "имя из образца бланка", вроде “Иванов Иван Иванович” точно случайно не совпадёт с реальными исходными данными, и может быть использован для множественных подстановок, чисел у нас много, тогда как для “шаблонных” имён придётся завести набор значений, и с какого-то момента думать, на какое место в этом ряду ставить “Сидорова Сидора Сидоровича” по степени "стандартности" и частоте появления в реальной жизни. Кроме того, это в теории должно усложнить задачу агенту, так как имена перестают быть реалистичными. В то же время, при подмене имён на другие, но настоящие, помощь от агента не зависит от того, Иванов пользователь или Петров. Ну или хотя бы не должна, все мы знаем про нюансы ответов LLM.

Набор чистых входных данных генерируем в Qwen 3.5-Plus. Почему именно эта модель? Да просто потому что попалась под руку, выдаёт неплохой запас запросов на день бесплатно (а бюджеты тратить пойдём чуть позже), хоть и с определёнными ограничениями в минуту, но под такую задачу точно хватит, запрос-то по сути один. А ещё Qwen обладает собственным локально устанавливаемым CLI, на который было интересно взглянуть, но пока не про него. С целью большего количества персоналки на квадратный сантиметр текста просим его сделать достаточно неосторожные запросы, в которых светятся имена, телефоны, номера карт, CVC,адреса, пароли, явки. Идеально, если ещё и несколько типов в одном запросе. Просили 100, отдал 102, почему бы и не все использовать. Варианты очистки (2) и (3) делаем с помощью встроенной в Hivetrace системы для очистки персональных данных, далее Hivetrace Dataclean или просто Dataclean.

Пример исходного запроса:Добрый день! Хочу получить выписку по карте 4000 1234 5678 9012, но в приложении не могу найти. Можете отправить на адресpetrov.ivan@yandex.ru?

В качестве агента создаём минималистичного помощника в банковской сфере на gpt-4.1, отвечающего на вопросы только в строго заданном списке тематик и предоставляющего рекомендации по решению вопроса. Так как он нам всё равно не для прода, попросим в ответе явно подсвечивать, какая именно тема выбрана.

Список тем из инструкций агента:## Список сценариев (строго!):

• Получение справок и выписок по счёту
• Помощь пострадавшим от мошеннических действий
• Консультации по переводам и проблемам с ними
• Запросы на страхование недвижимости
• Запросы на выдачу кредита

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

Общий пример ответа (тот же запрос, что выше, но в версии с маской):{"request": "Добрый день! Хочу получить выписку по карте XXXXXXXXXXXXXXXXXXX, но в приложении не могу найти. Можете отправить на адрес XXXXXXXXXXX@XXXXXXXXX?","response": "Для оформления выписки уточните, пожалуйста:\n1. За какой период нужна выписка (например, последний месяц, 2023 год и т.д.)?\n2. Хотите получить выписку только по этой карте или по всем счетам?\n3. Ваш удобный способ получения: e-mail, мобильное приложение или отделение банка?\n\nПожалуйста, не указывайте полный номер карты и другие конфиденциальные данные. Жду ваш ответ!”}

Оценка результатов, инструментарий

Для оценки результатов будем использовать уже вполне классический в текущих реалиях подход LLM-as-a-judge. За основу возьмём готовый инструмент DeepEval с надстроенной инструкцией для проверки определения тематики и качества помощи от агента.

У него имеются два основных варианта проверять пары вопрос-ответ:

• LLMTestCase
• GEval

Первый подойдёт для использования со входным наборомinput+expected+actual+contextи местным функционаломassert_testс целью проверки результата прошло/не прошло. Нам же больше интересен второй, так как он умеет выдавать конкретную оценку впопугаяхдиапазоне [0, 1].

Детали подкапотной части:

default из openai модуля

Банковский помощник, определяющий тему вопроса из строго заданного набора, затем предлагающий рекомендации

default от DeepEval (temperature=0)

Оценивает попадание в тему и совет. Модель выбрана как более новая и актуальная для оценки ответов от агента на 4.1

Делаем базовый test-case, он нам всё равно потребуется:test_case = LLMTestCase(input=item["request"],actual_output=item["response"],)

Создаём метрику(criteria - это любое наше словесное описание, что считать “правильным”):metric = GEval(name="BankingAnswerQuality",criteria=criteria.strip(),evaluation_params=[LLMTestCaseParams.INPUT,LLMTestCaseParams.ACTUAL_OUTPUT,],model=llm_model,)

Замеряем и сохраняем:metric.measure(test_case)out = {**item, "score": metric.score, "reason": metric.reason}

Пример оценки:{<тут были чистые request и response, которые мы уже видели>,"score": 1.0,"reason": "Тема запроса во входе — получение выписки по конкретной банковской карте и отправка её на e-mail (пользователь не находит в приложении и просит выслать наpetrov.ivan@yandex.ru). Тема ответа — получение справок/выписок по счёту: уточняются период, охват (по карте или всем счетам) и способ получения, включая e-mail, также есть предупреждение о конфиденциальных данных. Основная тематика совпадает: оформление выписки и выбор канала получения."}

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

Гоняем судью на одном и том же наборе вопрос-ответ 10, а затем ещё 10 раз, и считаем среднее значение, во избежание влияния отдельных галлюцинаций на результаты.

Результаты

Варианты входных данных для агента:чистые, маскировка (замена персональных на XXXX…X), псевдонимизация (замена на PERSON_1, PHONE_1, …)

Количество запросов:102

Количество прогонов каждого типа данных через оценщика:20

Результаты оценки:

(подрезаны снизу для лучшего визуального восприятия отрезков стандартного отклонения)

Запускаем первые 10:

Продолжаем до 20:

Видим, что средние меняются незначительно. Подросло отклонение на маскировке и псевдонимах, но это за счёт отдельных пиков, где gpt решил был более критичным, чем обычно, или наоборот расслабился. В целом, определённая тенденция появилась, можно сэкономить, что осталось на api-ключе.

Недостатки и ограничения текущего подхода

1. Диалог состоит из пары вопрос-ответ, а не полноценной беседы до решения вопроса агентом или передачи оператору
2. Персональные данные не используются приложением для дальнейшего реального решения задачи пользователя
3. Запросы синтетические и могут явно превышать количество данных, предоставляемых за раз в реальных сценариях
4. Выбранный тип псевдонимизации данных сохраняет для LLM условный контекст: был тут person или address.
5. Для маски использовалась только буква “X”, а не какая-либо другая или спецсимволы. Поэтому влияние выбора символа на результат неизвестно.

Для работы над пунктом (1) выше DeepEval предоставляет оценку multi-turn проходов с помощьюConversationalTestCaseчерез заданиеscenarioиexpected_outcome, что подаёт для дальнейших исследований идею взять более объёмные реалистичные диалоги и попробовать проанализировать их в различных вариантах деперсонализации.

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