В прошлый раз я рассказывал, как работает Guardrails Filter: зачем вообще понадобился отдельный слой защиты данных при работе с LLM и какие задачи он решает.

В этот раз хочу обсудить то, какие подводные камни могут оказаться под капотом этой технологии. Пока мы делали свой Guardrails Filter, быстро выяснилось, что найти персональные данные — далеко не самая сложная часть задачи. Гораздо сложнее оказалось встроиться между приложением и моделью так, чтобы ничего не сломать.

Как это сделать? Сейчас расскажу.

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

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

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

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