Памятка «не отправляйте в нейросеть персональные данные и коммерческую тайну» работает ровно до тех пор, пока сотрудник о ней помнит. Но он может забыть, так как фокусируется на задаче: свести воедино таблицу, быстрее ответить клиенту, разобрать длинный документ. Любое правило, которое держится только на памяти, когда-нибудь будет нарушено. Скорее всего непреднамеренно: сотрудник устал или просто торопился выполнить задачу. Правильный подход заключается не в ужесточении инструкций, а в автоматизации, когда между сотрудником и моделью появляется слой автоматической проверки. Этот слой называют guardrails (гардрейлы): он читает запрос до отправки в LLM и ответ до того, как тот вернётся сотруднику. Разберём, из чего собирают guardrails, чем они отличаются от DLP, насколько на них можно опереться и какие правила доступа выстраивают вокруг них.
Что сотрудники передают в LLM, сами того не замечая
Три типичных сценария
Утечка данных может произойти непосредственно при работе с моделью или вместе с материалами, которые сотрудник использует для решения задачи. Например:
- при разборе ошибки в приложение отправляют стектрейс и фрагмент конфигурации, где может находиться API-ключ;
- для подготовки резюме переписки с клиентом загружают весь диалог, включая имя, телефон и адрес;
- при подготовке ответа на письмо в запрос попадает вся цепочка сообщений с номером договора и реквизитами.
В каждом случае конфиденциальная информация оказывается внутри запроса вместе с рабочими данными. Отдельного действия по передаче этих сведений сотрудник может не выполнять — достаточно вставить исходный текст, файл или фрагмент кода в чат с моделью.
Почему обучение не закрывает этот риск
Инструктаж меняет поведение медленно и непоследовательно. Проверка на уровне инфраструктуры срабатывает одинаково каждый раз. Это меры разного класса и одна не заменяет другую: обучение снижает число ошибок, а фильтр перехватывает те, которые всё равно случаются. Утечка через промпт — не единственный вектор. OWASP (Open Worldwide Application Security Project) — международная некоммерческая организация, которая разрабатывает открытые стандарты безопасности приложений, а её списки топ-10 рисков служат отраслевым ориентиром. В списке рисков для LLM-приложений организация держит на втором месте Sensitive Information Disclosure и относит туда персональные данные, финансовую информацию, коммерческие данные и учётные записи. Первое место занимает Prompt Injection: подмена поведения модели через сам текст запроса.
Что такое guardrails
Guardrails — программный слой, который контролирует, что уходит в модель и что возвращается из неё. Саму модель guardrails не меняют: они работают снаружи и применяют правила к тексту запроса и ответа.
Чем guardrails отличаются от DLP и AI Firewall
Эти четыре термина часто используют как синонимы, хотя разница между ними существенная. Она в том, где стоит проверка и что она способна увидеть.
| Класс решения | Где работает | Что перехватывает | Чего не закрывает |
|---|---|---|---|
| DLP | Периметр сети и агент на устройстве | Файлы, буфер обмена, исходящий трафик, обращения к запрещённым доменам | Смысл промпта, ответ модели, запросы с личного устройства |
| Guardrails | Внутри ИИ-приложения или шлюза | Текст промпта, текст ответа, смысл запроса | Любой трафик мимо этого приложения |
| AI Firewall, AI Secure Gateway | Отдельный сервис перед моделями | То же, что guardrails, плюс сетевые политики и лимиты по потребителям | Каналы, не заведённые на этот сервис |
| Корпоративный ИИ-шлюз (AI Gateway) | Единая точка доступа приложений к моделям | Аутентификацию, права, квоты, маршрутизацию, логи; guardrails встраиваются в него как проверка | Работу сотрудника в личном аккаунте |
DLP и guardrails не конкурируют, а дополняют друг друга: первый контролирует канал передачи, второй — содержание запроса. Внедрение DLP-системы закрывает выход данных за периметр, а guardrails-слой — содержание того, что уходит в модель по легальному каналу.
Из чего собирают фильтр
Guardrails в продакшене — не одна проверка, а несколько независимых, собранных в конвейер. NVIDIA NeMo Guardrails применяет проверки в заданном порядке и на каждом шаге может пропустить, изменить или отклонить сообщение. Типы проверок:
- Детерминированные. Регулярные выражения, словари, контрольные суммы. Ловят данные с предсказуемым форматом: номера карт, ИНН, СНИЛС, номера паспортов, email, телефоны, ключи API по характерным префиксам. Работают быстро и дёшево, но только внутри шаблона.
- Статистические. Распознавание именованных сущностей (NER) и классификаторы текста. Находят имена, организации, адреса и финансовые показатели там, где формат не фиксирован. Microsoft Presidio совмещает регулярные выражения, словари, проверку контрольных сумм и NER в одном движке.
- Модель-судья. Отдельная небольшая модель оценивает смысл всего запроса, а не отдельные слова. Так работают Llama Guard и Llama Prompt Guard от Meta, Azure AI Content Safety с Prompt Shields, открытый Guardrails AI. Этот уровень ловит не «текст с номером счёта», а запрос, который по смыслу пытается извлечь закрытые данные или обойти ограничение.
Готового стандарта, который предписывал бы конкретный набор и порядок проверок, нет: их подбирают под свои категории данных и требования контура.
Русский PII: чего не знают зарубежные детекторы
Готовые распознаватели Presidio рассчитаны на США, Великобританию, Германию, Индию и ещё около полутора десятков стран. Российских идентификаторов среди них нет: зарубежный детектор из коробки не найдёт ни ИНН, ни СНИЛС, ни серию и номер паспорта РФ, ни полис ОМС. Эти правила дописывают отдельно. У ИНН и СНИЛС есть контрольные суммы, поэтому детерминированная проверка для них точна и дешева.
Фильтрация на входе и на выходе
Guardrails работают в двух направлениях. Ограничиться одним — типичная ошибка.
Входной фильтр
Входная проверка читает запрос до отправки в модель. Здесь фильтр перехватывает документ с персональными данными, фрагмент кода с секретами или текст NDA. Здесь же отсекают промпт-инъекции (prompt injection).
Выходной фильтр и RAG
Выходная проверка читает готовый ответ до того, как он попадёт к сотруднику или уйдёт дальше по цепочке — например, в автоматическое письмо клиенту. Она закрывает два разных сценария:
- модель может воспроизвести чувствительные данные, которые оказались в контексте диалога раньше;
- если модель подключена к внутренней базе знаний через RAG, ответ может содержать выдержку из документа с ограниченным доступом, хотя сам запрос сотрудника выглядит безобидно.
Что делать при срабатывании
Срабатывание фильтра не обязано означать блок. Политика задаёт реакцию по категории данных и уровню риска:
- замаскировать чувствительный фрагмент перед отправкой в модель;
- пропустить запрос с пометкой для последующего аудита;
- заблокировать и показать сотруднику причину.
Обратимое и необратимое маскирование
У маскирования два режима, и разница между ними практическая. Необратимое затирание безопаснее, но ломает задачу: модель не вернёт в ответе номер договора, которого она не видела. Обратимая токенизация подставляет вместо значения токен, а в ответе восстанавливает исходное. За это приходится хранить словарь соответствий. Словарь становится отдельным объектом защиты со своим режимом доступа и сроком хранения.
Насколько надежны guardrails
Абсолютной защиты guardrails не дают, и публичные замеры позволяют оценить, насколько велик остаточный риск. Meta в карточке модели Llama Guard 4 приводит собственные измерения: при фильтрации ответов модель ловит 69% нарушений на английском языке и 43% на мультиязычных данных. Это измерения самого вендора, то есть цифры скорее в его пользу. Исследование устойчивости guardrails к обходу (препринт arXiv, принят на LLMSec 2025) показывает картину с другой стороны. Техника emoji smuggling дала 100% успешных обходов Azure Prompt Shield и Meta Prompt Guard, а простые вставки символов срабатывали в 60–73% попыток. Microsoft формулирует то же в документации Prompt Shields: сервис может пропустить часть атак или отметить легитимный запрос, поэтому нужны дополнительные уровни проверки. Отсюда единственная корректная формулировка: guardrails снижают вероятность утечки на уровне архитектуры, но не сводят её к нулю.
Правила доступа вокруг фильтра
Фильтр эффективен настолько, насколько разумны правила вокруг него. Список запрещённых паттернов — только часть системы.
Права по роли и классификации данных
Единая политика на всех не работает. Права привязывают к роли сотрудника и к классу данных:
- специалисту поддержки открыты обезличенные обращения клиентов, но не полные выгрузки из CRM;
- разработчику — технические запросы, но не юридические документы компании;
- финансовому отделу — свои показатели, но не персональные данные сотрудников.
Разные политики для разных каналов
Уровень контроля зависит от того, куда уходит запрос. Для модели в контуре компании или у провайдера с договорными гарантиями по обработке данных политика может быть мягче. Для публичного бесплатного сервиса в личном аккаунте — жёстче: там у компании нет контроля над дальнейшей судьбой данных.
Исключения, эскалации и ложные срабатывания
Часть блокировок будет ложной по существу задачи. Юрист работает с номерами договоров, кадровик с персональными данными, врач с диагнозами. Формально фильтр прав, но задачу он блокирует. Поэтому нужен процесс, а не только правило:
- явный маршрут согласования доступа к категории данных, которую фильтр блокирует по умолчанию;
- срок ответа по такой заявке;
- регулярный разбор ложных срабатываний и корректировка правил по итогам.
Если такого процесса нет, официальный канал начинает казаться слишком медленным, и сотрудник ищет обходной путь.
Проверка запросов в реальном времени
Что проверяют быстро, а что медленно
Задержка здесь имеет прямые последствия: если проверка ощутимо замедляет работу, сотрудники начинают искать способ её обойти. Детерминированные проверки укладываются в десятки миллисекунд. Модель-судья добавляет секунды. NVIDIA приводит замер на своей конфигурации: ответ без guardrails занимал 0,91 секунды, с тремя проверками — 1,44 секунды. Детект нарушений политики вырос с 75 до 98,9%. Замер сделан на GPU и на моделях-фильтрах размером 8B, на процессорную установку эти цифры не переносятся. Есть ограничение, которое касается порядка вызовов и часто упускается. Тяжёлую проверку входящего запроса нельзя выполнять параллельно с обращением к модели. Если запрос ушёл в модель одновременно с проверкой, данные уже покинули периметр, и фильтр опоздал. Параллельно считают только то, что не связано с утечкой: оценку качества ответа, детект джейлбрейка для статистики. Проверки на чувствительные данные идут синхронно, до вызова модели. Ускорить их можно каскадом: сначала дешёвые детерминированные правила на каждом запросе, затем модель-судья выборочно, только для категории повышенного риска.
Логи фильтра как новый объект защиты
Каждое срабатывание логируют: запрос, правило, время, пользователь. По логам видно, какие правила дают ложные срабатывания и какие категории данных сотрудники пытаются передать чаще всего. У подробного журналирования есть обратная сторона. Журнал промптов сам становится хранилищем персональных данных и коммерческой тайны. Ему нужен режим доступа, срок хранения и размещение по требованиям 152-ФЗ — как любой другой базе с такими данными. Инфраструктурную часть закрывает аттестованное облако для ИСПДн.
Guardrails работают только в едином канале доступа
Фильтр решает задачу, если встроен в тот канал, которым сотрудники пользуются каждый день. Если единой точки входа к моделям нет, фильтровать нечего. Часть сотрудников работает через личные аккаунты, и запрос никогда не проходит через инфраструктуру компании.
Что делать с теневым ИИ
Guardrails-слой сам по себе проблему теневого ИИ (shadow AI) не закрывает. Нужны два контура одновременно:
- Технический запрет обходных каналов. Блокировка доменов публичных сервисов, allowlist разрешённых приложений, DLP-контроль на устройствах.
- Рабочая альтернатива. Официальный канал должен быть быстрее и удобнее личного аккаунта. Иначе запрет переносит обход на личный телефон, где корпоративных средств контроля нет вообще.
За удобство единой точки доступа приходится платить архитектурным риском. Через один сервис проходят все промпты компании: это и концентрация данных, и точка отказа, которую нужно резервировать.
AIaaS от ITGLOBAL.COM
Практический путь — перевести доступ к моделям в единый корпоративный шлюз. Фильтрация, права по ролям и аудит настраиваются на уровне платформы и не зависят от того, какой инструмент выбрал конкретный сотрудник. Такую основу даёт платформа AIaaS от ITGLOBAL.COM:
- единый API к 100+ языковым моделям, российским и зарубежным;
- DLP-фильтрация промптов и ответов в реальном времени как штатный шаг обработки запроса;
- ролевая модель доступа, квоты и бюджеты по подразделениям и пользователям;
- полное логирование всех запросов для аудита;
- работа в соответствии с 152-ФЗ, обработка данных на территории РФ.
Порядок обработки запроса на платформе: аутентификация и проверка прав → фильтрация промпта → маршрутизация к нужной модели → фильтрация ответа → биллинг и запись в лог. Для контуров с повышенными требованиями есть Private AI Cloud: изолированный ИИ-контур на GPU ITGLOBAL с возможностью дообучения на данных клиента. Выбор внешнего сервиса и архитектуру защиты разбирали в статье о безопасности данных при использовании внешних AI-сервисов. Про шлюз как класс решения есть отдельный материал о преимуществах единой точки доступа к ИИ-сервисам.
Предыдущая статья
