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