Presidio и LiteLLM прячут ПДн от внешней LLM: тест трёх конфигураций на 20 текстах

Знакомая ситуация: в компании хотят прогнать через GPT или Claude обращения клиентов, а в них фамилии, телефоны, почта и адреса. Юристы морщатся, безопасники просят «что-нибудь сделать». Самое простое решение — не отправлять ПДн вообще: заменить их метками, дождаться ответа и подставить значения обратно. Именно эту схему на Хабре разобрали на базе Presidio и LiteLLM.

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

Как это работает на простом примере

Presidio — open-source библиотека Microsoft для поиска и обезличивания персональных данных. Она состоит из двух частей. Analyzer находит в тексте сущности: имена, телефоны, e-mail, номера карт. Anonymizer заменяет найденное по выбранному правилу: удаляет, маскирует или подставляет метку.

Представьте запрос: «Иван Петров просит перезвонить по номеру +7 900 123-45-67». В модель уходит «<PERSON_1> просит перезвонить по номеру <PHONE_1>». Модель отвечает, используя те же метки, а прокси подставляет настоящие значения обратно. Внешний провайдер реальных данных не видит, а пользователь получает связный ответ.

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

Где начинаются сложности с русским

Из коробки Presidio заточена под английский. Для русского нужно подключить подходящую языковую модель, например из spaCy, и проверить, что она вообще находит имена в падежах. «Ивану Петрову», «у Ивана Петрова» и «Петрова И. А.» для модели разные задачи.

Дальше нужны собственные правила. Presidio позволяет добавлять свои распознаватели на регулярных выражениях, контекстных словах и списках. Для российских реалий это номера договоров, ИНН, СНИЛС, внутренние идентификаторы клиентов. Готового распознавателя под такие данные, скорее всего, нет, и писать его придётся самим. Автор отдельно разбирает эту настройку.

Что показал тест

Автор сравнил три конфигурации на 20 вымышленных текстах. Подробные цифры в анонсе не приводятся, но один вывод назван прямо: в некоторых случаях часть адреса остаётся открытой.

Причина типична для адресов. Это составная сущность из города, улицы, дома и квартиры. Модель уверенно помечает город или регион, а улицу с номером дома пропускает или режет посередине. Для утечки хватает и фрагмента: «ул. Лесная, 12» в сочетании с другими данными уже указывает на человека.

Что делать на практике

• Не считайте маскирование «включил и забыл». Соберите собственный тестовый набор русских текстов с типичными для вас данными и измеряйте долю пропусков до запуска в продакшен.

• Адреса, номера документов и внутренние идентификаторы закрывайте отдельными правилами. Стандартной NER-модели для них мало.

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

• Храните соответствие меток и значений только на стороне прокси и только на время запроса.

Ограничения

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

Итог такой: связка Presidio и LiteLLM — рабочий и недорогой способ снизить риск при использовании внешних LLM. Но гарантией она не служит, пока вы не проверили её на своих данных и не закрыли дыры вроде частично открытых адресов. Для команд, которые уже ходят в облачные модели с клиентскими текстами, это стоит прочитать в оригинале и повторить на собственном наборе.