Как очистка персональных данных влияет на LLM-агентов: эксперимент Hivetrace Dataclean

Очистка персональных данных перед отправкой в LLM-агента обычно выглядит как очевидный шаг в сторону безопасности, но цена этого решения не всегда понятна. В материале Habr AI авторы проверили, насколько меняется работа банковского агента, если вместо реальных ФИО и других идентификаторов он получает маски или псевдонимы.

Где возникает конфликт LLM-агенты всё чаще работают с пользовательскими сценариями, где без

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

«Насколько агент деградирует, если вместо "Иванов Иван" он видит "PERSON_1" или "XXXXXXXX"?»

На практике это не академический спор, а инженерная задача. Если система перестаёт понимать, что один и тот же клиент фигурирует в нескольких местах запроса, страдает не только качество текста, но и бизнес-логика: маршрутизация кейса, сверка реквизитов, интерпретация статусов, проверка последовательности шагов. Поэтому важен не общий тезис «анонимизация полезна» или «анонимизация мешает», а измеримый ответ для конкретного класса агентов и конкретного способа очистки.

Как проверяли гипотезу Для проверки авторы подняли минималистичного банковского агента и подключили к нему

Hivetrace Dataclean. Дальше агенту отправили по 102 синтетических запроса в трёх вариантах входных данных: без изменений, с маскированием и с псевдонимами. Такой дизайн полезен тем, что убирает шум реальных пользовательских историй и даёт контролируемое сравнение. В каждом случае агент решает одну и ту же задачу, но видит разную форму идентификаторов, имён и других персональных атрибутов. Отдельно важен способ оценки. Авторы использовали DeepEval в режиме LLM-as-a-judge, то есть сравнивали не субъективные впечатления от пары ответов, а пытались формализовать качество через единый проверочный контур. Для быстрого прикладного исследования это разумный ход: он не делает выводы «абсолютной истиной», но позволяет увидеть, где деградация заметна сразу, а где агент сохраняет полезность даже после очистки чувствительных полей.

Три режима данных Суть эксперимента — не просто проверить, «работает или не работает» агент

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

• Чистые данные — базовый сценарий без искажений.
• Маска вроде XXXXXXXX — максимум приватности, минимум семантики.
• Псевдонимы вроде PERSON_1 — скрывают личность, но сохраняют связи. * 102 синтетических запроса на режим — возможность честного сравнения. Из такого теста команды обычно получают не универсальный запрет или разрешение, а карту компромиссов. Если агенту важно лишь общее намерение пользователя, жёсткая маска может оказаться приемлемой. Если же логика зависит от того, что один и тот же объект повторяется в нескольких фрагментах, псевдонимы часто выглядят более практичным вариантом. Именно поэтому подобные проверки особенно полезны перед внедрением агентов в банк, финтех, медицину и любой процесс, где ошибки на персональных данных быстро становятся дорогими.

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

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