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

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

Почему обычный прокси не справляется с LLM

Прокси и балансировщики проектировались под HTTP-запросы, где важны маршрутизация, шифрование и пропускная способность. Смысл содержимого их не интересует. С LLM всё иначе: один запрос — это длинный текстовый контекст, а ответ — сгенерированный текст, который может содержать как безобидный пересказ, так и выдержки из внутренних документов.

  • Нет анализа содержимого. Прокси не отличает публичный вопрос от промпта с вставленным фрагментом договора или клиентской базы.
  • Нет учёта токенов. Стоимость запроса зависит от длины контекста и ответа, а не от числа обращений. Без подсчёта токенов расходы становятся непредсказуемыми.
  • Нет контроля ответов. Утечка может произойти не на входе, а в сгенерированном ответе, который прокси просто пропустит.
  • Нет привязки к пользователю и задаче. Непонятно, кто, каким инструментом и в каком объёме расходует бюджет.

Итог: политики безопасности формально есть, а фактического контроля над тем, какие данные покидают периметр, нет.

Что должен уметь AI-шлюз

AI-шлюз — это слой между сотрудниками и внешними моделями, который берёт на себя функции, недоступные прокси. Его задача не «запретить», а сделать использование LLM управляемым: видимым, безопасным и предсказуемым по затратам.

  • Инспекция промптов. Проверка входящих запросов на наличие персональных данных, секретов, внутренних идентификаторов. Правила могут быть как жёсткими (блокировка), так и мягкими (маскирование).
  • Фильтрация ответов. Анализ сгенерированного текста на утечки и нежелательный контент перед выдачей пользователю.
  • Учёт токенов. Подсчёт расхода по пользователю, команде и инструменту, лимиты и оповещения при приближении к порогу.
  • Маршрутизация моделей. Возможность направлять разные задачи в разные модели с учётом стоимости, скорости и требований к данным.
  • Логирование и аудит. Хранение истории запросов и решений шлюза для разбора инцидентов и улучшения правил.

Важно, чтобы шлюз не превращался в узкое место: задержки должны оставаться приемлемыми, а ложные срабатывания — редкими. Иначе сотрудники начнут искать обходные пути, и контроль снова станет формальным.

Как выглядит архитектура на практике

Типовая схема включает несколько уровней. Сначала аутентификация и привязка запроса к сотруднику или сервису. Затем предобработка: нормализация промпта, проверка по правилам, при необходимости маскирование чувствительных фрагментов. Далее — выбор модели и отправка запроса. После получения ответа — постобработка: фильтрация, подсчёт токенов, запись в журнал. И только затем ответ возвращается пользователю.

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

Ещё один элемент — интеграция с корпоративными системами: каталогом пользователей, биллингом, SIEM. Без этого учёт токенов и разбор инцидентов останутся ручными.

Шаги внедрения и типичные ошибки

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

  • Шаг 1. Собрать список инструментов и сценариев, включая «теневые» подписки.
  • Шаг 2. Определить категории данных, которые нельзя отправлять в модели, и описать правила.
  • Шаг 3. Запустить пилот с логированием и учётом токенов без жёстких блокировок.
  • Шаг 4. Настроить лимиты и оповещения по итогам пилота.
  • Шаг 5. Ввести регулярный пересмотр правил и разбор инцидентов.

Типичные ошибки: пытаться решить задачу только запретами, из-за чего растёт теневой трафик; включать фильтрацию без настройки ложных срабатываний; считать токены только суммарно, без разбивки по командам; внедрять шлюз без обучения сотрудников, которые не понимают, почему запрос заблокирован. Пример из практики: команда блокирует промпты с длинными вставками, и сотрудники начинают дробить документы на части, обходя проверку. Лечится не ужесточением, а понятными правилами и маскированием вместо запрета.

AI-шлюз — не серебряная пуля, а инфраструктурный элемент. Он не отменяет политик и обучения, но даёт то, чего не может прокси: видимость того, что происходит с данными и бюджетом при работе с нейросетями.