Публичных собственных кейсов у Нексус-Тех пока нет — платформа относительно свежая, и большинство клиентов под NDA. Поэтому в этом разборе — чужой кейс: 17 марта 2026 года о нём отчитался крупнейший банк Словении NLB (Nova Ljubljanska Banka) вместе со своим интегратором Adastra (первоисточник). Архитектурные решения и логика внедрения здесь очень близки к тому, что мы делаем в архитектуре on-premise — особенно полезно российским банкам, страховщикам и финансовым группам, проходящим тот же путь: bank-grade контроль, предсказуемые косты, отсутствие shadow IT, масштабирование агентов по подразделениям.

Коротко: что сделали

5 мес.
от старта до платформы и первого продуктового кейса
−80%
времени и стоимости внедрения новых AI-кейсов
100%
трассировки, аудита и data security по всем агентам

NLB построил централизованную агентную платформу: единый контур, в котором любой AI-агент по банку проходит стандартный путь «идея → утверждение → продакшн». Каждый агент работает под ролевой моделью доступа, интегрирован с корпоративной IDP (Entra ID), все запросы и расходы видны через админ-портал и Grafana.

«Вопрос был не в том, масштабировать ли AI-агентов, а в том, как это сделать ответственно, под контролем и с учётом лучших практик, при этом не замедляя команды» — Dejan Pust, CIO NLB.

Почему это важная история для enterprise

До платформы NLB, как и многие банки, уже работал с облачными GenAI-сервисами. Проблема: облачные сервисы индустриально-общие, они не знают, что такое «требования банковского регулятора» и «процедура утверждения кредита». Любое самостоятельное применение GenAI в отдельном отделе быстро приводило к типичному набору рисков:

  • Shadow IT. Сотрудники используют непроверенные AI-инструменты и агентов мимо службы безопасности — слепые зоны по данным и комплаенсу.
  • Перегрузка IT. Каждый новый пилот превращается в отдельный ad-hoc проект с собственными интеграциями и аудитом.
  • Agent sprawl. Бесконтрольное размножение агентов с несогласованными промптами и противоречащими ответами.
  • Непредсказуемые расходы. Траты на токены/инференс без лимитов, бюджетирования и прогноза.

Знакомо любому CISO и CIO, который уже видел 15 параллельных пилотов в разных отделах. Проблема номер один для российского enterprise абсолютно такая же — с поправкой на регуляторику ИИ в РФ и требование не выпускать данные за периметр.

Что именно построили

Ключевая идея: не давать подразделениям «что-то своё» — поставить единую управляющую прослойку над любой моделью и любым провайдером. В кейсе NLB эта прослойка называется AGate (разработка Adastra), но архитектурно это то же самое, что оркестратор + governance-слой в мультиагентной системе.

Контролируемая автономия агентов

Каждый агент работает в чётко очерченных границах, привязанных к чувствительному банковскому процессу: AML-проверки, предварительная обработка кредитных заявок, извлечение фактов для комплаенса, поддержка решений сотрудников. Оркестратор не даёт агенту выйти за рамки своей роли и вызвать действие, которое не согласовано политикой.

Идентификация и утверждения

Всё привязано к Entra ID: кто создал агента, кто утвердил перед продакшном, кто его вызвал. Это решает не только комплаенс («покажите журналы»), но и вполне операционный вопрос: когда агент что-то натворил, видно, кто и почему подписал релиз.

Видимость расходов и наблюдаемость

Использование, запросы, токены, расходы — всё через админ-портал и Grafana. На каждого агента можно повесить rate limit и spend cap. Это то, чего почти никогда нет в «пилотах от подрядчика» — и что обязательно всплывает на третьем месяце после запуска, когда финансы спрашивают, почему инференс стоит в 4 раза дороже плана.

Разделённые среды

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

Vendor-agnostic архитектура

Поддержка Azure и AWS, без жёсткой привязки к одному поставщику моделей. Для российского enterprise это интересно в зеркальном виде: нужна архитектура, которая одинаково держит облачные LLM (там, где это допустимо) и открытые модели Qwen/Llama/DeepSeek on-premise в собственном ЦОДе — с возможностью переключаться между ними под конкретный кейс.

Итог за 5 месяцев

За 5 месяцев NLB вывел в продакшн и саму платформу, и первый бизнес-кейс. Дальше — масштабирование по подразделениям: те же политики, тот же путь утверждения, тот же набор гардов. Отсюда и «−80% к стоимости внедрения» — это не про волшебную экономию на токенах, а про то, что на десятый внедрённый use case уже не нужно проходить заново путь архитектуры, безопасности, аудита и интеграций.

«Платформа даёт безопасность, масштаб и скорость. Наши команды могут внедрять агентов без shadow IT, без рисков безопасности и без непредсказуемых расходов» — Dejan Pust, CIO NLB.

Что из этого полезно российскому банку и enterprise

Формально кейс словенский, и NLB опирается на гибридную архитектуру с облачными компонентами. В российских реалиях логика должна быть более жёсткой: данные клиентов и документы не должны покидать периметр по умолчанию, это требование и регуляторики, и самой бизнес-модели банка. Тем не менее, пять уроков из кейса универсальны:

  • Не начинайте с отдельных AI-пилотов — начинайте с платформы. Иначе на 5–6 пилоте вы получите инфраструктурный хаос, а не ROI.
  • Governance — это первый use case, а не последний. Роли, утверждения, журналы, разделение сред и бюджеты — это не «обвязка», это и есть продукт.
  • Spend caps и rate limits — сразу. Без них любой сценарий с агентами превращается в открытый счёт в облаке.
  • Единый путь «идея → продакшн» окупается быстро. Экономия в разы появляется не на первом, а на третьем–пятом use case — когда всё уже по шаблону.
  • Выбирайте vendor-agnostic архитектуру. Сегодня актуальна одна модель, через полгода — другая. Стек должен это переживать без переписывания.

У нас в Нексус-Тех эти принципы «вшиты» в платформу: платформа ставится 100% on-premise, governance и разделение ролей — не «опция», а обязательная часть развёртывания, модели можно менять (Qwen, DeepSeek, Llama, российские), а интеграции с 1С, ЭДО, Bitrix24, Честным Знаком собраны по стандарту. Как это выглядит в проекте и какие сроки реальны — разбирали в материале «Внедрение мультиагентного ИИ за 1–2 месяца».

Итого

Кейс NLB — свежий и «канонический» пример того, как крупный регулируемый банк внедрил агентную ИИ-платформу не как набор экспериментов, а как управляемый корпоративный продукт. Для российского enterprise он полезен не цифрами «−80%» (их всегда нужно перепроверять на своём контуре), а структурой решения: платформа → governance → контролируемые агенты → предсказуемые косты → масштабирование по отделам.

Если смотрите в ту же сторону — посмотрите решения и подход к безопасности, либо оставьте заявку на пилот ниже. Сделаем разбор ваших процессов и предложим конкретную архитектуру под вашу отрасль.

Источник: Adastra Success Story — «NLB Scales AI Agents with Enterprise Agentic AI Platform», 17 марта 2026. Дополнительно — сайт банка: nlbgroup.com. Материал — аналитический пересказ публичного кейса.