В Битрикс24 много ИИ-функций: чат с нейросетью, транскрибация звонков, протоколы созвонов. По умолчанию все они работают через внешнее облако - каждый запрос уходит за периметр компании. Мы сделали для коробочного Битрикс24 собственного провайдера ИИ: локальная модель на сервере клиента подключена штатным механизмом портала и обслуживает все его ИИ-функции. Данные остаются внутри.
Провайдера мы собрали для крупной инженерной компании из промышленной автоматизации и энергетики - той же, где работает наш ИИ-бот техподдержки на тысячи обращений в месяц. История внедрения целиком - в кейсе, а здесь разбираем одну её часть: как весь ИИ портала переехал на локальную модель.
Что уходит в облако со штатным ИИ
Встроенный ИИ Битрикса удобен, пока не смотреть на содержимое запросов. Транскрибация звонка - это полная запись разговора: цены, условия, имена. Протокол созвона - всё, что обсуждали на внутренней встрече. Чат с нейросетью - вопросы сотрудников, в которые они вставляют куски регламентов и таблиц. Со штатным ИИ всё это уезжает на серверы внешнего провайдера и обрабатывается там.
Для компании с закрытым контуром это дыра в периметре. Коробочный Битрикс24 клиента стоит на его серверах и с внешним миром не общается, а облачный ИИ при каждом запросе выносил бы наружу самое чувствительное: переговоры, внутренние документы, цифры. Поэтому штатный облачный ИИ у этого клиента выключен.
Провайдер ИИ: штатная точка замены
У Битрикса есть официальный механизм: стороннюю модель можно зарегистрировать как провайдера ИИ, и портал станет работать с ней во всех ИИ-функциях - так же, как со встроенным облаком. Мы написали прослойку между порталом и локальной моделью и зарегистрировали её этим механизмом. Для Битрикса это обычный провайдер; на деле запросы не покидают локальную сеть.
В настройке провайдера прописывается путь с токеном, тип данных - текст или аудио - и модель, на которую направляется запрос. Текстовые запросы уходят в языковую модель, голос - в модель распознавания речи. Обе стоят на сервере клиента.
Прослойка подключена к порталу как внешнее приложение через REST API и в ядро Битрикса не лезет. Обновления коробки её не ломают: вышла новая версия портала - провайдер продолжает работать.
Что теперь работает внутри периметра
- →Чаты с ИИ. Сотрудники общаются с нейросетью в веб-чате в стиле ChatGPT и через ИИ-функции портала. В вопрос можно вставить внутренний документ или таблицу - дальше серверной он не уйдёт.
- →Транскрибация звонков. К порталу подключается телефония: запись разговора переводит в текст локальный Whisper, разбирает текст локальная языковая модель.
- →Протоколы созвонов. Фоллоапы встреч Битрикса работают на тех же локальных моделях, дообученных на терминах компании. Как это устроено - в отдельном разборе.
- →Текст и картинки. Базовая модель Gemma мультимодальная: понимает и текст, и изображения, с русским работает нормально.
Лишние ИИ-функции портала при этом выключены. Логика простая: каждая включённая функция - ещё один путь, по которому данные могут уйти в обход. Остаётся то, чем сотрудники реально пользуются, и всё это работает через локального провайдера.
Зачем это бизнесу
Сотрудники всё равно пользуются нейросетями. Когда у компании нет своего ИИ, рабочие вопросы уходят в личные чаты с публичными ботами - вместе с кусками внутренних документов, и проконтролировать это никто не может. Свой провайдер снимает саму причину: те же возможности есть на портале, под рабочими учётными записями, внутри периметра.
У этого клиента на локальных моделях уже работает всё боевое: ИИ-бот техподдержки, чаты с нейросетью, транскрибация звонков, протоколы созвонов, адаптация новичков. Данные компании остаются её данными - для инженерного бизнеса с собственным производством и разработкой это условие, при котором ИИ вообще пускают во внутренние процессы.
Если у вас коробочный Битрикс24 и данные, которые нельзя отдавать в облако, - ИИ-функции портала можно перевести на локальную модель в вашем контуре. Расскажите про свою инфраструктуру, и мы предложим схему под неё.
