OpenAI Guardrails — безопасность или лишь её иллюзия?

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

В экосистеме OpenAI guardrails появились в 2025 году. На сегодняшний день они доступны как в Agent Builder, так и в виде Python SDK — openai-guardrails.

С ростом таких возможностей возрастают и риски.

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

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

Идея guardrails как раз и заключается в снижении подобных рисков. Архитектурно это реализуется следующим образом: до и после вызова основной LLM в цепочку добавляются дополнительные проверки, которые валидируют данные на входе (например, обнаруживают и анонимизируют персональные данные пользователя) и данные на выходе модели (например, проверяют, что ответ не содержит информации, не предназначенной для распространения).

Очевидным следствием такого подхода является увеличение времени отклика системы за счет дополнительных вызовов моделей и проверок. Однако на практике компромисс между небольшой задержкой и повышением уровня безопасности выглядит вполне оправданным.

Возникает ключевой вопрос: действительно ли guardrails обеспечивают заявленный уровень безопасности?

Согласно документации, “из коробки” платформа OpenAI поддерживает следующие типы guardrails:

• Moderation — модерация контента с использованием API модерации OpenAI

• URL Filter — фильтрация URL-адресов и работа с белыми и черными списками доменов

• Contains PII — обнаружение персональных данных (PII, Personally Identifiable Information)

• Hallucination Detection — обнаружение галлюцинаций (выдуманного контента) с использованием векторных хранилищ

• Jailbreak — выявление попыток обхода ограничений модели

• NSFW Text — обнаружение контента, неприемлемого для рабочего контекста

• Off Topic Prompts — контроль отклонения запросов от заданной бизнес-тематики

• Custom Prompt Check — пользовательские проверки и guardrails на основе LLM

Чтобы проверить, насколько эти механизмы действительно работают на практике, я построила в Agent Builder простую RAG-систему для ответов на вопросы пользователя по книге «451 градус по Фаренгейту» и провела серию тестов с различными типами запросов.

В схеме агента были добавлены два компонента guardrails:

• Guardrails до RAG — компонент, обрабатывающий пользовательский ввод. Он проверяет запрос на наличие персональных данных (PII) и попыток обхода ограничений модели (jailbreak) до обращения к retrieval-части системы.

• Guardrails после RAG — компонент, обрабатывающий сгенерированный ответ модели. Он проверяет, соответствует ли ответ данным, извлеченным из источника, и не содержит ли информации, выходящей за рамки полученного контекста.

Результаты эксперимента

Полный список тестовых вопросов, а также ответы системы и сработавшие guardrails доступен по ссылке (всего было задано 130 различных запросов).

В ходе тестирования были выявлены несколько устойчивых проблем в работе guardrails.

1. Детектор PERSON воспринимает имена персонажей как PII и искажает запросы к RAG

Текущий фильтр “на имена” срабатывает на любые сущности типа PERSON — в том числе на имена литературных персонажей (Montag, Clarisse и т.д.). В результате маскировка начинает “ломать” семантику запроса: модель либо теряет часть вопроса, либо подменяет важные слова на <PERSON> и ухудшает каТеги: ИИ, безопасность, guardrailsчество retrieval.

Наблюдаемый эффект (по логам маскировки):

• маскировка может заменять не только ФИО пользователя, но и слова рядом, превращая корректный вопрос в “обрезок”.

Статистика (по ответам системы):

• В блоке “обычных” вопросов по книге (ID 13–48, всего 36 запросов), где пользователь не передает свои персональные данные, PII-гардрейл всё равно срабатывал 10 раз и почти всегда из-за Detected: PERSON (иногда вместе с DATE_TIME).
  → это примерно 28% “ложных PII-срабатываний” в чистом домене книги.

Вывод: “PERSON ⇒ PII” работает слишком “в лоб” и не подходит для домена, где персоналии (персонажи книги, авторы, исторические фигуры) — часть нормального запроса.

2. Русские ФИО распознаются нестабильно

На запросах с русскими ФИО без паспортов (ID 111–120, 10 запросов) детектор PII срабатывал не всегда.

Статистика (по ответам системы):

• В группе 111–120 PII-детектор нашёл PERSON только в 6 из 10 случаев (60%).

• В 4 из 10 случаев ФИО прошло без триггера PII (система просто ответила по содержанию вопроса).

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

3. Паспортные данные распознаются, но неверно типируются (PHONE_NUMBER / DATE_TIME)

Для паспортов видно два класса проблем:
(а) неправильный тип сущности - паспорт трактуется как телефон/дата (отдельно типа номер паспотра не предусмотрено),
(б) иногда — сопутствующие “шумы” (например, внезапный Jailbreak).

РФ-паспорта (ID 66–80 и 121–130, всего 25 запросов)

Статистика по типам детекта (из ответов системы):

• DATE_TIME встречается в 21/25 случаев (84%) — то есть паспортные номера часто классифицируются как “дата/время”.

• PHONE_NUMBER встречается в 13/25 случаев (52%) — паспорт нередко интерпретируется как “телефон”.

Иногда в таких запросах всплывает Jailbreak, хотя в тексте нет попытки обхода (например, ID 66, 71).

Примеры искажения запросов при маскировке:

Итого можно сказать, что сама по себе идея guardrails — своевременная и концептуально правильная: она отвечает реальным рискам использования LLM, агентных и RAG-систем в продакшене.

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

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