Cloud.ru открыл исходный код фильтра данных для ИИ-моделей

20 июля 2026 года Cloud.ru опубликовал исходный код Guardrails Filter — промежуточного сервиса для защиты чувствительной информации при работе с большими языковыми моделями. Решение можно развернуть в собственном контуре и использовать с моделями разных поставщиков.

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

Где находится фильтр

Guardrails Filter размещается между корпоративным приложением и API модели. Это удобная точка контроля: интеграции не должны реализовывать собственный набор регулярных выражений и правил в каждом сервисе, а события можно собирать централизованно.

Открытая версия поддерживает стандартные и пользовательские правила. Компания может добавить форматы внутренних договоров, идентификаторы клиентов или кодовые названия проектов. Также заявлены журналирование событий безопасности и Ghost Mode — режим, в котором система выявляет совпадения, но ещё не изменяет рабочий трафик.

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

Что означают результаты теста

Cloud.ru сообщает о значении F1 93,1 и точности 99,9% на публичном наборе pii-bench. Эти цифры относятся к конкретной версии, конфигурации и тестовым данным. Они полезны как исходная точка, но не гарантируют тот же результат на документах организации.

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

• реальные обезличенные запросы пользователей;
• варианты написания персональных и платёжных данных;
• секреты в коде, таблицах и вложенных документах;
• запросы без чувствительной информации;
• пограничные значения, которые не должны блокироваться.

Измерять следует не только precision, но и полноту обнаружения. Редкие ложные срабатывания важны для удобства, однако пропущенный секрет создаёт прямой риск утечки.

Какие риски фильтр не закрывает

Маскирование защищает содержимое запроса, но оставляет другие классы угроз:

1. Приложение может передать модели лишний документ целиком.
2. Пользователь или внешний источник может внедрить вредоносную инструкцию.
3. Ответ модели способен содержать ошибочную или опасную рекомендацию.
4. Журналы самого фильтра могут стать хранилищем чувствительных данных.
5. Компрометация сервиса восстановления раскроет соответствие синтетических и исходных значений.
6. ИИ-агент с инструментами может получить секрет через последующий API-вызов.

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

Как встроить решение в корпоративную архитектуру

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

Для промышленной эксплуатации потребуются:

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

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

Практический вывод

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

При этом ценность Guardrails Filter определяется не фактом установки, а качеством правил, собственным тестовым набором и безопасностью всей цепочки. Начинать следует с инвентаризации данных и измеримого пилота, а не с обещания «все запросы теперь безопасны».

Источник: официальный блог Cloud.ru.