ИИ-ассистент в корпоративном мессенджере на своём сервере: AstrBot + локальная LLM в Docker, данные в периметре

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

Решение строится на связке локальной языковой модели и универсальной платформы AstrBot. Этот инструмент с открытым исходным кодом поддерживает более 1000 плагинов, изолированную среду выполнения кода и нативную работу с Telegram, Slack и корпоративными чатами. Такой подход обеспечивает полный контроль над данными при сохранении функциональности интеллектуального помощника.

Корпоративный ии ассистент в своём контуре — это связка мессенджера, локальной языковой модели и слоя-посредника, которая работает на серверах компании и не отправляет переписку наружу. Главное отличие от ChatGPT, GigaChat или YandexGPT в облаке — данные не покидают периметр сети, журналируются вашими средствами и подчиняются вашему регламенту удаления.

Когда сотрудник копирует в облачный чат фрагмент договора, выписку из CRM или код внутреннего сервиса, он формально передаёт это оператору сервиса. Для персональных данных российских граждан это автоматически попадает под 152-ФЗ: требуется законное основание обработки, согласие субъекта, локализация на территории РФ и реестровая запись оператора. Облачные LLM иностранных провайдеров эти требования не закрывают, а отечественные облачные модели закрывают их условно — нужно отдельно изучать договор, расположение мощностей и режим логирования.

На наших проектах в корпоративном сегменте мы видим три повторяющиеся причины уходить в self-hosted ии ассистент. Первая — коммерческая тайна и NDA с заказчиками: финансовая модель, тендерная документация, исходники не должны утекать к стороннему оператору даже в виде эмбеддингов. Вторая — отраслевое регулирование: банки, медицина, госсектор, оборонные подрядчики проходят аудиты, где «наш ИИ работает в чужом облаке» — это сразу замечание. Третья — стоимость на длинной дистанции: при стабильной нагрузке десятков пользователей в день своя GPU-машина окупает облачный API за несколько кварталов.

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

Резюме периметра: локальное развёртывание LLM закрывает 152-ФЗ по локализации, снимает зависимость от внешнего SLA, даёт полный контроль над логами и позволяет использовать модель в закрытом контуре без интернета. Дальше вопрос инженерный — из чего собрать такую систему за разумные деньги и сроки.

Корпоративный ии ассистент в мессенджере собирается из трёх слоёв, и их полезно различать с самого начала — иначе при выборе инструмента легко перепутать функции и купить «не то».

Первый слой — корпоративный мессенджер. Это Mattermost, Rocket.Chat, Matrix (Synapse/Element), VK Teams, Express, eXpress или RuPost для коллаборации — площадка, в которую сотрудники уже ходят за рабочей перепиской. Ассистент должен жить там же: отдельный веб-интерфейс ИИ-чата люди забрасывают за неделю, а бот в общем канале или в личке мессенджера используется ежедневно.

Второй слой — локальная LLM-модель и слой инференса. Это Ollama, llama.cpp, vLLM или TGI поверх открытых моделей (Llama 3, Qwen, Mistral) или российских (Saiga, T-lite, YandexGPT On-Prem, GigaChat для On-Prem-сценариев). Слой инференса принимает запросы по OpenAI-совместимому API и отвечает токенами. На этом же сервере живут векторная база (Qdrant, Weaviate, pgvector) и эмбеддер для RAG.

Третий слой — слой-доставка между мессенджером и моделью. Он принимает события из мессенджера, ведёт историю диалогов, прикручивает RAG, инструменты, плагины и форматирует ответ обратно в чат. AstrBot — это универсальная платформа Agent-чатботов с открытым исходным кодом, которая интегрируется с основными приложениями для обмена мгновенными сообщениями, и удобна именно как такой слой-доставка. Её альтернативы — нативные интеграции вроде Mattermost Agents и Matrix baibot, а также самописные адаптеры на webhooks.

