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

При масштабировании использования LLM на всю компанию возникают системные проблемы. Первая — утечка данных: в запросы легко попадают персональные данные, коммерческая тайна и внутренние документы, что при отправке в облачные модели вызывает вопросы трансграничной передачи и соответствия законодательству. Вторая — неконтролируемое поведение модели: она может генерировать токсичный контент, запрещённые инструкции или медицинские советы, создавая репутационные риски. Третья — prompt injection, особенно в агентских системах, когда злоумышленник может спрятать в PDF или письме инструкцию, заставляющую модель игнорировать системный промпт или раскрыть данные. Четвёртая — отсутствие единой точки управления: когда каждая команда ходит в модели напрямую, невозможно ответить на базовые вопросы о том, кто отправил запрос, какие политики сработали и сколько токенов потрачено. Эти проблемы порождают отдельный класс решений — LLM Guardrails, AI Firewall, LLM Gateway, идея которых заключается в создании управляемого слоя безопасности между корпоративными пользователями и моделями.

StarGuard AI работает как reverse proxy для LLM: пользователь, OpenWebUI, IDE, агент или внутреннее приложение отправляет запрос не напрямую провайдеру модели, а в корпоративный endpoint шлюза, который проверяет запрос, применяет политики и проксирует его дальше в нужную модель. Разработчики сознательно выбрали reverse proxy, а не DPI или системный forward proxy, поскольку перехват TLS и настройка прокси на клиентских устройствах превращаются в отдельный инфраструктурный проект с сертификатами, исключениями и долгими согласованиями. Reverse proxy проще встроить в существующий процесс: команда получает корпоративный URL и прописывает его в своём инструменте как LLM endpoint. Сейчас StarGuard AI ориентируется на модели и провайдеров с OpenAI-compatible Chat Completions API, что позволяет через один шлюз подключать как облачные LLM, так и локальные inference-сервисы.

Архитектура продукта включает несколько основных сущностей. Портал администратора, где настраиваются шлюзы, модели, политики, детекторы, пользователи, группы, лимиты и события — это рабочее место администратора информационной безопасности или платформенной команды. Шлюз — runtime-компонент, через который проходит LLM-трафик, способный проксировать несколько моделей, при этом платформа может управлять несколькими шлюзами. Модель — логическое подключение к конкретной LLM или провайдеру, где можно переопределять политики: например, для локальной модели разрешить передачу чувствительных данных, а для облачной включить маскирование. Аутентификация строится через OpenID Connect с интеграцией с Keycloak, ADFS или другим identity provider, а доступ к моделям и политикам назначается на пользователя или группу. Детекторы — проверки, через которые проходит входящий запрос и исходящий ответ модели, а портал пользователя позволяет видеть доступные модели, лимиты, фактическое потребление и API-токен для подключения внешнего клиента.

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

На рынке существуют зарубежные аналоги, такие как Guardrails AI или NVIDIA NeMo Guardrails, но российские разработчики делают акцент на адаптации к локальным требованиям и поддержке отечественных моделей, включая GigaChat и YandexGPT. В отличие от системного forward proxy, reverse proxy-подход StarGuard AI упрощает внедрение и снижает операционные риски, связанные с настройкой клиентских устройств. Однако остаются открытые вопросы, связанные с производительностью при высоких нагрузках, совместимостью с различными API и глубиной детекции угроз. Дальнейшее развитие продукта, вероятно, будет включать расширение списка поддерживаемых моделей, улучшение алгоритмов маскирования данных и интеграцию с системами управления инцидентами информационной безопасности, что позволит компаниям более уверенно масштабировать использование языковых моделей в своих бизнес-процессах.