Корпоративные LLM без защитного шлюза: четыре уязвимости, которые ведут к утечкам и штрафам

Никита Векессер, специалист по продуктам в области ИИ-инфраструктуры, описал архитектуру защитного шлюза StarGuard AI и системные проблемы, которые возникают при массовом корпоративном использовании LLM. Материал ценен не столько продуктом, сколько разбором конкретных болей: какие данные утекают, где модель выходит из-под контроля и почему «каждая команда ходит в модели напрямую» превращается в неуправляемый хаос. Ниже я адаптировал этот разбор в пошаговый план, который можно применить к любому шлюзу или даже собрать минимальную защиту вручную.

Четыре боли, которые ломают корпоративные LLM без контроля

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

• Утечка данных. В запросы попадают ФИО, паспортные данные, ИНН, СНИЛС, тексты договоров и коммерческая тайна. Если запрос уходит в облачную модель за рубеж, возникают прямые вопросы по 152-ФЗ и трансграничной передаче.
• Неконтролируемое поведение модели. LLM может выдать токсичный контент, медицинские советы или политические высказывания. Для внутреннего помощника это неприятность, для внешнего чат-бота поддержки это репутационный удар.
• Инъекция в промпт (prompt injection, когда злоумышленник прячет скрытую команду для модели внутри обычного документа). В агентных системах (где ИИ-агент сам читает файлы, письма, PDF) атакующий может заставить модель проигнорировать системный промпт (system prompt, базовая инструкция, заданная разработчиком), раскрыть данные или вызвать опасный инструмент.
• Отсутствие единой точки управления. Невозможно ответить, кто отправил запрос, в какую модель, сколько токенов (единиц текста, за которые платит компания) потрачено и почему ответ был заблокирован.

Именно из этих болей родился отдельный класс решений: LLM-шлюзы, они же AI Firewall или LLM Gateway. Названия разные, суть одна: между пользователями и моделями появляется управляемый слой проверки.

Что понадобится

• Любая LLM с OpenAI-совместимым API (GigaChat, YandexGPT, DeepSeek, Claude, OpenAI или локальная модель на собственном сервере).
• Шлюз безопасности. StarGuard AI, описанный в источнике, работает как обратный прокси (reverse proxy, посредник, через который проходит весь трафик к модели). Альтернативы с похожей архитектурой существуют и в опенсорсе.
• Провайдер аутентификации (Keycloak, ADFS или другой сервис, поддерживающий OpenID Connect), чтобы каждый запрос был привязан к конкретному сотруднику.
• 30 минут на базовую настройку шлюза и подключение первой модели. Полная настройка детекторов и политик потребует от нескольких часов до пары дней.

Пошаговая инструкция

1. Разверните шлюз как единую точку входа. Все инструменты (IDE, чат-интерфейс OpenWebUI, внутренние приложения, ИИ-агенты) должны отправлять запросы не напрямую провайдеру модели, а на корпоративный URL шлюза. Команда просто прописывает новый адрес вместо прямого endpoint.

2. Подключите аутентификацию через OpenID Connect. Это привяжет каждый запрос к конкретному пользователю или группе. Без этого шага аудит бесполезен: вы видите трафик, но не знаете, кто его создал.

3. Настройте детекторы для входящих запросов. Минимальный набор:

4. Детектор чувствительных данных (ФИО, ИНН, СНИЛС, паспортные данные, номера договоров).
5. Детектор языка: он сам по себе не блокирует, но даёт сигнал следующим проверкам, потому что русский и английский текст обрабатываются по-разному.

6. Детектор промпт-инъекций: проверяет, нет ли в тексте скрытых команд для модели.

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

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

9. Включите журналирование событий. Каждое событие должно сохранять: применённые политики, вердикты детекторов, количество токенов, пользователя, модель и причину блокировки, если она была.

10. Назначьте лимиты по пользователям и группам. Это решает и финансовый вопрос (сколько токенов потрачено отделом за месяц), и вопрос безопасности (аномальный всплеск запросов может означать компрометацию учётной записи).

Что делать с этим прямо сейчас, по ролям

Автору на Дзене. Если вы используете ChatGPT или Claude для подготовки текстов и загружаете туда черновики с именами экспертов, адресами, цитатами из договоров, осознайте: эти данные уходят на серверы за пределами РФ. Минимальный шаг: перед отправкой вручную убирайте ФИО и реквизиты. Идеальный: используйте локальную модель или сервис с российскими серверами (GigaChat, YandexGPT).

Маркетологу. Корпоративные LLM без шлюза это не только риск утечки, но и невозможность показать руководству, сколько компания тратит на ИИ и какой отдел генерирует основной объём запросов. Журнал шлюза даёт аргументы для бюджетирования.

Предпринимателю в РФ. Если ваши сотрудники уже пользуются LLM (а они пользуются, даже если вы об этом не знаете), 152-ФЗ делает вас ответственным за каждый запрос с персональными данными. Единая точка управления это не перфекционизм, а базовая гигиена, аналог антивируса в 2005-м.

Кто не выстроит управляемый слой между сотрудниками и моделями сегодня, завтра будет объяснять регулятору, почему ИНН клиентов оказались в логах зарубежного провайдера, и аргумент «мы не знали» в 2025 году уже не работает.