Что даёт такой слой кроме «принять и отдать». На примере AstrBot: диалоги с ИИ-моделями, мультимодальность, Agent, MCP, Skills, База знаний, настройка личности и автоматическое сжатие диалогов. Плюс изолированная среда Agent Sandbox для безопасного выполнения кода и Shell с повторным использованием ресурсов на уровне сессии. По нашему опыту, именно эти функции отличают «бот, который пересылает запросы в LLM» от рабочего ассистента, который помнит контекст, ходит в базу знаний и умеет вызвать внутренний API.

Ещё одна полезная развилка: слой-доставка может работать поверх своих локальных моделей, а может интегрироваться с платформами агентов — Dify, Alibaba Cloud Bailian, Coze. Для контура предприятия мы обычно выбираем первый вариант, для пилота — второй.

Короткий ответ: если у вас Mattermost — берите нативные Mattermost Agents, если Matrix — baibot, если зоопарк мессенджеров или Telegram/Slack для внутренней команды — AstrBot. Для Rocket.Chat есть штатные интеграции и внешние боты через webhooks, но «коробочного» ИИ-агента уровня Mattermost Agents там пока нет, поэтому удобнее подключить тот же AstrBot.

Чтобы выбор был основан не на ощущениях, мы сравниваем слои-доставки по пяти критериям: какие мессенджеры поддержаны, как добавляется RAG, есть ли плагины и MCP, насколько богат веб-интерфейс, кто будет это сопровождать.

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

AstrBot мы рассматриваем как универсальный путь в трёх случаях. Первый — несколько мессенджеров одновременно: например, внутренний Mattermost и Telegram для подрядчиков. AstrBot интегрируется с основными приложениями для обмена мгновенными сообщениями, а значит, можно дать один ассистент в разные каналы без зоопарка адаптеров. Второй — расширяемость: более 1000 плагинов и поддержка MCP закрывают типовые задачи без своего кода. Третий — мультиязычность и распределённые команды: поддержка интернационализации (i18n) полезна при работе с филиалами в СНГ и Азии.

На наших проектах развилка обычно решается по принципу «следуй за мессенджером»: меняем доставку, а не корпоративную коммуникацию.

Локальный запуск LLM начинается с честного ответа на два вопроса: какой язык преобладает в задачах ассистента и какое железо вы готовы выделить. От этих ответов зависит и модель, и слой инференса, и итоговая стоимость.

Для русскоязычной нагрузки на открытом стеке мы рассматриваем три семейства: дообученные на русском версии Llama-3 и Qwen 2.5, специализированные русскоязычные модели Saiga и T-lite, а также мультиязычные Mistral и Gemma. Под бизнес-задачи в офисе обычно достаточно модели 7–14B параметров: она отвечает по фактам из RAG, формулирует письма, разбирает протоколы. Модели на 32–70B параметров заметно лучше в рассуждениях и кодинге, но требуют серверной GPU и заметно дороже в эксплуатации.

Российские LLM мы выбираем там, где заказчику важна не только локализация данных, но и происхождение модели. GigaChat в On-Prem-варианте и YandexGPT On-Prem поставляются по отдельным договорам с вендором и требуют подтверждённого железа; они хорошо стыкуются с регуляторкой и закрывают вопросы юристов. Saiga — открытое семейство дообученных моделей, подходит для пилотов и не привязывает к вендору. По нашему опыту, для типового корпоративного ассистента с RAG разница между свежей Qwen 2.5 14B и более крупными российскими моделями на бизнес-вопросах заметна не всегда, а вот стоимость владения отличается в разы.

Слой инференса выбираем по сценарию использования. Ollama удобен на старте: ставится одной командой, тянет модели из реестра, имеет OpenAI-совместимый API и хорошо живёт даже на CPU для маленьких моделей. llama.cpp даёт максимальный контроль и работает на скромном железе через квантизацию GGUF. vLLM и TGI — это уже про продакшен на GPU с десятками одновременных пользователей и нормальным батчингом.

Ресурсы под GPU/CPU прикидываем так. Для пилота на 5–15 сотрудников нам хватает одной видеокарты потребительского класса с 16–24 ГБ видеопамяти и моделью 7–13B в квантизации Q4–Q5. Для 50–100 активных пользователей нужна серверная карта с 40–80 ГБ видеопамяти или две карты по 24 ГБ. Для CPU-only сценариев берём процессор с высоким количеством ядер и быстрой памятью DDR5 — это рабочий вариант для текстовых задач без жёстких требований к скорости отклика.

Не делайте ставку на «одну универсальную модель навсегда» — мы сталкивались с тем, что заказчик закупал железо под 70B-модель «с запасом», а через полгода новые 14B-модели обгоняли её на бизнес-метриках при кратно меньших ресурсах. Лучше начать с экономной конфигурации и заложить апгрейд через 12 месяцев.

Универсальный путь развёртывания мы выбираем, когда корпоративный ии ассистент должен жить в нескольких мессенджерах или когда внутри Mattermost/Matrix хочется получить богатый агент с плагинами и базой знаний. Сценарий — поднять AstrBot в Docker рядом с локальной LLM и подключить его к мессенджеру через штатные адаптеры.

Подготовка стенда. Нам нужны три компонента на одном сервере или в одной приватной сети: контейнер с AstrBot, инференс-сервер локальной модели (Ollama или vLLM) и контейнер векторной базы для будущего RAG. Сеть закрываем — наружу торчит только мессенджер, а AstrBot и LLM общаются по внутреннему bridge-сетевому интерфейсу Docker. Хранилище для AstrBot выносим в именованный том, чтобы переживать пересборку образа.

Базовый каркас Compose-файла выглядит так — конкретные образы, теги и пути проверяйте по актуальной документации проекта:

После запуска заходим в WebUI AstrBot — он же служит панелью администратора. AstrBot предоставляет WebUI и Web ChatUI со встроенной песочницей агента и веб-поиском; через WebUI создаём подключение к локальной LLM как к OpenAI-совместимому провайдеру (указываем внутренний адрес инференс-сервера и любой непустой ключ), задаём системную подсказку и роль ассистента.

Подключение к мессенджеру делается в той же админке. AstrBot интегрируется с основными приложениями для обмена мгновенными сообщениями и поддерживает QQ, WeChat для предприятий, Feishu, DingTalk, публичные аккаунты WeChat, Telegram, Slack и другие. Для Telegram внутри корпоративной сети мы заводим бота через BotFather и регистрируем токен в адаптере; для Slack — приложение в рабочем пространстве с нужными правами; для Mattermost/Rocket.Chat подключение делается через webhooks-плагины и личный токен сервисной учётки.

Проверка работоспособности — три шага. Сначала отправляем боту простой вопрос в личке и смотрим, что LLM отвечает на родном языке. Затем включаем автоматическое сжатие диалогов и проверяем, что бот не теряет контекст после 20–30 сообщений. И, наконец, добавляем бота в групповой канал, ограничиваем доступ только нужным сотрудникам и наблюдаем за нагрузкой на GPU/CPU в первые сутки. По нашему опыту, на этом этапе обычно всплывают тайминги и лимиты, которые нужно подкрутить в инференс-сервере.

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

Источники для базы знаний на наших проектах обычно одни и те же: внутренняя Confluence или Wiki.js, регламенты в формате DOCX и PDF, FAQ службы поддержки, выгрузки из CRM/Service Desk, репозитории с README и архитектурными решениями. Конвейер строим по схеме «загрузка → нарезка на чанки → эмбеддинги → запись в векторную базу → переиндексация по расписанию». Для русского языка лучше работают мультиязычные эмбеддеры; чанки делаем по 400–800 токенов с перекрытием, иначе модель теряет контекст сноски.

В AstrBot есть встроенная функция базы знаний — она в списке штатных возможностей вместе с диалогами, мультимодальностью, Agent, MCP, Skills, настройкой личности и автоматическим сжатием диалогов. Этого хватает для пилота: загрузили документы через WebUI, дали боту инструкцию «отвечай только по этим источникам, при отсутствии — пиши, что не знаешь» — и получили рабочий FAQ-ассистент. Для зрелых сценариев мы выносим RAG в отдельный сервис на Qdrant или Weaviate и подключаем его к AstrBot как внешний инструмент через MCP.

