Это не наш кейс — разбираем публичную историю коллег из Швеции, которая хорошо ложится на российский энергетический и промышленный сектор. 5 марта 2026 муниципальная энергокомпания Borås Energi och Miljö (BEM) совместно с вендором Intric опубликовала отчёт о переходе от облачного пилота с генеративным ИИ к on-premise развёртыванию с планом масштабирования на всю организацию. Ниже — что они делали, почему ушли из облака и что из этого полезно российским компаниям в энергетике, ЖКХ и тяжёлой промышленности.

Кто такие BEM и зачем им ИИ

Borås Energi och Miljö — муниципально-контролируемая компания города Борос (Швеция). Она отвечает за теплоснабжение, водоснабжение, канализацию и обращение с отходами. Масштаб: ~380 сотрудников, оборот около SEK 1,3 млрд (примерно 11 млрд ₽). По российским меркам — типичный региональный «энергосбыт + водоканал + ТГК» в одном юрлице.

Задача, которую ставили перед ИИ, — вполне узнаваемая:

  • Знания есть — но их сложно найти. Инструкции, регламенты, нормативка, документация к АСУ ТП и биллингу разбросаны по системам; поиск отнимает часы.
  • Сложные специализированные среды. Информация о ТЭЦ, чертежи, ERP, HR-политики, тарифы — десятки разных систем с разной структурой.
  • Онбординг и «бас-фактор». Новые сотрудники постоянно дёргают старших коллег по операционным вопросам.
  • Качество ручных операций. Проверка документации поставщиков, наименование/метаданные технической документации — места, где чаще всего ошибаются.
  • Перед масштабированием — нужна инфраструктура. Чтобы перейти от PoC к устойчивой эксплуатации, нужны governance, качество данных, безопасность.

Две фазы пилота: сначала облако, потом on-premise

В 2025 году BEM совместно с городом Борос запустили облачный пилот на платформе Intric. В пилоте создавали и валидировали множество AI-ассистентов: «чат с инструкциями», помощники для техников, клиентского сервиса, HR, финансов. За несколько месяцев накопили портфель рабочих прототипов.

Главный инсайт пилота: наибольшую ценность ИИ приносил как раз там, где данные — высокого класса чувствительности. То есть на том, что в облако отдавать нельзя: операционные системы, чувствительные документы, регламенты.

Отсюда — решение: масштабировать не в облаке, а в собственной инфраструктуре (on-premise). Вся логика платформы и AI-ассистентов переезжает в контур заказчика, доступ к чувствительным системам — по гранулярной модели прав, данные не покидают периметр. В этот момент пилот перестаёт быть «ещё одной облачной подпиской» и превращается в корпоративный ИТ-продукт.

Для российского рынка это ровно та же логика, которую мы закладываем в архитектуру Нексус-Тех: в периметре остаются и LLM, и векторная БД, и оркестратор агентов, и журналы. Подробнее про этот подход — в разборе «RAG on-premise».

Как строили: «AI-амбассадоры», а не «проект от подрядчика»

Интересный организационный приём: вместо того чтобы спускать кейсы сверху, BEM назначили AI-амбассадоров — представителей разных функций (ИТ, эксплуатация, клиентский сервис, HR, финансы), которые сами собирали ассистентов и делились опытом в регулярных AI-лабах.

Методика выглядела так:

  • Собирают реальные кейсы по отделам — и мелкие «боли», и стратегические запросы.
  • Обучают сотрудников работе с платформой.
  • Амбассадоры сами собирают ассистентов из существующих знаний — PDF, инструкции, регламенты, тарифы, договоры, стандарты, законодательство.
  • Итерируют: правят промпты, пополняют источники, учитывают ограничения.
  • По единой модели оценки сводят результаты и презентуют управленческой команде.
  • После утверждения — переезд на on-premise и план рулаута на всю организацию.

«Широкая инициатива с AI-амбассадорами по всей организации — ключевой фактор: именно это помогло распространить интерес и быстро нарастить знания» — Fredrik Andersson, Enterprise Architect, BEM.

Результаты

25+
AI-ассистентов по техподдержке, клиентам, HR, финансам, вебу
336
обращений к чат-боту на сайте за первый месяц после запуска
on-prem
архитектура после пилота — данные не покидают периметр

Главное — не метрика по одному «главному ассистенту», а широкий портфель ассистентов, привязанных к конкретным рабочим задачам:

