Пару дней назад Cloud.ru выложил исходный код Guardrails Filter в открытый доступ. Это прозрачный обратный прокси между клиентом и LLM-провайдерами, он убирает чувствительные данные из запросов к модели и восстанавливает их в ответах. Я один из разработчиков этого инструмента и хотел бы рассказать подробнее, зачем вам вообще может быть нужно опенсорс-решение, как его можно внедрить в свою инфраструктуру, ну и ответить на вопрос: зачем облаку бесплатно делиться своими наработками с рынком?

Начнем с того, что кейсов утечки персональных данных через языковые модели более чем достаточно. Пользователи каждый день, не раздумывая, пихают в популярные LLM логи чатов, саммари созвонов, данные анализов, истории болезней, тексты договоров и что только не. А там имена, адреса, номера телефонов, ИНН, иногда даже паспортные данные, реквизиты счетов и API-ключи. Чем это грозит, я подробно писал вот в этой статье. Можно, конечно, сколько угодно образовывать пользователей и уповать на то, что они вычистят чувствительную инфу из своих запросов, но надеяться на авось — это не инженерный подход.

Изначально мы создавали Guardrails Filter как часть нашей собственной платформы, потому что для клиентов такая проблема тоже была актуальна. Всем им хотелось уверенности в том, что данные при обращении через наши Evolution Foundation Models к внешним LLM не осядут где-то за границей и не будут использованы для атак. А таким суровым ребятам как банки, страховщики и e-comm даже этого было недостаточно: нужно было, чтобы данные не уходили даже в свое, родное дружественное публичное облако и оставались внутри контура компании.

Тогда мы решили улучшить наши внутренние наработки и поделиться решением и с клиентами, и вообще со всеми.

Создание базового механизма детекции и маскировки чувствительных данных с их последующим восстановлением с точки зрения сложности инженерной задачи не так уж тяжело. Берем регулярные выражения — то есть шаблоны, которые ищут в тексте похожие на email, номер карты, ИНН или пароль строки; добавляем к ним простые проверки типа «а сходится ли контрольная цифра» (это отсекает случайные совпадения) и на каждое найденное значение заводим временную замену-заглушку вроде <EMAIL_1>, по которой идет восстановление исходных значений. Пока идет обработка одного запроса, где какая заглушка на что заменена, храним прямо в памяти программы.

Это не рокет-сайенс и брать за такое деньги с пользователей было бы как-то даже неловко.

Как работает Guardrails Filter

Настоящая сложность появляется не в самом поиске, а в мелочах вокруг. Ведь одной из основных задач является мутация request-response. Одно дело спарсить из запроса какой-то контекст, а другое — не сломать структуру взаимодействия LLM-модели с ИИ-приложениями. Навскидку — при обработке tool-call тоже могут возникать чувствительные данные, например, когда модель хочет прочитать переменные окружения (выполнить cat .env).

Еще одна нетривиальная задача — сделать процесс маскировки очень быстрым и не тормозить каждый запрос. Мы решаем это тем, что вы сами можете выбирать, в каком «быстром» источнике хранить оригинальные значения для демаскировки: прямо в оперативной памяти, в Redis или PostgreSQL. На этом моменте у кого-то может подняться бровь: «То есть чувствительная информация все-таки где-то хранится как обычный текст?». Спокойствие, только спокойствие. У нас предусмотрены встроенные механизмы шифрования, которыми может управлять администратор.

И даже если вы сами решили две предыдущие задачи со звездочкой, на десерт остается самое неприятное: научиться правильно подставлять обратно настоящие данные, даже когда ответ модели приходит не целиком, а маленькими кусочками одновременно с тем, как он генерируется (стриминг)…

Мы подумали, раз уж мы все равно хотим причинить добро клиентам, которые пользуются нашей платформой, но не хотят к ней привязываться, то почему бы не распространить свою щедрость на всех?

Сейчас на наших ресурсах в GitHub и GitVerse опубликовано две версии прокси-сервиса.

Первая — standalone service, чтобы просто поднять одной командой и пользоваться. Это один Go-бинарь, три порта (data-plane, config API с веб-консолью и метрики Prometheus), который сразу работает как полноценный прокси — достаточно поднять упакованный docker-образ и указать GUARDRAILS_UPSTREAM_BASE_URL. Он может выступать в качестве шлюза для работы с LLM-моделями от любых поставщиков, можете сами решить, заворачивать туда весь трафик или только от отдельных приложений.

Вторая — для продвинутых сетевых администраторов. Она рассчитана на инфраструктуру, где уже есть Envoy как единая точка прохождения трафика: вместо того, чтобы переключать base URL в каждом приложении по отдельности, администратор один раз подключает ext_proc-сайдкар к Envoy, и та же логика детекции и маскирования начинает применяться централизованно ко всем запросам, которые проходят через guardrails-llm-filter-extproc.

В системе предусмотрено журналирование событий безопасности и тестовый режим Ghost Mode, который позволяет проверить работу сервиса еще до включения защиты. То есть опционально можно выключить механизм маскирования, но оставить детекцию, чтобы посмотреть, как работает Guardrails Filter.

Интерфейс веб-консоли

Помимо WebUI в инструмент встроен адаптер для Prometheus и есть демонстрационные дашборды для Grafana, чтобы наши алерты встраивались в ваш контур максимально нативно.

Мы проверили инструмент на трех независимых PII-датасетах, средние результаты:

• Precision (точность срабатывания) стабильно 92–99.9% на всех датасетах.

• Per-type recall (защита от утечки) варьируется в пределах 75-87%. Такой разброс обусловлен тем, что четкие форматы вроде ИНН, телефона или email распознаются почти всегда, потому что у них строгий шаблон и проверяемая контрольная цифра; а вот имена и адреса ловятся хуже, потому что они пишутся очень по-разному, и словарь не покрывает все варианты — где разметка датасета полнее и данные чище, там и цифры выше.

• F1-score варьируется от 82% до 93%, что вытекает из того же — F1 объединяет precision и recall, а precision у нас стабильно высокий везде, поэтому именно колебания recall из-за качества разметки и типов PII в каждом датасете и тянут итоговый F1 вниз.

Подробнее читайте в наших мультибенчмарк-замерах.

Что касается сравнения с альтернативами, подробная таблица здесь. Но если коротко: наше решение — единственное среди аналогов, которое полноценно восстанавливает оригинальные данные в ответе модели, причем даже внутри потокового SSE-ответа токен-за-токеном и в аргументах вызова инструментов. У LiteLLM+Presidio, Kong AI Gateway, Portkey и NeMo Guardrails это либо работает частично, либо отсутствует вовсе.

Дополнительно мы из коробки закрываем то, чего почти нет у конкурентов — проверку российских ПДн с контрольными суммами (СНИЛС, ИНН, ОГРН) и каталог секретов и API-ключей на основе gitleaks и других баз эвристических подходов.

Да, в сущности, ни в чем. Решение уже работает под капотом Evolution Foundation Models как опция, сами пользуемся и вам советуем. Для своей внутрянки скоро планируем улучшить ядро сканирования за счет интеграции NER-модели для покрытия более сложных edge-кейсов.

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

Напоследок скажу, что мы всегда открыты для обратной связи: пишите комментарии, открывайте pull request’ы, оставляйте issuе. Не дадим треклятому ChatGPT узнать, на какой адрес мы заказываем пиццу! 😁

• Guardrails Filter (Standalone) GitHub | GitVerse

• Guardrails Filter (ExtProc) GitHub | GitVerse