Меня зовут Антон Чикин, я руковожу отделом интеллектуального анализа в «Инфосистемы Джет». В статье я попробую показать на практическом примере, почему корпоративный ИИ нельзя свести к установке готовой LLM — и что именно приходится выстраивать вокруг неё, чтобы получить реальную ценность для бизнеса.
Этот материал будет полезен тем, кто отвечает за внедрение ИИ в компаниях среднего и крупного масштаба: ИТ-директорам, архитекторам корпоративных систем, специалистам по информационной безопасности и тем, кто рассматривает генеративный ИИ как инструмент автоматизации бизнес-процессов.
Сегодня вокруг крупных языковых моделей (LLM) вроде ChatGPT или DeepSeek сформировалось устойчивое впечатление: «достаточно взять готовую модель и подключить её к работе». На практике же бизнес довольно быстро сталкивается с ограничениями.
1. Конфиденциальность и требования регуляторов.
Отправка внутренних документов или клиентских данных в публичное облако несовместима с корпоративными ИБ-политиками и требованиями регуляторов (например, ФСТЭК). В большинстве случаев необходима работа внутри собственного контура и под полным контролем.
2. Контекст компании.
LLM «из коробки» хорошо справляется с общими задачами, но ничего не знает о внутренней ERP-системе, базе знаний в Confluence, процессах в Jira или данных в корпоративных SQL-хранилищах. Без интеграции с этими источниками модель быстро теряет практическую ценность.
3. Инфраструктурные ограничения.
Современные модели — это десятки и сотни миллиардов параметров. Развернуть и поддерживать подобные системы локально — серьёзный вызов даже для технологических гигантов. Необходимы GPU-фермы, системы оркестрации и продуманная стратегия масштабирования под нагрузку.
4. Ассистент вместо «умного чата».
Корпоративному пользователю нужен не собеседник, а инструмент, встроенный в рабочие процессы: генерация отчётов, автоматизация поддержки, поиск информации в узкоспециализированных базах. Интерфейс должен быть привычным и интегрированным в корпоративные сервисы.
5. Управление и безопасность.
Ролевой доступ, аудит действий, мониторинг и интеграция с системами кибербезопасности — обязательные требования к любой корпоративной платформе. Без них внедрение превращается в потенциальный риск.
Таким образом, когда речь идёт о внедрении LLM в корпоративную среду, становится очевидно: «просто взять модель» и встроить её в бизнес-процессы не получится. Необходимы инструменты для интеграции, безопасности, управления и масштабирования. По сути, LLM — это лишь фундамент, на котором нужно выстраивать целый «дом» из сервисов и компонентов. Этот дом дорогой, сложный в проектировании и требует системного подхода.
Из этих вызовов и сложилась архитектура нашей платформы, которую мы разработали совместно с Yandex Cloud. Её задача — не заменить модель, а дополнить её необходимым окружением:
обеспечить локальное и безопасное развертывание;
интегрироваться с корпоративными источниками данных (от ERP до SQL-хранилищ);
упростить создание ИИ-ассистентов, которые работают именно с данными компании, а не только обучены на общедоступном интернет-контенте.
Поэтому JET & Yandex GPT Lab — это не «очередная LLM», а набор инженерных инструментов, позволяющих строить корпоративные ИИ-сервисы так же системно, как внедряются CRM, BI или системы документооборота.
Давайте пройдемся по ключевым идеям, которые заложены в основу.
1. Локальность + гибридность
Ядро платформы — это YandexGPT (включая последнюю YandexGPT 5.1 Pro), развёрнутая прямо в контуре компании. Это исключает утечку чувствительных данных во внешние облака.
В то же время архитектура не замыкается только на локальной модели. Через слой абстракции LLM Proxy возможно гибко подключать публичные модели, если политика компании это допускает. Такой гибридный подход позволяет подбирать оптимальную LLM под конкретную задачу.
2. Интеграция как «кровеносная система»
Ассистенты полезны только тогда, когда умеют работать с корпоративными системами: ERP, БД, тикет-системами, хранилищами документов. Для этого используется единый API-шлюз, к которому можно подключать внутренние источники.
Создание ассистентов не требует глубоких знаний программирования: в платформе есть low-code/no-code инструменты, позволяющие бизнес-аналитикам собирать прототипы визуально. Сервисный слой реализован по enterprise-стандартам: авторизация, мониторинг, аудит действий — встроены «по умолчанию».
3. Работа с данными как ключевая способность
Ассистенты работают не только с текстом, но и с данными:
неструктурированные источники (PDF, документы) индексируются через векторные базы и доступны для семантического поиска;
структурированные данные (SQL-хранилища) доступны через безопасное выполнение автоматически сгенерированных запросов в режиме «только чтение»;
логика выбора источника автоматизирована: ассистент сам решает, обратиться ли к векторам, SQL или внешнему API.
4. Агентский RAG
Классический RAG («нашёл документ → передал в модель → получил ответ») стал отправной точкой. Но в реальных сценариях этого недостаточно. Мы добавили слой агентского мышления, позволяющий ассистентам планировать действия, выполнять последовательные шаги и комбинировать данные из разных источников.
За последний год термин «ИИ-агенты» стал одним из самых популярных в индустрии. Его используют почти везде — иногда формально. Но важно понимать, что именно скрывается за этим понятием.
Классическая работа с LLM выглядит линейно: запрос → ответ. Агентский подход предполагает более сложное поведение:
планирование шагов для решения задачи;
рефлексия — оценка прошлых действий и корректировка стратегии;
выбор инструментов из доступного набора;
итеративное рассуждение с уточнением результата;
даже частичное наличие этих элементов делает систему «агентской».
Смотрим, как агентский RAG работает на практике:
В корпоративном сценарии сотрудник задаёт вопрос в чат-боте и ожидает ответа из внутренних систем. Чтобы это работало, данные предварительно индексируются с помощью эмбеддинг-моделей, преобразующих тексты в векторы. В процессе поиска осуществляется выбор и ранжирование фрагментов, наиболее близких к запросу. На основе этих фрагментов LLM строит ответ — это и есть классический RAG.
Агентский RAG — итеративный и управляемый моделью процесс. Модель сама:
анализирует найденное и при необходимости переформулирует запрос;
может вызывать внешние инструменты;
оценивает качество промежуточного результата;
при необходимости повторяет процесс (ещё итерации) и только затем формирует итоговый ответ.
Процесс ограничен по времени и итерациям, чтобы избежать слишком долгой обработки. Это превращает ассистента в исследователя: он уточняет гипотезы, комбинирует источники и формирует осмысленный ответ.
Более того, мы даём разработчикам возможность самим собирать ассистентов под свои задачи. Вы можете не ограничиваться простым запросом к языковой модели или использованием RAG, а добавить в арсенал внешние инструменты: загрузку задач из Jira, извлечение данных из Confluence, обновление записей в базах. Так ассистент перестаёт быть просто умным собеседником и превращается в полноценного «цифрового коллегу», который умеет не только отвечать, но и действовать.
Итог: ответы на сложные, комплексные корпоративные запросы становятся качественно глубже и точнее. Это не цитата из одного источника, а согласованный по нескольким источникам ответ.
5. Мультимодальность
Ассистенты работают не только с текстом, но и с мультимодальным контентом. Для этого применяются модели VLM (Visual Language Models), которые умеют:
анализировать документы как визуальные объекты;
читать встроенный в картинки текст;
интерпретировать схемы и чертежи до их индексирования.
Для простых задач используются OCR-модели, которые быстрее извлекают текст без глубокого анализа.
6. Интерфейс
Интерфейс платформы построен на привычных практиках (вроде ChatGPT), но адаптирован для бизнеса:
гибкое управление историей;
подключение корпоративных хранилищ документов;
выбор ассистентов под бизнес-задачи.
Кейсы корпоративных ассистентов
1. Ассистент техподдержки. Работает на базе документации и инструкций. Формирует готовые пошаговые ответы с иллюстрациями, например по SAP.
2. Работа с базами данных. Ассистент может обращаться как к неструктурированным данным (документы), так и к SQL-базам. Подбирает оптимальный инструмент под задачу.
3. ИБ-ассистент. Агрегирует данные из баз данных уязвимостей, описаний сегментов сети и отчётов сканеров уязвимостей (например, MaxPatrol). Приоритизирует уязвимости в контексте конкретной инфраструктуры, чтобы выделить критичные риски. Сила этого ассистента – в умении не просто «сыпать» списками CVE, а мыслить как опытный аналитик по кибербезопасности. Он проводит кросс-анализ и расставляет приоритеты так, чтобы в потоке данных не утонули действительно опасные проблемы.
Опыт разработки JET & Yandex GPT Lab показывает: генеративный ИИ в бизнесе — это не отдельная модель, а целая экосистема. Чтобы LLM приносила реальную пользу, её нужно окружать инфраструктурой, интеграциями, системами безопасности и удобным интерфейсом.
LLM сегодня — это как процессор в компьютере: без памяти, ОС и приложений он не выполняет полезной работы. То же и с корпоративными платформами: модель — лишь ядро, вокруг которого строится архитектура.
Ключевые направления на ближайшие годы:
Рост агентских систем: от поиска к полноценным цифровым сотрудникам.
Мультимодальность как стандарт: работа с текстом, изображениями, схемами, видео.
Интеграция с процессами: ассистенты станут частью бизнес-цепочек.
Фокус на экономике: оценка внедрения по конкретным метрикам эффективности.
Мы убеждены: следующий этап — переход от «просто LLM» к корпоративным GPT-платформам, которые станут стандартом наряду с CRM, ERP и BI-системами.