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

Cloud.ru выложил в открытый доступ Guardrails Filter — прокси, который перехватывает запросы к языковым моделям, скрывает чувствительные фрагменты и подставляет их обратно в ответах. Это не про магию и не про «умный» анализ ради галочки, а про практичную защиту данных там, где люди и ИИ постоянно обмениваются текстом.

Какую проблему решаем

Основная беда проста: пользователи тащат в языковые модели слишком много лишнего. В запросы попадают имена, адреса, номера телефонов, ИНН, реквизиты, API-ключи и даже медицинские данные. Если такой текст уходит во внешний сервис без фильтра, компания теряет контроль над тем, где и как он дальше хранится.

Guardrails Filter закрывает именно этот разрыв между удобством и безопасностью. Он подходит там, где важны защита переписки, контроль метаданных и снижение риска случайной утечки из рабочих сценариев с ИИ.

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

Что подготовить

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

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

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

Пошаговые действия

один. Определите, что именно надо скрывать

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

два. Поставьте фильтр перед запросами к модели

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

три. Включите восстановление данных в ответах

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

четыре. Настройте журналирование и наблюдаемость

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

пять. Проверьте сценарий до включения защиты

У Guardrails Filter есть тестовый режим Ghost Mode: он детектирует чувствительные данные, но не маскирует их. Это помогает понять, как часто срабатывают правила, и не ломает ли фильтр рабочие процессы на старте.

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

Как проверить себя

После запуска сделайте несколько безопасных тестовых запросов с заведомо чувствительными вставками: номером телефона, email, API-ключом, номером счета. Если фильтр работает правильно, он покажет срабатывание в консоли, а на выходе приложение получит корректный ответ без «дыр» в тексте.

Затем проверьте, не ломаются ли tool-call, потоковая генерация и обычные рабочие сценарии сотрудников. Если модель отвечает кусками, важно убедиться, что восстановление данных не сбивается на середине ответа.

Для удаленных команд и фрилансеров такой слой можно рассматривать как часть базовой гигиены. В связке с шлюзом для защищённой передачи трафика он закрывает не все риски, но заметно снижает шанс, что кто-то случайно отправит наружу лишнее.

Что делать, если не получилось

Если фильтр начал слишком агрессивно резать текст, сначала проверьте правила распознавания. Часто проблема не в самой идее, а в слишком широких шаблонах или в том, что бизнес-термины совпали с шаблоном для персональных данных.

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

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

Чек-лист

  • Определил, какие данные нельзя отправлять в языковые модели без маскировки
  • Понял, где в контуре поставить прозрачный прокси
  • Проверил, какие типы данных фильтр должен скрывать и восстанавливать
  • Включил тестовый режим перед полноценным запуском
  • Настроил журналирование и просмотр срабатываний
  • Проверил потоковые ответы и tool-call на тестовых сценариях
  • Договорился, кто отвечает за правила, доступ к логам и шифрование временных данных
  • Напомнил сотрудникам: в ИИ нельзя бездумно тащить персональные и служебные данные
Поделиться: