Когда компания переезжает с облачного Битрикс24 на коробку, за плечами у неё обычно уже есть история: юристы сказали, что клиентские базы нельзя держать где попало, интеграции упёрлись в потолок типовых сценариев, а доработки требуют доступа внутрь. Коробка закрывает главный вопрос — данные лежат на вашей территории, и всё, что с ними происходит, происходит по вашим правилам.
Но у переезда есть цена, о которой часто вспоминают позже: вместе с облаком с портала уходят и встроенные ИИ-функции. В облаке они работают через внешние модели — а те самые тексты, документы и переписки, ради которых всё и переезжало, отправлять за периметр нельзя. Портал рискует превратиться в очень аккуратную «умную папку»: данные разложены идеально, а думать над ними некому.
Выход — поставить модель рядом с порталом, в том же контуре. Мы такую связку собираем и гоняем на своём железе, и в этой статье покажем, как она устроена, что для неё нужно и с какими задачами справляется.
Table Of Contents
Почему уходят в коробку
Причины переезда звучат по-разному, но сводятся к трём. Первая — данные: клиентская база, переписка и документы должны оставаться на своей территории. Для компаний с персональными данными это вопрос не удобства, а закона — мы разбирали его в статье про локальный ИИ и 152-ФЗ. Вторая — интеграции: когда учёт завязан на внутренние системы, облачный портал приходится выворачивать наизнанку, чтобы протянуть в него нужные данные. Третья — доработки: на коробке можно менять всё, от бизнес-процессов до интерфейса, и не ждать, пока нужная функция появится у вендора.
Плата за этот контроль — потеря встроенных облачных ИИ-функций. Они работают через модели провайдера, и туда уезжает ровно то, что вы решили не выпускать: тексты сделок, содержимое документов, история переписки. Портал остаётся умным по форме — воронки, роботы, автоматизация на месте, — но глухим по содержанию: смыслы, спрятанные в документах и чатах, никто не вытаскивает.
Что возвращает локальная модель
Локальная модель закрывает почти всё, что давал облачный ИИ, — только обработка теперь идёт внутри контура. Список задач, которые мы отдаём модели в связке с порталом:
- извлечение данных из документов — реквизиты, стороны, суммы и условия уходят из файла в поля карточки;
- OCR — сканы и фотографии превращаются в текст, с которым умеют работать бизнес-процессы;
- генерация документов — черновики писем, ответов и договоров по данным сделки;
- сводки по чатам — длинные переписки сжимаются до выжимки, которую видят менеджер и руководитель;
- ассистент в бизнес-процессах — модель подсказывает на конкретных шагах робота, а не живёт отдельным чатом сбоку.
Общее у всех задач одно: исходные данные — это ваши клиенты, ваши документы, ваши переговоры. Отдавать их наружу ради автоматизации значило бы обнулять саму идею коробки.
Архитектура: весь путь внутри контура
Связка устроена прямолинейно, и в этом её сила. Портал живёт в вашем контуре. Рядом — приложение или скрипт, который через REST API Битрикс24 забирает задачу: текст документа, переписку, поля сделки. Данные уходят локальному инференсу — модели на вашем железе, — результат возвращается в карточку: в поле, комментарий или файл, а бизнес-процесс идёт дальше.
Ни на одном шаге данные не выходят наружу. Нет вызовов внешних API моделей, нет «где-то в облаке обработалось и вернулось» — весь путь от карточки до модели и обратно замкнут на вашей сети. Периметр, ради которого покупалась коробка, не продырявливается трубой до чужого дата-центра.
Info
Интеграция идёт через REST API Битрикс24 и приложения портала: приложение забирает данные из карточки, отправляет их локальному инференсу и возвращает результат туда же. Отдельного «моста наружу» в схеме нет.
Единственное, что нужно этой схеме, — место для железа: серверная в офисе или площадка, которую вы полностью контролируете. Дальше вопрос уже не архитектуры, а хозяйства.
На каком железе это работает
Самый частый вопрос после схемы — «на чём это крутится». Мы держим локальные модели на своих DGX Spark: у нас работают Qwen3.8-Flash и DeepSeek V4.1 Flash 1017. Аппетиты у моделей разные — одной хватает одного узла, второй нужна пара связанных узлов, — поэтому модель под связку подбирают под задачи портала, а не наоборот.
Подробности — замеры, настройки, выводы из эксплуатации — мы уже разложили в статьях про Qwen3.8-Flash локально и про DGX Spark, здесь повторять их не будем. Важен принцип: железо с моделью живёт в том же периметре, что и портал. Это не «арендованная видеокарта где-то в дата-центре», а машины, которые вы видите, контролируете и обслуживаете сами — именно поэтому связка работает там, куда облачному ИИ хода нет.
Эксплуатация: коробка требует хозяйской руки
Переезд в коробку меняет не только место хранения, но и роль вашей ИТ-команды: портал теперь нужно обслуживать. Обновления — включая обновления PHP-стека, на котором собран Битрикс24, — нельзя откладывать: запоздание однажды оборачивается простоем в самый неподходящий момент. Бэкапы должны жить по регламенту и с проверенным восстановлением: копия, которую ни разу не разворачивали, — это не бэкап, а надежда. Мониторинг нужен обеим половинкам связки — и порталу, и железу с моделью: связка надёжна ровно настолько, насколько рано вы узнаёте о проблеме.
Отдельно про отказоустойчивость: второй узел — не для красоты. Пока модель работает на одной машине, её авария останавливает все ИИ-функции портала разом. Второй узел превращает «упало и ждём» в «переключились и работаем», и для связки, на которой завязаны бизнес-процессы, это базовая гигиена, а не роскошь.
Warning
Коробочный портал требует своей эксплуатации: обновления — в том числе PHP-стека, бэкапы, мониторинг. Если в команде нет человека, отвечающего за это хозяйство, связка «портал + модель» начнёт сбоить не из-за технологии, а из-за его отсутствия.
Что уже готово: приложения из каталога
Начинать с нуля не нужно. В каталоге Битрикс24 у нас 30+ приложений, и ключевые для ИИ давно живут в нём: AI Документы, OCR24, AI Аудит чатов, GPT24, Генератор документов. Каждое закрывает свою задачу — от работы с документами до разбора переписок, — и все они встраиваются в карточки и бизнес-процессы портала.
Раньше таким приложениям для «мозгов» требовался внешний ИИ-сервис. Теперь тот же набор можно повернуть на собственный бэкенд модели: интерфейс в карточках не меняется, переучивать пользователей не нужно, меняется лишь то, куда данные уходят на обработку, — не наружу, а в вашу серверную. Полный список — на странице приложений.
Облако или свой контур: где что выигрывает
Выбор между облачным ИИ и локальной моделью — это выбор не «что умнее», а какой компромисс вам ближе:
| Критерий | Облачный ИИ | Локальная модель |
|---|---|---|
| Данные | уходят за периметр, к провайдеру модели | остаются в контуре, обрабатываются на вашем железе |
| Стоимость | платёж за каждый запрос, растёт вместе с использованием | железо и его обслуживание, без счётчика за токены |
| Задержка | зависит от внешнего канала и чужой загрузки | определяется вашим железом и предсказуема |
| Приватность | регулируется договором с провайдером | полный контроль: ничего не покидает периметр |
Читается таблица просто: если критичны данные и приватность, локальная модель выигрывает по определению — не потому что она быстрее или умнее, а потому что альтернатива для вас не существует. Если же данные нечувствительны, а платить за токены не жалко, облачный ИИ остаётся самым коротким путём «просто включить». Экономику выбора «свой ИИ против сервиса» мы считали отдельно в статье про TCO своего ИИ.
Итог
- Коробка отвечает на вопрос «где лежат данные», но не на вопрос «кто их читает» — без своей модели ИИ внутри периметра не появляется.
- Локальная модель возвращает извлечение данных из документов, OCR, генерацию документов, сводки по чатам и ассистента в бизнес-процессах — и всё это без единого запроса наружу.
- Архитектура простая: портал → приложение через REST API → локальный инференс → результат в карточку.
- Планируйте не только железо, но и эксплуатацию: обновления, бэкапы, мониторинг и второй узел.
- Приложения уже готовы — AI Документы, OCR24, AI Аудит чатов, GPT24, Генератор документов — теперь со своим бэкендом модели.
Если присматриваетесь к связке для своего портала, начните со страницы приложений — оттуда проще всего увидеть, какие задачи вашего Битрикс24 уже закрыты готовым.