Как приручить LLM-дракона. Архитектура корпоративного AI-шлюза и ограничения классических прокси в работе с нейросетями

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

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

Часть 1. Архитектура корпоративного AI-шлюза и почему классические прокси не справляются с генеративным ИИ

Потребность в едином AI-шлюзе возникла не на пустом месте: в большинстве компаний внедрение генеративного ИИ начиналось стихийно и децентрализованно. Прямые запросы к нейросетям в обход общего контура лишают компанию контроля, нельзя посчитать расходы на сервисы и понять, куда уходят данные. Это создает комплекс системных рисков:

• Теневой ИИ. Разработка, клиентская поддержка и аналитика используют собственные API-ключи. Расходы выпадают из общего финансового учета, а передаваемый трафик не попадает под контроль систем информационной безопасности.

• Утечки в промптах. Исходный код, тексты договоров и персональные данные отправляются во внешние нейросети без обезличивания, предварительной проверки и фиксации самого факта передачи.

• Бесконтрольные ИИ-агенты. Автономные агенты подвержены зацикливанию. Без установленных лимитов поток лавину вызовов невозможно остановить в реальном времени, что приводит к неконтролируемым затратам, которые обнаруживаются постфактум.

• Отсутствие журнала аудита. В инфраструктуре нет централизованного хранилища логов. Служба безопасности или аудиторы не могут получить верифицируемую историю.

Естественная первая реакция команды на появление неконтролируемого сетевого трафика — закрыть прямой доступ наружу и пропустить вызовы моделей через уже существующий в компании прикладной проксирующий периметр (L7). В корпоративной инфраструктуре этот слой обычно уже развернут и построен на базе Nginx / Angie, Envoy или Kong. 

Однако, при попытке перевести трафик языковых моделей на стандартные обратные прокси, инженеры сталкиваются с тем, что классические HTTP/REST-балансировщики не рассчитаны на специфику генеративного ИИ:

• Контроль потоковой передачи (SSE) в рамках требований 152-ФЗ. В отличие от стандартных REST API, ответы языковых моделей передаются в виде непрерывного потока Server-Sent Events (SSE). Классический веб-сервер не анализирует семантику токенов «на лету»: он не поддерживает маскирование паспортных данных, СНИЛС или номеров счетов непосредственно в стриме, когда сущности разбиты на несколько чанков. Если модель начинает отдавать конфиденциальные сведения (например, извлеченные через RAG), стандартный прокси не сможет перехватить и штатно прервать SSE-сессию на прикладном уровне с фиксацией инцидента безопасности.

• Гибридный контур и маршрутизация по категориям данных. Типовая архитектура крупной российской компании — это гибрид: локальный инференс (стек на vLLM или тестовые среды на Ollama с открытыми весами Qwen и DeepSeek) на дефицитных графических ускорителях плюс внешние коммерческие API (GigaChat, YandexGPT) для некритичных задач. Стандартный балансировщик маршрутизирует трафик по сетевым путям или круговому алгоритму, но не способен анализировать полезную нагрузку: он не умеет классифицировать данные внутри промпта, чтобы гарантированно направить закрытый исходный код или чувствительный контекст на локальный GPU-кластер, а безопасный общий запрос — во внешнее облако, исключая человеческий фактор при выборе эндпойнта.

• Неэффективность классического ограничения частоты запросов и риск деградации GPU-очередей. Ограничение частоты запросов (RPS) на стандартных балансировщиках бессильно перед агентскими сценариями: единичный вызов с фактическим объемом контекста в 64 000 токенов нагружает видеопамять ускорителя сильнее, чем сотня коротких обращений.

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

• Игнорирование архитектуры контекста (кэширование и протоколы агентов). Стандартный сетевой шлюз не оптимизирует структуру передаваемых данных: он не упорядочивает системные инструкции для стабильного попадания в кэш контекста, что ведет к повторной оплате одних и тех же фрагментов текста. Кроме того, он не контролирует вызовы внешних инструментов и открытый протокол MCP, через которые автономные агенты получают доступ во внутреннюю сеть.

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

• бэкенд-сервисы и кастомный код приложений;

• внешние клиенты разработки и редакторы;

• интерактивный веб-интерфейс;

• автономные агенты и скрипты аналитики.

Базовая задержка обработки сетевого ядра AI-шлюза на сквозном пробросе трафика укладывается в десятки миллисекунд. При включении политик инспекции полезной нагрузки тайминги прозрачно разделяются по двум фазам:

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

• Исходящие потоки ответов: для выявления чувствительных данных в генерируемом тексте применяется адаптивный скользящий микробуфер. Он удерживает минимально необходимое окно контекста, исключая пропуск сущностей, разорванных межтокеновыми границами (например, разбиение номера карты на 3–4 чанка). Это добавляет прогнозируемую дельту к задержке первого видимого токена, но не деградирует скорость и плавность последующего стриминга.

Для контроля задержек и прозрачности выполнения запросов в платформе предусмотрены инструменты профилирования и сквозной трассировки. В консоли доступна детальная декомпозиция времени обработки каждого обращения:

• время выполнения проверок в контуре безопасности (маскирование персональных данных, проверка политик и фильтрация контента);

• сетевая задержка и чистая длительность генерации на стороне поставщика модели;

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

AI-шлюз совместим с контрактом OpenAI API (/v1/chat/completions и /v1/models), поэтому интеграция существующих пайплайнов сводится к смене base_url и ключа аутентификации без правок в кодовой базе.

Сетевая совместимость решает задачу быстрого переключения, но основная сложность эксплуатации лежит в плоскости затрат и регуляторных требований. В следующих статьях цикла подробно разберем, сколько корпорации в реальности тратят на ИИ, как отслеживать целевые потоки данных, а также как настроить гардрейлы и потоковую защиту персональных данных в строгом соответствии со 152-ФЗ.