Функция Примеры ассистентов
Технологии / АСУ ТП «Чат с инструкциями» для ABB 800xA, помощь в reverse engineering и конверсии legacy-кода
Техническая документация Ассистент читает штампы и имена файлов в сканах чертежей, пакетная обработка вместо ручного открытия каждого файла
Веб и клиенты Чат-бот на borasem.se — 336 вопросов за первый месяц, опирается на контент сайта и релевантные документы
Клиентский сервис Быстрые ответы из инструкций и регламентов — особенно ценно при онбординге новых сотрудников
HR Ассистент по вопросам HR, зарплаты, законодательства, коллективных договоров
Финансы Ассистент по ERP (Agresso), помощник по проводкам, формированию отчётности (K3), сверкам, черновикам управленческих комментариев

Обратите внимание на логику: это не «один большой AI-проект на миллион», а портфель из 20–30 маленьких, но попадающих в реальные операции. Именно такой формат лучше всего ложится на мультиагентную архитектуру, где отдельные агенты специализируются на своих задачах, а оркестратор направляет запрос к нужному — см. модели агентов.

Пять уроков для российских энергетиков и промышленников

Если читать кейс BEM глазами руководителя ИТ или цифровизации в российской генерации, сетях, ЖКХ, ТЭЦ или промышленном холдинге, полезны пять прикладных выводов:

  1. Начинайте широко, но быстро валидируйте. Много маленьких пилотов с понятным владельцем задачи дают импульс и видимую пользу — в отличие от одного «флагманского» проекта, который буксует полтора года.
  2. База знаний — это продукт, а не «файлы на SharePoint». Документы должны поддерживаться, версионироваться и обновляться. Без этого любой RAG со временем деградирует в неточные ответы.
  3. Governance — условие масштабирования, а не «потом». On-premise, качество данных, политики доступа и GDPR/152-ФЗ должны быть заложены до рулаута, иначе уткнётесь в безопасность.
  4. Снижайте порог входа. Простые точки входа и очевидные подтверждения пользы резко повышают долю сотрудников, которые вообще начнут пользоваться ИИ.
  5. Контроль доступа — ключевой элемент. Возможность безопасно работать с разными классами данных и управлять доступом на уровне пользователя — это условие массового внедрения без инцидентов.

Почему это близко к российской повестке

Российская специфика делает on-premise подход ещё более обязательным: нельзя отдавать в облако тарифную информацию, персональные данные клиентов, регламенты АСУ ТП и чувствительные данные операционных систем. Инсайт BEM — «ценность там, где данные высокой чувствительности» — у нас работает тем более жёстко.

Кроме того, многие кейсы из BEM напрямую ложатся на типовые задачи российских компаний:

  • «Чат с регламентами» — тепловые карты, безопасность, стандарты — у российских генерирующих компаний таких документов ещё больше, и они ещё менее структурированы.
  • Ассистент по ERP — у нас это 1С, SAP, Галактика. Логика та же: бухгалтер/экономист описывает задачу словами, а не ищет проводку по справочнику.
  • Работа с чертежами и технической документацией — штампы, шифры, метаданные, поиск по архиву. Боль всех КБ, заводов, сетевых компаний.
  • Публичный чат-бот с опорой на внутренние документы — тарифы, условия подключения, график отключений — точка входа для населения и малых юрлиц.
  • HR-ассистент — вопросы по отпускам, командировкам, соцпакету, коллективному договору, Трудовому кодексу.

Как мы смотрим на такой сценарий

В Нексус-Тех мы заточены ровно под такую модель внедрения: 100% on-premise, мультиагентная архитектура, RAG по внутренним документам, интеграции с 1С / ЭДО / Bitrix24, отсутствие отправки данных в облако. Сроки сопоставимые с кейсом BEM: на полноценный пилот с частью ассистентов и переходом в продакшн обычно хватает 1–2 месяцев. Безопасность — отдельная тема: защита от утечек и prompt injection разбиралась в материалах «Предотвращение утечек данных» и «Защита от prompt injection».

Если у вас похожий пейзаж — много источников знаний, сложные операционные системы, требование держать данные в периметре — кейс BEM показывает вполне реалистичный маршрут: аккуратный пилот → честная оценка ценности → переход в on-premise → масштабирование по отделам. Оставить заявку на обсуждение пилота под ваши процессы можно прямо ниже.

Источник: Intric Customer Story — «Borås Energi och Miljö: From Pilot to Full-Scale AI Rollout with Local On-Prem Deployment», 5 марта 2026. Сайт компании: borasem.se. Материал — аналитический пересказ публичного кейса.