MCP (Model Context Protocol) — это то, что превращает ассистента из «чат-бота» в агента. Через MCP корпоративный ии ассистент получает доступ к внутренним API: проверить статус заявки в Service Desk, посмотреть остатки на складе 1С, открыть тикет в Jira, найти контакт в RuPost-почте, выполнить SQL-запрос к витрине. AstrBot поддерживает MCP и Skills как штатную функцию, и в его экосистеме доступно более 1000 плагинов сообщества в один клик — от поиска по веб-источникам до интеграций с задачниками.

Безопасность инструментов закрываем изолированной средой Agent Sandbox: она обеспечивает безопасное выполнение любого кода, вызов Shell и повторное использование ресурсов на уровне сессии. На практике это значит, что ассистент может выполнить пользовательский Python-сниппет или shell-команду без риска для хоста.

По нашему опыту, главная ошибка на этом шаге — пытаться сразу подключить всё. Мы начинаем с одного-двух инструментов под конкретную метрику (например, «снизить время ответа Service Desk на типовые вопросы на 30%»), а расширяем набор только после того, как пользователи освоили текущий.

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

Сеть. Сервер с LLM и AstrBot не должен иметь прямого доступа в интернет; обновления моделей и образов идут через прокси с белым списком репозиториев. Между мессенджером и AstrBot — внутренний TLS. WebUI AstrBot закрываем сетевым доступом или ставим reverse-proxy с корпоративной SSO; админская панель — самый частый канал утечки промптов и базы знаний, поэтому 2FA здесь обязательна.

Доступы. Заводим сервисную учётку в мессенджере с минимальными правами: бот должен видеть только те каналы, где он явно приглашён. На стороне RAG — разграничение по тегам/индексам: HR-документы видит только HR-канал, финансовые — только финансовый. На стороне LLM-сервера — отдельный API-ключ для AstrBot, ротация раз в квартал. Для админов AstrBot — именные учётки, без общего admin/admin.

Журналирование. Это та область, где облачные сервисы проигрывают по определению, а у нас — единственный способ доказать аудитору, что ИИ не «уехал в неизвестном направлении». Мы храним три потока логов: события AstrBot (кто, когда, в каком канале спросил), запросы к LLM (промпт, контекст, ответ, токены) и обращения к инструментам/RAG (какой документ был извлечён, какой API вызван). Логи льём в централизованный сборщик (Loki/ELK), храним по сроку, согласованному с ИБ, маскируем персональные данные на уровне фильтра.

Эксплуатация. По нашему опыту, корпоративный ии ассистент стабильно работает первые две недели и начинает «плыть» на третьей, когда вырастает база знаний и количество одновременных диалогов. Мы заранее настраиваем мониторинг: загрузка GPU/CPU, latency инференса, длина очередей в AstrBot, доля ответов «не знаю», частота фолбэков на веб-поиск. Бэкап — ежедневный снимок тома AstrBot и векторной базы, отдельно — выгрузка системных подсказок и конфигов в Git.

Отдельно — про антипаттерн «бот в общем канале без правил». Мы сталкивались с ситуацией, когда ассистент в открытом чате начинал отвечать на каждое сообщение и за сутки сжёг недельную квоту GPU. Лечится это явными триггерами вызова (упоминание, префикс, команда), лимитом запросов на пользователя в день и явным правилом «в каналах — по обращению, в личке — свободно». Это в чек-листе у нас отдельным пунктом и проверяется на каждом запуске.

Ответы на часто задаваемые вопросы по теме статьи.

Константин Тютюнник — ведущий инженер IT For Prof. Специализируется на архитектуре self-hosted решений и безопасности данных. Имеет опыт развертывания локальных LLM-кластеров для финтех-сектора и промышленных предприятий.